S’il y a bien un service d’importance vitale sur le réseau, c’est le système de noms de domaine (DNS, Domain Name System). C’est grâce à lui que nous disposons d’adresses faciles à retenir, comme zestedesavoir.com, et que nous n’avons pas à retenir d’adresses IP. En effet, le concept du DNS est d’attribuer des noms à des adresses, pour que ce soit plus parlant aux utilisateurs.
Nous commencerons ce chapitre par une présentation globale de ce système. Nous aborderons ensuite le principe de récursivité et la répartition des serveurs, puis nous nous pencherons sur les différents types de requêtes. Enfin, nous verrons quelles sont les évolutions actuelles du DNS qui tentent de pallier ses défauts.
DNS est un système devenu très complexe qui peut faire l’objet de livres entiers pour le maitriser. Ce chapitre pose seulement les bases permettant de comprendre les fondamentaux du système. Rendez-vous dans la conclusion pour des pistes permettant d’approfondir le sujet !
En bref
Si on veut résumer de manière succincte ce qu’est DNS, on peut dire que c’est un système permettant d’attribuer des noms à des adresses IP. Faisons tout de suite un test, ouvrez une console et tapez la commande suivante :
- Pour Windows :
nslookup zestedesavoir.com - Pour Linux et Mac OS :
dig zestedesavoir.com
On obtient un résultat de ce genre sous Windows :
Serveur : UnKnown
Address: 192.168.1.1
Réponse ne faisant pas autorité :
Nom : zestedesavoir.com
Addresses: 2001:4b98:dc0:41:216:3eff:febc:7e10
92.243.7.44
Sous Linux :
; <<>> DiG 9.10.3-P4-Debian <<>> zestedesavoir.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34910
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;zestedesavoir.com. IN A
;; ANSWER SECTION:
zestedesavoir.com. 300 IN A 92.243.7.44
;; Query time: 89 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
[...]
Ce retour nous donne plusieurs informations. Le plus important, ce sont les adresses associées au nom de domaine zestedesavoir.com, qui sont 92.243.7.44 et 2001:4b98:dc0:41:216:3eff:febc:7e10. Par défaut, dig ne demande que l’adresse IPv4, c’est pourquoi nous ne voyons pas l’adresse IPv6 ici.
Un nom de domaine désigne un nom utilisé par DNS auquel on peut associer une ou plusieurs adresses IP. Il est composé de plusieurs parties séparées par des points.
Grâce à cette information, quand vous tapez zestedesavoir.com dans votre navigateur, il sait qu’il doit contacter une des adresses IP renvoyées.
L’autre information importante, c’est le serveur contacté, ici 192.168.1.1. Le client (ici, nslookup ou dig) s’est adressé à ce serveur au moyen d’une requête DNS, envoyée en UDP sur le port 53. La réponse se fait par le même moyen. Nous verrons en fin de chapitre que ce fonctionnement pose des problèmes de sécurité. Avant cela, voyons pourquoi c’est ce serveur en particulier qui a été contacté et pas un autre.
Un arbre à l'envers
Dans la majorité des cas, le serveur DNS que notre ordinateur contacte est défini par le réseau. Notre système reçoit généralement cette information au moyen du protocole DHCP, qui fera l’objet du prochain chapitre. Ce serveur DNS fait souvent partie du réseau local, comme dans l’exemple précédent. Et notre pauvre serveur DNS local, eh bien, il ne peut pas connaitre tous les noms de domaine du monde. 
Passe à ton voisin
Quand il ne sait pas répondre, un serveur DNS transmet la requête à un autre, qui fait office de référent. Un cas classique : sur votre connexion Internet privée, votre routeur fait probablement office de serveur DNS. S’il ne sait pas répondre à une requête, il la transmet à un serveur DNS de votre opérateur, qui sera plus à même de connaitre la réponse.
Pourquoi on ne contacte pas directement le serveur de l’opérateur, alors ?
Déjà, c’est plus rapide de contacter son voisin qu’un serveur on ne sait où. En plus, cela permet d’économiser des ressources. Le serveur DNS local apprend et enregistre les requêtes et les réponses associées et peut y répondre directement quand elles sont à nouveau demandées. Ces enregistrements sont valables pour une période de temps donnée : c’est le Time To Live (TTL). La durée de validité peut être d’une heure, un jour, … On appelle cela un cache.
Et le serveur de l’opérateur, il connait forcément la réponse ?
Eh bien non, c’est pareil : quand il ne connait pas, il demande et garde en mémoire la réponse. Il peut demander à d’autres serveurs qui sont ses propres référents, et ainsi de suite. Le dernier recours, ce sont les serveurs racines, ou root servers.
Par la racine
Il existe dans le monde plusieurs serveurs DNS un peu particuliers. On s’adresse à eux quand on est vraiment désespéré on n’a aucun autre serveur à contacter. Leurs adresses sont fixes et ils ne font que renvoyer vers les serveurs d’autorité du domaine de premier niveau (TLD, Top Level Domain). Cela correspond à la dernière partie du nom de domaine : .com, .net, .fr, …
Un serveur DNS peut faire autorité sur un domaine, c’est-à-dire que c’est lui qui a la réponse aux requêtes d’un domaine donné. Ainsi, le serveur d’autorité du domaine com peut légitimement renvoyer une réponse lorsqu’on lui parle de zestedesavoir.com.
Ce comportement est reproduit pour la plupart des domaines, jusqu’à arriver au serveur final qui nous délivrera la réponse attendue. Si vous demandez le domaine fr.wikipedia.org à un serveur DNS, en supposant qu’il ne le connaisse pas déjà, il va questionner un root server qui va le renvoyer vers le serveur d’autorité du domaine org. Ce dernier va renvoyer à son tour vers le serveur d’autorité de wikipedia.org. C’est finalement lui qui va fournir une ou plusieurs adresses IP associées à fr.wikipedia.org. On parle de structure en arbre inversé, avec la racine en haut. On peut observer ce fonctionnement en analysant une requête non récursive.
Lorsqu’on fait une requête DNS, par défaut, le serveur qu’on contacte transmet directement à son référent ou à un serveur d’autorité, et ainsi de suite. Cela permet d’instaurer un système de cache comme vu précédemment. C’est un fonctionnement récursif. Il est possible d’effectuer des requêtes en mode itératif (non récursif), ce qui fait que le demandeur réémet une requête à chaque étape, au lieu de laisser les serveurs se contacter entre eux.
La commande suivante interroge le serveur DNS public 1.1.1.1 et effectue la requête de manière itérative.
# dig @1.1.1.1 fr.wikipedia.org +trace
; <<>> DiG 9.10.3-P4-Debian <<>> @1.1.1.1 fr.wikipedia.org +trace
; (1 server found)
;; global options: +cmd
. 303 IN NS g.root-servers.net.
. 303 IN NS h.root-servers.net.
. 303 IN NS i.root-servers.net.
. 303 IN NS j.root-servers.net.
. 303 IN NS k.root-servers.net.
. 303 IN NS l.root-servers.net.
. 303 IN NS m.root-servers.net.
. 303 IN NS a.root-servers.net.
. 303 IN NS b.root-servers.net.
. 303 IN NS c.root-servers.net.
. 303 IN NS d.root-servers.net.
. 303 IN NS e.root-servers.net.
. 303 IN NS f.root-servers.net.
. 303 IN RRSIG NS 8 0 518400 20190901050000 20190819040000 59944 . [...]
;; Received 717 bytes from 1.1.1.1#53(1.1.1.1) in 5 ms
org. 172800 IN NS a0.org.afilias-nst.info.
org. 172800 IN NS a2.org.afilias-nst.info.
org. 172800 IN NS b0.org.afilias-nst.org.
org. 172800 IN NS b2.org.afilias-nst.org.
org. 172800 IN NS c0.org.afilias-nst.info.
org. 172800 IN NS d0.org.afilias-nst.org.
org. 86400 IN DS 9795 7 1 364DFAB3DAF254CAB477B5675B10766DDAA24982
org. 86400 IN DS 9795 7 2 3922B31B6F3A4EA92B19EB7B52120F031FD8E05FF0B03BAFCF9F891B FE7FF8E5
org. 86400 IN RRSIG DS 8 1 86400 20190901170000 20190819160000 59944 . [...]
;; Received 818 bytes from 198.97.190.53#53(h.root-servers.net) in 80 ms
wikipedia.org. 86400 IN NS ns2.wikimedia.org.
wikipedia.org. 86400 IN NS ns0.wikimedia.org.
wikipedia.org. 86400 IN NS ns1.wikimedia.org.
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN NSEC3 1 1 1 D399EAAB H9PARR669T6U8O1GSG9E1LMITK4DEM0T NS SOA RRSIG DNSKEY NSEC3PARAM
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN RRSIG NSEC3 7 2 86400 20190909185601 20190819175601 44078 org. H6i2CguBU78xSKcGUIqL86LmOZP7OF0gWJFiczb6VCqp1phCqnSocrEP kp2vL9cgYuCZUB7uifT2JmmOmxdm336gBfFQxnSLUl8wD5XDFthwZK/4 gjAQL/H2qCKGd+uwlQXUqDA0emWZoMJq60eEftTU0mlucqQtHigRy1cs 994=
hhdkj29uji44onob8fm7tnl1n6nes0jb.org. 86400 IN NSEC3 1 1 1 D399EAAB HHE40886E1IPI0A8N1TCCMQEN3JPUHJO NS DS RRSIG
hhdkj29uji44onob8fm7tnl1n6nes0jb.org. 86400 IN RRSIG NSEC3 7 2 86400 20190907152407 20190817142407 44078 org. PcdtrdhckwwQweIf1aVvpr69kgQnw9dwJC/orqxTp3Ed4FwGpb9pY3bO jaXBW34bjOxNk9pdE2ysbHK1wZUa5eAipTcKr2jcAW8SIkplsN2/lF80 b2+zCdgaMBACQhYXKfTw4AJICWJaYpGHJ5R6c8Qv1ipaCYXbvcDTwx05 v1I=
;; Received 650 bytes from 199.19.53.1#53(c0.org.afilias-nst.info) in 6 ms
fr.wikipedia.org. 86400 IN CNAME dyna.wikimedia.org.
;; Received 74 bytes from 91.198.174.239#53(ns2.wikimedia.org) in 22 ms
Quelques lignes ont été tronquées pour améliorer la lisibilité. On suit bien la logique décrite : d’abord on récupère auprès de 1.1.1.1 les adresses des root servers. Pour cela, on lui demande l’adresse de « . ». Oui, point. « . » représente le domaine d’origine, qui fait autorité pour tous les domaines de premier niveau.
Dans le système de noms de domaine, il existe une subtilité à laquelle on n’est confronté que lorsqu’on configure un serveur DNS. Quand un nom de domaine est écrit sans point à la fin, il est relatif au domaine dans lequel on se trouve. Ainsi, si vous configurez le domaine agrume.com pour qu’il redirige vers zestedesavoir.com, vous allez vous retrouver vers zestedesavoir.com.agrume.com ! Pour préciser que le domaine cible est absolu, et non relatif, il faut rajouter un point à la fin, pour signifier qu’on veut pointer sur zestedesavoir.com. (« relatif au domaine d’origine », donc absolu). Sur Internet, on n’est pas dans un domaine en particulier, donc tous les domaines qu’on demande sont absolus. On peut, si on le souhaite, rajouter un point à tous nos noms de domaines : ça marchera ! Essayez donc de faire une requête DNS sur zestedesavoir.com. avec le point à la fin ! 
Cette notation s’appelle FQDN, pour Fully Qualified Domain Name.
Ensuite, on demande à l’un des serveurs racines qui a autorité sur le domaine org. Dans notre cas, c’est le serveur racine H qui a été interrogé. Il existe 13 adresses pour les root servers : ce sont des sous-domaines de root-servers.net qui vont de A à M. La page Wikipédia consacrée au sujet explique plus en détail comment ils fonctionnent.
Un des serveurs d’autorité du TLD org (dans notre cas, c0.org.afilias-nst.info à l’adresse 199.19.53.1) est interrogé pour connaitre qui contrôle le domaine wikipedia.org. Enfin, ns2.wikimedia.org (91.198.174.239) nous dit à quoi correspond fr.wikipedia.org.
dig n’a pas affiché les adresses IP récupérées à chaque étape. Pour interroger le serveur racine H, une autre requête a dû être effectuée pour connaitre l’IP de h.root-servers.net, et ainsi de suite. Dans le résultat de la commande, à la fin, on nous dit que fr.wikipedia.org est équivalent à dyna.wikimedia.org. Nous allons apprendre à déchiffrer, entre autres, ces NS et CNAME dans la section suivante.
On peut représenter les échanges précédents par ce schéma.
Ce schéma ne représente que des serveurs DNS et un client, sans considération pour le réseau. Dans la réalité, ils ne sont pas directement connectés.
Nous avons vu dans cette section que des échanges DNS, ce n’est finalement pas que des associations de noms de domaine et d’adresses IP. Voyons maintenant les différents types de requêtes qui existent.
Drôle de type
Il existe officiellement plusieurs dizaines de types d’enregistrements et donc de requêtes DNS. Voici une liste de ceux qu’on rencontre le plus souvent.
Association d’adresses IP
C’est quand même l’intérêt principal du service : associer un nom de domaine avec une adresse IP. Les enregistrements de type A sont ceux qui renvoient des adresses IPv4. Autrement dit, quand on souhaite obtenir comme information une adresse IPv4, on envoie une requête de type A. Pour les adresses IPv6, c’est le type AAAA.
Services particuliers
Il y a un type d’enregistrement qui ne sert que pour les e-mails : il s’agit de MX (Mail eXchange). Les serveurs SMTP s’en servent pour savoir vers où transférer les messages. Quand un e-mail à destination de truc@example.org doit être acheminé, le serveur SMTP envoie une requête DNS de type MX pour connaitre l’adresse du serveur mail associé au domaine example.org.
On trouve aussi des enregistrements SRV (service) qui permettent de renvoyer une adresse de serveur selon le service désiré. Ainsi, si on veut connaitre l’adresse du serveur SIP (téléphonie sur IP) du domaine example.org, on peut demander le domaine _sip.tcp.example.org. Si l’enregistrement existe, il renverra l’adresse et le numéro de port du serveur associé. Toutefois, il ne faut pas trop compter dessus : ce type d’enregistrement est assez peu utilisé en pratique.
Allez voir ailleurs
L’enregistrement de type CNAME correspond à un alias. On envoie rarement une requête DNS pour obtenir effectivement un CNAME, mais on peut en recevoir quand on envoie une requête de type A ou AAAA. Une réponse CNAME signifie alors que le nom de domaine demandé renvoie vers un autre.
Il ne faut pas confondre avec le type NS (Name Server). Celui-ci indique que l’autorité du domaine demandé est transférée à un autre serveur. On peut aussi recevoir ce genre de réponse avec une requête de type A ou AAAA. Ce sont généralement les serveurs DNS qui reçoivent ce type de réponse, quand ils recherchent une adresse en remontant les domaines (org., example.org., …). On a pu voir cela lors de l’exemple de la section précédente.
Divers
L’enregistrement SOA (Start Of Authority) est particulier. Il doit théoriquement être systématiquement défini pour une zone donnée. Une zone correspond à un sous-domaine, comme test.example.org ou hello.example.org. Il permet de délivrer des informations sur le maitre de la zone, comme le serveur primaire ou une adresse e-mail de contact. Cela est utile quand plusieurs serveurs collaborent sur un domaine donné, par exemple pour se répartir la charge.
Terminons ce petit tour d’horizon des requêtes DNS par le type TXT. Pas de piège, ça veut bien dire texte. Si la RFC 1035, qui définit ce standard, ne dit rien à son sujet, elle est en pratique utilisée à des fins d’authentification. Les enregistrements de type TXT permettent de renvoyer une information textuelle. Cela permet de prouver à des services que vous êtes bien le propriétaire d’un nom de domaine, sans en altérer le fonctionnement normal. Ils peuvent aussi être utilisés conjointement avec d’autres types de requêtes, comme RP (Responsible Person, assez rare), qui servent à demander qui est la personne responsable du domaine. Ne confondez pas avec SOA : on parle ici d’une personne, pas d’un serveur.
Récapitulatif
En résumé, les principaux types d’enregistrements DNS sont récapitulés dans le tableau suivant.
| Type | Utilité | Fréquence d’utilisation |
|---|---|---|
| A | adresse IPv4 | très courant |
| AAAA | adresse IPv6 | très courant |
| MX | serveur SMTP | très courant |
| SRV | serveur pour un service donné | courant |
| CNAME | alias de nom | très courant |
| NS | serveur d’autorité | très courant |
| SOA | maitre d’une zone | très courant |
| TXT | texte | courant |
| RP | personne responsable du domaine | rare |
Évolutions
DNS a évolué depuis sa création en 1983, mais fondamentalement, il s’agit toujours d’échanges en clair sur UDP. Avec l’explosion de l’utilisation d’Internet et des réseaux IP en général, des problèmes de sécurité ont commencé à apparaitre. Seulement, on ne peut pas changer d’un claquement de doigts un système sur lequel le monde entier repose. Des améliorations sont apparues et sont progressivement adoptées depuis plusieurs années.
DNSSEC
Dans les années 1990, pour apporter un peu de sécurité, une amélioration au protocole DNS a été proposée sous le nom Domain Name System Security Extensions, abrégé DNSSEC. Ce système a été ensuite modernisé en 2005. Il consiste à signer les enregistrements DNS émis pour éviter qu’ils ne soient altérés. Techniquement, pour reprendre notre cas de serveur DNS d’opérateur, rien ne nous garantit que les enregistrements qu’il retourne soient les vrais et qu’il ne les modifie pas comme bon lui semble. Dans les faits, de telles altérations sont opérées par des opérateurs de télécoms à la demande de gouvernements ou suite à des décisions de justice dans des pays qui pratiquent la censure du net, comme la Chine, l’Irlande ou la France (voir cet article en anglais pour plus d’informations). On peut aussi s’inquiéter, sur un réseau local, d'une attaque Man In The Middle.
C’est en partie pour disposer d’une indépendance par rapport aux serveurs DNS d’opérateurs télécoms qu’il existe des services indépendants comme OpenDNS, Google Public DNS ou encore le DNS de Cloudflare.
Avec DNSSEC, si des enregistrements DNS signés sont altérés, ça se sait tout de suite : la signature n’est plus bonne. Pour plus d’informations sur les mécanismes de signature numérique, nous vous invitons à consulter ce document de l’université Paris-Est Marne-la-Vallée. Ce système, bien que standardisé, n’est pas utilisé et déployé partout. L’intégralité des équipements sur Internet utilise DNS, alors on ne peut pas forcer le changement d’un des plus fondamentaux services du réseau. Cela se fait progressivement. Les systèmes d’exploitation modernes le supportent nativement.
La signature ne chiffre pas le contenu des échanges : requêtes et réponses sont toujours transmises en clair sur le réseau.
DOT
Une autre façon de se prémunir d’une altération en cours de route est l’utilisation de DNS Over TLS (DOT). Le principe est simple : les échanges DNS sont encapsulés dans un tunnel TLS entre le client et le serveur. Cela implique nécessairement davantage d’échanges pour initier la connexion sécurisée, d’autant qu’ils sont transportés par TCP. Aussi, vu qu’il s’agit d’un protocole différent du DNS vanilla (c’est-à-dire "d’origine", "pur"), un port différent doit lui être attribué. En l’occurrence, c’est le port 853 qui remplit cette fonction. Cela ajoute une difficulté dans certains environnements sécurisés ou filtrés : il est courant, dans des réseaux d’entreprise, d’empêcher tout trafic non prévu, ce qui fait que si l’utilisation du DOT n’est pas explicitement admise, ce nouveau port risque d’être bloqué par défaut. Il en va également ainsi pour certains accès publics, comme des réseaux Wi-Fi de restaurants, qui peuvent souhaiter empêcher l’utilisation de services inconnus.
Certains serveurs DNS publics supportent DOT, mais son utilisation n’est pas encore très courante. Cette technique a été standardisée en 2016, puis améliorée en 2018. Android le supporte nativement depuis sa version Pie. Windows 10 ne permet pas son utilisation sans un logiciel tiers comme Chocolatey. Pour plus d’informations techniques, vous pouvez consulter les documents de référence : la RFC 7858 et la RFC 8310.
DOH
Il est aussi possible d’encapsuler des échanges DNS dans HTTPS avec le DNS Over HTTPS (DOH). Cette proposition est publiée notamment par Mozilla en octobre 2018 dans la RFC 8484. Elle permet de contourner d’éventuels filtrages en ayant recours à un protocole sécurisé extrêmement commun et rarement filtré (HTTPS), mais cela nécessite que le client supporte ce système. Cela ajoute aussi de l’encapsulation et donc réduit potentiellement les performances d’un point de vue réseau. En 2024, DOH est supporté nativement par les systèmes d’exploitation Windows 11, iOS, macOS et Android mais son utilisation nécessite un paramétrage spécifique.
DNS est un système complexe, d’importance vitale et dont les évolutions sont difficiles à mettre en place. Son omniprésence empêche une mise à jour globale, car tous les systèmes doivent continuer à fonctionner, ce qui impose aux serveurs une compatibilité constante et cause une inertie importante au déploiement à grande échelle.
Pour approfondir le sujet, nous vous recommandons les ressources suivantes :
- How DNS works, une bande dessinée en anglais qui illustre le fonctionnement de DNS ;
- Protocole DNS, article de FrameIP en français qui se focalise sur l’aspect protocole ;
- DNS Zones Explained, un article en anglais qui explique ce qu’est une zone DNS et qui revient sur les points importants de ce chapitre.
Enfin, les spécificités de ce protocole, notamment son mode récursif et sa capacité à transporter autre chose que des adresses IP, permettent d’en détourner l’usage initial. Ainsi, il est techniquement possible d’encapsuler le protocole IP lui-même dans DNS ! Cette prouesse est appelée IP over DNS. Les performances sont extrêmement limitées et les cas d’usage restreints, mais l’exploit mérité d’être mentionné. Plus modestement, le système Chatavion permet, grâce à une application Android, l’échange de messages courts type SMS au travers du protocole DNS. Cela permet une communication minimale sur des réseaux limités, par exemple en 2G, et même sur des accès Wi-Fi avec portail captif.