Unable to resolve domain with DNSSEC

Zero Trust 1.1.1.1
,
1

I’m not able to resolve sp.edu.sg without disabling dnssec check, however it can be resolved on google dns with out disabling the check.

dig sp.edu.sg @1.1.1.1 +cd

; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> sp.edu.sg @1.1.1.1 +cd
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38985
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;sp.edu.sg. IN A

;; ANSWER SECTION:
sp.edu.sg. 3600 IN A 35.201.83.130

;; Query time: 418 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Jan 13 11:45:47 DST 2019
;; MSG SIZE rcvd: 54

dig sp.edu.sg @1.1.1.1

; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> sp.edu.sg @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4654
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;sp.edu.sg. IN A

;; Query time: 294 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Jan 13 11:46:13 DST 2019
;; MSG SIZE rcvd: 38

Google DNS is able to resolve without disabling dnssec check.

dig sp.edu.sg @8.8.8.8

; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> sp.edu.sg @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36061
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;sp.edu.sg. IN A

;; ANSWER SECTION:
sp.edu.sg. 3599 IN A 35.201.83.130

;; Query time: 19 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Jan 13 12:04:28 DST 2019
;; MSG SIZE rcvd: 54

2

The domain barely works:

http://dnsviz.net/d/sp.edu.sg/XDq51w/dnssec/

https://ednscomp.isc.org/ednscomp/b5ec302aa9

The IPv6 nameservers are down entirely and the IPv4 nameservers don’t support TCP.

At a guess, 1.1.1.1 might be timing out waiting for the IPv6 nameservers, or it might want to resolve the large DNSKEY record set using TCP.

Edit: I’m almost certain it fails for the latter reason. The former reason might also cause some failures, though.

2 Likes