lalahop

DNS : glue records, net/com/org et error 2003

Aujourd'hui, je vais vous parler des glue records et notamment des cas où il faut les utiliser alors que ça ne correspond pas à la définition première que l'on se fait d'un glue record.

Je trouve que c'est assez peu documenté et très peu connu. J'ai découvert ça très récemment, alors que je configurais les serveurs de noms qui font autorité sur arn-fai.net (appartenant à ARN, FAI associatif alsacien). Je n'avais jamais eu un nom de domaine sous un TLD concerné par cette exception ni utilisé un autre secondaire pour faire autorité sur mes zones que celui proposé par mon bureau d'enregistrement, ceci explique peut-être cela.

Pour aborder sereinement ce billet, il faut avoir une petite idée du processus de résolution d'un nom par le DNS ainsi de ce qu'est un glue record (en fin de section) quand on cause de noms de domaine et de comment ça se mange.

Vous avez un nom de domaine sous les TLD net, com ou org. Vous voulez qu'un deuxième serveur fasse autorité sur votre zone. Le nom de ce serveur est aussi sous com, net ou org. Alors, vous devez déclarer un (ou plusieurs) glue record pour ce deuxième serveur via le bureau d'enregistrement via lequel le deuxième nom de domaine a été obtenu.

Si vous ne le faites pas, le registre (Verisign pour com/net, Afilias pour la gestion technique de org) vous retournera l'erreur « error : 2003 required parameter missing » lors de la déclaration des nouveaux serveurs faisant autorité sur l'interface web de votre bureau d'enregistrement.

Quelques exemples concrets :

  • On veut que la machine désignée par le nom alsace.tetaneutral.net. soit le deuxième serveur qui fait autorité sur arn-fai.net. Il faut donc que Tetaneutral.net ajoute des glue records (A/AAAA) pour alsace.tetaneutral.net. via son bureau d'enregistrement (Gandi).
  • On veut que les machines désignées par les noms (ns0|ns1).fdn.org soient les serveurs qui font autorité sur ffdn.org. Il faudra donc que FDN ajoute des glue records pour les noms (ns0|ns1).fdn.org.
  • Un enregistrement associant une IPv4 au nom ns6.gandi.net. (type A) est déclaré dans la zone net. C'est un glue record et il permet aux clients de Gandi qui achètent un nom de domaine dans net/com/org de déclarer la machine pointée comme étant un serveur faisant autorité sur leur domaine.

On peut trouver une autre illustration concrète ici : Soit disant glue records - Gandi.net Groups.

Vous allez me dire : « cet usage des glue records est un usage dérivé de la définition puisqu'un glue record sert normalement à casser une référence circulaire comme « A ns0.arn-fai.net ? » -> « je sais pas, demande à ns0.arn-fai.net qui fait autorité sur arn-fai.net ». Oui, on peut voir ça comme un usage dérivé dans le sens où on ne s'en sert pas pour casser une référence circulaire mais ça reste le même principe de fonctionnement fondamental : faire remonter une information dans la zone parente. Une information qui sera, de ce fait, hors zone.

Le seul intérêt que je vois à cette manipulation, c'est que cela permet de réduire la charge sur les serveurs qui font autorité sur net/com/org. Cela évite un échange supplémentaire. J'imagine que cela procurait un bénéfice vu les caractéristiques (latence surtout) des réseaux de l'époque bien que je ne comprends pas pourquoi certains TLD créés à l'époque (exemple : fr) ont fait un choix technique différent ...

Pour illustrer le gain d'un glue record dans le cas qui nous intéresse, imaginons un dialogue approximatif entre un récursif-cache et les serveurs qui font autorité sur net/com (ça serait pareil pour org).

D'abord, sans glue record (évidemment, on suppose qu'on a vidé le cache du récursif-cache pour les noms concernés ...) :

  • A xxx.arn-fai.net. ?
  • je ne sais pas, va voir ns0.arn-fai.net. qui a telle IP et alsace.tetaneutral.net.. Ils font autorité sur arn-fai.net.
  • ...
  • (ici, ns0.arn-fai.net ne répond pas/pas assez vite ou le récursif-cache veut mettre en cache alsace.tetaneutral.net pour plus tard au cas où, donc le récursif-cache veut interroger alsace.tetaneutral.net) : « A alsace.tetaneutral.net. ? »
  • « je ne sais pas, va voir ns0.tetaneutral.net. qui a telle IP et qui aura la réponse car il fait autorité sur tetaneutral.net. »
  • ...

Maintenant, avec un glue record (évidemment, on suppose qu'on a vidé le cache du récursif-cache pour les noms concernés ...) :

  • A xxx.arn-fai.net. ?
  • je ne sais pas, va voir ns0.arn-fai.net. qui a telle IP et alsace.tetaneutral.net. qui a telle autre IP. Ils auront la réponse car ils font autorité sur arn-fai.net.
  • ...

Notons que cela concerne uniquement les noms de domaine qui se trouvent sous un TLD dont le registre est (ou fut) Verisign. Donc net, com et org. Le registre de org est, aujourd'hui, Public Interest Registry (avec une sous-traitance à Afilias pour la partie technique) mais fut un temps, Verisign était bien le registre de org. Pour les autres TLD, il n'est pas nécessaire d'ajouter un glue record. Par exemple, je peux très bien dire :

  • un des serveurs qui fait autorité sur mazone.fr, c'est ns0.monautrezone.fr.
  • un des serveurs qui fait autorité sur mazone.info, c'est bidule.monautrezone.info.
  • ...

De quand date ce principe de fonctionnement ? De l'époque (année 2000) où Verisign a acheté Network Solutions ? De l'époque "purement" Network Solutions (1991-2000) ? De quelques années auparavant ? Je n'en ai aucune idée mais ça m'intéresse. 😉

Vous allez me dire « non mais pourquoi s'embêter avec ton histoire de glue records ... regardes, pour alsace.tetaneutral.net par exemple, il suffit de créer un enregistrement « arn-fai.net. NS vmttnn.arn-fai.net. », d'ajouter les bons enregistrements de types A/AAAA pour le nom vmttnn.arn-fai.net ainsi que d'ajouter les glue records pour ce nom et on peut très bien déclarer vmttn.arn-fai.net comme étant un serveur qui fait autorité sur arn-fai.net. ». Oui, ça marche aussi et c'est parfaitement valide.

Mais si Tetaneutral.net décide de renuméroter tout ou partie de son réseau, ARN doit être informé et modifier les valeurs des enregistrements vmttnn.arn-fai.net de types A/AAAA ainsi que les valeurs des glue records. Avec les glue records du côté de Tetaneutral.net (alsace.tetaneutral.net.), ARN n'a rien à faire. Si, à cet instant, vous avez pensé à déclarer vmttnn.arn-fai.net. comme un alias (CNAME) vers alsace.tetaneutral.net., vous avez perdu : on ne doit pas mettre un alias en valeur d'un enregistrement de type MX ou NS. C'est indiqué dans la section 10.3 du RFC 2181.

Comment voir un glue record ? C'est une information additionnelle, qui sera envoyée, par un serveur qui fait autorité, uniquement en complément d'une réponse contenant une délégation. Dans ce cas, le serveur qui fait autorité ajoutera le ou les enregistrements "glue" dans la section « additional » de sa réponse.

Exemple : l'enregistrement alsace.tetaneutral.net. de type A sera envoyé, par les serveurs qui font autorité sur net, uniquement en complément d'une réponse contenant un enregistrement NS avec la valeur alsace.tetaneutral.net. Dans notre cas, la seule question susceptible de générer cette réponse est « NS arn-fai.net. ? ». Donc la commande suivante permet de voir les glue records dans la section additionnelle : « dig @a.gtld-servers.net. NS arn-fai.net. ».

Évidemment, si alsace.tetaneutral.net est aussi déclaré comme serveur public[1] faisant autorité sur d'autres domaines, une requête « dig @a.gtld-servers.net. NS domaine.exemple. » affichera tout aussi bien les enregistrements dits "glue".

J'espère avoir réussi à documenter quelques points obscurs en étant clair et accessible.

[1] Oui, on n'est pas obligé de déclarer tous les serveurs faisant autorité sur un domaine dans des enregistrements de type NS. Cela sert notamment pour mettre en place un master "caché" (fin de section) pour, par exemple, signer hors-ligne une zone (DNSSEC) ou pour réserver des slaves qui seront seulement interrogés par les machines internes à l'organisation (association, entreprise, ...) qui possède le nom de domaine (voir : Conférence Mail/DNS à partir de 1h25m50).