Unable to access npm.community due to false DNSSEC

Zero Trust 1.1.1.1
1

Hello,

It seems as though Cloudflare’s 1.1.1.1 DNS resolver returns bad info for DNSSEC for the domain npm.community (CNAME of npm1.hosted-by-discourse.com). I have checked using Verisign’s DNSSEC validator and there is NO DNSSEC anywhere for the 2 domains, and I have confirmed the results with dnsviz.

Cloudflare should be returning INSECURE not BOGUS, as there is no DNSSEC enabled for those domains, as confirmed by those 2 tests.

Could someone please fix this? It means I can’t access that domain because I run piHole with DNSSEC enabled.

2 
nslookup npm.community 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
Name:    npm1.hosted-by-discourse.com
Addresses:  2001:470:1:791::23
          72.52.80.23
Aliases:  npm.community

nslookup npm.community 1.0.0.1
Server:  one.one.one.one
Address:  1.0.0.1

Non-authoritative answer:
Name:    npm1.hosted-by-discourse.com
Addresses:  2001:470:1:791::23
          72.52.80.23
Aliases:  npm.community

nslookup npm.community 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    npm1.hosted-by-discourse.com
Addresses:  2001:470:1:791::23
          72.52.80.23
Aliases:  npm.community

nslookup -class=chaos -type=txt id.server 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
id.server       text =

        "YUL"
 nslookup -class=chaos -type=txt id.server 1.0.0.1
Server:  one.one.one.one
Address:  1.0.0.1

Non-authoritative answer:
id.server       text =

        "YUL"
PS C:\Users\thoma> nslookup -type=txt whoami.Cloudflare.com ns3.Cloudflare.com
Server:  ns3.cloudflare.com
Address:  162.159.7.226

whoami.Cloudflare.com   text =

        "24.202.160.112"

dnsviz test: npm.community | DNSViz

3

Here’s the output of dig from the pi itself using the cloudflared dns-over-https proxy and through the regular dns, plus the same query using Google’s DNS servers:

 $ dig npm.community +dnssec @127.0.0.1 -p 5053

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> npm.community +dnssec @127.0.0.1 -p 5053
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47907
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
; PAD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ("........................")
;; QUESTION SECTION:
;npm.community.                 IN      A

;; ANSWER SECTION:
npm.community.          300     IN      CNAME   npm1.hosted-by-discourse.com.
npm1.hosted-by-discourse.com. 300 IN    A       72.52.80.23

;; Query time: 59 msec
;; SERVER: 127.0.0.1#5053(127.0.0.1)
;; WHEN: Sun Jan 19 01:20:22 EST 2020
;; MSG SIZE  rcvd: 169

$ dig npm.community +dnssec @1.1.1.1

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> npm.community +dnssec @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39171
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;npm.community.                 IN      A

;; ANSWER SECTION:
npm.community.          300     IN      CNAME   npm1.hosted-by-discourse.com.
npm1.hosted-by-discourse.com. 482 IN    A       72.52.80.23

;; Query time: 29 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Jan 19 01:22:20 EST 2020
;; MSG SIZE  rcvd: 100

$ dig npm.community +dnssec @1.0.0.1

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> npm.community +dnssec @1.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61761
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;npm.community.                 IN      A

;; ANSWER SECTION:
npm.community.          300     IN      CNAME   npm1.hosted-by-discourse.com.
npm1.hosted-by-discourse.com. 440 IN    A       72.52.80.23

;; Query time: 31 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Sun Jan 19 01:23:02 EST 2020
;; MSG SIZE  rcvd: 100

$ dig npm.community +dnssec @8.8.8.8

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> npm.community +dnssec @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49126
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;npm.community.                 IN      A

;; ANSWER SECTION:
npm.community.          80      IN      CNAME   npm1.hosted-by-discourse.com.
npm1.hosted-by-discourse.com. 599 IN    A       72.52.80.23

;; Query time: 28 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Jan 19 01:23:21 EST 2020
;; MSG SIZE  rcvd: 100
4

It uses CNAME at zone apex, i.e. CNAME npm.community is wrong. That’s a breakage of standards and it’s asking for trouble. (It’s especially troublesome with validation after forwarding.)

5

While I agree the CNAME at the apex isn’t permitted, it seems like the DNS returns a valid response sometimes. That is, sometimes when you dig the misconfigured domain you get an insecure result, othertimes 1.1.1.1 returns a bogus result. See Cloudflare ticket 1817200

6

This is why it isn’t permitted. CNAME prohibits other record type other than its RRSIG for the same name not just for the sake of it, but because of the ambiguity. If it’s not cached resolver will work okay because it doesn’t know the CNAME is there. If it does get cached, resolver will answer other record types differently knowing that the CNAME exists. We’re trying to reach out and add a workaround if it can’t be fixed. The only solution to make it consistent is to not cache CNAME at all and cache it for each individual record type, which makes it slower for everybody else.