Toute résolution
Le problème est particulièrement important pour les noms qui
n'existent
Bien qu'il existe aujourd'hui des centaines de sites dans le
monde où se trouve une instance d'un serveur racine, ce nombre
reste faible par rapport au nombre total de réseaux connectés à
l'Internet. Dans certains endroits de la planète, le serveur
racine le plus proche est assez lointain. Voici les
% check-soa -4 -i .
a.root-servers.net.
198.41.0.4: OK: 2015112501 (54 ms)
b.root-servers.net.
192.228.79.201: OK: 2015112501 (236 ms)
c.root-servers.net.
192.33.4.12: OK: 2015112501 (62 ms)
d.root-servers.net.
199.7.91.13: OK: 2015112501 (23 ms)
e.root-servers.net.
192.203.230.10: OK: 2015112501 (18 ms)
f.root-servers.net.
192.5.5.241: OK: 2015112501 (69 ms)
g.root-servers.net.
192.112.36.4: OK: 2015112501 (62 ms)
h.root-servers.net.
128.63.2.53: OK: 2015112501 (153 ms)
i.root-servers.net.
192.36.148.17: OK: 2015112501 (67 ms)
j.root-servers.net.
192.58.128.30: OK: 2015112501 (55 ms)
k.root-servers.net.
193.0.14.129: OK: 2015112501 (72 ms)
l.root-servers.net.
199.7.83.42: ERROR: Timeout
m.root-servers.net.
202.12.27.33: OK: 2015112501 (79 ms)
Ces délais peuvent sembler courts mais ils ne forment qu'une
partie du travail de résolution, il est donc légitime de vouloir
les réduire encore.
En outre, ces requêtes à la racine peuvent être observées, que
ce soit par les opérateurs de serveurs racine, ou par des tiers
sur le projet, ce qui n'est pas forcément souhaitable, question
vie privée (cf.
Donc, l'idée de base de ce RFC est de :
Dans tous les cas, le RFC recommande que la configuration
décrite ici ne soit
Pas découragé ? Vous voulez encore le faire ? Alors, les
détails pratiques. D'abord (section 2 du RFC), les
pré-requis.
Il est important de lister plusieurs serveurs maîtres dans sa
configuration. En effet, si la mise à jour de la racine dans votre
serveur esclave échoue, ce sera catastrophique (signatures
Il est donc important d'avoir un mécanisme de supervision, pour être prévenu si quelque chose échoue. On peut par exemple interroger le numéro de série dans l'enregistrement SOA de la racine et vérifier qu'il change.
Ensuite, une fois ce serveur faisant autorité configuré, il ne
reste qu'à indiquer à un résolveur (comme
Voici un exemple, pris dans l'annexe B du RFC et testé. J'ai
choisi l'exemple avec
# RFC 7706
server:
ip-address: 127.12.12.12
zone:
name: "."
request-xfr: 192.228.79.201 NOKEY # b.root-servers.net
request-xfr: 192.33.4.12 NOKEY # c.root-servers.net
request-xfr: 192.5.5.241 NOKEY # f.root-servers.net
request-xfr: 192.112.36.4 NOKEY # g.root-servers.net
request-xfr: 193.0.14.129 NOKEY # k.root-servers.net
request-xfr: 192.0.47.132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 192.0.32.132 NOKEY # xfr.lax.dns.icann.org
request-xfr: 2001:500:84::b NOKEY # b.root-servers.net
request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net
request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net
request-xfr: 2620:0:2830:202::132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 2620:0:2d0:202::132 NOKEY # xfr.lax.dns.icann.org
Le démarrage de NSD (notez qu'il faut patienter un peu la première
fois, le temps que le premier transfert de zone se passe) :
Nov 25 19:50:43 machine-locale nsd[2154]: [2015-11-25 19:50:43.791] nsd[2175]: notice: nsd started (NSD 4.1.2), pid 2154
Nov 25 19:50:56 machine-locale nsd[2154]: zone . serial 0 is updated to 2015112501.
Nov 25 19:50:56 machine-locale nsd[2154]: [2015-11-25 19:50:56.166] nsd[2154]: info: zone . serial 0 is updated to 2015112501.
C'est bon, on a transféré la zone. Testons (notez le bit AA
-
>HEADER<<- opcode: QUERY, status: NOERROR, id: 61984
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 25
...
;; ANSWER SECTION:
. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. (
2015112501 ; serial
...
]]>
C'est bon.
Maintenant, la configuration d'Unbound (prise dans le RFC) :
server:
# RFC 7706
do-not-query-localhost: no
# RFC 7706
# Requires a slave auth. running (normally, nsd)
stub-zone:
name: "."
stub-prime: no
stub-addr: 127.12.12.12
Et le test :
>HEADER<<- opcode: QUERY, status: NOERROR, id: 23562
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3
...
;; ANSWER SECTION:
www.cnam.fr. 0 IN CNAME sarek.cnam.fr.
sarek.cnam.fr. 86400 IN A 163.173.128.52
]]>
Ça a marché. Avec
08:37:24.869569 IP (tos 0x0, ttl 64, id 7734, offset 0, flags [none], proto UDP (17), length 76)
127.0.0.1.10908 > 127.12.12.12.53: 42633% [1au] A? www.tunisair.com.tn. (48)
08:37:24.869671 IP (tos 0x0, ttl 64, id 12657, offset 0, flags [none], proto UDP (17), length 685)
127.12.12.12.53 > 127.0.0.1.10908: 42633- 0/8/13 (657)
08:38:04.734565 IP (tos 0x0, ttl 64, id 12887, offset 0, flags [none], proto UDP (17), length 71)
127.0.0.1.45221 > 127.12.12.12.53: 25787% [1au] A? www.edreams.es. (43)
08:38:04.734645 IP (tos 0x0, ttl 64, id 19270, offset 0, flags [none], proto UDP (17), length 749)
127.12.12.12.53 > 127.0.0.1.45221: 25787- 0/10/14 (721)
08:38:04.734867 IP (tos 0x0, ttl 64, id 12888, offset 0, flags [none], proto UDP (17), length 70)
127.0.0.1.40575 > 127.12.12.12.53: 61589% [1au] AAAA? ns-ext.nic.cl. (42)
08:38:04.734932 IP (tos 0x0, ttl 64, id 19271, offset 0, flags [none], proto UDP (17), length 622)
127.12.12.12.53 > 127.0.0.1.40575: 61589- 0/8/11 (594)
08:44:00.366698 IP (tos 0x0, ttl 64, id 27563, offset 0, flags [none], proto UDP (17), length 62)
127.0.0.1.22009 > 127.12.12.12.53: 30565% [1au] A? po.st. (34)
08:44:00.389126 IP (tos 0x0, ttl 64, id 34039, offset 0, flags [none], proto UDP (17), length 404)
127.12.12.12.53 > 127.0.0.1.22009: 30565- 0/6/5 (376)
08:44:01.229635 IP (tos 0x0, ttl 64, id 27693, offset 0, flags [none], proto UDP (17), length 69)
127.0.0.1.65173 > 127.12.12.12.53: 32911% [1au] AAAA? ns3.perf1.eu. (41)
08:44:01.229705 IP (tos 0x0, ttl 64, id 34207, offset 0, flags [none], proto UDP (17), length 560)
127.12.12.12.53 > 127.0.0.1.65173: 32911- 0/8/10 (532)
Pour
À noter qu'il existe un