reece.wales - Possible DNSSEC issue?

[Adam Reece]

Hello,

There appears to be an issue for getting answers with one of my domain names "reece.wales" but only when asking Google's DNS cluster.

Other DNS clusters I've queried return responses fine:

• Zen Internet -- 212.23.3.100 / 212.23.6.100 / 2a02:8010:1:0:212:23:3:100 / 2a02:8010:1:0:212:23:6:100
• Level 3 -- 4.2.2.1 / 4.2.2.2
• OpenDNS -- 208.67.222.222 / 208.67.220.220
• BuddyNS -- c.ns.buddyns.com / j.ns.buddyns.com

Examples:

$ dig reece.wales. NS @2a02:8010:1:0:212:23:3:100

; <<>> DiG 9.11.2-P1 <<>> reece.wales. NS @2a02:8010:1:0:212:23:3:100

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60691

;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;reece.wales.                   IN      NS

;; ANSWER SECTION:

reece.wales.            588     IN      NS      ns3.reece.wales.

reece.wales.            588     IN      NS      j.ns.buddyns.com.

reece.wales.            588     IN      NS      ns2.reece.wales.

reece.wales.            588     IN      NS      ns1.reece.wales.

reece.wales.            588     IN      NS      c.ns.buddyns.com.

;; Query time: 16 msec

;; SERVER: 2a02:8010:1:0:212:23:3:100#53(2a02:8010:1:0:212:23:3:100)

;; WHEN: Wed Oct 31 18:06:13 GMT 2018

;; MSG SIZE  rcvd: 140

$ dig reece.wales. NS @4.2.2.1

; <<>> DiG 9.11.2-P1 <<>> reece.wales. NS @4.2.2.1

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31983

;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 8192

;; QUESTION SECTION:

;reece.wales.                   IN      NS

;; ANSWER SECTION:

reece.wales.            3600    IN      NS      c.ns.buddyns.com.

reece.wales.            3600    IN      NS      j.ns.buddyns.com.

reece.wales.            3600    IN      NS      ns1.reece.wales.

reece.wales.            3600    IN      NS      ns2.reece.wales.

reece.wales.            3600    IN      NS      ns3.reece.wales.

;; Query time: 49 msec

;; SERVER: 4.2.2.1#53(4.2.2.1)

;; WHEN: Wed Oct 31 18:05:35 GMT 2018

;; MSG SIZE  rcvd: 140

$ dig reece.wales. NS @c.ns.buddyns.com.

; <<>> DiG 9.11.2-P1 <<>> reece.wales. NS @c.ns.buddyns.com.

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44461

;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 10

;; WARNING: recursion requested but not available

;; QUESTION SECTION:

;reece.wales.                   IN      NS

;; ANSWER SECTION:

reece.wales.            3600    IN      NS      c.ns.buddyns.com.

reece.wales.            3600    IN      NS      j.ns.buddyns.com.

reece.wales.            3600    IN      NS      ns1.reece.wales.

reece.wales.            3600    IN      NS      ns2.reece.wales.

reece.wales.            3600    IN      NS      ns3.reece.wales.

;; ADDITIONAL SECTION:

c.ns.buddyns.com.       10800   IN      A       88.198.106.11

c.ns.buddyns.com.       10800   IN      AAAA    2a01:4f8:d12:d01::10:4

j.ns.buddyns.com.       10800   IN      A       185.34.136.178

j.ns.buddyns.com.       10800   IN      AAAA    2a00:dcc7:d3ff:88b2::1

ns1.reece.wales.        3600    IN      AAAA    2a02:8010:8002:1::1000

ns1.reece.wales.        3600    IN      A       88.97.144.90

ns2.reece.wales.        3600    IN      AAAA    2a02:8010:8002:1::1

ns2.reece.wales.        3600    IN      A       88.97.144.81

ns3.reece.wales.        3600    IN      AAAA    2a02:8010:8002:1::2

ns3.reece.wales.        3600    IN      A       88.97.144.82

;; Query time: 51 msec

;; SERVER: 2a01:4f8:d12:d01::10:4#53(2a01:4f8:d12:d01::10:4)

;; WHEN: Wed Oct 31 18:06:41 GMT 2018

;; MSG SIZE  rcvd: 349

