Mon blog

Le DNS repose sur un système de délégation, avec des dépendances qui ne sont pas toujours maitrisées. (Si vous êtes responsables d'un nom de domaine, veillez à connaitre ces dépendances et à les examiner !) Un exemple concret aujourd'hui avec telehouse.fr.

Ce nom de domaine est utilisé par le gérant de centres de données pour certains services à destination des clients (un portail clients, par exemple). Ce matin, il ne répond pas (dans l'après-midi, tout remarchait) :

% dig telehouse.fr
…
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44602
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
…
;; Query time: 4000 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Sep 24 11:13:46 CEST 2024
;; MSG SIZE  rcvd: 41

SERVFAIL signifie SERVer FAILure et, comme ce nom l'indique, c'est mauvais. Si on demande à un autre résolveur DNS qui met en œuvre les rapports d'erreur détaillés (RFC 8914), on a :

  
% dig @1.1.1.1 telehouse.fr   
…
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20599
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; EDE: 22 (No Reachable Authority): (at delegation telehouse.fr.)
…
;; Query time: 4256 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Tue Sep 24 11:14:37 CEST 2024
;; MSG SIZE  rcvd: 74

L'EDE (Extended DNS Error) nous dit que le résolveur n'a pu joindre aucun des serveurs faisant autorité. On va donc devoir creuser. D'abord, quels sont ces serveurs faisant autorité pour telehouse.fr ? Demandons à un des serveurs du domaine parent .fr :

    
% dig @d.nic.fr telehouse.fr 
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21940
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; WARNING: recursion requested but not available
…
;; AUTHORITY SECTION:
telehouse.fr.		3600 IN	NS ns1.fr.kddi.com.
telehouse.fr.		3600 IN	NS ns2.fr.kddi.com.

  

Bien, nous avons les noms de ces serveurs, interrogeons-les :

    
% dig ns1.fr.kddi.com.
…
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20153
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
…
;; Query time: 12 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Sep 24 11:15:12 CEST 2024
;; MSG SIZE  rcvd: 44

  

Ah, raté, on ne peut pas résoudre le nom du serveur de noms. Le serveur est toujours là et, si on connait son adresse IP (par exemple parce qu'elle est encore dans la mémoire du résolveur), on peut l'interroger :

%  dig @85.90.48.10 telehouse.fr
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15119
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
…
;; ANSWER SECTION:
telehouse.fr.		900 IN A 85.90.40.15

  

Bon, et si on n'a pas cette adresse IP ? Demandons au domaine parent :

    
% dig kddi.com NS            
…
;; ANSWER SECTION:
kddi.com.		85645 IN NS dnsa01.kddi.ne.jp.
kddi.com.		85645 IN NS dnsa02.kddi.ne.jp.
kddi.com.		85645 IN NS dns103.kddi.ne.jp.
kddi.com.		85645 IN NS dns104.kddi.ne.jp.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Sep 24 11:15:33 CEST 2024
;; MSG SIZE  rcvd: 131

  

Et interrogeons-les :

    
% dig @dnsa01.kddi.ne.jp. fr.kddi.com  NS
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43194
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available
…
;; AUTHORITY SECTION:
fr.kddi.com.		86400 IN NS ns1.kddi-telehouse.eu.
fr.kddi.com.		86400 IN NS ns2.kddi-telehouse.eu.

;; Query time: 216 msec
;; SERVER: 54.64.39.199#53(dnsa01.kddi.ne.jp.) (UDP)
;; WHEN: Tue Sep 24 11:15:57 CEST 2024
;; MSG SIZE  rcvd: 121

  

Et suivons cette délégation :

% dig ns1.kddi-telehouse.eu.
…
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48644
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
…
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Sep 24 11:16:11 CEST 2024
;; MSG SIZE  rcvd: 50

Bon, même problème, le nom du serveur de noms ne peut pas être résolu. Poursuivons notre quête auprès des serveurs de .eu :

% dig @w.dns.eu. kddi-telehouse.eu. NS 
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26571
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; WARNING: recursion requested but not available
…
;; AUTHORITY SECTION:
kddi-telehouse.eu.	86400 IN NS ns2.validname.com.
kddi-telehouse.eu.	86400 IN NS ns1.validname.com.

Et demandons :

    
% dig @ns1.validname.com kddi-telehouse.eu.
;; communications error to 2a01:c8:ff00:200::219#53: timed out
;; communications error to 2a01:c8:ff00:200::219#53: timed out
;; communications error to 2a01:c8:ff00:200::219#53: timed out
;; communications error to 2a01:c8:ff00:200::220#53: timed out
;; communications error to 185.65.56.219#53: timed out
;; communications error to 185.65.56.220#53: timed out

  

Ah, cette fois, les choses ont changé : on arrive bien à trouver l'adresse IP de ces serveurs, le nom peut être résolu, mais le serveur ne répond pas (idem pour ns2.validname.com).

Arrivé là, il est temps de faire un bilan : le domaine telehouse.fr dépend du domaine fr.kddi.com qui dépend du domaine kddi-telehouse.eu qui dépend de deux serveurs (ns1.validname.com et ns2.validname.com) qui sont en panne. Vu en sens inverse, la panne des validname.com a entrainé celle du domaine kddi-telehouse.eu qui a entrainé celle du domaine fr.kddi.com qui a entrainé celle du domaine telehouse.fr.

La morale ? Soyez attentifs aux dépendances. Si le domaine X.example a tous ses serveurs de noms dans Y.example, une panne de ce dernier sera fatale à X.example. Et cette dépendance est transitive : si Y.example dépend de Z.example, une panne de ce dernier cassera X.example. Pour afficher les dépendances d'un domaine, vous pouvez utiliser l'outil ns-tree :

% ./ns-tree.py telehouse.fr
telehouse.fr
telehouse.fr.
  └─ fr.kddi.com. ← { ns2.fr.kddi.com., ns1.fr.kddi.com. }
     ├─ kddi-telehouse.eu. ← { ns2.kddi-telehouse.eu., ns1.kddi-telehouse.eu. }
     │  └─ validname.com. ← { ns1.validname.com., ns2.validname.com. }
     │     └─ namebay.com. ← { ns1.namebay.com., ns2.namebay.com. }
     │        └─ namebay.com. ← { ns1.namebay.com., ns2.namebay.com. }
     └─ fr.kddi.com. ← { ns2.fr.kddi.com., ns1.fr.kddi.com. }
  

Autre solution, en ligne : https://trans-trust.verisignlabs.com/.

Une note finale : validname.com est géré par Namebay qui a annoncé sur sa page d'accueil une panne DNS :

Cette panne DNS était peut-être liée au passage d'un rançongiciel trois jours auparavant (cf. cet article) :