Pourquoi plusieurs enregistrements PTR dans DNS ne sont pas recommandés?
I souventlire que l'utilisation de plusieurs enregistrements PTR dans une configuration DNS n'est pas recommandée.
Cependant, les raisons sont souvent vagues ou moins évidentes:
- "cela peut causer des problèmes",
- "peut déclencher des bugs dans les programmes qui attendent une réponse unique": c'est le problème du logiciel alors, non?!
- "peut rendre le paquet de réponse DNS trop volumineux": n'est-ce pas résolu avec EDNS ?
Ces bonnes raisons? Connaissez-vous d'autres (bonnes) raisons? Tout cela ressemble un peu à une "peur héritée" ...
L'enregistrement PTR pour un nom inversé (par exemple 7.2.0.192.in-addr.arpa) devrait identifier le nom canonique associé à cette adresse IP.
Les pointeurs de passerelle sur les nœuds de réseau et les pointeurs d'hôte normaux sur les nœuds d'adresse complète utilisent le RR PTR pour pointer vers les noms de domaine principaux des hôtes correspondants.
De: http://tools.ietf.org/html/rfc1035#section-3.5
Cette attente se reflète dans les logiciels qui effectuent des recherches inversées; souvent, un tel logiciel attend spécifiquement un nom unique et il s'attend à pouvoir utiliser ce nom comme nom canonique pour cet hôte. S'il y a plusieurs noms retournés, il est courant d'en prendre un au hasard, car ils n'ont absolument aucun moyen de savoir lequel vous auriez préféré pour cette occasion particulière.
Comme l'attente générale est qu'il y a un nom canonique associé à une adresse IP et que c'est ce nom que le PTR devrait pointer, l'ajout de plusieurs noms n'a généralement aucun avantage (rien ne s'attend à un aléatoire A/AAAA record pour avoir un PTR correspondant) mais il a un inconvénient potentiel car il peut entraîner des résultats étranges car vous n'avez aucun contrôle sur lequel de vos enregistrements PTR sera utilisé si vous en avez ajouté plusieurs.
En substance, si vous avez plusieurs enregistrements PTR, vous ne faites pas apparaître votre hôte plus légitime, mais plutôt le contraire, vous courez le risque d'échouer une validation ou de casser quelque chose.
Comme métaphore peut-être un peu extrême, remettre cinq passeports avec votre photo mais avec des noms différents à l'aéroport ne sera probablement pas reçu aussi bien que si vous en remettez un.
Tout se résume à un comportement imprévisible car la RFC n'impose pas de limite ni de moyen de gérer ces enregistrements PTR. La plupart des implémentations choisissent le round-robin et vous n'atteindrez pas le résultat souhaité (correspondance parfaite entre plusieurs noms et une seule IP).
Vous pouvez en savoir plus à ce sujet ici: https://supernoc.rogerstelecom.net/pdfs/multiple-ptrs.pdf
Vérifiez également ce bogue à partir de la fonction getnameinfo de la Glibc ( https://sourceware.org/bugzilla/show_bug.cgi?id=579 ). Comment pouvez-vous garantir que cela ne se produit pas dans le nombre infini de systèmes différents autour d'Internet (certains d'entre eux sont très anciens et non corrigés)?
Pour renforcer, en règle générale, il est toujours bon d'éviter un comportement non spécifié et imprévisible. Malheureusement, plusieurs enregistrements PTR pour une seule IP entrent dans cette catégorie (en ce qui concerne les RFC).
Comment garantissez-vous qu'un PTR correspondra à un enregistrement avant particulier si vous avez plusieurs PTR?
Ceci est particulièrement important dans les actions du serveur de messagerie, où la plupart des serveurs SMTP de réception entrants vérifieront si le transfert correspond à l'inverse.
Assez difficile, vous avez plusieurs PTR et aucun moyen de garantir quel PTR est sélectionné et qu'il correspond à l'avant que vous avez donné lors de la connexion
Le moyen le plus simple de garantir une correspondance parfaite est d'avoir un PTR qui correspond à une entrée vers l'avant