[GH-ISSUE #2099] Non-existent CNAME target in the same zone should be returned with NXDOMAIN instead of NOERROR rcode #885

New issue

Open

opened 2026-03-16 00:45:07 +03:00 by kerem · 1 comment

kerem commented

2026-03-16 00:45:07 +03:00

Owner

Originally created by @SivaKesava1 on GitHub (Nov 30, 2023).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2099

Describe the bug
This is related to if 'A CNAME B' exists in a zone, but B (related to the same zone) does not exist, then the return code should be NXDOMAIN. RFC 6604 mentions that

When chains are followed the RCODE in the ultimate DNS response MUST BE set based on the final query cycle leading to that
response.

To Reproduce
Consider the following zone file:

test.   500     IN      SOA     ns1.outside.edu. root.campus.edu. 3 6048 4000 2419200 6048
test.   500     IN      NS      ns1.outside.edu.
c.test. 500     IN      CNAME   *.*.test.
b.test. 500     IN      CNAME   e.test.
e.test. 500     IN      CNAME   f.test.
a.test. 500     IN      A       1.1.1.1

Expected behavior
Consider the following reponse:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15654
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;b.test.                                IN      A

;; ANSWER SECTION:
b.test.                 500     IN      CNAME   e.test.

;; ADDITIONAL SECTION:
e.test.                 500     IN      CNAME   f.test.

First, both the records should have been in the answer section.

Second, the RCODE should be NXDOMAIN given that the target belongs to the same zone file and doesn't exist.

CoreDNS and Yadifa had similar issues and they fixed it. Please check those for some more details.
https://github.com/coredns/coredns/issues/4288#issuecomment-746914722
https://github.com/yadifa/yadifa/issues/11

An even subtle bug was found in NSD, only when * is in RDATA - https://github.com/NLnetLabs/nsd/issues/152

System:
OS: Ubuntu
Architecture: x86_64
Version: 18
rustc version: cargo 1.47.0

Version:
Crate: server
Version: :Trust-DNS 0.23.1

Originally created by @SivaKesava1 on GitHub (Nov 30, 2023). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2099 **Describe the bug** This is related to if 'A CNAME B' exists in a zone, but B (related to the same zone) does not exist, then the return code should be NXDOMAIN. [RFC 6604](https://tools.ietf.org/html/rfc6604#section-3) mentions that > When chains are followed the RCODE in the ultimate DNS response MUST BE set based on the final query cycle leading to that > response. **To Reproduce** Consider the following zone file: ``` test. 500 IN SOA ns1.outside.edu. root.campus.edu. 3 6048 4000 2419200 6048 test. 500 IN NS ns1.outside.edu. c.test. 500 IN CNAME *.*.test. b.test. 500 IN CNAME e.test. e.test. 500 IN CNAME f.test. a.test. 500 IN A 1.1.1.1 ``` **Expected behavior** Consider the following reponse: ``` ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15654 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;b.test. IN A ;; ANSWER SECTION: b.test. 500 IN CNAME e.test. ;; ADDITIONAL SECTION: e.test. 500 IN CNAME f.test. ``` First, both the records should have been in the answer section. Second, the RCODE should be `NXDOMAIN` given that the target belongs to the same zone file and doesn't exist. CoreDNS and Yadifa had similar issues and they fixed it. Please check those for some more details. https://github.com/coredns/coredns/issues/4288#issuecomment-746914722 https://github.com/yadifa/yadifa/issues/11 An even subtle bug was found in NSD, only when `*` is in RDATA - https://github.com/NLnetLabs/nsd/issues/152 **System:** OS: Ubuntu Architecture: x86_64 Version: 18 rustc version: cargo 1.47.0 **Version:** Crate: server Version: :Trust-DNS 0.23.1

kerem added the

bug

crate:server

compliance

labels

2026-03-16 00:45:07 +03:00

kerem commented

2026-03-16 00:45:18 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 30, 2023):

Thanks for the detailed report. We should add this as a scenario to the battery tests for our authority types.

@bluejekyll commented on GitHub (Nov 30, 2023): Thanks for the detailed report. We should add this as a scenario to the battery tests for our authority types.

kerem referenced this issue

2026-03-16 02:24:23 +03:00

[PR #885] [MERGED] Bump webpki-roots from 0.17.0 to 0.18.0 #1768