Mon blog

Ce RFC est la documentation d'un nouveau type d'enregistrement DNS, le type URI qui permet de publier des URI et donc d'avoir un mécanisme pour faire correspondre un nom de domaine à un URI.

Petit rappel, les URI sont normalisés dans le RFC 3986 et permettent sous une forme simple et compacte d'identifier une ressource sur le Web et, très fréquemment, fournissent les moyens d'y accéder. Traditionnellement, quand on voulait mettre des URI dans le DNS et permettre de les retrouver, on utilisait les NAPTR des RFC 3401 et RFC 3404. Notre nouveau RFC critique cette solution en notant qu'une requête NAPTR récupère tous les NAPTR qu'il faut trier ensuite, pas uniquement ceux liés à un seul service (le triage est d'autant plus compliqué qu'il n'existe toujours aucune bibliothèque en logiciel libre pour manipuler des NAPTR). En effet, le nom du service fait partie des données du NAPTR, pas du nom de domaine (le seul critère de sélection dans une requête DNS, avec le type). La solution de notre RFC 7553 permet cette sélection en mettant le type de service souhaité dans le nom de domaine. En outre, l'URI est trivial à extraire, il est le dernier composant des données de l'enregistrement, et ne nécessite pas de traitement ultérieur (on est loin de la complexité des NAPTR, même si les S-NAPTR du RFC 3958 l'ont un tout petit peu simplifiée).

Donc, dès que vous avez besoin d'une correspondance simple entre un nom de domaine et un URL, allez-y, ce type d'enregistrement est fait pour vous. À quoi ressemble-t-il (section 4 du RFC) ? Le format de présentation en texte met dans les données (la partie droite de l'enregistrement) une priorité, suivie d'un poids et de l'URI (nommé Target). Cela donne comme exemple :

_ftp._tcp.example.net.    IN URI 10 1 "ftp://ftp1.example.com/public"

Priorité et poids ont la même sémantique que dans le RFC 2782 (voir plus loin).

Le nom de domaine suit certaines conventions (section 4.1), notamment d'indiquer le service demandé (pris dans le registre IANA qu'avait créé le RFC 6335) et le protocole utilisé, précédés d'un tiret bas.

L'enregistrement URI a le type 256 et figure à ce titre dans le registre IANA des types DNS.

On peut avoir plusieurs URI pour un même nom de domaine (donc un même service). La sélection se fait en examinant d'abord la priorité, puis le poids. La priorité est absolue. On contacte d'abord les URI ayant la priorité la meilleure (c'est le chiffre le plus bas, attention), et, seulement si cela échoue, on tente les autres. Par contre, à priorité équivalente, la sélection selon le poids est probabiliste. Cela permet de faire de la répartition de charge dans le DNS. Si j'écris deux URI avec la même priorité mais des poids différents :

_ftp._tcp.example.net.    IN URI 10 2 "ftp://ftp1.example.net/public"
                          IN URI 10 1 "ftp://ftp4.example.com/mirrors/example.net/"

Alors, l'URI ftp://ftp1.example.net/public a deux fois plus de chances d'être sélectionné, il recevra donc les deux tiers des requêtes. Si j'avais mis des priorités différentes :

_ftp._tcp.example.net.    IN URI 10 1 "ftp://ftp1.example.net/public"
                          IN URI 20 1 "ftp://ftp4.example.com/mirrors/example.net/"

Alors, ftp://ftp4.example.com/mirrors/example.net/ ne sera sélectionné que s'il n'y a pas le choix, uniquement si ftp1.example.net est en panne.

Et sur le réseau, comment est encodé ce nouveau type (section 4.5) ? C'est simple, deux octets pour la priorité, deux pour le poids et l'URI lui-même, sous forme de texte.

Les enregistrements URI permettent d'indiquer la même chose qu'un SRV (RFC 2782), à savoir un nom de serveur et un port, mais ils permettent en outre d'exprimer d'autres choses (comme le répertoire dans les exemples FTP plus haut). En contre partie, il faut pouvoir traiter les URI, les analyser, mais c'est aujourd'hui une tâche bien connue, pour laquelle on a déjà du code. Ainsi, ces deux informations sont presque équivalentes (si on sait que le protocole à utiliser est HTTP) :

_http._tcp    IN  SRV   0  1 8081  www.example.net.
_http._tcp    IN  URI   0  1 "http://www.example.net:8081"

Mais les enregistrements URI sont plus puissants, ceci ne pourrait pas être exprimé en SRV :

_http._tcp    IN  URI   0  1 "http://www.example.net:8081/actu/2015"

Les futurs protocoles pourraient donc n'utiliser que URI, et plus du tout SRV. (À l'heure actuelle, certains protocoles utilisent une combinaison de SRV + un enregistrement TXT, pour résoudre ce problème : l'enregistrement URI est plus élégant.)

Je ne peux pas m'empêcher de noter que bien des problèmes du Web auraient été évités si, dès le début, Tim Berners-Lee avait pensé à découpler le nom de domaine et le serveur, en utilisant les SRV. Actuellement, le nom dans l'URL doit être un nom de machine (il doit obéir aux règles syntaxiques restrictives sur les noms de machine, et il doit avoir une adresse IP). Cela oblige à mettre une adresse à l'apex (le sommet) de la zone DNS (si on veut que http://example.com/ marche, il faut une adresse IP mise au nom example.com, ce qui est compliqué à réaliser proprement). Si le Web utilisait les SRV ou, aujourd'hui, les enregistrements URI, on ne serait pas obligé de polluer l'apex de la zone avec des adresses IP, on aurait séparé le nom court (example.com), dans l'URL, et celui du serveur (qui ne serait pas visible à l'utilisateur ordinaire).

Bien que ce type d'enregistrement ait déjà plusieurs années (le RFC 6895 permet d'enregistrer un type d'enregistrement DNS sans avoir de RFC), certains logiciels ne le gèrent pas encore. Voici une version un peu ancienne d'OpenDNSSEC (je n'ai pas testé avec les versions plus récentes) :

ods-signerd: [adapter] error parsing RR at line 28 (Syntax error, could not parse the RR's rdata):   IN URI 0 1 "http://www.bortzmeyer.org/"

Aïe. Et pareil avec le signeur DNSSEC d'une version un peu vieille de BIND :

dnssec-signzone: warning: sources.org:23: unknown RR type 'URI'
dnssec-signzone: fatal: failed loading zone from 'sources.org': unknown class/type

Idem pour les formulaires Web qui permettent de créer des enregistrements DNS dans une zone gérée par son hébergeur DNS. Tous n'ont pas encore ce type, loin de là.

Pour une vision optimiste, voici le commit qui a ajouté le type URI à PowerDNS.

Un exemple d'utilisation des enregistrements URI est le service des codes postaux dans le DNS, où un URI pointe vers OpenStreetMap. Ici, la commune de Luchon :

% dig +short +nodnssec URI 31110.cp.bortzmeyer.fr
10 1 "http://www.openstreetmap.org/?mlat=42.781913&mlon=0.564010&zoom=12"