On 16.01.19 08:08, Evan Hunt wrote:
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?
Yes.., correct. Both are also authoritative for "example.com".
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.
Perfect.., thank you.
_______________________________________________
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
