RFC 5855: Nameservers for IPv4 and IPv6 Reverse Zones

http://www.bortzmeyer.org/5855.html

----------------------------

Auteur(s) du RFC: J. Abley (ICANN), T. Manderson (ICANN)


----------------------------


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 dcérit 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 ? 
Aujourd'hui, les serveurs de noms de ces domaines sont 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 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 seront tous dans un domaine dédié et auront 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 seront 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
* ...
Dans les deux cas, le nouveau schéma n'a pas encore été déployé le 24 
mai 2010, jour de la publication du RFC.

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 atttribue.