Consistência entre hostname, FQDN e DNS reverso: por que as verificações de nome do Kerberos e do TLS falham quando divergem

Objetivo

Confirmar que o hostname configurado de uma máquina, o registro DNS direto e o registro reverso (PTR) coincidem, antes de tratar uma falha de Kerberos ou TLS como se fosse um problema de credenciais ou de certificado.

Pré-requisitos

Acesso de leitura a /etc/hosts e ferramentas de resolução DNS no Linux; Resolve-DnsName (ou nslookup) no Windows. Nenhum dos dois casos exige privilégios elevados.

Passos

1. No Linux, obtenha o nome totalmente qualificado que a própria máquina considera seu: hostname -f (ou hostname --fqdn). A página de manual define esse FQDN como o nome canônico que o resolvedor retorna para o nome do host; assim, com hosts: files dns, quem decide é uma linha do /etc/hosts, não o DNS. Se o comando falhar ou retornar apenas um nome curto, sem domínio, a resolução DNS do próprio nome da máquina já está inconsistente.
2. Verifique se o /etc/hosts tem uma entrada que se sobrepõe ao DNS: o formato do arquivo, documentado em hosts(5), associa um endereço IP a um ou mais nomes em cada linha. Uma entrada para o nome da própria máquina é consultada antes do DNS (conforme a ordem definida em nsswitch.conf) e pode divergir silenciosamente do que o DNS informa.
3. Resolva o nome nos dois sentidos, de forma independente, e compare: a consulta direta do FQDN deve retornar o IP da máquina, e a consulta reversa (PTR) desse IP deve retornar o mesmo FQDN. No Windows, use Resolve-DnsName <fqdn> para o sentido direto e Resolve-DnsName <ip> -Type PTR para o reverso; a documentação de referência da Microsoft menciona explicitamente o tipo de consulta PTR.
4. Para uma máquina integrada a um domínio Kerberos ou que atua como cliente Kerberos, observe que a orientação do MIT sobre a configuração de realms discute o uso de DNS para descobrir o realm e o KDC. Se os nomes direto e reverso divergirem, a canonicalização do nome do serviço durante a solicitação de tickets pode resultar em um nome diferente do SPN registrado para o serviço, e o ticket será pedido para o SPN errado (ou para nenhum). No krb5.conf do MIT, rdns (padrão: true) adiciona uma consulta reversa a essa canonicalização; rdns = false ou dns_canonicalize_hostname = false elimina a dependência do PTR.
5. No caso do TLS, o cliente que verifica os Subject Alternative Names de um certificado compara com o nome que usou para se conectar, e não com um hostname "verdadeiro". Se o DNS direto e o reverso divergirem, ferramentas diferentes na mesma cadeia (por exemplo, uma que resolve no sentido direto e outra que depende de uma consulta reversa para log ou controle de acesso) podem acabar esperando nomes diferentes.

Resultado esperado

hostname -f retorna o mesmo nome com domínio que uma consulta DNS direta da máquina, e a consulta reversa do IP da máquina retorna esse mesmo nome: os três coincidem. Uma conexão a um serviço Kerberos e uma conexão TLS à máquina são bem-sucedidas, sem erros relacionados a nomes.

Limites e base de verificação

Máquinas com várias interfaces de rede ou IPs (multi-homed) podem ter, legitimamente, um registro PTR que não corresponde ao endereço usado pelo cliente para chegar até elas; antes de "corrigir" o DNS, trate isso como uma questão de projeto, e não automaticamente como um bug. Alterações no /etc/hosts ou nos registros DNS valem para novas resoluções assim que qualquer cache local (nscd, systemd-resolved, SSSD, o cliente DNS do Windows) e o TTL do registro permitirem, mas não afetam tickets ou conexões já em cache: um ticket Kerberos ou uma sessão TLS obtidos antes da correção precisam ser obtidos novamente.