Réponse courte
Les normes régissant le fonctionnement DNS exigent-elles que tous les appareils aient un enregistrement PTR correspondant? Non.
Est - ce que les normes de certains protocoles exigent des PTR
documents qui sont d' accord avec correspondants A
ou AAAA
dossiers? Oui.
Certaines applications non régies par un RFC ont-elles les mêmes exigences? Oui.
Un enregistrement PTR peut-il pointer sur un CNAME? Oui, mais la cible CNAME doit être le nom unique du périphérique en question (et non un autre CNAME). ( RFC 2181§10.2 , RFC1034 §3.6.2 )
La création d'enregistrements PTR obligatoires est-elle une meilleure pratique? On le croit généralement, mais il a ses propres problèmes.
Longue réponse
Ce Q&R est fourni dans le but d'aider à mettre fin à un malentendu commun.
Une section tragiquement sous-citée de la RFC1796 s'applique ici:
C'est une idée fausse bien répandue que la publication en tant que RFC offre un certain niveau de reconnaissance. Ce n'est pas, ou du moins pas plus que la publication dans une revue régulière. En fait, chaque RFC a un statut, par rapport à sa relation avec le processus de normalisation Internet: Informationnel, Expérimental ou Standards Track (Proposition de Norme, Projet de Norme, Norme Internet), ou Historique.
RFC1912 est informatif. La RFC1033 n'est pas clairement étiquetée et porte la désignation officielle INCONNU , ce qui signifie qu'elle est si ancienne qu'elle ne devrait être considérée comme une référence pour rien . Ils ne définissent pas de normes et ne peuvent pas être utilisés pour augmenter officiellement une norme. Ils ne doivent jamais être cités dans le contexte qui implique qu'ils définissent une norme.
Considérez les suggestions RFC informationnelles comme de bons conseils et les meilleures pratiques communément acceptées. Les recommandations du DNS inversé ont un sens en un coup d'œil: suivre ces directives réduit le risque d'être placé dans des situations où une application ne fonctionne pas car le DNS inversé était nécessaire et non prévu. Vous ne pouvez certainement pas vous attendre à ce qu'un administrateur DNS connaisse chaque application / protocole qui en a besoin, et malheureusement, la même chose a tendance à être vraie pour les propriétaires de services qui demandent ces enregistrements.
Cela dit, en dehors d'une très bonne automatisation , les politiques obligatoires de création d'enregistrements PTR créent également de la pollution.
- Il est extrêmement courant que les
PTR
enregistrements ne soient pas synchronisés avec leurs enregistrements A
/ correspondants AAAA
, car les appareils sont mis hors service, ce qui entraîne un fluage de PTR
données fausses au fil du temps. Ces données ne servent qu'à tromper ceux qui tentent de traiter ces informations comme crédibles. Certains propriétaires d'applications sont impatients de sauter dessus lorsqu'ils recherchent la cause d'un problème fantôme. Le problème ne fera que s'aggraver à mesure que l'adoption d'IPv6 devient plus courante, en particulier pour les administrateurs DNS responsables de l'espace IP de taille opérateur.
- Avoir plusieurs enregistrements PTR pour la même adresse IP est assez inutile, et suivre les conseils des RFC informatifs entraînera inévitablement cela. Voir: Pourquoi plusieurs enregistrements PTR dans DNS ne sont pas recommandés?
Pire: absence d'enregistrement PTR ou enregistrement PTR inexact? Si un protocole casse parce que sa norme requiert un DNS valide, les deux sont mauvais et ce dernier pourrait en fait être pire . En dehors de cela, tout le monde a une opinion différente sur la question. C'est très bien: vous êtes libre de mettre en place les politiques et les outils qui fonctionnent le mieux pour votre équipe et votre entreprise. Assurez-vous simplement qu'ils évoluent et produisent des résultats cohérents, et rappelez-vous que le DNS inversé ne sera aussi précis que le temps et la discipline que les membres de votre équipe doivent lui donner.
Mais les enregistrements PTR manquants provoquent le blocage de sshd!
Ce n'est pas vrai non plus. Les gens confondent souvent la ligne entre l'absence d'un enregistrement PTR (NXDOMAIN) et un DNS inversé cassé .
Une réponse de NXDOMAIN
ne causera un problème que si vous communiquez avec un service qui requiert un DNS inversé confirmé (FCrDNS). Serveurs de messagerie, Kerberos, VIP d'analyse Oracle, etc.
Un DNS inversé cassé, c'est quand il est impossible pour vous d'obtenir une NXDOMAIN
réponse en temps opportun. De nombreuses applications (le plus célèbre sshd
) bloqueront la recherche DNS inversée s'il y a des problèmes pour obtenir une réponse à partir de sources en amont en temps opportun, entraînant des retards dans l'application.
sshd
réponse peut être évité lentement en mettantUseDNS no
ensshd_config
. (Mais même si vous pouvez contourner le problème, il n'est bien sûr toujours pas acceptable, si le DNS inverse