Les normes Internet nécessitent-elles un DNS inversé pour chaque appareil?

Les exigences entourant le DNS inversé sont déroutantes! Les gens parlent souvent de tout ce qui se casse si le DNS inverse n'est pas présent, et cela semble effrayant. Même dans les cas où les applications ne nécessitent pas de DNS inversé, les RFC sont fréquemment cités à l'appui de la création d'enregistrement PTR obligatoire.

Certains de ces RFC comprennent:

RFC1912 : Erreurs courantes de fonctionnement et de configuration DNS

Chaque hôte accessible sur Internet doit avoir un nom. ... Assurez-vous que vos enregistrements PTR et A correspondent. Pour chaque adresse IP, il devrait y avoir un enregistrement PTR correspondant dans le domaine in-addr.arpa. Si un hôte est multi-hébergé (plus d'une adresse IP), assurez-vous que toutes les adresses IP ont un enregistrement PTR correspondant (et pas seulement le premier). Le fait de ne pas avoir les enregistrements PTR et A correspondants peut entraîner une perte de services Internet similaire à l'absence d'enregistrement du tout dans le DNS.

RFC1033 : GUIDE D'OPÉRATION DES ADMINISTRATEURS DE DOMAINE

Ajout d'un hôte.

 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.

Malgré tout cela, certaines personnes insistent encore pour dire que la création d'enregistrements PTR n'est pas requise par les normes régissant l'administration DNS. Quelles sont les exigences réelles?

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 PTRdocuments qui sont d' accord avec correspondants Aou AAAAdossiers? 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 PTRenregistrements 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 PTRdonné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 NXDOMAINne 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 NXDOMAINré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.