Re: RFC 5855: Nameservers for IPv4 and IPv6 Reverse Zones

2010/5/24 Stephane Bortzmeyer <[email protected]>

> 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.
>
>
Bonjour,

Petites questions.
Pourquoi il y a quelques années on avait également ip6.int. Il fallait à la
fois définir le PTR en ip6.int et ip6.arpa. Pour quelle raison le ip6.int a
été abandonné au profit du .arpa ?

Cdt,
Nicolas