1.1.1.1 sometimes returns RRSIG on CNAME

milk · March 31, 2022, 9:02pm

I noticed that 1.1.1.1 sometimes returns an RRSIG when a CNAME is queried.
It seems to only happen when the domain is not cached. It’s easy to spot on this domain as the TTL is only 20. It seems to be redundant and other resolvers also don’t return it.
I also noticed that Cloudflare doesn’t always return the same IP addresses when requesting this same CNAME. 1.1.1.1 does not use ECS, so I supposed the answers would always be the same, as all requests are made from 141.101.64.0/24 here (AMS). But I still seem to regularly get different results. Could this be because some queries were made over IPv6? Or does ECS still play a role here?
(@mvavrusa)

$ dig bankieren.rabobank.nl @1.1 +nsid

; <<>> DiG 9.16.1-Ubuntu <<>> bankieren.rabobank.nl @1.1 +nsid
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5020
;; flags: qr rd ra; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 32 30 6d 38 37 38 ("20m878")
;; QUESTION SECTION:
;bankieren.rabobank.nl.		IN	A

;; ANSWER SECTION:
bankieren.rabobank.nl.	7123	IN	CNAME	bankieren.rabobank.nl.edgekey.net.
bankieren.rabobank.nl.edgekey.net. 21523 IN CNAME e82494.dscb.akamaiedge.net.
bankieren.rabobank.nl.	7123	IN	RRSIG	CNAME 13 3 7200 20220403200620 20220331190620 6395 rabobank.nl. ZWY65LyyCCURD6a4j5AQjoYOX6J4QCO54xd2+/hcZGb3JWfB08k8szoK adTAVUz2EfzxRKALB9qJDzaZ3mYnDw==
e82494.dscb.akamaiedge.net. 20	IN	A	104.110.191.36
e82494.dscb.akamaiedge.net. 20	IN	A	104.110.191.39
e82494.dscb.akamaiedge.net. 20	IN	A	104.110.191.48
e82494.dscb.akamaiedge.net. 20	IN	A	104.110.191.40
e82494.dscb.akamaiedge.net. 20	IN	A	104.110.191.33
e82494.dscb.akamaiedge.net. 20	IN	A	104.110.191.34
e82494.dscb.akamaiedge.net. 20	IN	A	104.110.191.47
e82494.dscb.akamaiedge.net. 20	IN	A	104.110.191.44
e82494.dscb.akamaiedge.net. 20	IN	A	104.110.191.38

;; Query time: 24 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Thu Mar 31 22:49:55 CEST 2022
;; MSG SIZE  rcvd: 395

$ dig bankieren.rabobank.nl @1.1 +nsid

; <<>> DiG 9.16.1-Ubuntu <<>> bankieren.rabobank.nl @1.1 +nsid
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7142
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 32 30 6d 35 36 39 ("20m569")
;; QUESTION SECTION:
;bankieren.rabobank.nl.		IN	A

;; ANSWER SECTION:
bankieren.rabobank.nl.	7141	IN	CNAME	bankieren.rabobank.nl.edgekey.net.
bankieren.rabobank.nl.edgekey.net. 21541 IN CNAME e82494.dscb.akamaiedge.net.
e82494.dscb.akamaiedge.net. 9	IN	A	104.110.191.20
e82494.dscb.akamaiedge.net. 9	IN	A	104.110.191.16
e82494.dscb.akamaiedge.net. 9	IN	A	104.110.191.22
e82494.dscb.akamaiedge.net. 9	IN	A	104.110.191.15
e82494.dscb.akamaiedge.net. 9	IN	A	104.110.191.9
e82494.dscb.akamaiedge.net. 9	IN	A	104.110.191.11
e82494.dscb.akamaiedge.net. 9	IN	A	104.110.191.18
e82494.dscb.akamaiedge.net. 9	IN	A	104.110.191.6
e82494.dscb.akamaiedge.net. 9	IN	A	104.110.191.17

;; Query time: 20 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Thu Mar 31 22:49:56 CEST 2022
;; MSG SIZE  rcvd: 288

$ dig bankieren.rabobank.nl @1.1 +nsid

; <<>> DiG 9.16.1-Ubuntu <<>> bankieren.rabobank.nl @1.1 +nsid
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10143
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 32 30 6d 35 30 36 ("20m506")
;; QUESTION SECTION:
;bankieren.rabobank.nl.		IN	A

;; ANSWER SECTION:
bankieren.rabobank.nl.	7035	IN	CNAME	bankieren.rabobank.nl.edgekey.net.
bankieren.rabobank.nl.edgekey.net. 21435 IN CNAME e82494.dscb.akamaiedge.net.
bankieren.rabobank.nl.	7035	IN	RRSIG	CNAME 13 3 7200 20220403200620 20220331190620 6395 rabobank.nl. ZWY65LyyCCURD6a4j5AQjoYOX6J4QCO54xd2+/hcZGb3JWfB08k8szoK adTAVUz2EfzxRKALB9qJDzaZ3mYnDw==
e82494.dscb.akamaiedge.net. 20	IN	A	84.53.185.201
e82494.dscb.akamaiedge.net. 20	IN	A	84.53.185.179

;; Query time: 24 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Thu Mar 31 22:54:23 CEST 2022
;; MSG SIZE  rcvd: 283

$ dig bankieren.rabobank.nl @1.1 +nsid

; <<>> DiG 9.16.1-Ubuntu <<>> bankieren.rabobank.nl @1.1 +nsid
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22231
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 32 30 6d 35 32 32 ("20m522")
;; QUESTION SECTION:
;bankieren.rabobank.nl.		IN	A

