On lit souvent que le DNS sert à « traduire des noms de domaine en adresses IP ». C’est une vision très incomplète. Le DNS est en effet un service généraliste, qui est loin d’être spécifique aux adresses IP. Outre ces adresses, il permet de récupérer de nombreux autres types de données, et deux sont aujourd’hui très proches de la publication de leur norme technique : SVCB et HTTPS.
Rappels sur les types DNS
Le DNS (Domain Name System) permet, à partir d’un nom de domaine comme réussir-en.fr
ou sw.wikipedia.org
, d’obtenir des informations techniques de différents types. Ces types ont un numéro (que vous pouvez ignorer dans l’immédiat) et un mnémonique composé de quelques lettres. Ainsi, le mnémonique MX désigne le type DNS qui permet d’obtenir le nom du serveur de courrier électronique pour un nom de domaine donné. Lorsque vous écrivez à info@secourspopulaire.fr,
le logiciel de courrier va demander au DNS l’enregistrement MX de secourspopulaire.fr, ce qui lui permettra de contacter ensuite les serveurs indiqués.
L’un des types les plus connus est AAAA, qui désigne les adresses IP, identificateurs des machines connectées à l’Internet, pour assurer le routage des messages jusqu’à destination. Si vous visitez le site Web https://
www.ameli.fr
/
, votre navigateur Web va s’enquérir dans le DNS de l’adresse IP de www.
ameli
.fr
, et se servir ensuite de cette adresse pour se connecter au serveur Web.
Des nouveaux types sont régulièrement créés1, et c’est le sujet de cet article.
Le problème du logiciel client
Le navigateur Web (ou tout autre logiciel client, qui se connecte à un serveur), a donc le moyen de trouver l’information technique (l’adresse IP) dont il a besoin. Mais des demandes nouvelles sont apparues plus récemment. Par exemple, le protocole HTTP a désormais trois versions couramment utilisées, les versions 1, 2 et 32. Aucune de ces trois versions ne devrait disparaître à court terme, chacune ayant des avantages et des inconvénients. Il existe divers mécanismes à l’intérieur de HTTP pour informer le client des versions disponibles sur un serveur donné3 mais toutes prennent du temps puisqu’il faut d’abord se connecter en HTTP, ce qui peut être long surtout si on a choisit une version que le serveur ne gère pas. La latence (le temps d’aller-retour avec le serveur) étant le principal ennemi des performances du Web, il serait donc souhaitable de savoir, avant même de parler HTTP, quelles versions sont utilisables. Et nous avons un outil parfait pour cela, le DNS.
Le problème n’est d’ailleurs pas limité aux trois versions de HTTP. Ainsi, savoir à l’avance si le serveur permet du HTTPS (la version sécurisée par la cryptographie de HTTP) serait également utile4.
Les nouveaux types DNS présentés ici permettent également de résoudre le problème de la délégation d’un service Internet. Si la société Machin a le nom machin.example
mais veut faire héberger son site Web chez un fournisseur extérieur, qui prépare la machine sous le nom de client-56fa3.clients.fournisseur.example
, il n’y a pas à l’heure actuelle de solution vraiment satisfaisante pour faire cette délégation (on le fait quand même, mais avec des méthodes pas très pratiques5).
La solution
Le premier nouveau type d’enregistrement DNS, SVCB (pour SerViCe Binding) est générique, il n’est pas spécifique d’un service particulier. Il permet d’indiquer qu’un nom de domaine, avec une priorité donnée, va en fait vers un autre nom, avec une liste de paramètres. Le client qui veut se connecter à machin.example
va donc, d’une seule requête DNS, récupérer toutes les informations nécessaires à la connexion (alors que le type AAAA ne lui donnait que l’adresse IP). Pour des raisons de sécurité évidentes, il est bon que le domaine qui utilise SVCB soit protégé par DNSSEC.
Cela vous semble bien abstrait ? Voyons alors le second nouveau type d’enregistrement DNS, HTTPS6. Contrairement à SVCB, il est spécifique à un protocole, en l’occurrence HTTP. Sa forme est identique à celle de SVCB. Voici donc un exemple réel7, vu avec la commande Unix dig8 :
% dig mstdn.io HTTPS … ;; ANSWER SECTION: mstdn.io. 282 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.21.77.82,172.67.205.188 ipv6hint=2606:4700:3033::6815:4d52,2606:4700:3037::ac43:cdbc …
Comment le lire ? Cet enregistrement dit au client HTTP (par exemple un navigateur Web) que pour se connecter à mstdn.io
(un serveur du fédivers), on a le choix entre9 HTTP 2 et HTTP 3 (le paramètre alpn
), aux adresses IP indiquées (pour éviter de devoir faire une requête pour le type AAAA ensuite). D’autres paramètres sont possibles10, par exemple pour indiquer le port (un identificateur d’une application particulière sur une machine) ou bien des paramètres cryptographiques. En outre, la seule existence de l’enregistrement HTTPS indique que le serveur accepte le protocole sécurisé HTTPS.
En janvier 2022, la norme technique décrivant les types d’enregistrements SVCB et HTTPS, ce qu’on nomme le RFC (ce qui signifie Request For Comments, un terme très trompeur puisque c’est un document définitif) , n’était pas encore publié. Le futur RFC est encore en cours d’examen par l’IESG.
Le déploiement
Sur l’Internet, il n’est pas nécessaire d’avoir l’imprimatur de telle ou telle organisation pour déployer un service. L’Internet est « sans permission », contrairement à ce que pourraient faire croire tel ou tel raccourci lu dans certains médias, désignant une organisation ou une autre comme « régulateur de l’Internet », une fonction qui n’existe pourtant pas. Des services à succès, comme BitTorrent ou Bitcoin ont ainsi été déployés sans qu’il existe de norme technique formelle. Ce fut même le cas du Web qui, s’il avait dû attendre une autorisation, n’aurait peut-être jamais vu le jour. S’il fait aujourd’hui l’objet d’une normalisation, ce n’était pas le cas à ses débuts.
Donc, avant même l’approbation du futur RFC par l’IESG, on observe déjà des déploiements de ces deux nouveaux types sur l’Internet (en pratique, uniquement HTTPS, pas SVCB). Voici par exemple ce que peut observer le logiciel tcpdump sur un des serveurs DNS faisant autorité pour le domaine eu.org
:
14:32:23.959828 IP X.Y.Z.T.65532 > 172.104.125.43.53: 28264% [1au] Type65? domain1.eu.org. (43) 14:32:24.260731 IP X.Y.Z.T.50162 > 172.104.125.43.53: 34613% [1au] Type65? bfbbf90.domaine2.eu.org. (49) 14:32:25.872131 IP X.Y.Z.T.19924 > 172.104.125.43.53: 45232% [1au] Type65? domain3.eu.org. (52)
On voit ici trois requêtes DNS dans un intervalle rapproché, provenant de résolveurs différents, et interrogeant le serveur 172.104.125.43
. Comme tcpdump ne connaît pas le type HTTPS, trop récent, il affiche juste son numéro (65 ; SVCB est le 64). On voit également des centaines de requêtes par seconde sur les serveurs faisant autorité pour .fr
:
D’où viennent ces requêtes ? Sans doute en grande partie du système d’exploitation de l’iPhone, iOS. Sa version 14, publiée en septembre 2020, envoie déjà des requêtes HTTPS. Les navigateurs Web Chrome et Firefox ont également déjà, dans leur version de développement, la possibilité de faire la même chose (mes essais semblent indiquer que ce n’est pas encore activé).
Notez qu’à l’heure actuelle, un logiciel client HTTP qui souhaite profiter du type DNS HTTPS doit également savoir s’en passer, de tels enregistrements n’étant pas encore présents partout. L’administrateur DNS qui met des enregistrements HTTPS dans son domaine doit également veiller à ce que tout fonctionne sans eux, pour tenir compte des anciens clients.
Avant les types SVCB et HTTPS, un autre type d’enregistrement avait été prévu pour un usage analogue, SRV. Il a été largement un échec, en tout cas dans le monde du Web. La décision de ne pas l’utiliser au début du Web avait été une grosse erreur, difficile à corriger par la suite car l’Internet ne bouge pas facilement : non seulement on n’a pas besoin d’une autorisation pour déployer une technique mais, en sens inverse, avoir une norme technique publiée ne garantit nullement son déploiement. On est dépendants de la bonne volonté des auteurs de logiciels, des acteurs souvent méconnus de ce que l’on nomme la « gouvernance de l’Internet ». Il est vrai que SRV a des limites que n’ont pas SVCB et HTTPS11.
Conclusion
On voit que le DNS, pourtant un des protocoles les plus anciens de l’Internet, continue à évoluer. Les types SVCB et HTTPS fournissent un moyen d’éviter de faire une première connexion HTTP pour connaître les caractéristiques d’un serveur, ce qui devrait contribuer à diminuer la latence des connexions sur le Web. Mais son déploiement ne sera pas instantané ; par exemple, beaucoup de gérants de zones DNS utilisent des interfaces graphiques pour créer des enregistrements, interfaces qu’il faudra mettre à jour.
1 – La liste complète figure dans un registre IANA.
2 – Cette dernière utilisant le transport QUIC.
3 – C’est notamment le cas du mécanisme Alt-Svc:
, un champ dans l’en-tête de la réponse HTTP.
4 – Le système HSTS (HTTP Strict Transport Security), comme le mécanisme Alt-Svc:
, nécessite une première connexion au serveur HTTP, augmentant ainsi la latence.
5 – C’est le problème dit du « CNAME à l’apex » ou encore « CNAME and other data ».
6 – Un nom mal choisi, en raison du risque de confusion entre le protocole HTTPS et le type d’enregistrement HTTPS.
7 – Cet enregistrement est mis automatiquement par le système d’hébergement Cloudflare donc tous les domaines Cloudflare l’ont aussi, par exemple cinemasducentre.asso.fr
ou arts.fr
.
8 – Ce n’est pas l’outil le plus facile à utiliser et à comprendre mais les types SVCB et HTTPS étant récents, ils ne sont pas encore intégrés dans tous les logiciels, loin de là.
9 – HTTP 1 n’a pas besoin d’être spécifié : pour l’instant, il va de soi.
10 – Leur liste figurera également dans un registre IANA qui, en janvier 2022, n’était pas encore créé.
11 – SVC ne permettait pas l’ajout de paramètres nouveaux, par exemple l’ALPN (Application Layer Protocol Negotiation) qui permet d’indiquer qu’on accepte HTTP 2 et 3.