La délégation DNS et sa possible évolution avec DELEG

Rappel administratif et technique

Figure 1 : Arbre (partiel !) des noms de domaine

Les noms de domaine sont gérés de manière décentralisée. Si vous êtes titulaire de wikipedia.org. vous pouvez ajouter ou enlever des sous-domaines comme fr.wikipedia.org, attribuer des valeurs (par exemple une adresse IP) au nom wikipedia.org, le tout sans demander à quiconque : il n’y a pas d’autorité centrale par laquelle passer¹.

Un nom de domaine étant constitué de plusieurs composants qu’on écrit séparés par des points, cette décentralisation se fait en délégant un sous-domaine à une autre entité. Il n’y a pas forcément de délégation sur chaque point ( fr.wikipedia.org et wikipedia.org relèvent de la même autorité, il n’y a pas de délégation) mais, quand il y en a une, elle se fait sur un point².

Ainsi, l’Afnic délègue u-bourgogne.fr à l’Université de Bourgogne qui, a son tour peut décider ou non³ de déléguer iut.u-bourgogne.fr à l’IUT⁴ qui dépend de cette université.

La délégation peut être purement administrative. Ainsi, gouv.fr reste techniquement géré par l’Afnic, comme .fr, mais est administrativement indépendant : le gouvernement français décide seul des noms sous gouv.fr, de leur création ou de leur suppression.

Mais il y a aussi, et surtout, une délégation technique, que permet le DNS (Domain Name System), le protocole informatique qui permet le fonctionnement de ces noms de domaine et les services qu’ils rendent. Elle se matérialise dans le DNS par la création d’enregistrements de type NS (pour NameServer) qui contiennent la liste des serveurs de noms faisant autorité pour le nom délégué. Ainsi,  u-bourgogne.fr est, en juin 2024, délégué à trois serveurs, dns1.u-bourgogne.fr, dns2.u-bourgogne.fr, et ufc.univ-fcomte.fr. Lorsqu’un résolveur DNS (le serveur que votre machine va interroger pour obtenir des informations DNS) veut des données sur u-bourgogne.fr, il va interroger un de ces trois serveurs.

Figure 2 : La résolution DNS, avec le résolveur et les serveurs faisant autorité

C’est ainsi que fonctionne la décentralisation : le titulaire de u-bourgogne.fr (l’université) peut créer, supprimer et modifier à sa guise les noms sous u-bourgogne.fr. Aucune autorisation de l’Afnic ou de quelque autre organisme n’est nécessaire, le registre situé « au-dessus » (.fr) n’est même pas informé.

Un ensemble contigu de noms de domaines qui sont délégués ensemble est appelé une zone⁵. Ainsi, gouv.fr est dans la zone fr mais  u-bourgogne.fr est dans sa propre zone.

Ah, mais comment voit-on qu’il y a délégation technique ou pas ? Le plus simple est de demander les enregistrements de type NS ou SOA (pour Start Of Authority), qui ne peuvent se trouver qu’à l’apex de la zone, le sommet. S’ils sont présents, c’est que ce domaine est délégué. Sinon, c’est qu’il ne l’est pas. Ainsi, on peut voir avec un logiciel client DNS⁶ que gouv.fr n’est pas techniquement délégué mais que museedesconfluences.fr l’est :

% dig gouv.fr SOA

…

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59426

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

…

(Pas d’erreur mais zéro réponse.)

% dig  museedesconfluences.fr SOA

…

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10536

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

…

;; ANSWER SECTION:

museedesconfluences.fr. 10800 IN SOA ns1.gandi.net. hostmaster.gandi.net. (

                        1718236800 ; serial

                        10800      ; refresh (3 hours)

                        3600       ; retry (1 hour)

                        604800     ; expire (1 week)

                        10800      ; minimum (3 hours)

                        )

…

(Une réponse.)

Ses limites

Accrochez-vous, car on va désormais devoir plonger plus profondément dans la technique, pour comprendre les limites de ce mécanisme de délégation technique, et la réforme proposée.

Les enregistrements DNS habituels, par exemple les types AAAA (adresses IP), TXT (texte libre), MX (nom des serveurs de messagerie), le récent HTTPS (noms et caractéristiques des serveurs HTTP⁷), sont situés dans le domaine concerné, ce qui est logique. Mais il y a trois exceptions à cette règle : la première concerne les enregistrements NS (noms des serveurs DNS faisant autorité) dont j’ai parlé plus haut. Ces enregistrements sont à la fois dans le domaine concerné et dans le domaine parent. Et ils doivent être maintenus identiques, ce qui n’est pas toujours le cas. Les résolveurs DNS partent en effet de la racine, puis suivent les enregistrements NS indiqués, pour arriver aux serveurs faisant autorité. Les NS dans le domaine parent sont donc indispensables, mais parfois négligés.

