DNAME: synthetized CNAME might be perfect answer to CNAME query
Summary
When there is a DNAME
record in the zone file (partial rewrite to the same zone), and that record handles the query, then the RCODE
of the server should probably be different depending on whether the query is for CNAME
or not. After the DNAME
rewrite, the new query name belongs to the same zone but doesn't exist. The server currently returns NXDOMAIN
for all the types, but it might be reasonable to return NOERROR
for the CNAME
type.
BIND version used
BIND 9.11.3-1ubuntu1.13-Ubuntu (Extended Support Version) id:a375815
Steps to reproduce
Consider the following sample zone file:
campus.edu. | 500 SOA | ns1.campus.edu. root.campus.edu. 3 86400 7200 604800 300 |
campus.edu. | 500 NS | ns1.outside.edu. |
c.d.campus.edu. | 500 DNAME | f.d.campus.edu. |
For the query <a.c.d.campus.edu., CNAME>
the answer from the BIND server is:
"opcode QUERY",
"rcode NXDOMAIN",
"flags QR AA",
";QUESTION",
"a.c.d.campus.edu. IN CNAME",
";ANSWER",
"a.c.d.campus.edu. 500 IN CNAME a.f.d.campus.edu.",
"c.d.campus.edu. 500 IN DNAME f.d.campus.edu.",
";AUTHORITY",
";ADDITIONAL"
What is the current bug behavior?
The RCODE
is NXDOMAIN.
What is the expected correct behavior?
The answer section would be the same for the above query, but the RCODE
should likely be NOERROR.
PowerDNS was doing it that way, but BIND, NSD, and Knot were returning NXDOMAIN
for all types so I thought it might be an issue with PowerDNS. I have filed a GitHub issue with PowerDNS, and they said it's intentional and they are doing it correctly. A patch was sent to Knot server also to return NOERROR
for the CNAME
type.