Pourquoi le DNS ne se résout-il pas après un changement de serveur de noms, malgré une recherche récursive DNS réussie?

J'ai récemment migré un domaine que je possède de Cloudflare vers Netlify DNS, j'ai donc dû mettre à jour mes serveurs de noms. Lorsque j'exécute une recherche DNS récursive qui contourne le cache DNS, tout semble être correctement configuré:

$ dig howtogit.net +trace
(output truncated)
howtogit.net.       20  IN  A   159.65.199.87
;; Received 57 bytes from 198.51.44.1#53(dns1.p01.nsone.net) in 18 ms

Cependant, une recherche DNS régulière échoue:

$ nslookup howtogit.net                                                                               
Server:     192.168.1.1
Address:    192.168.1.1#53

** server can't find howtogit.net: SERVFAIL

Je suppose que si la mise en cache était en faute, Cloudflare résoudrait toujours la recherche, ce qui n'est pas le cas. Une recherche à 8.8.8.8 (DNS de Google) échoue également:

$ dig @8.8.8.8 howtogit.net

; <<>> DiG 9.10.6 <<>> @8.8.8.8 howtogit.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63809
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;howtogit.net.          IN  A

;; Query time: 43 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Sep 23 13:05:50 CEST 2018
;; MSG SIZE  rcvd: 41

Étant donné que les enregistrements DNS sont mis en cache, j'ai également essayé de vider le cache DNS de Google pour mes enregistrements NS et A. J'obtiens toujours le même résultat, malgré le changement intervenu il y a plus de 10 heures.

Ma configuration est-elle incorrecte? Comment puis-je m'assurer que mon DNS peut à nouveau se résoudre correctement?

domain-name-system

— Pieter
source

Dans des cas comme celui-ci, un outil comme celui-ci dnsviz.netdevrait facilement vous montrer qu'il y a un problème DNSSEC. En fait, vous pouvez clairement voir le problème ici: dnsviz.net/d/howtogit.net/W6d5WA/dnssec que vous pouvez comparer à celui qui fonctionne actuellement: dnsviz.net/d/howtogit.net/W6kJlg/dnssec

— Patrick Mevzek

Oui, je l'ai compris. Finalement, j'ai décidé de migrer vers Cloudflare car Netlify DNS ne prend pas en charge DNSSEC. Mais bon à savoir!

— Pieter

DNSSEC est difficile, en effet. Un compromis entre les fonctionnalités qu'il propose et les étapes nécessaires pour ne pas l'avoir. Dans les cas connexes, une astuce de dépannage: si un digéchec avec SERVFAIL mais si vous refaites exactement le même ajout +cdet qu'il n'échoue plus, cela signifie probablement que le problème est lié à DNSSEC. +cddésactiver les contrôles DNSSEC, d'où la différence possible. Mais SERVFAIL peut se produire pour beaucoup de problèmes, il n'y a pas (pour l'instant) de codes d'erreur étendus dans le DNS ...

— Patrick Mevzek

Il semblerait que la howtogit.netzone utilisée pour qu'il ait signé, et qu'après avoir changé de serveur de noms, elle ne soit plus signée.

Cependant, vous avez laissé l'ancien DSenregistrement en place, indiquant que la zone doit être signée avec une clé spécifique.

Supprimez l' DSenregistrement ou signez à nouveau la zone et mettez à jour l' DSenregistrement si nécessaire (l' DSenregistrement est géré par votre registraire).

Si vous regardez la fin de la dig +tracesortie pertinente, il est en fait assez clair que cela doit être le cas ( DSdans le cadre de la référence mais pas DNSKEYà la fin faisant autorité, ou tout simplement pas de signatures si vous interrogez un autre type):

$ dig +trace +all howtogit.net DNSKEY

...

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63298
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;howtogit.net.                  IN      DNSKEY

;; AUTHORITY SECTION:
howtogit.net.           172800  IN      NS      dns1.p01.nsone.net.
howtogit.net.           172800  IN      NS      dns2.p01.nsone.net.
howtogit.net.           172800  IN      NS      dns3.p01.nsone.net.
howtogit.net.           172800  IN      NS      dns4.p01.nsone.net.
howtogit.net.           86400   IN      DS      2371 13 2 F7822E035739507BFB9ED504B65FFE7A95698E58C069EF1DE754EED0 55E6799F
howtogit.net.           86400   IN      RRSIG   DS 8 2 86400 20180927051931 20180920040931 7934 net. POLNdGPgCCeF6ClG4ro1mkUI5DpqUuuLLeR4WCly1L5GbOTgPnzg02Nx 2Sse2dYDLJLB1EQYotZkvVm8GNFS5iE8UQlmp4GA3yxTgUeifw5PX6Eh kiJSip37/CyGCTy6OMPoVeMgQjLnrxt1aAOsnO5BszeGY7gD6ee/XHMO zc4=

;; ADDITIONAL SECTION:
dns1.p01.nsone.net.     172800  IN      A       198.51.44.1
dns2.p01.nsone.net.     172800  IN      A       198.51.45.1
dns3.p01.nsone.net.     172800  IN      A       198.51.44.65
dns4.p01.nsone.net.     172800  IN      A       198.51.45.65

;; Query time: 159 msec
;; SERVER: 2001:503:231d::2:30#53(2001:503:231d::2:30)
;; WHEN: Sun Sep 23 11:35:52 UTC 2018
;; MSG SIZE  rcvd: 402

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53062
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;howtogit.net.                  IN      DNSKEY

;; AUTHORITY SECTION:
howtogit.net.           3600    IN      SOA     dns1.p01.nsone.net. hostmaster.nsone.net. 1537613509 43200 7200 1209600 3600

;; Query time: 1 msec
;; SERVER: 198.51.45.65#53(198.51.45.65)
;; WHEN: Sun Sep 23 11:35:52 UTC 2018
;; MSG SIZE  rcvd: 103

$

— Håkan Lindqvist
source

Vous êtes sur place ... on dirait que j'ai oublié de désactiver DNSSEC avant de migrer. J'ai supprimé l'enregistrement DS avec mon registraire et 8.8.8.8 a immédiatement commencé à résoudre le domaine correctement.

— Pieter

@Pieter Pas de problème. Merci de ne pas avoir obscurci les détails, ce qui, autrement, tend à rendre ces types de questions inutilement difficiles à répondre.

— Håkan Lindqvist