Os padrões da Internet exigem DNS reverso para todos os dispositivos?

Os requisitos em torno do DNS reverso são confusos! As pessoas frequentemente falam sobre tudo que está quebrando se o DNS reverso não estiver presente, e isso parece assustador. Mesmo nos casos em que os aplicativos não exigem DNS reverso, as RFCs são frequentemente citadas como suporte à criação obrigatória de registros PTR.

Alguns desses RFCs incluem:

RFC1912 : Erros operacionais e de configuração comuns do DNS

Todo host acessível pela Internet deve ter um nome. ... Verifique se os registros PTR e A correspondem. Para cada endereço IP, deve haver um registro PTR correspondente no domínio in-addr.arpa. Se um host tiver hospedagem múltipla (mais de um endereço IP), verifique se todos os endereços IP possuem um registro PTR correspondente (não apenas o primeiro). A falha em ter registros PTR e A correspondentes pode causar perda de serviços da Internet semelhantes a não serem registrados no DNS.

RFC1033 : GUIA DE OPERAÇÕES DE ADMINISTRADORES DE DOMÍNIO

Adicionando um host.

 To add a new host to your zone files:

    Edit the appropriate zone file for the domain the host is in.

    Add an entry for each address of the host.

    Optionally add CNAME, HINFO, WKS, and MX records.

    Add the reverse IN-ADDR entry for each host address in the
    appropriate zone files for each network the host in on.

Apesar de tudo isso, algumas pessoas ainda insistem em dizer que a criação de registros PTR não é exigida pelos padrões que governam a administração do DNS. Quais são os requisitos reais?

Resposta curta

Os padrões que regem a operação DNS exigem que todos os dispositivos tenham um registro PTR correspondente? Não.

Será que as normas para determinados protocolos exigem PTRregistros que concordam com correspondente Aou AAAAregistros? Sim.

Alguns aplicativos não governados por uma RFC têm os mesmos requisitos? Sim.

Um registro PTR pode apontar para um CNAME? Sim, mas o destino CNAME deve ser o nome exclusivo do dispositivo em questão (e não outro CNAME). ( RFC 2181§10.2 , RFC1034 §3.6.2 )

A criação obrigatória de registros PTR é uma prática recomendada? Geralmente se acredita que sim, mas tem seus próprios problemas.

Resposta longa

Essas perguntas e respostas são fornecidas com a intenção de ajudar a resolver um mal-entendido comum.

Uma seção tragicamente não citada do RFC1796 se aplica aqui:

É um equívoco lamentavelmente bem difundido que a publicação como uma RFC forneça algum nível de reconhecimento. Não, ou pelo menos não mais do que a publicação em uma revista regular. De fato, cada RFC tem um status, relativo à sua relação com o processo de padronização da Internet: faixa informativa, experimental ou de padrões (padrão proposto, esboço de padrão, padrão da Internet) ou histórico.

RFC1912 é informativo. O RFC1033 não está claramente rotulado e tem uma designação oficial de UNKNOWN , o que significa que é tão antigo que não deve ser considerado uma referência para nada . Eles não definem padrões nem podem ser usados ​​para aumentar oficialmente um padrão. Eles nunca devem ser citados no contexto que implica que eles estão definindo um padrão.

Pense nas sugestões informativas da RFC como um bom conselho e as melhores práticas comumente aceitas. As recomendações do DNS reverso fazem sentido à primeira vista: seguir estas diretrizes diminui o risco de ser colocado em situações em que um aplicativo falha no trabalho porque o DNS reverso era necessário e não planejado. Você certamente não pode esperar que um administrador de DNS conheça todos os aplicativos / protocolos que o exijam e, infelizmente, o mesmo tende a acontecer com os proprietários do serviço que solicitam esses registros.

Dito isto, fora da automação muito boa , as políticas obrigatórias de criação de registros PTR também criam poluição.

• É extremamente comum que os PTRregistros não sejam mantidos em sincronia com seus correspondentes A/ AAAAregistros à medida que os dispositivos são desativados, resultando em um rastreamento de PTRdados falsos ao longo do tempo. Esses dados servem apenas para enganar aqueles que tentam tratar essas informações como credíveis. Alguns proprietários de aplicativos estão ansiosos para pular nele quando estão procurando a causa de um problema fantasma. O problema continuará piorando à medida que a adoção do IPv6 se tornar mais comum, principalmente para os administradores de DNS responsáveis ​​pelo espaço IP do tamanho da operadora.
• Ter vários registros PTR para o mesmo endereço IP é bastante inútil, e seguir os conselhos dos RFCs informativos resultará inevitavelmente nisso. Consulte: Por que vários registros PTR no DNS não são recomendados?

O que é pior: ausência de um registro PTR ou um registro PTR impreciso? Se um protocolo for interrompido porque seu padrão requer DNS válido, ambos são ruins e o último pode realmente ser pior . Fora isso, todo mundo tem uma opinião diferente sobre o assunto. Tudo bem: você é livre para montar as políticas e ferramentas que funcionam melhor para sua equipe e empresa. Apenas certifique-se de que eles escalem e produzam resultados consistentes e lembre-se de que o DNS reverso será tão preciso quanto o tempo e a disciplina que os membros da sua equipe precisam.

Mas a falta de registros PTR causa a interrupção do sshd!

Também não é verdade. As pessoas geralmente confundem a linha entre a ausência de um registro PTR (NXDOMAIN) e o DNS reverso quebrado .

Uma resposta de NXDOMAINapenas causará um problema se você estiver se comunicando com um serviço que requer DNS reverso confirmado por encaminhamento (FCrDNS). Servidores de correio, Kerberos, Oracle verificam VIPs, etc.

O DNS reverso quebrado é quando é impossível obter uma NXDOMAINresposta em tempo hábil. Muitos aplicativos (mais famosos sshd) bloquearão a pesquisa reversa do DNS se houver problemas em obter uma resposta das fontes upstream em tempo hábil, causando atrasos no aplicativo.