Le DNS, ça colle ou ça ne colle pas ?

Présentation

Cet article vise avant tout les personnes qui choisissent les serveurs de noms de leurs domaines. C’est sans doute une minorité, la plupart des titulaires délèguent ce choix à leur BE (Bureau d’Enregistrement) ou à un hébergeur DNS qu’ils ont choisi. Mais si vous êtes responsable du choix des serveurs faisant autorité pour un domaine, cet article pourra vous intéresser.

Pour comprendre la colle, il faut comprendre comment fonctionne le DNS. Avez-vous vu notre belle illustration ci-dessous sur ce sujet ?

Un résolveur DNS qui cherche des informations sur le nom de domaine, mettons www.saintdenis.re, va d’abord interroger les serveurs de noms faisant autorité pour la racine, puis ceux faisant autorité pour .re (gérés par l’Afnic) puis ceux de l’hébergeur DNS Oléane, qui gère actuellement le domaine saintdenis.re. Il y a donc deux délégations successives, de la racine vers .re, puis de l’Afnic vers Oléane. La délégation fonctionne en indiquant les serveurs de noms faisant autorité pour le domaine « fils », celui situé « en dessous » du domaine qui délègue. J’insiste sur ce point : la délégation se fait par des noms et non pas par des adresses IP.

Avec la commande « dig », on peut voir ce que le serveur de l’Afnic répond lorsque le résolveur lui demande l’adresse IP de www.saintdenis.re¹ :

% dig @d.nic.fr www.saintdenis.re A
…
;; AUTHORITY SECTION:
saintdenis.re.		3600 IN	NS ns6.oleane.net.
saintdenis.re.		3600 IN	NS ns7.oleane.net.

Le serveur d.nic.fr a donc répondu, en substance, à son client, le résolveur « je ne sais pas, mais demande à ns6.oleane.net ou ns7.oleane.net ». C’est la délégation.

Bon, c’est très bien, mais le résolveur, s’il veut continuer sa quête, va devoir interroger ces deux serveurs d’Oléane et, pour cela, il a besoin de leurs adresses IP. Pas de problème, il mettra en attente la requête principale, celle pour www.saintdenis.re, et fera une nouvelle requête, pour ns6.oleane.net. Celle-ci passera par la racine² puis par Verisign (qui gère .net). Une fois que le résolveur aura les adresses IP de ces serveurs, il pourra leur demander les informations concernant www.saintdenis.re.

Mais, ici, les serveurs³ de www.saintdenis.re étaient en dehors du domaine (et même en dehors du TLD, Top-Level Domain). Mais imaginons qu’on veuille envoyer un courrier à quelqu’un @inra.fr. Le résolveur doit demander les noms des serveurs de courrier de ce domaine et, pour cela, passer par le processus de résolution DNS. Quand il demandera à l’Afnic, registre du .fr :

% dig @d.nic.fr inra.fr MX
…
;; AUTHORITY SECTION:
inra.fr.		3600 IN	NS ns3.inra.fr.
inra.fr.		3600 IN	NS ns2.inra.fr.
inra.fr.		3600 IN	NS ns1.inra.fr.

Il y aura un problème d’œuf et de poule : pour obtenir les adresses des serveurs comme ns1.inra.fr, il faudra demander aux serveurs de noms faisant autorité pour inra.fr mais pour cela, il faut leurs adresses IP et, pour obtenir ces adresses, il faut leur demander… La colle est justement la solution qui permet de résoudre ce cercle vicieux. La colle (glue en anglais), ce sont des enregistrements supplémentaires retournés par le serveur du domaine « parent ». La réponse complète était en fait :

% dig @d.nic.fr inra.fr MX
…
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4
…
;; AUTHORITY SECTION:
inra.fr.		3600 IN	NS ns3.inra.fr.
inra.fr.		3600 IN	NS ns2.inra.fr.
inra.fr.		3600 IN	NS ns1.inra.fr.

;; ADDITIONAL SECTION:
ns3.inra.fr.		3600 IN	A 147.99.111.234
ns2.inra.fr.		3600 IN	A 147.100.222.2
ns1.inra.fr.		3600 IN	A 138.102.119.26
…

Le client DNS, le résolveur, a désormais toute l’information qu’il lui faut pour faire la résolution DNS. Ces trois derniers enregistrements de type A (adresse IP à l’ancien format), dans la section Additionnelle de la réponse, sont la colle. La colle était absente de la réponse pour www.saintdenis.re car les serveurs de noms n’étaient pas dans la zone servie, la colle n’était donc pas nécessaire.