Les enregistrements NS ne donnent que le nom des serveurs. On ne peut pas indiquer leurs caractéristiques, par exemple le numéro de port utilisé (c’est forcément 53) et surtout la possibilité ou non de communication sécurisée par la cryptographie, en utilisant DoT (DNS-sur-TLS⁸). À l’heure de la parution de cet article, très peu de serveurs faisant autorité sont ainsi protégés⁹, en partie parce que le client DNS, le résolveur, ne sait pas à l’avance s’il peut utiliser TLS.

Une autre exception au principe « les enregistrements sont dans le domaine concerné » concerne les enregistrements DS (signature des clés DNSSEC des domaines fils). Ces enregistrements ne sont que dans le domaine parent.

Une troisième et dernière exception à la règle comme quoi les données sur une zone sont dans la zone elle-même concerne la colle. Il s’agit des adresses IP des serveurs de noms, si et seulement si, ils sont dans la zone qu’ils servent. Sa nécessité vient de la manière dont fonctionne la résolution DNS. Le résolveur, lorsqu’il reçoit une délégation, une liste de serveurs de noms, reçoit des noms. Il doit les résoudre en adresses IP pour les contacter. Si ces noms de serveurs faisant autorité sont dans une autre zone, il n’y a pas de problème particulier. Mais s’ils sont dans la zone qu’ils servent, on a un problème d’œuf et de poule ; la délégation de caf.fr implique de pouvoir parler à ns.caf.fr et ns1.caf.fr. Mais pour résoudre ns.caf.fr, il faut passer par les serveurs de caf.fr ! C’est pour casser ce cercle vicieux que, lorsqu’un serveur de noms est dans le domaine qu’il sert, le parent doit également indiquer les adresses IP, ce que l’on nomme la colle. On voit ici la délégation faite par un serveur faisant autorité pour .fr, qui indique la colle à la fin :

% dig @d.nic.fr www.caf.fr

…

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65266

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3

…

;; AUTHORITY SECTION:

caf.fr.                 3600 IN     NS ns.caf.fr.

caf.fr.                 3600 IN     NS ns1.caf.fr.

;; ADDITIONAL SECTION:

ns1.caf.fr.       3600 IN     A 91.231.174.241

ns.caf.fr.        3600 IN     A 91.231.174.240

L’utilisation de serveurs dans la zone servie entraîne des servitudes : en cas de changement des adresses IP de ces serveurs, il faut penser à prévenir la zone parente de changer la colle. En pratique, cette étape est parfois oubliée.

Et au cas où la situation ne soit pas assez complexe, notons que les enregistrements NS et la colle dans la zone parente ne font pas autorité (ce sont des simples copies, en théorie, des informations dans la zone fille), alors que les enregistrements DS, eux, ne sont que dans la zone parente et font autorité.

Le rôle de l’hébergeur DNS

Lorsqu’un nom de domaine est délégué techniquement, on indique au domaine parent les noms des serveurs qui feront autorité pour ce domaine. Ces serveurs sont hébergés chez un ou plusieurs hébergeurs DNS (en anglais, on parle plus souvent de DNS operators.) Ce ou ces hébergeurs peuvent être le BE (Bureau d’Enregistrement), une organisation qui fait de l’hébergement DNS, sans être le BE, ou bien le titulaire lui-même, ce qui est techniquement possible, c’est même plus simple que d’héberger un serveur HTTP. Lorsque cet hébergeur n’est ni le BE, ni le titulaire, il n’a pas de rôle explicite dans les relations Registre – BE – Titulaire. Il ne peut pas, de lui-même, changer la délégation. Ainsi, si un hébergeur DNS avait un jeu de quatre serveurs de noms, et qu’il indiquait à ses clients qu’il fallait donner cette liste au registre, puis qu’il souhaite en ajouter un cinquième, il faudra qu’il communique à tous ses clients la nouvelle liste, et espérer qu’ils feront bien la modification auprès du registre, éventuellement via le BE.

