12

I recently migrated a domain I own from Cloudflare to Netlify DNS, so I had to update my nameservers. When I run a recursive DNS lookup that bypasses DNS cache everything seems to be set up correctly:

$ 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

However, a regular DNS lookup fails:

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

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

I assume that if caching was at fault, Cloudflare would still resolve the lookup which it doesn't. A lookup at 8.8.8.8 (Google's DNS) also fails:

$ 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

Since DNS records are cached, I also tried flushing Google's DNS cache for my NS and A records. I'm still getting the same result, despite the change having happened over 10 hours ago.

Is my configuration incorrect? How do I make sure my DNS can resolve properly again?

  • 1
    In cases like this, a tool like dnsviz.net should easily show you there is a DNSSEC problem. In fact you can clearly see the problem here: dnsviz.net/d/howtogit.net/W6d5WA/dnssec that you can compare to current working one: dnsviz.net/d/howtogit.net/W6kJlg/dnssec – Patrick Mevzek Sep 24 '18 at 15:58
  • Yep, I figured it out. Ultimately I decided to migrate back to Cloudflare because Netlify DNS doesn't support DNSSEC. But good to know! – Pieter Sep 24 '18 at 19:17
  • DNSSEC is hard, indeed. A compromise between the features it provides and the steps needed ot have it. In related cases, a troubleshooting tip: if a dig fails with SERVFAIL but if you redo the exact same one adding +cd and it does not fail anymore, then it probably means the problem is DNSSEC related. +cd disable DNSSEC checks, hence the possible difference. But SERVFAIL can happen for a lot of problems, there are no (for now) extended error codes in the DNS... – Patrick Mevzek Sep 24 '18 at 20:44
24

It would appear that the howtogit.net zone used to he signed, and that after switching nameservers it is no longer signed.

However, you have left the old DS record in place, indicating that the zone must be signed with some specific key.

Either remove the DS record or sign the zone again and update the DS record as necessary (the DS record is managed through your registrar).

If you look at the tail end of relevant dig +trace output it's actually quite clear that this must be the case (DS as part of referral but no DNSKEY on the authoritative end, or just no signatures if you query some other 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

$
| improve this answer | |
  • 1
    You're spot on... looks like I forgot to disable DNSSEC before migrating. I removed the DS record with my registrar and 8.8.8.8 started resolving the domain correctly immediately. – Pieter Sep 23 '18 at 17:36
  • 5
    @Pieter No problem. Thanks for not obfuscating the specifics, which otherwise tends to make these types of questions unnecessarily difficult to answer. – Håkan Lindqvist Sep 23 '18 at 19:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.