*.is-cf.cloudflareresolve.com is not a valid DNSSEC zone

dash-dns
dns-resolver
#1

https://1.1.1.1/help reflects incorrect information if you use 1.1.1.1 via a validating stub resolver because *.is-cf.cloudflareresolve.com is not a valid DNSSEC zone, causing a local SERVFAIL.

With local validation enabled:

$ dig @127.0.0.1 7fe8e839-5b5f-4df3-a6ec-be860de75dfd.is-cf.cloudflareresolve.com +dnssec

; <<>> DiG 9.10.6 <<>> @127.0.0.1 7fe8e839-5b5f-4df3-a6ec-be860de75dfd.is-cf.cloudflareresolve.com +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24904
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;7fe8e839-5b5f-4df3-a6ec-be860de75dfd.is-cf.cloudflareresolve.com. IN A

;; Query time: 253 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Feb 27 02:02:55 AEDT 2019
;; MSG SIZE  rcvd: 82

With local validation disabled:

$ dig @127.0.0.1 7fe8e839-5b5f-4df3-a6ec-be860de75dfe.is-cf.cloudflareresolve.com +dnssec

; <<>> DiG 9.10.6 <<>> @127.0.0.1 7fe8e839-5b5f-4df3-a6ec-be860de75dfe.is-cf.cloudflareresolve.com +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43371
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;7fe8e839-5b5f-4df3-a6ec-be860de75dfe.is-cf.cloudflareresolve.com. IN A

;; ANSWER SECTION:
7fe8e839-5b5f-4df3-a6ec-be860de75dfe.is-cf.cloudflareresolve.com. 0 IN CNAME is-cf.cloudflareresolve.com.cdn.cloudflare.net.
is-cf.cloudflareresolve.com.cdn.cloudflare.net.	109 IN A 104.16.225.45
is-cf.cloudflareresolve.com.cdn.cloudflare.net.	109 IN A 104.16.224.45
is-cf.cloudflareresolve.com.cdn.cloudflare.net.	109 IN RRSIG A 13 6 300 20190227160110 20190225140110 34505 cloudflare.net. VbZf7w1m5lbmkcOw8KnwXe6I82UdduYsOk4Yi5p3deZ7A8pm4BVtyLSf 3uw/TsjWR4sH0FDezNhvKpCCI61vKA==

;; Query time: 200 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Feb 27 02:04:21 AEDT 2019
;; MSG SIZE  rcvd: 497
1 Like
#2

I can confirm the issue @bardi.harborow has reported, namely if one uses a locally configured recursive resolver (like for example unbound), however configured to forward requests to 1.1.1.1 (perhaps over TLS), but also configured to verify DNSsec, then the https://1.1.1.1/help page fails to correctly reflect that the user is indeed using 1.1.1.1 as a DNS resolver (including the other checks).

The following is the log that unbound prints when trying to resolve ff51022f-06ec-4a23-9772-a2bff19fd651.is-cf.cloudflareresolve.com:

Apr 18 17:16:41 unbound[2371:0] info: resolving ff51022f-06ec-4a23-9772-a2bff19fd651.is-cf.cloudflareresolve.com. A IN
Apr 18 17:16:41 unbound[2371:0] info: response for ff51022f-06ec-4a23-9772-a2bff19fd651.is-cf.cloudflareresolve.com. A IN
Apr 18 17:16:41 unbound[2371:0] info: reply from <.> 1.1.1.1#853
Apr 18 17:16:41 unbound[2371:0] info: query response was CNAME
Apr 18 17:16:41 unbound[2371:0] info: resolving ff51022f-06ec-4a23-9772-a2bff19fd651.is-cf.cloudflareresolve.com. A IN
Apr 18 17:16:41 unbound[2371:0] info: response for ff51022f-06ec-4a23-9772-a2bff19fd651.is-cf.cloudflareresolve.com. A IN
Apr 18 17:16:41 unbound[2371:0] info: reply from <.> 1.1.1.1#853
Apr 18 17:16:41 unbound[2371:0] info: query response was ANSWER

# NOTE:  these lines are repeated over-and-over until `unbound` gives up and fails.
Apr 18 17:16:41 unbound[2371:0] info: resolving is-cf.cloudflareresolve.com. DS IN
Apr 18 17:16:42 unbound[2371:0] info: response for is-cf.cloudflareresolve.com. DS IN
Apr 18 17:16:42 unbound[2371:0] info: reply from <.> 1.0.0.1#853
Apr 18 17:16:42 unbound[2371:0] info: query response was CNAME
Apr 18 17:16:42 unbound[2371:0] info: resolving is-cf.cloudflareresolve.com. DS IN
Apr 18 17:16:42 unbound[2371:0] info: response for is-cf.cloudflareresolve.com. DS IN
Apr 18 17:16:42 unbound[2371:0] info: reply from <.> 1.1.1.1#853
Apr 18 17:16:42 unbound[2371:0] info: query response was nodata ANSWER

Apr 18 17:16:42 unbound[2371:0] info: Could not establish a chain of trust to keys for is-cf.cloudflareresolve.com. DNSKEY IN

The following are the two links for 1.1.1.1/help, the first is when unbound is configured to ignore DNSsec for the cloudflareresolve.com domain, and the second one is when DNSsec is enabled (thus it fails to detect its usage):

#3

The *.cloudflareresolve.com has special records generated by the resolver (depending on which protocol did the client use etc.), but unfortunately it doesn’t have any DNSSEC signing capability for these records (yet) so the test page is not going to work properly if you use 1.1.1.1 behind a revalidating stub or forwarder, sorry! See https://twitter.com/vavrusam/status/1113488064528015360

1 Like
#4

It’s quite obvious that these records are “injected” by the CloudFlare resolver, however wouldn’t it have been simpler to just use for this purpose a TLD that isn’t marked as DNSsec compliant?

#5

I second that idea. I’m currently finalizing implementing DoT + DNSSEC support in Asuswrt-Merlin, and it’s getting annoying having to constantly repeat that that DOT + DNSSEC are working fine, it’s the test site that’s broken due to its unsigned test record. If you’re going to use that method to determine that DoT/DoH is used, please use an unsigned domain. Dnsmasq now defaults to strict validation since around release 2.78, so out of the box dnsmasq will return a BOGUS response for that record when DNSSEC is enabled. It means any system running an up-to-date version of dnsmasq will fail the CF tests out of the box - as it should, since an unsigned response from a signed zone could indicate a forged record.

1 Like