La recherche de dig ne renvoie pas les serveurs de noms

Un résolveur DNS récursif nécessite que les informations qu'il acquiert de manière récursive soient autoritatives pour les renvoyer en réponse à une requête; il ne fait pas d'inférences.

L'autorité est établie dans le DNS en utilisant des enregistrements SOA et NS. Le premier est utilisé pour établir l'autorité entre les serveurs autoritaires, et il est servi depuis la zone. Par exemple, l'enregistrement SOA indique quelle copie des données de la zone est plus récente lorsque des serveurs DNS autoritaires pour une zone effectuent un transfert de zone. Le second est utilisé pour établir l'autorité lors de la requête.

Lorsqu'un enregistrement NS pour un sous-domaine est dans un domaine, et que le serveur qui le possède n'est pas un serveur autoritaire pour le nom interrogé, cet enregistrement NS est un enregistrement de délégation. Ainsi, le résolveur récursif interrogera les enregistrements de délégation en commençant par la racine .. Dans votre cas, il remonte la chaîne vers cette réponse de dns2.stabletransit.com.:

subdomain.codecrab.org. 300     IN      NS      ns1.macmonster.co.uk.

Il s'agit d'un enregistrement de délégation, car ces données n'existent pas:

subdomain.codecrab.org. 300     IN      NS      dns2.stabletransit.com

Ce qui existait en réalité était ceci:

codecrab.org.           86400   IN      NS      dns2.stabletransit.com.

Ainsi, le serveur à dns2.stabletransit.com. peut donner des réponses autoritatives pour codecrab.org., car le résolveur précédent a délégué cette zone. Mais il n'est pas autoritaire pour subdomain.codecrab.org., donc il ne peut pas répondre à la requête; il peut seulement déléguer.

Les résolveurs DNS peuvent bien sûr être configurés pour être autoritaires pour n'importe quel nom que l'administrateur souhaite. Cependant, s'ils sont configurés pour être autoritaires pour des zones qu'ils essaient de déléguer, ils donneront plutôt des réponses (sans avoir les données), donc cela n'est évidemment pas fait.

Le fonctionnement de la récursion est simple, même si ce n'est pas intuitif au départ. Le résolveur récursif envoie la requête complète aux serveurs de noms pour . (qu'il a dans son fichier d'indices pour la zone racine). Le serveur de noms . envoie une réponse, mais une réponse comporte deux composantes qui nous intéressent pour ce but: la section d'autorité, et la section de réponse (il y a aussi la section additionnelle et la section question). La réponse contiendra des enregistrements comme:

org.                    172800  IN      NS      b0.org.afilias-nst.org.

Cela dit au résolveur récursif de répéter sa requête là-bas, car la zone est déléguée. Cela inclut également des "glue" dans la section additionnelle donnant les adresses IP des serveurs de noms dans la section d'autorité, car il sait que vous ne pourrez pas trouver le serveur de noms pour interroger sinon. Il s'agit d'une décision administrative dans la gestion du DNS; si les enregistrements de glue ne sont pas présents, le résolveur récursif interrogera les enregistrements AAAA ou A pour l'un des serveurs autoritaires avant de procéder.

Ainsi, vous pouvez remarquer que lorsque vous envoyez votre requête IN NS subdomain.codecrab.org. à la dernière délégation, dns2.stabletransit.com., la réponse ressemble à ceci:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35461
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;subdomain.codecrab.org.                IN      NS

;; AUTHORITY SECTION:
subdomain.codecrab.org. 300     IN      NS      ns2.macmonster.co.uk.
subdomain.codecrab.org. 300     IN      NS      ns1.macmonster.co.uk.

;; Query time: 104 msec
;; SERVER: 65.61.188.4#53(65.61.188.4)
;; WHEN: Sat Sep 28 14:50:45 MDT 2013

Remarquez comment vous n'obtenez ni section additionnelle ni section de réponse (mais aussi NOERROR pour le statut de retour). C'est parce que l'enregistrement est une délégation vers ns2.macmonster.co.uk. pour subdomain.codecrab.org., pour laquelle dns2.stabletransit.com. sait qu'il n'est pas autoritaire. Il n'y a pas de section additionnelle car les serveurs de noms sont du côté de co.uk. et administrativement il n'était pas nécessaire d'inclure de glue car ils sont résolus de l'autre côté (bien sûr, de la glue aurait pu être incluse). Donc, pour répondre à votre requête, car la réponse doit venir d'une section de réponse (ce qui signifie qu'elle est identifiée par le serveur répondant comme une réponse, venant de l'autorité), votre résolveur récursif essaiera de trouver ns1.macmonster.co.uk., et en le trouvant à 1.1.1.1, enverra sa requête là-bas.

Bien sûr (puisque cette adresse est dans un préfixe de débogage) il n'y a pas de serveur de noms là-bas (pour l'instant). Quant à ns2.macmonster.co.uk. à 2.2.2.2, si quelqu'un chez Wanadoo France décidait qu'il devrait y avoir un serveur de noms portant des enregistrements autoritaires pour subdomain.codecrab.org. et en particulier:

subdomain.codecrab.org 99999999 IN NS now.go.away.or.i.will.taunt.you.a.second.time.

la moitié du temps (aussi souvent que ce serveur de noms est choisi), la requête renverra now.go.away.or.i.will.taunt.you.a.second.time. comme serveur de noms pour votre zone, même si le bon sens suggérerait que ce devrait être ns2.macmonster.co.uk. (et même si c'était ce dernier serveur de noms qui a donné cette réponse de manière autoritaire).