Merlin DNSSEC Cloudflare vs Quad9

[maxbraketorque]

I initially set up DNSSEC using Cloudflare DNS servers (1.1.1.1, 1.0.0.1) and found frequent entries in the log of the type:

... dnsmasq[...]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers​

No such messages were generated when I switched to Quad9 (9.9.9.9, 149.112.112.112). I verified that the entries are tied to Cloudflare by switching back to it's servers. "DNSSEC: strict unsigned validation" is enabled. I'm wondering if anyone else is seeing this log entry with Cloudflare.

 

[CooCooCaChoo]

Yeah, Cloudflare doesn't have full DNSSEC support implemented or something so you'll get these error messages.

 

[bbunge]

I have better success with Cloudflare DNSSEC than Quad9. Am using Stubby for DoT and DNSSEC. Could be a geographical issue?

Sent from my SM-T380 using Tapatalk

 

[maxbraketorque]

I'm on the other side of the country so perhaps that's the case.

 

[ColinTaylor]

... dnsmasq[...]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers

I think the message is not that surprising given that you should never be trying to resolve 168.192.in-addr.arpa on an external DNS server anyway. So any kind of response would be "undefined".

So a better question might be, why are you trying to resolve 168.192.in-addr.arpa externally?

For bonus points: Why does 9.9.9.9 only respond with NXDOMAIN 50% of the time?

# dig @9.9.9.9 168.192.in-addr.arpa

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> @9.9.9.9 168.192.in-addr.arpa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59607
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;168.192.in-addr.arpa.          IN      A

;; AUTHORITY SECTION:
168.192.in-addr.arpa.   3554    IN      SOA     prisoner.iana.org. hostmaster.root-servers.org. 1 604800 60 604800 604800

;; Query time: 19 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sat Apr 13 15:34:42 BST 2019
;; MSG SIZE  rcvd: 126

# dig @9.9.9.9 168.192.in-addr.arpa

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> @9.9.9.9 168.192.in-addr.arpa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26463
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;168.192.in-addr.arpa.          IN      A

;; AUTHORITY SECTION:
168.192.in-addr.arpa.   10800   IN      SOA     localhost. nobody.invalid. 1 3600 1200 604800 10800

;; Query time: 20 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sat Apr 13 15:34:43 BST 2019
;; MSG SIZE  rcvd: 108

 

[maxbraketorque]

I think the message is not that surprising given that you should never be trying to resolve 168.192.in-addr.arpa on an external DNS server anyway. So any kind of response would be "undefined".

So a better question might be, why are you trying to resolve 168.192.in-addr.arpa externally?

....

I have no idea what I'm doing to trigger this. Any connections I make within my private network are done with the dotted decimal address.