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.
