Error in bahavior when CNAME point at its owner name

[matsduf]

Error in bahavior when CNAME point at its owner name

[matsduf]

I have a similar issue with CNAME in a loop with three CNAME records involved. Maybe the same root cause? Zone file:

$TTL 3600
$ORIGIN cname.recursor.engine.xa.

@                       SOA  (
                                   ns1
                                   root
                                   2023111502
                                   86400
                                   14400
                                   3600000
                                   3600
                                 )

@                       NS    ns1
ns1                     A     127.30.1.31
ns1                     AAAA  fda1:b2:c3:0:127:30:1:31

; For scenario LOOPED-CNAME-IN-ZONE-2
looped-cname-in-zone-2        CNAME looped-cname-in-zone-2-a
looped-cname-in-zone-2-a      CNAME looped-cname-in-zone-2-b
looped-cname-in-zone-2-b      CNAME looped-cname-in-zone-2-a

Configuration:

# ns1 cname.recursor.engine.xa                                                                                                                                                                                                                                                                  
cname.recursor.engine.xa:53 {
   bind 127.30.1.31
   bind fda1:b2:c3:0:127:30:1:31
   log
   file Engine/Recursor-PM/cname.recursor.engine.xa cname.recursor.engine.xa.
}

The response where the CNAME records are repeated:

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> @127.30.1.31 looped-cname-in-zone-2.cname.recursor.engine.xa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35027
;; flags: qr aa rd; QUERY: 1, ANSWER: 10, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: b00b99182da09e6a (echoed)
;; QUESTION SECTION:
;looped-cname-in-zone-2.cname.recursor.engine.xa. IN A

;; ANSWER SECTION:
looped-cname-in-zone-2.cname.recursor.engine.xa. 3600 IN CNAME looped-cname-in-zone-2-a.cname.recursor.engine.xa.
looped-cname-in-zone-2-a.cname.recursor.engine.xa. 3600	IN CNAME looped-cname-in-zone-2-b.cname.recursor.engine.xa.
looped-cname-in-zone-2-b.cname.recursor.engine.xa. 3600	IN CNAME looped-cname-in-zone-2-a.cname.recursor.engine.xa.
looped-cname-in-zone-2-a.cname.recursor.engine.xa. 3600	IN CNAME looped-cname-in-zone-2-b.cname.recursor.engine.xa.
looped-cname-in-zone-2-b.cname.recursor.engine.xa. 3600	IN CNAME looped-cname-in-zone-2-a.cname.recursor.engine.xa.
looped-cname-in-zone-2-a.cname.recursor.engine.xa. 3600	IN CNAME looped-cname-in-zone-2-b.cname.recursor.engine.xa.
looped-cname-in-zone-2-b.cname.recursor.engine.xa. 3600	IN CNAME looped-cname-in-zone-2-a.cname.recursor.engine.xa.
looped-cname-in-zone-2-a.cname.recursor.engine.xa. 3600	IN CNAME looped-cname-in-zone-2-b.cname.recursor.engine.xa.
looped-cname-in-zone-2-b.cname.recursor.engine.xa. 3600	IN CNAME looped-cname-in-zone-2-a.cname.recursor.engine.xa.
looped-cname-in-zone-2-a.cname.recursor.engine.xa. 3600	IN CNAME looped-cname-in-zone-2-b.cname.recursor.engine.xa.

;; AUTHORITY SECTION:
cname.recursor.engine.xa. 3600	IN	NS	ns1.cname.recursor.engine.xa.

;; Query time: 0 msec
;; SERVER: 127.30.1.31#53(127.30.1.31) (UDP)
;; WHEN: Wed Nov 29 12:41:25 UTC 2023
;; MSG SIZE  rcvd: 296

I updated the configuration with a template with the response I wanted:

cname.recursor.engine.xa:53 {
   bind 127.30.1.31
   bind fda1:b2:c3:0:127:30:1:31
   log
   file Engine/Recursor-PM/cname.recursor.engine.xa cname.recursor.engine.xa.

    template IN A looped-cname-in-zone-2.cname.recursor.engine.xa {
        answer     "looped-cname-in-zone-2.cname.recursor.engine.xa. 3600 IN CNAME looped-cname-in-zone-2-a.cname.recursor.engine.xa."
        answer     "looped-cname-in-zone-2-a.cname.recursor.engine.xa. 3600     IN CNAME looped-cname-in-zone-2-b.cname.recursor.engine.xa."
	answer     "looped-cname-in-zone-2-b.cname.recursor.engine.xa. 3600     IN CNAME looped-cname-in-zone-2-a.cname.recursor.engine.xa."
	authority  "cname.recursor.engine.xa. 3600      IN      NS      ns1.cname.recursor.engine.xa."
    }
}

That gave a similar response with even more copies of the same DNS records.

Then I tried a new approache and removed the CNAME records from the zone and kept the template in the configuration, which gave the response I wanted:

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> @127.30.1.31 looped-cname-in-zone-2.cname.recursor.engine.xa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25713
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 39d0589b05519144 (echoed)
;; QUESTION SECTION:
;looped-cname-in-zone-2.cname.recursor.engine.xa. IN A

