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 PTR
registros que concordam com correspondente A
ou AAAA
registros? 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
PTR
registros não sejam mantidos em sincronia com seus correspondentes A
/ AAAA
registros à medida que os dispositivos são desativados, resultando em um rastreamento de PTR
dados 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 NXDOMAIN
apenas 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 NXDOMAIN
resposta 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.
sshd
responder lentamente pode ser evitado, colocandoUseDNS no
emsshd_config
. (Mas mesmo que você pode contornar o problema é, naturalmente, ainda não é aceitável, se os tempos de DNS reverso fora ou produzir uma resposta falha do servidor.)