I've run the domain name through IntoDNS, which they say has the following issues:

1) Name of nameservers are valid

WARNING: At least one of your NS name does not seem a valid host name

The ones that do not seem valid:

ns1.reece.wales ns3.reece.wales ns2.reece.wales

That's not true. When querying any of the aforementioned DNS clusters I get the following (correct) responses:

• ns1.reece.wales: 88.97.144.90 / 2a02:8010:8002:1::1000
  
• ns2.reece.wales: 88.97.144.81 / 2a02:8010:8002:1::1
  
• ns3.reece.wales: 88.97.144.82 / 2a02:8010:8002:1::2
  

2) MX name validity

The MX records that do not seem valid hostname: 

mail.reece.wales

This can cause problems

That's not true. This resolves to 88.97.144.90 / 2a02:8010:8002:1::1000 correctly.

3) WWW A Record

ERROR: I could not get any A records for www.reece.wales!

That's irrelevant. There is a CNAME here pointing to the root record correctly.

I am only able to get a response from Google's cluster if I include the +cd option suggesting there is a DNSSEC issue, for example:

$ dig reece.wales. NS @8.8.8.8

; <<>> DiG 9.11.2-P1 <<>> reece.wales. NS @8.8.8.8

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62866

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 512

;; QUESTION SECTION:

;reece.wales.                   IN      NS

;; Query time: 45 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)

;; WHEN: Wed Oct 31 18:09:11 GMT 2018

;; MSG SIZE  rcvd: 40

$ dig reece.wales. NS @8.8.8.8 +cd

; <<>> DiG 9.11.2-P1 <<>> reece.wales. NS @8.8.8.8 +cd

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31082

;; flags: qr rd ra cd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 512

;; QUESTION SECTION:

;reece.wales.                   IN      NS

;; ANSWER SECTION:

reece.wales.            3599    IN      NS      c.ns.buddyns.com.

reece.wales.            3599    IN      NS      j.ns.buddyns.com.

reece.wales.            3599    IN      NS      ns1.reece.wales.

reece.wales.            3599    IN      NS      ns2.reece.wales.

reece.wales.            3599    IN      NS      ns3.reece.wales.

;; Query time: 46 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)

;; WHEN: Wed Oct 31 18:09:13 GMT 2018

;; MSG SIZE  rcvd: 140

That being said, none of the other clusters complain about invalid DNSSEC information. The DS records have been correctly registered into the "wales." registry:

$ dig reece.wales. DS @dnsd.nic.wales.

; <<>> DiG 9.11.2-P1 <<>> reece.wales. DS @dnsd.nic.wales.

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49019

;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;reece.wales.                   IN      DS

;; ANSWER SECTION:

reece.wales.            3600    IN      DS      62074 8 2 51B05BFBF17FCB7E51F8D3E7ACEBD6AD7815EFA06477C0424A2945AE 4F2D60DC

reece.wales.            3600    IN      DS      62074 8 1 4071CE420E02B441E67BD0DE91F349EF8D9A83A2

;; Query time: 21 msec

;; SERVER: 156.154.103.3#53(156.154.103.3)

;; WHEN: Wed Oct 31 18:10:24 GMT 2018

;; MSG SIZE  rcvd: 124

Would anyone mind offering some insight into what's incorrect about this domain name?

[Alex Dupuy]

Yes, your domain has DNSSEC issues. http://dnsviz.net/d/reece.wales/dnssec/ will show you what they are, but they are rather odd. Maybe the name servers at buddyns.com don't support DNSSEC or something like that? It certainly seems odd that they don't return EDNS OPT (EDNS is a prerequisite for DNSSEC). There may be other problems as well.

[Adam Reece]

Hi Alex,

You're right, it would appear that BuddyNS does not support DNSSEC. From their FAQ:

DNSSEC

BuddyNS does not support DNSSEC because it exposes to some vulnerabilities unsuited to a high-volume DNS service.

Hmm no explanation, a little suspicious! I do need the redundancy BuddyNS provides, so I've decided to take away the DNSSEC records off my zone. (It doesn't appear to be very well supported anyway, particularly across registrars.)

Removing the DNSSEC records appears to have resolved the issue with Google's cluster. The fact that only Google's stopped working probably shows that Google are one of the only clusters to properly support it. :)

Thank you for your insight.