;; ANSWER SECTION:
looped-cname-in-zone-2.cname.recursor.engine.xa. 3600 IN CNAME looped-cname-in-zone-2-a.cname.recursor.engine.xa.
looped-cname-in-zone-2-a.cname.recursor.engine.xa. 3600	IN CNAME looped-cname-in-zone-2-b.cname.recursor.engine.xa.
looped-cname-in-zone-2-b.cname.recursor.engine.xa. 3600	IN CNAME looped-cname-in-zone-2-a.cname.recursor.engine.xa.

;; AUTHORITY SECTION:
cname.recursor.engine.xa. 3600	IN	NS	ns1.cname.recursor.engine.xa.

;; Query time: 0 msec
;; SERVER: 127.30.1.31#53(127.30.1.31) (UDP)
;; WHEN: Wed Nov 29 12:49:25 UTC 2023
;; MSG SIZE  rcvd: 488

[SivaKesava1]

Hello,

I have noticed this behavior with DNAMEs too here #6419 where same DNAME and synthesized records are added multiple times, but with SERVFAIL and the logs showed that it received query multiple times.

However, consider the following zone file:

test.	500	SOA	ns1.outside.com. root.test 3 604800 86400 2419200 604800
test.	500	NS	ns1.outside.com.
*.test.	500	CNAME	*.test.

I know, these are all not very realistic zone files, but nonetheless, pushes testing of corner cases.

For the query <a.test., A> we get response:

; <<>> DiG 9.16.1-Ubuntu <<>> @127.0.0.1 -p 8500 +norecurse a.test
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43690
;; flags: qr aa; QUERY: 1, ANSWER: 10, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: b09ae78d4d34ac52 (echoed)
;; QUESTION SECTION:
;a.test.                                IN      A

;; ANSWER SECTION:
a.test.                 500     IN      CNAME   *.test.
*.test.                 500     IN      CNAME   *.test.
*.test.                 500     IN      CNAME   *.test.
*.test.                 500     IN      CNAME   *.test.
*.test.                 500     IN      CNAME   *.test.
*.test.                 500     IN      CNAME   *.test.
*.test.                 500     IN      CNAME   *.test.
*.test.                 500     IN      CNAME   *.test.
*.test.                 500     IN      CNAME   *.test.
*.test.                 500     IN      CNAME   *.test.

;; AUTHORITY SECTION:
test.                   500     IN      NS      ns1.outside.edu.

Here we get NOERROR and the reply has duplicate records. The very interesting part is that in the logs this is recorded as a single request, unlike SERVFAIL where the log has multiple entries.

test.:53
CoreDNS-1.11.1
linux/amd64, go1.20.10, 45923b6e
[INFO] 172.17.0.1:44106 - 43690 "A IN a.test. udp 47 false 4096" NOERROR qr,aa 317 0.000408864s

This probably goes back the fix we made a while back - #4378

Please consider all of these cases, when making the fix to avoid adding duplicate records.

Thanks,
Siva

[chrisohaver]

What do the DNS RFCs say about how CNAME loops should be handled?

[matsduf]

From https://www.sidnlabs.nl/en/news-and-blogs/tsuname-dns-loops-are-a-well-known-problem-but-arent-properly-addressed-by-current-rfcs I find three RFCs that mentions CNAME loops:

• RFC 1034
• RFC 1035
• RFC 1536

None of them handles the issue reported here, i.e. that an authoritative server repeats DNS records from its zone. Rather they talk about having some break and reporting the loop as an error. I think that the advice is meant for resolving name servers rather than authoritative name servers.

If there is a "template" plugin section for the query name and type, and that section has answer section statements, shouldn't CoreDNS respond with the records from those statements without further processing?

[chrisohaver]

So the question is: What is the proper response for a DNS server serving a CNAME loop?

1. respond with a SERVFAIL response code
2. respond with the list of CNAMEs that complete the loop (not repeating any records)
3. respond with a list of CNAMESs that trace the loop, possibly repeating records until reaching a predefined depth

1 above I think is closest to the RFC suggestion (i.e. regarding it as an error).

Detecting loops this way however will add some additional processing (albeit probably small amount) to serving all alias type records - regardless if they create a loop or not.

[SivaKesava1]

For the context,

PowerDNS always responds with SERVFAIL and with empty answer section if it detects any loop - CNAME loop, wildcard loop, DNAME loop, CNAME-DNAME or any combination loop. (Option 1)

Bind, NSD and Knot as far I remember return records in the loop but does it only once. They do not return any duplicate records in the answer section. (Option 2)

[chrisohaver]

Are duplicate records in the response significantly problematic? Making sure there are no duplicates in the response imposes a performance hit on all query responses, just to give special handling for corner-case mis-configured CNAME loops.

[SivaKesava1]

I believe they should not do any harm as far as I know, but I do not have an experience with resolvers. I do not know how resolvers process such responses with duplicate records. Given that these are corner cases and if detecting duplicates takes a performance hit, then I think it should be okay to leave it as is.