On Wed, Jan 16, 2019 at 07:02:05AM +0100, Tom wrote: > $ dig +norec -4 @ns3.example.com www.mydomain.net > > ; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> +norec -4 @ns3.example.com > www.mydomain.net > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36984 > ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: 847bc109e7f71243dd664e215c3ec4c412619cff362fd7fc (good) > ;; QUESTION SECTION: > ;www.mydomain.net. IN A > > ;; ANSWER SECTION: > www.mydomain.net. 3600 IN A 44.44.44.44 > > ;; AUTHORITY SECTION: > mydomain.net. 3600 IN NS ns3.example.com. > mydomain.net. 3600 IN NS ns2.example.com. > mydomain.net. 3600 IN NS ns1.example.com.
Huh, looks like you're right. Both of these servers also authoritative for example.com, I'm guessing? It seems that if the additional data comes from a different zone on the same server (as opposed to the same zone, or from the cache), then it's not being looked up. I don't think this change was intentional. It was introduced during the work to improve performance in delegation-heavy zones: the old code would search through all of the zone databases every time it went to look up additional data. The newer code saves time by searching only the database that it's already found. That's more efficient and yields correct results in the "minimal-responses yes" case, but it's wrong for "no". It's possible there was a reason for the change that I've forgotten, but I think we intended to leave the "no" behavior alone. Thanks for bringing it up, I'll open a bug ticket about it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