Par exemple, c’est typiquement l’hébergeur DNS qui gère les clés DNSSEC¹⁰. Il serait donc intéressant que ledit hébergeur puisse modifier les enregistrements DS (qui pointent vers les clés DNSSEC) seul, alors qu’actuellement il faut que son client le fasse, en passant par le BE. Si le BE est également l’hébergeur, la situation est simple mais, dans le cas contraire, on ajoute de la communication, de la complexité, et des risques d’erreur.

Le projet DELEG

Ce projet est porté par l’IETF, l’organisation de normalisation présentée plus haut. Il s’agit de résoudre plusieurs problèmes :

• Le fait que l’hébergeur DNS ne soit pas explicitement impliqué, ce qui rend difficile certaines opérations, qui doivent passer par tous les titulaires de noms qui sont clients de l’hébergeur,
• le fait que les enregistrements NS doivent être synchronisés entre le domaine parent et le domaine délégué,
• le fait que les enregistrements NS ne permettent pas d’indiquer les caractéristiques techniques des serveurs de noms, par exemple l’utilisation d’un port réseau¹¹ différent de l’habituel port 53, ou le fait qu’ils acceptent, en plus du DNS en clair, le DNS chiffré, sur TLS, HTTPS¹² ou QUIC¹³.

Le projet DELEG prévoit donc de remplacer les enregistrements NS du domaine parent par des enregistrements DELEG, plus riches. Contrairement aux NS, mais comme les enregistrements DS, ils feront autorité et seront donc signés si on utilise DNSSEC. Je vais donner deux exemples mais rappelez-vous que DELEG n’est qu’un projet en cours, rien n’est encore fermement décidé :

1. On veut déléguer à example.com, qui accepte DoT. Un enregistrement DELEG pourra ressembler à DELEG ns1.example.com ipv4hint=192.0.2.1 ipv6hint=2001:db8::1 alpn=dot, pour indiquer à la fois les adresses IP (la colle) et le fait que DoT fonctionne¹⁴. Il est important de noter que la liste des couples clé=valeur est extensible : ce mécanisme permettra, dans le futur, d’indiquer d’autres choses sur les serveurs de noms.
2. On a un hébergeur DNS séparé, mettons net, et on veut simplement mettre une référence vers leur jeu de serveurs. On mettra alors un alias, DELEG config2.example.net et, en config2.example.net, on trouvera la liste des serveurs, ainsi stockée en un seul endroit, que l’hébergeur DNS pourra facilement changer sans déranger ses clients.

Il est prévu d’utiliser le cadre général des enregistrements SVCB (Service Binding and Parameter Specification), normalisé dans le RFC 9460. Avec la syntaxe des fichiers de zone, celle que produit dig, cela pourrait ressembler à, dans le premier cas :

example.com.  86400  IN DELEG  1 ns1.example.com. (

                   ipv4hint=192.0.2.1 ipv6hint=2001:db8::1 alpn=dot)

Et, dans le second :

example.com.  86400  IN DELEG 0   config2.example.net.

Puis, chez l’hébergeur :

config2.example.net. 3600    IN SVCB 1 . (

                   ipv4hint=192.0.2.54,192.0.2.56

                   ipv6hint=2001:db8:2423::3,2001:db8:2423::4 )

Si ce projet aboutit, on voit qu’il nécessitera de modifier plusieurs logiciels :

• les serveurs faisant autorité, qui devront, lorsqu’on les interroge pour un nom qui est sous un domaine délégué, renvoyer les DELEG et non plus les NS,
• les résolveurs, qui devront suivre des DELEG et non plus des NS pour aller vers les serveurs faisant autorité,
• les interfaces Web et les API qui, chez les BE, permettent d’indiquer les informations de délégation,
• les outils de test et de débogage comme Zonemaster,
• les protocoles EPP¹⁵, pour pouvoir créer et modifier ces enregistrements DELEG, et RDAP¹⁶, pour pouvoir les afficher. Voir un article décrivant le processus d’avitaillement des noms de domaine pour plus de détails.
• Les systèmes d’enregistrement des registres (base de données, serveurs, etc).

On voit qu’il ne s’agit pas d’un petit changement ; cela touche un ensemble important d’outils et d’acteurs. En outre, il va de soi que tout le monde ne transitionnera pas en même temps et que la période intermédiaire, pendant laquelle les deux systèmes coexisteront, durera de nombreuses années. Les vieux résolveurs ignoreront les DELEG pendant ce temps, et il faudra donc continuer à publier des NS corrects. Cette publication de deux jeux d’information ne se fera sans doute pas sans problèmes.

