Comprendre le NOERROR de dig
Récemment les serveurs DNS D’SFR ont décidé de faire paniquer un client, qui n’avait plus aucun enregistrement A sur sa zone; nous étions en plein recette sur sa nouvelle plateforme, et son site actuel paraissait du coup « en carafe ». En analysant un peu, j’ai découvert une réponse étrange que j’aimerai partager avec vous.
Donc l’agence m’interpelle à propos du domaine après avoir été alertée par le client, leur premier diagnostic semble correct, en effet, plus aucune IP n’est renvoyée sur le domaine principal ou ses différents sous-domaines :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
[seboss666@SebLBNvm ~ ]$ dig client.fr +all ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59247 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: ; udp: 4096 ;; QUESTION SECTION: ;client.fr. IN A ;; AUTHORITY SECTION: client.fr. 3556 IN SOA ns1.sfrbusinessteam.fr. admin.sfrbusinessteam.fr. 2017061902 43200 3600 604800 3600 ;; Query time: 4 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Tue Jun 20 09:44:37 CEST 2017 ;; MSG SIZE rcvd: 104 |
Quel est donc ce NOERROR qu’il nous retourne ? Je connais le NXDOMAIN, mais c’était la première fois. En fouillant les résultats Google j’ai fini par avoir une réponse, une fois de plus en anglais, il me semble donc intéressant d’en parler en Français (et non, notre expert national Stéphane Bortzmeyer ne semble pas en avoir parlé). Et manifestement, contrairement à ce que dig prétend, il y a bien une erreur.
Il se trouve que le code d’erreur associé à NOERROR n’existe tout simplement pas. Mais ce qu’il signifie, c’est qu’il existe des enregistrements sur le domaine interrogé, mais pas celui qu’on recherche. Si je cherche du A, je n’en ai pas, cependant :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
[seboss666@SebLBNvm ~ ]$ dig client.fr +all ANY ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 651 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;client.fr. IN ANY ;; ANSWER SECTION: client.fr. 3307 IN NS ns1.sfrbusinessteam.fr. client.fr. 3307 IN NS ns2.sfrbusinessteam.fr. ;; Query time: 3 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Tue Jun 20 09:48:46 CEST 2017 ;; MSG SIZE rcvd: 94 |
C’est exactement ce que j’ai au dessus, les champs NS existent encore (c’est d’ailleurs les seuls qui restent). La réponse de dig est donc parfaitement logique. Je n’ai pas eu la fin de l’histoire du côté d’SFR, mais bon, j’imagine qu’ils ont compris qu’ils avaient fait de la merde quelque part et qu’il fallait réparer.
Billet intéressant ! Merci.
Je connaissais le NODATA qui précise qu’il existe bien un ou des enregistrements portant le nom spécifié dans la requête DNS mais qu’ils sont d’un type différent de celui spécifié.
Toujours bon à savoir.
🙂