Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Ève

RFC 5001: DNS Name Server Identifier Option (NSID)

Date de publication du RFC : Août 2007
Auteur(s) du RFC : R. Austein (ISC)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsext
Première rédaction de cet article le 1 septembre 2007
Dernière mise à jour le 11 mars 2010


Cette nouvelle option du DNS permet d'identifier le serveur de noms physique auquel on parle, dans le cas où plusieurs machines servent sous la même adresse IP. Elle a vocation à remplacer l'ancien hostname.bind.

En application du cahier des charges du RFC 4892, ce très court RFC normalise une nouvelle utilisation d'EDNS pour transporter une chaîne de bits qui identifie une instance particulière d'un serveur de noms.

Aujourd'hui, en effet, comme l'explique le RFC 4892, il est fréquent qu'un même serveur de noms (par exemple F.root-servers.net, serveur de la racine) soit mis en œuvre par plusieurs machines physiques (des dizaines dans le cas de F.root-servers.net). En cas de défaillance d'une seule de ces machines, il est préférable de pouvoir détecter quelle machine était en cause (voir par exemple la panne de C-root). Cela se faisait autrefois avec le nom spécial hostname.bind (un id.server a été proposé pour être moins lié à BIND). Cette méthode ayant plusieurs inconvénients (là encore, voir le RFC 4892), une nouvelle méthode était nécessaire.

NSID est simplement une option EDNS. Lorsqu'elle est présente dans la requête, le serveur mettra son identité dans la réponse.

En quoi consistera cette identité ? Ce fut le grand et vif débat au sein du groupe de travail dnsext de l'IETF. Certains operateurs de serveurs de noms ne souhaitaient pas en révéler trop, certains souhaitaient mettre de l'Unicode dans la réponse, etc. Le compromis a finalement été de décider que la chaîne de bits mise dans la réponse n'a aucune signification standard. Elle dépend entièrement de l'opérateur. Il pourra mettre un nom de machine (comme on le fait souvent aujourd'hui avec hostname.bind), un identificateur opaque, ou même une valeur différente à chaque fois (la section 3.1 détaille ces possibilités).

Voici une configuration de cette option sur un BIND 9.7 :

options {
    ...
    server-id "My super X-server";
};

et son résultat, lorsque le serveur est interrogé par dig :

% dig +nsid @ns1.example.org SOA example.org
...
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; NSID: 4d 79 20 73 75 70 65 72 20 58 2d 73 65 72 76 65 72  \
           (M) (y) ( ) (s) (u) (p) (e) (r) ( ) (X) (-) (s) (e) (r) (v) (e) (r)
;; QUESTION SECTION:
...

Comme le contenu du NSID peut être absolument quelconque, dig affiche les valeurs des différents octets (et, pour être sympa, le caractère correspondant à ce code ASCII). Si on met une valeur en UTF-8 :

   server-id "Café-crème";

dig, n'affichera que les caractères ASCII :

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; NSID: 43 61 66 c3 a9 2d 63 72 c3 a8 6d 65  \
          (C) (a) (f) (.) (.) (-) (c) (r) (.) (.) (m) (e)

Avec nsd (depuis la version 3.2.5), la configuration est en hexadécimal (NSD 4 permet de mettre des chaînes ASCII). J'utilise ce petit programme en Python pour faire la traduction. Mais on peut aussi, toujours en Python, faire simplement python -c 'import sys;print sys.stdin.read().encode("hex")' (merci à @alexpigne) ou bien en classique shell Unix, utiliser hexdump avec hexdump -v -e '/1 "%02X"' (merci à @guguscat). Si vous le faites en une ligne de shell, n'oubliez pas le -n en argument à echo. En tout cas, voici un exemple :

% echo -n "ns1.example.net" | hexdump -v -e '/1 "%02X"'      
6E73312E6578616D706C652E6E6574

# nsd.conf
nsid: 6E73312E6578616D706C652E6E6574

Si vous cherchez un exemple réel, les serveurs de l'AFNIC ont NSID :


% dig +nsid @c.nic.fr. SOA fr
...
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; NSID: 64 6e 73 2e 74 68 32 2e 6e 69 63 2e 66 72  (d) (n) (s) (.) (t) (h) (2) (.) (n) (i) (c) (.) (f) (r)

Ici, c'était une machine installée au Telehouse 2 (th2) à Paris. Mais c'est évidemment plus drôle avec une « machine » anycast, essayez depuis plusieurs endroits du réseau avec d.nic.fr. Une telle étude a été faite et publiée. Autre exemple d'utilisation importante de NSID, sur le serveur L-root, décrit dans le RFC 7108.

Si vous voulez avoir une idée de ce qu'implique une mise en œuvre de ce RFC, vous pouvez regarder le « commit » 4cd33c... de GRONG. Voici son utilisation :

% grong-server -servername="ns1.local.bortzmeyer.org"
...
% dig +nsid @::1 nimportequoi
...
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; NSID: 6e 73 31 2e 6c 6f 63 61 6c 2e 62 6f 72 74 7a 6d 65 79 65 72 2e 6f 72 67  \
      (n) (s) (1) (.) (l) (o) (c) (a) (l) (.) (b) (o) (r) (t) (z) (m) (e) (y) (e) (r) (.) (o) (r) (g)
...

Téléchargez le RFC 5001

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)