Un problème supplémentaire est posé par le fait que la signalisation faite par les DELEG peut être erronée, soit qu’elle l’était dès le départ, soit qu’elle le soit devenue avec le temps. Si un enregistrement DELEG annonce qu’un serveur accepte DoT, mais que cela n’est pas ou plus exact, le client DNS, le résolveur, doit être prêt à essayer rapidement sans DoT¹⁷.

Quel est l’état actuel du projet ? Le 27 juin 2024, le groupe de travail IETF DELEG a été créé (visitez https://datatracker.ietf.org/wg/deleg/ pour les dernières nouvelles). Sa charte prévoit d’écrire un cahier des charges précis, puis de spécifier les changements techniques à faire dans le DNS¹⁸. Les futures modifications d’autres protocoles, comme EPP, seront du ressort d’autres groupes de travail¹⁹.

Conclusion

DELEG ne serait pas seulement un changement technique mais également un changement politique, avec un déplacement de pouvoir vers les hébergeurs DNS (lorsqu’ils sont distincts du BE). Ce projet nécessiterait l’accord d’un grand nombre de catégories d’acteurs, dans un environnement critique où on hésite devant toute modification. Le mécanisme de délégation du DNS est perfectible, DELEG est une bonne idée mais il est peut-être trop tard pour l’envisager.

1 – Ce n’était pas le cas autrefois : il y a très longtemps, dans un pays lointain, l’ensemble des noms de domaine du réseau étaient gérés de manière centralisée, dans une liste unique, gérée par une seule personne, Elizabeth Feinler. Son texte de souvenirs, «Host tables, top level domain names and the origin of dot com » est une lecture recommandée. L’invention du DNS a permis de mettre fin à ce système qui n’aurait pas tenu face à la croissance du réseau.

2 – Lorsqu’il y a une délégation technique, on dit qu’on a créé une nouvelle zone. Chaque zone a, à son apex, son sommet, un ensemble d’enregistrements NS et un enregistrement SOA qui contient des méta-données utiles. Ainsi, gouv.fr est dans la zone fr mais cgt.fr n’y est pas, il s’agit d’une zone séparée. Dans cet article, pour simplifier, on parlera souvent de domaines même quand ils sont également des zones.

3 – En juin 2024, ce nom est délégué.

4 – Institut Universitaire de Technologie

5 – Et la distinction entre zone et domaine, un détail sans importance dans la majorité des usages, est cruciale si on utilise le mécanisme de sécurité DNSSEC.

6 – Dans les exemples suivants, on utilisera dig, le logiciel de test et débogage DNS le plus répandu.

7 –% dig abeille-sucree.fr HTTPS

…

;; ANSWER SECTION:

abeille-sucree.fr.      300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.21.69.108,172.67.207.111 ipv6hint=2606:4700:3035::6815:456c,2606:4700:3035::ac43:cf6f

8 – Transport Layer Security, le même protocole de cryptographie que pour HTTPS. RFC 8446.

9 – Si vous souhaitez tester, les serveurs faisant autorité pour wikipedia.org acceptent DoT.

10 – Domain Name System Security Extensions, un mécanisme de signature cryptographique des enregistrements, pour assurer leur authenticité et leur intégrité.

11 – Numéro identifiant un service particulier sur une machine.

12 – Hypertext Transfer Protocol Security, la base de la plupart des serveurs Web, sur laquelle on peut faire passer le DNS afin de protéger la connexion. DNS sur HTTPS (DoH pour DNS-over-HTTPS) est normalisé dans le RFC 8484.

13 – Un protocole de transport, concurrent du classique TCP, mais incluant la cryptographie afin de protéger la connexion. DNS sur QUIC (DoQ pour DNS-over-QUIC) est normalisé dans le RFC 9250.

14 – ALPN signifie Application-Layer Protocol Negotiation, est normalisé dans le RFC 7301, et est une méthode permettant d’indiquer le protocole applicatif à utiliser.

15 – Extensible Provisioning Protocol

16 – Registration Data Access Protocol

17 – Le RFC 9539 décrit une méthode pour essayer différentes possibilités de communiquer avec un serveur DNS dont on ne connaît pas a priori les capacités.

18 – Il existe des brouillons, sans valeur officielle.

19 – Vous pouvez consulter les brouillons, très préliminaires, sur EPP et sur RDAP.