;; ANSWER SECTION:
bankieren.rabobank.nl.	7161	IN	CNAME	bankieren.rabobank.nl.edgekey.net.
bankieren.rabobank.nl.edgekey.net. 21561 IN CNAME e82494.dscb.akamaiedge.net.
e82494.dscb.akamaiedge.net. 19	IN	A	84.53.185.179
e82494.dscb.akamaiedge.net. 19	IN	A	84.53.185.201

;; Query time: 16 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Thu Mar 31 22:55:38 CEST 2022
;; MSG SIZE  rcvd: 176

mvavrusa · March 31, 2022, 9:43pm

Hi! They usually are the same results. Sometimes the upstream load balancers give out different pools to different source IPs, so it also depends on which Cloudflare node is assigned to your request. The resolver platform behind 1.1.1.1 runs other services as well, that might have ECS enabled. If some other query on those services populates the cache entry matching your source network, you could get a response from that cache entry, but you won’t be able to refill it when it expires (as ECS isn’t enabled on 1.1.1.1).

I can replicate the RRSIG record randomly popping in, I’ll look into it.

mvavrusa · March 31, 2022, 9:56pm

The RRSIG seems to be appended in some particular sequences of cache refills, I’ll schedule the bugfix to be released next week.

milk · March 31, 2022, 10:20pm

Awesome! That was insanely quick
Also, a very very small nitpick I also noticed: when querying for DNSSEC, the RRSIG will always be the first response of the query, while every other resolver puts it at the end. Is there a reason for this? Just wondering why it’s different.

$ dig cloudflare-dns.com +dnssec +short @1.1.1.1
A 13 2 300 20220401230749 20220330210749 34505 cloudflare-dns.com. PkmmmNBRP6x1JaooTwCGFrQY60dD7sOj3n5t7YJ9ahz9p94Dfsbmbgdw S/yZPspLj0ZWakFywPdra4Uz6Kcibw==
104.16.249.249
104.16.248.249
$ dig cloudflare-dns.com +dnssec +short @208.67.222.222
104.16.248.249
104.16.249.249
A 13 2 300 20220401230631 20220330210631 34505 cloudflare-dns.com. AxSmq/wn9naSv3pudmpFUKhDtyS274pPPnu8E/6RVVfgeICRLa648iBi sA0zVXArSkXCgCDfBeuW6QJ4yiO1XA==
$ dig cloudflare-dns.com +dnssec +short @8.8.8.8
104.16.249.249
104.16.248.249
A 13 2 300 20220401231038 20220330211038 34505 cloudflare-dns.com. 8OzSfAHdCLOMgViyg4lZjtF0FF8E4Ddnx54B0hDAiaOH4F6fsA8sNtuV mS0JCQQykdbfsLx2rcgoLFBcBaUEuw==
$ dig cloudflare-dns.com +dnssec +short @9.9.9.9
104.16.249.249
104.16.248.249
A 13 2 300 20220401230920 20220330210920 34505 cloudflare-dns.com. 8Pw3Hcr8HzCJ5iCHGAx/htGwBk73KNoe/F8Cg1EY+iHwivzEprufQ4mt KNg9tD+LD5on210hGcSx8h52wYWwHg==
$ dig cloudflare-dns.com +dnssec +short @45.90.28.70
104.16.249.249
104.16.248.249
A 13 2 300 20220401230912 20220330210912 34505 cloudflare-dns.com. WznZ9g4pvFP9aCsv/RFFtzFS5CTWQI8eyFeNg3JIkaWsONu/yXjJWXFb Gu9WNWrlwmn2TRZ3lLDqjjGr4S7pCQ==
$ dig cloudflare-dns.com +dnssec +short @94.140.14.14
104.16.249.249
104.16.248.249
A 13 2 300 20220401230835 20220330210835 34505 cloudflare-dns.com. q4z9vygNHtf1ahPMZZqPXlWJlO682Hsi4pJlMAoTJ0UjrcSw7lwpou94 sD0MOI/VuzdzKp/xW3OnNgaUPGnmtg==
$ dig cloudflare-dns.com +dnssec +short @4.2.2.1
104.16.248.249
104.16.249.249
A 13 2 300 20220401230706 20220330210706 34505 cloudflare-dns.com. QFVeyuUjo/SuOAiR3dZX44BdsDoc2HvB/UqHuc9qU1SHJlTSlJkgP0fU ORH15RDpFJ7+Nlge+11is9QXzIPNlA==
$ dig cloudflare-dns.com +dnssec +short @62.179.104.196
104.16.248.249
104.16.249.249
A 13 2 300 20220401231141 20220330211141 34505 cloudflare-dns.com. nU/81ojAOZ1z7UazVmLPa2wg5doMQXWU5Y+n3QIKecEfte3BARx5Vi1W eaFnq5fsayhyXb73lb+lzIG9lXPDcA==

I also noticed that when querying the nameservers for . (with dig . ns @1.1.1.1, or just dig @1.1.1.1) it still returns the (redundant) Additional Section. All other queries do not show this section.

Also HAPPY CAKE DAY! And congrats with 4 years of 1.1.1.1. We’ve come a very long way.

mvavrusa · March 31, 2022, 10:54pm

The ordering is a side effect of shuffling, there isn’t any particular reason for this and I also prefer when it’s after the records so I’ll change that as well.

The answers from the root zone are served locally, so that’s why you see more information there in general. I’m not sure it makes sense to rewrite it in this case as it’s not usually queried directly by clients, but nice find!

system · April 3, 2022, 10:55pm

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.