Au passage, comme le DNS a subi de nombreux changements depuis sa création, il est difficile de suivre toutes les normes techniques qui le décrivent. Je recommande de passer par la norme dite BCP 219, qui spécifie rigoureusement la terminologie du DNS. (Sa section 7 définit les « glue records », les enregistrements DNS qui forment la colle.)

Gérer la colle

Bon, mais pour que les serveurs faisant autorité pour .fr renvoient au client DNS la colle, il faut qu’ils la connaissent, donc que cette colle se retrouve dans la base de données du registre de .fr. Cette base est remplie par les BE (Bureaux d’Enregistrement), via le protocole EPP (Extensible Provisioning Protocol). Il faut donc que le BE ait envoyé ces informations sur la colle. Et voici pourquoi, si vous choisissez vous-même votre hébergeur DNS, au lieu de prendre le choix proposé par défaut par votre BE, et si les serveurs DNS que vous indiquez sont dans le domaine qu’ils vont servir, vous devrez indiquer leurs adresses IP.

Si vous aimez plonger dans les détails du protocole, la transmission de ces colles en EPP se fait en suivant la norme du RFC 5732, qui normalise la classe « host » des objets manipulés par EPP.

Indiquer cette colle est donc un travail supplémentaire pour le ou la titulaire de nom de domaine, qui veut utiliser les serveurs faisant autorité de son choix. Mais il y a plus gênant : la mise à jour dans le temps. En effet, les adresses IP des serveurs faisant autorité peuvent changer. Et il faut désormais penser à les modifier, non seulement dans sa base locale, mais également auprès du registre, par l’intermédiaire du BE. L’expérience prouve que cette étape est souvent oubliée. Quelles sont les conséquences ? Si la colle connue du domaine « parent » est invalide, parce qu’elle correspond à une ancienne adresse IP qui n’est plus la bonne, le domaine perd un, voire plusieurs serveurs de noms puisqu’ils ne pourront plus être contactés⁴. Pire, si l’ancienne adresse IP est désormais attribuée à quelqu’un d’autre, celui-ci pourra détourner une partie du trafic. Il est donc important de gérer la colle avec rigueur.

Dans le domaine ou pas dans le domaine ?

On l’a vu, la colle n’est pas obligatoire⁵ si le serveur de noms faisant autorité n’est pas dans le domaine qu’il sert (l’exemple de saintdenis.re plus haut). Compte tenu du travail et des responsabilités supplémentaires que représente la colle, faut-il mettre ses serveurs de noms dans le domaine servi ? La réponse n’est pas simple car chaque méthode a ses avantages et ses inconvénients. Avoir les serveurs en dehors du domaine fait qu’on n’a pas à indiquer et à maintenir la colle. Avoir les serveurs dans le domaine permet de ne pas dépendre de domaines extérieurs, qu’on ne contrôle peut-être pas. C’est pour cela que l’ANSSI recommande de « privilégier les délégations avec colle lorsque l’usage de délégation sans colle introduit de nouvelles dépendances tierces ». Mais, dans ce cas, faites bien attention à maintenir une colle exacte, lorsqu’un serveur faisant autorité change d’adresse IP.

Notez que pour voir ces dépendances d’un domaine, vous pouvez utiliser l’outil NS Tree.

Enfin, sachez qu’il peut exister des cas plus complexes, comme celui d’un domaine A dont tous les serveurs de noms seraient dans le domaine B qui lui-même aurait tous ses serveurs de noms dans le domaine A, créant ainsi une boucle dont il serait impossible de sortir. Quand vous choisissez des serveurs de noms, prenez le temps d’examiner la question.

Peut-être un jour…

Nous l’avons vu, la colle permet de fournir l’adresse IP d’un serveur de noms de façon à ce que le nom de domaine puisse être résolu dans le cas où ce dernier utilise des serveurs de noms hébergés sous ce même domaine.

L’IETF (Internet Engineering Task Force) a un projet, DELEG, de changement radical de la délégation du DNS (cf. mon article « La délégation DNS et sa possible évolution avec DELEG ») . S’il aboutit (mais c’est un projet complexe, et à long terme), le concept de colle sera profondément changé, rendant cet article obsolète.