Le système DDDS, décrit dans le
permet d'associer à un nom de domaine l'adresse d'une ressource. Le
en donne une vision très générale, le
spécifie l'algorithme et notre RFC va
préciser tout le reste pour le cas d'une base de données particulière,
le DNS. C'est notamment dans notre RFC que se
trouve décrits les enregistrements NAPTR.
Le n'impose pas une base de données
particulière pour DDDS. Mais toutes les applications, aujourd'hui, se
servent du DNS, selon les règles édictées dans
notre RFC (qui remplace donc le ).
Le normalise donc les enregistrements NAPTR du DNS. Ces
enregistrements ressemblent à ceci :
cid.urn.arpa. IN NAPTR 100 10 "" "" "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i" .
où cid.urn.arpa est le nom de domaine, 100
l'ordre (au cas où il y aie plusieurs règles), 10 la préférence (nommé
priorité dans le ), les deux chaînes
vides sont les options (flags) et le service (le
protocole utilisé), les deux derniers termes étant l'expression et le
remplacement (ici vide).
Suivant l'exemple (hypothétique) de notre RFC,
inspiré du sur les URN : on
veut construire un service qui va permettre de trouver un message en
connaissant son Content-ID (un en-tête MIME
normalisé dans le ). Prenons
urn:cid:199606121851.1@bar.example.org comme
exemple d'URN. La règle bien connue (elle doit être spécifiée dans la
définition de l'application DDDS) dit que la première clé est comprise
entre le premier et le deuxième signe :, donc
ici, "cid" et on y ajoute urn.arpa.
La première règle trouvé dans le DNS pour ce nom est :
cid.urn.arpa. IN NAPTR 100 10 "" "" "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i" .
L'expression rationnelle extrait juste le nom de domaine (en
retirant le premier label) :
\2 désigne le second groupe de parenthèses, ici
example.org. Comme il n'y a pas d'options
(flags est une chaîne vide), la règle n'est pas
terminale et on recherche donc un nouvel enregistrement NAPTR en
utilisant example.org comme clé. Supposons que
cela donne :
example.org. IN NAPTR 100 50 "s" "http" "" www.example.org.
On saurait alors qu'il faut utiliser le protocole HTTP pour
demander à www.example.org ce message.
Aujourd'hui, les NAPTR sont surtout utilisés dans le contexte
d'ENUM, par exemple
1.9.7.9.0.7.8.6.8.0.3.9.4.e164.arpa est un nom de
domaine qui a deux enregistrements NAPTR nous donnant le numéro de
téléphone de son titulaire (en Allemagne) et son adresse SIP. Mais on voit aussi
des NAPTR dans les domaines http.uri.arpa et
ftp.uri.arpa pour résoudre les
URI (ici, avec l'outil
dig) :
% dig NAPTR http.uri.arpa
http.uri.arpa. 20969 IN NAPTR 0 0 "" "" "!^http://([^:/?#]*).*$!\\1!i" .
où ils extraient simplement le nom de machine de l'URI.
Je ne connais pas de mise en œuvre de NAPTR en logiciel
libre, malheureusement (le module PerlNet::DNS::RR::NAPTR permet leur analyse mais ne
met pas en œuvre l'algorithme ; même chose pour la classe NAPTR
de DNS Python).
Une bonne synthèse expliquant les NAPTR figure dans le blog de Nominet.