Ce
Parmi ces techniques, l'utilisation d'un grand nombre de
Outre l'aspect technique, un autre intéret de Yeti était qu'il
s'agissait d'un projet international. Réellement international,
pas seulement des états-uniens et des européens de divers pays !
Yeti est d'inspiration chinoise, la direction du projet était
faite en Chine, aux États-Unis et au Japon, et parmi les équipes
les plus impliquées dans le projet, il y avait des Russes, des
Indiens, des Français, des Chiliens… Le projet, on l'a dit, était surtout
technique (même si certains participants pouvaient avoir des
arrière-pensées) et la zone racine servie par Yeti était donc
exactement la même que celle de l'
L'annexe E du RFC est consacrée aux controverses sur le
principe même du projet Yeti. Le projet a toujours été discuté en
public, et présenté à de nombreuses réunions. Mais il y a toujours
des râleurs, affirmant par exemple que ce projet était une racine
alternative (ce qui n'est pas faux mais attendez, lisez jusqu'au
bout) et qu'il violait donc le
La racine du
Mais le point important est que la racine est un système en
production, avec lequel on ne peut pas expérimenter à loisir. D'où
l'idée, portée notamment par BII, mais aussi
par TISF et
Au passage, puisqu'on parle d'un projet international, il faut
noter que ce
Parmi les idées testées sur Yeti (section 3 du RFC) :
La section 4 du RFC décrit l'infrastructure de Yeti. Elle a
évidemment changé plusieurs fois, ce qui est normal pour un
service voué aux expérimentations. Yeti utilise l'architecture
classique du DNS. Les serveurs racine sont remplacés par ceux de
Yeti, les autres serveurs faisant autorité (ceux de
Voici la configuration de mon résolveur à la maison, avec
Knot sur une
config resolver 'common'
option keyfile '/etc/kresd/yeti-root.keys'
option prefered_resolver 'kresd'
config resolver 'kresd'
option rundir '/tmp/kresd'
option log_stderr '1'
option log_stdout '1'
option forks '1'
option include_config '/etc/kresd/custom.conf'
et
hints.root({
['bii.dns-lab.net.'] = '240c:f:1:22::6',
['yeti-ns.tisf.net .'] = '2001:4f8:3:1006::1:4',
['yeti-ns.wide.ad.jp.'] = '2001:200:1d9::35',
['yeti-ns.as59715.net.'] = '2a02:cdc5:9715:0:185:5:203:53',
['dahu1.yeti.eu.org.'] = '2001:4b98:dc2:45:216:3eff:fe4b:8c5b',
['ns-yeti.bondis.org.'] = '2a02:2810:0:405::250',
['yeti-ns.ix.ru .'] = '2001:6d0:6d06::53',
['yeti.bofh.priv.at.'] = '2a01:4f8:161:6106:1::10',
['yeti.ipv6.ernet.in.'] = '2001:e30:1c1e:1::333',
['yeti-dns01.dnsworkshop.org.'] = '2001:1608:10:167:32e::53',
['yeti-ns.conit.co.'] = '2604:6600:2000:11::4854:a010',
['dahu2.yeti.eu.org.'] = '2001:67c:217c:6::2',
['yeti.aquaray.com.'] = '2a02:ec0:200::1',
['yeti-ns.switch.ch.'] = '2001:620:0:ff::29',
['yeti-ns.lab.nic.cl.'] = '2001:1398:1:21::8001',
['yeti-ns1.dns-lab.net.'] = '2001:da8:a3:a027::6',
['yeti-ns2.dns-lab.net.'] = '2001:da8:268:4200::6',
['yeti-ns3.dns-lab.net.'] = '2400:a980:30ff::6',
['ca978112ca1bbdcafac231b39a23dc.yeti-dns.net.'] = '2c0f:f530::6',
['yeti-ns.datev.net.'] = '2a00:e50:f15c:1000::1:53',
['3f79bb7b435b05321651daefd374cd.yeti-dns.net.'] = '2401:c900:1401:3b:c::6',
['xn--r2bi1c.xn--h2bv6c0a.xn--h2brj9c.'] = '2001:e30:1c1e:10::333',
['yeti1.ipv6.ernet.in.'] = '2001:e30:187d::333',
['yeti-dns02.dnsworkshop.org.'] = '2001:19f0:0:1133::53',
['yeti.mind-dns.nl.'] = '2a02:990:100:b01::53:0'
})
Au bureau, avec
server:
auto-trust-anchor-file: "/var/lib/unbound/yeti.key"
root-hints: "yeti-hints"
Et
Comme Yeti s'est engagé à ne pas modifier le contenu de la zone
racine (liste des
>HEADER<<- opcode: QUERY, status: NOERROR, id: 45919
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
. 86400 IN SOA www.yeti-dns.org. bii.yeti-dns.org. (
2018121600 ; serial
1800 ; refresh (30 minutes)
900 ; retry (15 minutes)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
. 86400 IN RRSIG SOA 8 0 86400 (
20181223050259 20181216050259 46038 .
BNoxqfGq5+rBEdY4rdp8W6ckNK/GAOtBWQ3P36YFq5N+
...
;; Query time: 44 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 16 16:01:27 CET 2018
;; MSG SIZE rcvd: 369
]]>
(Notez que l'adresse du responsable de la zone indique le
DM qui a été utilisé par ce résolveur particulier. Un autre
résolveur pourrait montrer un autre SOA, si le DM était différent.)
Comme les serveurs racine « officiels » n'envoient pas de message
/tmp/root.zone
% head -n 25 /tmp/root.zone
; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> @k.root-servers.net AXFR .
; (2 servers found)
;; global options: +cmd
. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. (
2018121600 ; serial
1800 ; refresh (30 minutes)
900 ; retry (15 minutes)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
. 172800 IN DNSKEY 256 3 8 (
AwEAAdp440E6Mz7c+Vl4sPd0lTv2Qnc85dTW64j0RDD7
...
]]>
De son côté, l'
Pour l'étape de signature de la zone, Yeti a testé plusieurs
façons de répartir le travail entre les trois DM
(
La configuration chez les DM et leur usage de
Les serveurs racine de Yeti n'ont plus ensuite qu'à récupérer
la zone depuis un des DM ; chaque serveur racine peut utiliser
n'importe quel DM et en changer, de façon à éviter de dépendre du
bon fonctionnement d'un DM particulier. Voici par exemple la
configuration d'un serveur
server:
ip-address: 2001:4b98:dc2:45:216:3eff:fe4b:8c5b
nsid: "ascii_dahu1.yeti.eu.org"
# RFC 8201
ipv6-edns-size: 1460
zone:
name: "."
outgoing-interface: 2001:4b98:dc2:45:216:3eff:fe4b:8c5b
# We use AXFR (not the default, IXFR) because of http://open.nlnetlabs.nl/pipermail/nsd-users/2016-February/002243.html
# BII
request-xfr: AXFR 240c:f:1:22::7 NOKEY
allow-notify: 240c:f:1:22::7 NOKEY
# TISF
request-xfr: AXFR 2001:4f8:3:1006::1:5 NOKEY
allow-notify: 2001:4f8:3:1006::1:5 NOKEY
# WIDE
request-xfr: AXFR 2001:200:1d9::53 NOKEY
allow-notify: 2001:200:1d9::53 NOKEY
Notez que la configuration réseau était un peu plus complexe, la
machine ayant deux interfaces, une de service, pour les requêtes
DNS, et une d'aministration, pour se connecter via
Contrairement aux serveurs de la racine « officielle », qui
sont tous sous le domaine
Une des conséquences est que la réponse initiale à un résolveur
(
% dig @bii.dns-lab.net. NS .
...
;; SERVER: 240c:f:1:22::6#53(240c:f:1:22::6)
;; MSG SIZE rcvd: 1591
On voit qu'elle dépasse la
Au moment de la publication du RFC, Yeti avait 25 serveurs
racine gérés dans 16 pays différents (section 4.6 du RFC), ici vus
par check-soa
(rappelez-vous qu'ils n'ont que des adresses
% check-soa -i .
3f79bb7b435b05321651daefd374cd.yeti-dns.net.
2401:c900:1401:3b:c::6: OK: 2018121400 (334 ms)
bii.dns-lab.net.
240c:f:1:22::6: OK: 2018121400 (239 ms)
ca978112ca1bbdcafac231b39a23dc.yeti-dns.net.
2c0f:f530::6: OK: 2018121400 (170 ms)
dahu1.yeti.eu.org.
2001:4b98:dc2:45:216:3eff:fe4b:8c5b: OK: 2018121400 (18 ms)
dahu2.yeti.eu.org.
2001:67c:217c:6::2: OK: 2018121400 (3 ms)
ns-yeti.bondis.org.
2a02:2810:0:405::250: OK: 2018121400 (24 ms)
xn--r2bi1c.xn--h2bv6c0a.xn--h2brj9c.
2001:e30:1c1e:10::333: OK: 2018121400 (188 ms)
yeti-ns.as59715.net.
2a02:cdc5:9715:0:185:5:203:53: OK: 2018121400 (43 ms)
yeti-ns.datev.net.
2a00:e50:f155:e::1:53: OK: 2018121400 (19 ms)
yeti-ns.ix.ru.
2001:6d0:6d06::53: OK: 2018121400 (54 ms)
yeti-ns.lab.nic.cl.
2001:1398:1:21::8001: OK: 2018121400 (228 ms)
yeti-ns.switch.ch.
2001:620:0:ff::29: OK: 2018121400 (16 ms)
yeti-ns.tisf.net.
2001:4f8:3:1006::1:4: OK: 2018121400 (175 ms)
yeti-ns.wide.ad.jp.
2001:200:1d9::35: OK: 2018121400 (258 ms)
yeti-ns1.dns-lab.net.
2400:a980:60ff:7::2: OK: 2018121400 (258 ms)
yeti-ns2.dns-lab.net.
2001:da8:268:4200::6: OK: 2018121400 (261 ms)
yeti-ns3.dns-lab.net.
2400:a980:30ff::6: OK: 2018121400 (268 ms)
yeti.aquaray.com.
2a02:ec0:200::1: OK: 2018121400 (4 ms)
yeti.bofh.priv.at.
2a01:4f8:161:6106:1::10: OK: 2018121400 (31 ms)
yeti.ipv6.ernet.in.
2001:e30:1c1e:1::333: OK: 2018121400 (182 ms)
yeti.jhcloos.net.
2001:19f0:5401:1c3::53: OK: 2018121400 (108 ms)
yeti.mind-dns.nl.
2a02:990:100:b01::53:0: OK: 2018121400 (33 ms)
Notez que l'un d'eux a un nom
Pour tester que la racine Yeti fonctionnait vraiment, il ne suffisait évidemment pas de faire quelques dig, check-soa et tests avec les sondes RIPE Atlas. Il fallait un trafic plus réaliste. Certains résolveurs (dont les miens, à la maison et au bureau) ont été configurés pour utiliser la racine Yeti et fournissaient donc un trafic réel, quoique faible. En raison des caches des résolveurs, le trafic réel ne représentait que quelques dizaines de requêtes par seconde. Il était difficile d'augmenter ce nombre, Yeti étant une racine expérimentale, où des choses risquées étaient tentées, on ne pouvait pas utiliser des résolveurs de production. Il a donc fallu aussi injecter du trafic artificiel.
Tout le trafic atteignant les serveurs racines Yeti était
capturé (c'est une autre raison pour laquelle on ne pouvait pas
utiliser les résolveurs de production ; Yeti voyait toutes leurs
requêtes à la racine) et étudié. Pour la capture, des outils comme
dnscap ou
pcapdump
(avec un petit
patch) étaient utilisés pour produire des
La section 5 du RFC décrit les problèmes opérationnels qu'a
connu Yeti. Si vous voulez tous les détails, vous pouvez regarder
les
archives de la liste de diffusion du projet, et le blog du
projet. D'abord, ce qui concerne
En pratique, le meilleur contournement de ce problème est de
réduire la taille maximale des réponses
ipv6-edns-size: 1460
Les réponses resteront à moins de 1 460 octets et ne seront donc
en général pas fragmentées.
Les transferts de zone depuis les DM ont levé quelques
problèmes. Les zones sont légèrement différentes d'un DM à l'autre
(SOA et surtout signatures). Les transferts de zone
incrémentaux (IXFR,
Lors des essais de remplacement de la KSK (on sait que, depuis
la parution de ce RFC, la KSK
de la racine « officielle » a été successivement
remplacée le 11 octobre 2018) quelques problèmes sont
survenus. Par exemple, la documentation de BIND n'indiquait pas,
lorsque le résolveur utilise l'option
La capture du trafic DNS avec les serveurs racine Yeti a
entrainé d'autres problèmes (section 5.4 du RFC). Il existe
plusieurs façons d'enregistrer le trafic d'un serveur de noms, de
la plus courante (
Les serveurs racine changent de temps en temps. Dans la racine
« officielle », les changements des noms sont très rares. En
effet, pour des raisons politiques, on ne peut pas modifier la
liste des organisations qui gèrent un serveur racine. Vouloir
ajouter ou retirer une organisation déclencherait une crise du
genre « pourquoi lui ? ». L'
Mais Yeti est différent : les changements sont beaucoup plus
fréquents et, avec eux, le risque que la liste connue par les
résolveurs dévie trop. D'où la création d'un outil spécial, hintUpdate
(personnellement, je ne l'ai jamais utilisé, je modifie la
configuration du résolveur, c'est tout). Un point intéressant
d'hintUpdate est qu'il dépend de
Dernier problème, et rigolo, celui-ci, la compression
inutile. En utilisant le logiciel
La conclusion du RFC, en section 6, rappelle l'importance de
disposer de bancs de test, puisqu'on ne peut pas faire courir de
risques à la racine de production. La conclusion s'achève en
proposant de chercher des moyens de rendre le DNS moins dépendant
de la racine actuelle. Et, vu la mode actuelle, le mot de