Les serveurs DNS, notamment ceux de la
racine, sont en permanence bombardés par un
trafic « inutile », des demandes de résolution DNS d'origine locale,
et qui n'auraient jamais dû sortir. Par exemple, dans les réseaux qui
utilisent les adresses IP privées du RFC 1918,
les demandes de « résolution inverse » (« quel est le nom
correspondant à 192.168.24.66 ? ») devraient
toujours être
résolues localement (après tout, il s'agit d'adresses privées) mais
souvent les gestionnaires de ces réseaux ne configurent pas
correctement leurs résolveurs et paf, la requête
66.24.168.192.in-addr.arpa arrive à la racine,
qui ne peut pas en faire grand'chose. Idem si un réseau local utilise
(bien à
tort) un TLD local comme
.home ou .corp. Les requêtes
pour des TLD inexistants font plus de 25 % du trafic
atteignant la racine. Pour les noms correspondants aux adresses du
RFC 1918, le problème a été réglé par la
création d'un « puits DNS », l'AS112 (RFC 7534). Les serveurs de l'AS112 sont des
machines sacrifiées, à qui on envoie toutes les requêtes pour les noms
en in-addr.arpa correspondant au RFC 1918. Cela marche très bien depuis de nombreuses
années. Tellement bien qu'on se dit qu'on pourrait jeter dans ce puits
bien d'autres choses comme les équivalents IPv6
du RFC 1918 (d.f.ip6.arpa,
par exemple, cf. RFC 4193), ou comme les TLD tel que
.home. Seulement, voilà, l'AS112 n'a pas été
prévu pour cela et, avec leur configuration actuelle, ses serveurs
ne répondraient pas correctement à ces requêtes. Il suffit de changer
cette configuration ? Plus facile à dire qu'à faire, car l'AS112 est
composé de nombreux serveurs plus ou moins coordonnés. Il est
probablement impossible de les reconfigurer tous. D'où la nouvelle
technique, utiliser (pour la première fois en grand) les
enregistrements DNAME.
La nature même de l'AS112, système très décentralisé, sans
direction claire,
fait qu'il est impossible de
changer la configuration de tous les nœuds. Même si l'IETF, l'ARCEP,
l'ICANN, la NSA, le
CSA et Jean-Kevin étaient tous d'accord,
on ne pourrait pas garantir qu'il ne traine pas des nœuds AS112 ayant
l'ancienne liste. Et puis on ne veut pas faire juste un changement une
fois. On voudrait davantage de souplesse, permettant d'ajouter (ou de
retirer) des
noms à l'AS112 facilement, sans passer à chaque fois des mois, voire
des années, à rappeler aux gérants des serveurs AS112 qu'ils doivent
changer leur configuration.
Comme toujours avec l'AS112, l'idéal serait que les
administrateurs DNS fassent tous correctement leur travail et suivent
le RFC 6303, qui leur impose de servir des zones
comme *.168.192.in-addr.arpa localement. Mais,
dans le monde réel, ça n'arrive pas et l'AS112 (nommé, j'ai oublié de
le dire, d'après le numéro de système autonome
qui lui a été attribué) reste
indispensable.
On a vu plus haut que l'AS112 n'était que faiblement
coordonné. Ses serveurs sont anycastés (RFC 4786) et composés de nombreuses
machines, administrées par des personnes différentes. Si on décidait de déléguer, mettons,
.home, aux serveurs de l'AS112,
blackhole-1.iana.org et
blackhole-2.iana.org, certaines des instances de
ces deux serveurs seront correctement configurées et répondront, à
juste titre, NXDOMAIN (ce domaine n'existe pas :
c'est la réponse unique de l'AS112). Mais d'autres instances,
administrées avec retard, ou gérées par des gens surmenés qui ont raté
l'annonce faite sur la liste des gérants AS112, ne sauront pas qu'elles doivent répondre
aux requêtes pour *.home. Elles seront en
lame delegation, avec des résultats plus ou moins
bons (selon le logiciel utilisé) tels qu'une réponse
REFUSED (qui poussera les résolveurs à essayer un
autre serveur de la zone, alors que l'objectif était au contraire de
diminuer le trafic).
L'IETF a donc choisi une voie différente pour l'évolution de l'AS112 : créer un nouveau préfixe, qui recevra les délégations des
nouveaux in-addr.arpa,
ip6.arpa, TLD, etc. Les nœuds utilisant ce nouveau
préfixe utiliseront une nouvelle technique, à base de
DNAME (RFC 6672), pour ne
pas avoir à être configuré avec la liste des domaines à servir. Cela
permettra de faire évoluer cette liste, ce qui est
organisationnellement impossible avec les préfixes actuels de l'AS112.
Un enregistrement DNAME dit qu'une zone est un alias d'une
autre. Ainsi :
example.com. DNAME example.net.
va faire que tous les noms sous
example.com (mais
pas
example.com lui-même, attention), sont les
alias des noms correspondants en
example.net. Si
on veut trouver l'adresse IPv6 associée à
foobar.example.com, le résolveur DNS, en trouvant
le DNAME, fera une requête pour
foobar.example.net et en transmettra le résultat
à l'utilisateur.
La nouvelle zone de l'AS112 se nomme empty.as112.arpa
et elle est déléguée à un seul serveur (anycasté),
blackhole.as112.arpa
(192.31.196.1 /
2001:4:112::1). Ce serveur n'a
pas les mêmes adresses que les serveurs
traditionnels de l'AS112, il y aura deux jeux de serveurs
complètement différents, puisqu'ils auront une configuration distincte
(une liste fixée de domaines pour les anciens serveurs, cf. RFC 6304, et une seule zone, la cible des DNAME,
pour les nouveaux serveurs). Certains serveurs pourront faire partie
des deux jeux à la fois (par exemple des anciens serveurs qui seraient
modifiés pour gérer les nouvelles adresses en même temps que les
anciennes). L'ancien AS112 continue à fonctionner comme avant. Les
nouveaux préfixes anycast correspondants sont 192.31.196.0/24 et
2001:4:112::/48, qui ne servent qu'à l'AS112. (Vous pouvez les chercher dans le looking
glass de votre choix. L'AS d'origine sera le
112. L'AS112 est désormais à l'origine de quatre préfixes.)Ces adresses IP du serveur du nouvel AS112 ont été enregistrées dans
le registre des adresses spéciales créé
par le RFC 6890.
Donc, si vous voulez rediriger une zone DNS vers le puits du nouvel
AS112, il suffit d'en faire un DNAME de
empty.as112.arpa. Oui, aucun besoin de prévenir
qui que ce soit, ou de demander une autorisation, vous n'avez qu'à
ajouter cet enregistrement.
Un petit mot pour les fanas de gouvernance :
le RFC 3172 confie la gestion politique de
.arpa à
l'IAB et c'est donc celle-ci qui a eu à
approuver, sinon ce RFC, du moins le domaine dont il avait besoin, as112.arpa.
À l'heure actuelle, je n'ai pas l'impression qu'il y ait déjà des
redirections vers empty.as112.arpa (en tout cas,
DNSDB n'en trouve pas). Il faut dire
qu'il y a encore peu de serveurs dans le nouvel AS112. Une fois qu'il
sera peuplé, et pourra donc gérer le trafic, on pourra mettre des
redirections. Rappelez-vous que l'installation d'une redirection ne
nécessite aucun changement dans les serveurs du nouvel AS112. Pour
tester, vous pouvez utiliser ma zone
sink.bortzmeyer.fr. Normalement,
nimportequoi.sink.bortzmeyer.fr doit vous obtenir
un NXDOMAIN de la part du serveur AS112 « le plus
proche ». Voici, vu par les sondes
Atlas les différentes réponses possibles pour le nouvel AS112,
ce qui semble indiquer qu'il n'a que quatre serveurs :
% python resolve-name.py -t SOA empty.as112.arpa
Measurement #2004698 for empty.as112.arpa/SOA uses 497 probes
[] : 11 occurrences
[as112.ottix.net. dns.ottix.net. 1 604800 60 604800 604800] : 2 occurrences
[blackhole.as112.arpa. dns.ripe.net. 1 604800 60 604800 604800] : 226 occurrences
[as112.hivane.net. info.hivane.net. 1 604800 60 604800 604800] : 184 occurrences
[blackhole.as112.arpa. noc.dns.icann.org. 1 604800 60 604800 604800] : 60 occurrences
Test done at 2015-05-14T10:59:36Z
Et l'ancien AS112 ? Il continue à fonctionner comme avant. Si le
nouvel AS112 marche bien, s'il est largement peuplé, on pourra
changer les actuelles délégations des zones RFC 1918 comme 10.in-addr.arpa et les
remplacer par une redirection DNAME vers
empty.as112.arpa, le nouvel AS112. Une fois que
cela sera fait, l'ancien AS112 et ses serveurs blackhole-1.iana.org et
blackhole-2.iana.org pourront être supprimés. Il
n'y a toutefois pas de plan précis pour cela : il faut d'abord que le
nouvel AS112 fasse ses preuves.
Quelles zones seront mises dans le nouvel AS112 ? Comme indiqué
plus haut, n'importe quelle zone peut être déléguée au nouvel AS112 de
manière unilatérale. Mais ce service est surtout utile pour les zones
à fort trafic, comme celles listées dans le RFC 6303 (qui ne sont pas toutes dans l'ancien AS112, par
exemple aucune zone en ip6.arpa n'y est) ou comme
certains TLD (les plus importants à l'heure actuelle sont, dans
l'ordre, .local, .home,
.html, .localdomain et
.internal). Dans le cas des TLD, toutefois, il est probable que l'incroyable
bureaucratie ICANN et la mainmise du
gouvernement états-unien sur le contenu de la racine ne retardent
considérablement le projet.
Le choix d'utiliser DNAME n'a pas été sans mal. En effet, DNAME ne
fait pas partie du DNS original, et ce n'est
pas un simple type d'enregistrement pour des données passives, il
nécessite un traitement spécifique dans les résolveurs (et, dans une
certaine mesure, dans les serveurs faisant autorité). On ne peut donc
pas compter sur 100 % de serveurs DNS gérant DNAME. Est-ce un
problème ? Le RFC 6672 prévoit un mécanisme de
secours, où l'enregistrement DNAME est accompagné d'un CNAME (les
alias classiques) synthétisé à la demande par le serveur. En théorie,
tout doit donc bien se passer, même dans un monde imparfait où tous
les serveurs ne gèrent pas DNAME. Et en pratique ? L'annexe A décrit
les expérimentations qui avaient été faites avant de choisir la
solution DNAME (quelques autres avaient été proposées).
Le test avait consisté en quatre images sur une
page Web que devait charger les navigateurs. La page était distribuée sous forme
d'une publicité payante, envoyée par la régie publicitaire à de nombreux
navigateurs. Le premier URL,
http://a.UNIQUE_STRING.dname.example.com/1x1.png?a.UNIQUE_STRING.dname
utilise un domaine qui a un DNAME vers un autre domaine. Si tout
l'Internet peut travailler avec des DNAME sans problème, l'image
correspondante sera chargée dans 100 % des cas. (La chaîne de
caractères UNIQUE_STRING est la même pour toutes les images mais varie
à chaque chargement de la page. C'est donc l'identificateur d'un test donné.) Le second URL,
http://b.dname.example.com/1x1.png?b.UNIQUE_STRING.dname,
qui, contrairement au premier, utilise un nom de domaine qui a un DNAME,
et qui n'a pas de partie unique et est donc
fréquemment mis en cache. Le troisième URL,
http://c.UNIQUE_STRING.target.example.net/1x1.png?c.UNIQUE_STRING.target,
ressemble beaucoup au premier mais n'utilise pas du tout de
DNAME. C'est du DNS on ne peut plus traditionnel, et il sert donc de
contrôle : si le score est de moins de 100 % sur cette troisième
image, c'est que le navigateur, la machine sur laquelle il tourne, ou
bien le réseau qui l'héberge, ont d'autres problèmes que les
DNAME. Un
script en Flash dans la page mesure le résultat et le temps nécessaire pour
l'obtenir. Enfin, une quatrième image, http://results.recorder.example.net/1x1.png?
results.UNIQUE_STRING?za=FIRST_RESULT&zb=SECOND_RESULT&zc=THIRD_RESULT,
sert juste à transmettre les résultats. Le
journal du serveur HTTP ressemblera à :
GET /1x1.png?results.UNIQUE_STRING?za=1822&zb=1674&zc=1582
(Les chiffres sont les temps de chargement en millisecondes.)
Les résultats ? 98,1 % des tests ont permis le chargement de la
première ou de la seconde image, celles qui utilisaient les DNAME. Il
y a donc 1,9 % de clients qui ne peuvent pas utiliser les DNAME ? Non,
car 2,8 % des tests de chargement de la troisième image (qui n'utilise
pas de DNAME, que du DNS d'avant-guerre) ont également échoué. Ce qui
montre que ce chiffre de 1,9 % est inférieur au pourcentage d'erreur
(soubresauts du réseau, etc). Bref, les DNAME marchent très bien.
À noter que les serveurs du nouvel AS112, eux, n'ont aucun besoin
de savoir gérer les DNAME. Seuls les résolveurs, et les serveurs
faisant autorité pour les zones redirigées doivent le faire.
Le as112.arpa a été délégué début février 2015 :
% check-soa -i as112.arpa
a.iana-servers.net.
199.43.132.53: OK: 2014122469 (2 ms)
2001:500:8c::53: OK: 2014122469 (14 ms)
b.iana-servers.net.
199.43.133.53: OK: 2014122469 (149 ms)
2001:500:8d::53: OK: 2014122469 (156 ms)
c.iana-servers.net.
2001:500:8e::53: OK: 2014122469 (13 ms)
199.43.134.53: OK: 2014122469 (15 ms)
Et son fils :
% check-soa -i empty.as112.arpa
blackhole.as112.arpa.
2001:4:112::1: OK: 1 (31 ms)
192.31.196.1: OK: 1 (23 ms)
Voici une réponse actuelle pour le nouveau domaine :
% dig ANY empty.as112.arpa
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ANY empty.as112.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30414
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;empty.as112.arpa. IN ANY
;; ANSWER SECTION:
empty.as112.arpa. 604800 IN SOA blackhole.as112.arpa. dns.ripe.net. (
1 ; serial
604800 ; refresh (1 week)
60 ; retry (1 minute)
604800 ; expire (1 week)
604800 ; minimum (1 week)
)
empty.as112.arpa. 3599 IN RRSIG NSEC 8 3 3600 20150515204633 (
20150508164936 52494 as112.arpa.
lZf9d6oYISRAq8i6gLXXCwUoQP+qmOfAEIiY3hNr6PvD
DE1kSeGGR3lo3fK6P/CajYv/8twZm/CNQvpAxlRLUyrY
Hc2WHhgxCtiQx01pLrY9d/QRhiL1WqYZaMSrfNZX0H0S
GUD1BOcVNzT/lYPz0EdZZKzEXle98ZGWwkIvewE= )
empty.as112.arpa. 3599 IN NSEC hostname.as112.arpa. NS RRSIG NSEC
empty.as112.arpa. 3599 IN NS blackhole.as112.arpa.
;; AUTHORITY SECTION:
empty.as112.arpa. 3599 IN NS blackhole.as112.arpa.
;; ADDITIONAL SECTION:
blackhole.as112.arpa. 3599 IN A 192.31.196.1
blackhole.as112.arpa. 3599 IN AAAA 2001:4:112::1
blackhole.as112.arpa. 3599 IN RRSIG A 8 3 3600 20150516053029 (
20150508164936 52494 as112.arpa.
B4eU9u5ZQVGf+Haro2CeCanWwFLeK3hvil8dIlpz1fMm
xR8K1No4rWTV5hWME1GhFatZVgpATfat9A3rghGWB9Xm
hcmsaE5uHTOB+56DNhiokWsVtj+WT828naDMlfvGWiP4
cXIxF/tLcR10XYviczlKYYR/SgAVxgmwjFkBHXg= )
blackhole.as112.arpa. 3599 IN RRSIG AAAA 8 3 3600 20150515212644 (
20150508164936 52494 as112.arpa.
Yk2l+kWkYbYruCNHIKZwGg8GZPDp9y5Qezqk+Ogq5rGF
/3+R/UjPPw240zdnLi4D2DeBFwlvM8rDq0xt3sreEmdk
jMdxGcAc8eEfM6O1heP7lgRJW4eCzwOdNX6f1IXEIerg
XwYWu+3VjI6y4NsrYoczfo+ORAHsdUvz9rdYumk= )
;; Query time: 854 msec
;; SERVER: 217.70.184.225#53(217.70.184.225)
;; WHEN: Fri May 8 20:43:04 2015
;; MSG SIZE rcvd: 726
