You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the file plugin chases a DNAME chain and ends up at a zonecut, the response has AA set (despite being a referral), and uses the apex NS records of the current zone as AUTHORITY, not the NS records at the zonecut. Further, if the query is for NS, the zonecut NS records is included in the ANSWER section.
How to reproduce it (as minimally and precisely as possible):
Using the following zone file (a.b.txt):
a.b. 500 IN SOA c.d.e. f.b.e. 3 604800 86400 2419200 604800
a.b. 500 IN NS c.d.e.
g.a.b. 500 IN DNAME a.b.
h.a.b. 500 IN NS h.b.
and this Corefile:
a.b.:1053 {
header {
response set ra
}
file a.b.txt
}
Response for querying <h.g.a.b., A> (output beautified):
root@e10adfbeed3f:/v# dig @127.0.0.1 -p 1053 h.g.a.b. A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14209;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1;; QUESTION SECTION:;h.g.a.b. IN A;; ANSWER SECTION:g.a.b. 500 IN DNAME a.b.h.g.a.b. 500 IN CNAME h.a.b.;; AUTHORITY SECTION:a.b. 500 IN NS c.d.e.
What you expected to happen:
aa should not be set (querying <h.a.b., A> directly, the aa bit is indeed not set), and the AUTHORITY section should include the h.a.b. NS record.
Further, if instead the query is for NS:
root@e10adfbeed3f:/v# dig @127.0.0.1 -p 1053 h.g.a.b. NS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57896;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1;; QUESTION SECTION:;h.g.a.b. IN NS;; ANSWER SECTION:g.a.b. 500 IN DNAME a.b.h.g.a.b. 500 IN CNAME h.a.b.h.a.b. 500 IN NS h.b.;; AUTHORITY SECTION:a.b. 500 IN NS c.d.e.
The h.a.b. NS record is in the ANSWER section, which is incorrect. Querying for h.a.b. NS directly would still end up with a referral response, where the ANSWER section is empty.
(Judging from these responses, it seems that CoreDNS is just not treating the response as a referral.)
Anything else we need to know?:
Environment:
the version of CoreDNS: CoreDNS-1.11.1, linux/arm64, go1.21.5, 45923b6e
Corefile: given above.
OS: this uses the docker environment from "Compilation with Docker".
Others:
Bind9 behavior under the same setup: the AUTHORITY is h.a.b. NS, and the ANSWER section never contains the NS record.
The text was updated successfully, but these errors were encountered:
In the case where the query matches an alias, and the server is not authoritative for the target of the alias but is authoritative for some name above the target of the alias, the resolution algorithm will produce a response that contains both the authoritative answer for the alias and a referral. Such a partial answer and referral response has data in the Answer section. It has the NS RRset for the referred-to zone in the Authority section. It may contain RRs that provide addresses in the Additional section. The AA bit is set because the first name in the Answer section matches the QNAME and the server is authoritative for that answer (see [RFC1035], Section 4.1.1).
AA Authoritative Answer - this bit is valid in responses,
and specifies that the responding name server is an
authority for the domain name in question section.
Note that the contents of the answer section may have
multiple owner names because of aliases. The AA bit
corresponds to the name which matches the query name, or
the first owner name in the answer section.
So in this case, the AA bit should be set, and it corresponds to the g.a.b. DNAME record in the ANSWER section (I was initially surprised to see bind9 has AA set and assumed it was a bug as well..).
Anyhow, CoreDNS may be correct to have set AA, but returning zone cut NS records in the answer section is still wrong.
What happened:
When the
file
plugin chases a DNAME chain and ends up at a zonecut, the response has AA set (despite being a referral), and uses the apex NS records of the current zone as AUTHORITY, not the NS records at the zonecut. Further, if the query is forNS
, the zonecut NS records is included in the ANSWER section.How to reproduce it (as minimally and precisely as possible):
Using the following zone file (
a.b.txt
):and this Corefile:
Response for querying
<h.g.a.b., A>
(output beautified):What you expected to happen:
aa
should not be set (querying<h.a.b., A>
directly, theaa
bit is indeed not set), and the AUTHORITY section should include theh.a.b. NS
record.Further, if instead the query is for
NS
:The
h.a.b. NS
record is in the ANSWER section, which is incorrect. Querying forh.a.b. NS
directly would still end up with a referral response, where the ANSWER section is empty.(Judging from these responses, it seems that CoreDNS is just not treating the response as a referral.)
Anything else we need to know?:
Environment:
CoreDNS-1.11.1, linux/arm64, go1.21.5, 45923b6e
Bind9 behavior under the same setup: the AUTHORITY is
h.a.b. NS
, and the ANSWER section never contains theNS
record.The text was updated successfully, but these errors were encountered: