Mon blog

Tous les RFC ne décrivent pas forcément une norme technique. Certains sont de nature plus opérationnelle et c'est le cas de de ce document, qui décrit le nouveau schéma de nommage des serveurs DNS de in-addr.arpa et ip6.arpa.

Bien qu'il n'existe aucun document décrivant l'usage qui peut être fait de la correspondance depuis l'adresse IP vers le nom de domaine (il y a eu plusieurs essais à l'IETF , tous ratés), il ne fait pas de doute que cette correspondance est utilisée. Par exemple, beaucoup de MTA , à l'exemple de Postfix , résolvent systématiquement l'adresse IP du client en nom, même s'ils ne se servent pas de ce nom. Pour cela, il font une requête de type PTR sur un nom spécial, formé à partir de l'adresse IP, et ajoutant un domaine spécial de .arpa à la fin. Avec l'option -x, dig fait tout cela automatiquement, ce qui permet de voir le processus, ici pour une adresse IPv6 :

% dig -x 2001:db8:dada::beef:1
; <<>> DiG 9.5.1-P3 <<>> -x 2001:db8:dada::beef:1
...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20846
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;1.0.0.0.f.e.e.b.0.0.0.0.0.0.0.0.0.0.0.0.a.d.a.d.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR
;; AUTHORITY SECTION:
d.0.1.0.0.2.ip6.arpa. 10800 IN SOA ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 3005122290 7200 1800 604800 172800
...

On voit le domaine « spécial », ip6.arpa (RFC 3152), à la fin (pour IPv4 , cela serait in-addr.arpa ). Tout ceci est rappelé dans la section 1 du RFC.

Mais qui gère ces domaines spéciaux et avec quels serveurs ? Avant ce RFC, les serveurs de noms de ces domaines étaient un sous-ensemble des serveurs racine :

% dig NS in-addr.arpa 
...
;; ANSWER SECTION:
in-addr.arpa. 86400 IN NS a.root-servers.net.
in-addr.arpa. 86400 IN NS b.root-servers.net.
in-addr.arpa. 86400 IN NS c.root-servers.net.
in-addr.arpa. 86400 IN NS d.root-servers.net.
in-addr.arpa. 86400 IN NS e.root-servers.net.
in-addr.arpa. 86400 IN NS f.root-servers.net.
in-addr.arpa. 86400 IN NS g.root-servers.net.
in-addr.arpa. 86400 IN NS h.root-servers.net.
in-addr.arpa. 86400 IN NS i.root-servers.net.
in-addr.arpa. 86400 IN NS k.root-servers.net.
in-addr.arpa. 86400 IN NS l.root-servers.net.
in-addr.arpa. 86400 IN NS m.root-servers.net.

pour in-addr.arpa (qui, en décembre 2010, n'a pas encore changé) et des serveurs fournis par les RIR pour ip6.arpa :

% dig NS ip6.arpa 
...
;; ANSWER SECTION:
ip6.arpa. 84600 IN NS ns.icann.org.
ip6.arpa. 84600 IN NS sec1.apnic.net.
ip6.arpa. 84600 IN NS ns2.lacnic.net.
ip6.arpa. 84600 IN NS ns-sec.ripe.net.
ip6.arpa. 84600 IN NS tinnie.arin.net.

Le but du nouveau schéma est de séparer les domaines en .arpa du reste de l'infrastructure, pour pouvoir les déléguer éventuellement à d'autres serveurs. Le RFC ne spécifie que le nommage. La nomination des opérateurs de ces domaines est une question politique, laissé à l'ICANN , via la fonction IANA , suivant le RFC 2860 :

% whois -h whois.iana.org arpa
IANA Whois Service
Domain: arpa
ID: arpa
Sponsoring Organization:
 Organization: Internet Assigned Numbers Authority
...
 Country: United States
...
Administrative Contact:
 Organization: Internet Architecture Board (IAB)
 c/o IETF Administrative Support Activity, ISOC
...
 Country: US
...
Technical Contact:
 Organization: Internet Assigned Numbers Authority
...

Donc, en quoi consiste le nouveau schéma ? Suivant de nombreuses zones (comme la racine mais aussi comme des TLD tels que .fr ), les serveurs de in-addr.arpa sont désormais tous dans un domaine dédié et ont un nom d'une seule lettre (section 2 du RFC) :

• A.IN-ADDR-SERVERS.ARPA
• B.IN-ADDR-SERVERS.ARPA
• C.IN-ADDR-SERVERS.ARPA
• ...

Ces noms se terminant par les deux mêmes composants permettent la compression des données DNS (RFC 1035, section 4.1.4).

Les serveurs de in-addr-servers.arpa et de in-addr.arpa sont les mêmes (puisqu'ils servent le même but et peuvent donc partager le même sort en cas de problème). La colle (les adresses IP des serveurs) sera de toute façon présente dans la zone parente et l'utilisation d'un seul domaine ne pose donc pas de problème de fiabilité.

Même système pour les serveurs de ip6.arpa (section 3 du RFC) :

• A.IP6-SERVERS.ARPA
• B.IP6-SERVERS.ARPA
• C.IP6-SERVERS.ARPA
• ...

Le nouveau schéma a été déployé quelques mois après la publication du RFC (travail terminé le 7 décembre 2010 pour ip6.arpa et le 18 février 2011, après quelques cafouillages, pour in-addr.arpa) :

% dig NS ip6.arpa.
...
;; ANSWER SECTION:
ip6.arpa.		84600	IN	NS	a.ip6-servers.arpa.
ip6.arpa.		84600	IN	NS	b.ip6-servers.arpa.
ip6.arpa.		84600	IN	NS	c.ip6-servers.arpa.
ip6.arpa.		84600	IN	NS	d.ip6-servers.arpa.
ip6.arpa.		84600	IN	NS	e.ip6-servers.arpa.
ip6.arpa.		84600	IN	NS	f.ip6-servers.arpa.

% dig NS in-addr.arpa.
...
;; ANSWER SECTION:
in-addr.arpa. 29652 IN NS a.in-addr-servers.arpa.
in-addr.arpa. 29652 IN NS c.in-addr-servers.arpa.
in-addr.arpa. 29652 IN NS d.in-addr-servers.arpa.
in-addr.arpa. 29652 IN NS f.in-addr-servers.arpa.
in-addr.arpa. 29652 IN NS e.in-addr-servers.arpa.
in-addr.arpa. 29652 IN NS b.in-addr-servers.arpa.

La gestion de .arpa étant une affaire de gouvernance complexe, la section 4 doit expliquer que l'IAB a donné son accord pour le nouveau schéma, rôle que le RFC 3172 lui attribue.

Notez enfin que ce RFC ne concerne que les sous-domaines de .arpa. Le cas du TLD lui-même a été traité ultérieurement dans le RFC 9120.