BIND 9.11.2 acting as a forwarder: authority section populated differently than BIND 9.9.11 ?
Irwin Tillman
irwin at princeton.edu
Tue Feb 13 15:56:19 UTC 2018
I'm preparing to upgrade from BIND 9.9.11 to 9.11.2.
I notice a difference in how named populates the authority section in some responses,
and am trying to understand if it's OK.
My server is a caching-only server, and provides recursive service.
For some zones, my server is configured to forward to another set of servers.
The servers specified as my forwarding target a BIND 9.9.11 servers providing
recursive service, and happen to also be authoritative for the zones I'm forwarding to them.
My server (and those servers it selectively forwards to) does not specify "minimal-responses"
in its configuration.
--
My server forwards queries for zone "princeton.edu" to another set of servers,
as described earlier.
I perform a recursive lookup for an existing RR inside that zone.
When my server is running BIND 9.9.11, it returns an answer with the
authority section populated.
That section's contents are what I expect -- the NS records
specified for the zone in which the label resides:
% dig @127.0.0.1 plaid.princeton.edu. A
; <<>> DiG 9.9.11 <<>> @127.0.0.1 plaid.princeton.edu. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4126
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;plaid.princeton.edu. IN A
;; ANSWER SECTION:
plaid.Princeton.EDU. 43179 IN A 140.180.226.197
;; AUTHORITY SECTION:
Princeton.EDU. 70344 IN NS dikahble.Princeton.EDU.
Princeton.EDU. 70344 IN NS auth1.dns.cogentco.com.
Princeton.EDU. 70344 IN NS adns1.ucsc.edu.
Princeton.EDU. 70344 IN NS adns2.ucsc.edu.
Princeton.EDU. 70344 IN NS dns.Princeton.EDU.
Princeton.EDU. 70344 IN NS auth2.dns.cogentco.com.
;; ADDITIONAL SECTION:
dns.Princeton.EDU. 30743 IN A 128.112.129.15
dikahble.Princeton.EDU. 32546 IN A 128.112.134.4
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 13 10:26:59 EST 2018
;; MSG SIZE rcvd: 257
--
But when I upgrade my server to BIND 9.11.2, the same lookup
performed immediately after I start my server returns no authority records,
which is a surprise to me:
% dig @127.0.0.1 plaid.princeton.edu. A
; <<>> DiG 9.11.2 <<>> @127.0.0.1 plaid.princeton.edu. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1135
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 63342752c773c411b8b830385a830429d4d1686dd32d2d60 (good)
;; QUESTION SECTION:
;plaid.princeton.edu. IN A
;; ANSWER SECTION:
plaid.Princeton.EDU. 43200 IN A 140.180.226.197
;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 13 10:28:41 EST 2018
;; MSG SIZE rcvd: 111
If I next issue another lookup like this to my server to cause
it to perform some different work:
% dig @127.0.0.1 foo.example.com. A
; <<>> DiG 9.11.2 <<>> @127.0.0.1 foo.example.com. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57462
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: f61e7ac231c1a37e3b5cdf575a83045994703633bafd0296 (good)
;; QUESTION SECTION:
;foo.example.com. IN A
;; AUTHORITY SECTION:
example.com. 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2018013013 7200 3600 1209600 3600
;; Query time: 672 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 13 10:29:29 EST 2018
;; MSG SIZE rcvd: 129
... and THEN re-issue my original query, the response's authority section is populated with
records for the root domain, which is a surprise to me:
% dig @127.0.0.1 plaid.princeton.edu. A
; <<>> DiG 9.11.2 <<>> @127.0.0.1 plaid.princeton.edu. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4208
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 27
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: fb305a768a4968defdf64dd65a830468abe3a7b146678e56 (good)
;; QUESTION SECTION:
;plaid.princeton.edu. IN A
;; ANSWER SECTION:
plaid.Princeton.EDU. 43137 IN A 140.180.226.197
;; AUTHORITY SECTION:
. 518385 IN NS l.root-servers.net.
. 518385 IN NS f.root-servers.net.
. 518385 IN NS k.root-servers.net.
. 518385 IN NS b.root-servers.net.
. 518385 IN NS g.root-servers.net.
. 518385 IN NS j.root-servers.net.
. 518385 IN NS h.root-servers.net.
. 518385 IN NS d.root-servers.net.
. 518385 IN NS i.root-servers.net.
. 518385 IN NS a.root-servers.net.
. 518385 IN NS e.root-servers.net.
. 518385 IN NS m.root-servers.net.
. 518385 IN NS c.root-servers.net.
;; ADDITIONAL SECTION:
a.root-servers.net. 604785 IN A 198.41.0.4
b.root-servers.net. 604785 IN A 199.9.14.201
c.root-servers.net. 604785 IN A 192.33.4.12
d.root-servers.net. 604785 IN A 199.7.91.13
e.root-servers.net. 604785 IN A 192.203.230.10
f.root-servers.net. 604785 IN A 192.5.5.241
g.root-servers.net. 604785 IN A 192.112.36.4
h.root-servers.net. 604785 IN A 198.97.190.53
i.root-servers.net. 604785 IN A 192.36.148.17
j.root-servers.net. 604785 IN A 192.58.128.30
k.root-servers.net. 604785 IN A 193.0.14.129
l.root-servers.net. 604785 IN A 199.7.83.42
m.root-servers.net. 604785 IN A 202.12.27.33
a.root-servers.net. 604785 IN AAAA 2001:503:ba3e::2:30
b.root-servers.net. 604785 IN AAAA 2001:500:200::b
c.root-servers.net. 604785 IN AAAA 2001:500:2::c
d.root-servers.net. 604785 IN AAAA 2001:500:2d::d
e.root-servers.net. 604785 IN AAAA 2001:500:a8::e
f.root-servers.net. 604785 IN AAAA 2001:500:2f::f
g.root-servers.net. 604785 IN AAAA 2001:500:12::d0d
h.root-servers.net. 604785 IN AAAA 2001:500:1::53
i.root-servers.net. 604785 IN AAAA 2001:7fe::53
j.root-servers.net. 604785 IN AAAA 2001:503:c27::2:30
k.root-servers.net. 604785 IN AAAA 2001:7fd::1
l.root-servers.net. 604785 IN AAAA 2001:500:9f::42
m.root-servers.net. 604785 IN AAAA 2001:dc3::35
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 13 10:29:44 EST 2018
;; MSG SIZE rcvd: 894
If I issue a query to my server asking for a non-existant name in the .EDU domain
(a parent of my domain):
% dig @127.0.0.1 foo.bar.edu. A
; <<>> DiG 9.11.2 <<>> @127.0.0.1 foo.bar.edu. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38495
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 40af4a03e24a2e33bab2a3735a8305204d66a0672db578d6 (good)
;; QUESTION SECTION:
;foo.bar.edu. IN A
;; AUTHORITY SECTION:
bar.edu. 10800 IN SOA ns1.afes.com. admin.afes.com. 201702211 3600 1200 7200 432000
;; Query time: 240 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 13 10:32:48 EST 2018
;; MSG SIZE rcvd: 122
...and THEN re-issue my original query, the response's authority section is populated
with the records for EDU, which is a surprise to me:
% dig @127.0.0.1 plaid.princeton.edu. A
; <<>> DiG 9.11.2 <<>> @127.0.0.1 plaid.princeton.edu. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54021
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 7
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: db4c1bfbec29b63ccb393c2c5a83052e6f673a8aaaeba623 (good)
;; QUESTION SECTION:
;plaid.princeton.edu. IN A
;; ANSWER SECTION:
plaid.Princeton.EDU. 42939 IN A 140.180.226.197
;; AUTHORITY SECTION:
EDU. 172786 IN NS c.edu-servers.net.
EDU. 172786 IN NS g.edu-servers.net.
EDU. 172786 IN NS d.edu-servers.net.
EDU. 172786 IN NS l.edu-servers.net.
EDU. 172786 IN NS f.edu-servers.net.
EDU. 172786 IN NS a.edu-servers.net.
;; ADDITIONAL SECTION:
c.edu-servers.net. 86386 IN A 192.26.92.30
d.edu-servers.net. 86386 IN A 192.31.80.30
f.edu-servers.net. 86386 IN A 192.35.51.30
g.edu-servers.net. 86386 IN A 192.42.93.30
l.edu-servers.net. 86386 IN A 192.41.162.30
g.edu-servers.net. 86386 IN AAAA 2001:503:cc2c::2:36
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 13 10:33:02 EST 2018
;; MSG SIZE rcvd: 330
If I issue a query that causes my server to learn the NS records for my zone princeton.edu:
% dig @127.0.0.1 princeton.edu. NS
; <<>> DiG 9.11.2 <<>> @127.0.0.1 princeton.edu. NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26590
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: be4537dbb4406eeda89bf1cb5a8305b0f7f8fb0962ad02ac (good)
;; QUESTION SECTION:
;princeton.edu. IN NS
;; ANSWER SECTION:
Princeton.EDU. 172800 IN NS auth2.dns.cogentco.com.
Princeton.EDU. 172800 IN NS dikahble.Princeton.EDU.
Princeton.EDU. 172800 IN NS dns.Princeton.EDU.
Princeton.EDU. 172800 IN NS adns1.ucsc.edu.
Princeton.EDU. 172800 IN NS auth1.dns.cogentco.com.
Princeton.EDU. 172800 IN NS adns2.ucsc.edu.
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 13 10:35:12 EST 2018
;; MSG SIZE rcvd: 225
...and then re-issue my original query, the authority section is populated
with the records for princeton.edu, as I would have expected:
% dig @127.0.0.1 plaid.princeton.edu. A
; <<>> DiG 9.11.2 <<>> @127.0.0.1 plaid.princeton.edu. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20918
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 6fe3a124e6ff5d3b5095ae475a8305d851a935c0c4f2fc92 (good)
;; QUESTION SECTION:
;plaid.princeton.edu. IN A
;; ANSWER SECTION:
plaid.Princeton.EDU. 42769 IN A 140.180.226.197
;; AUTHORITY SECTION:
Princeton.EDU. 172760 IN NS adns2.ucsc.edu.
Princeton.EDU. 172760 IN NS auth1.dns.cogentco.com.
Princeton.EDU. 172760 IN NS dns.Princeton.EDU.
Princeton.EDU. 172760 IN NS auth2.dns.cogentco.com.
Princeton.EDU. 172760 IN NS adns1.ucsc.edu.
Princeton.EDU. 172760 IN NS dikahble.Princeton.EDU.
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 13 10:35:52 EST 2018
;; MSG SIZE rcvd: 253
--
It feels to me that to get the authority section populated as I expected, I have
to "prime" my BIND 9.11.2 server to get those NS records cached first.
I wondered if this might be a variation of minimal-responses.
By my server config does not specify minimal-responses.
--
I found that if I reconfigure my BIND 9.11.2 server to *not* act as a forwarder for the
domain (princeton.edu) containing the label I am querying for, BIND 9.11.2
returns the results I used to see in BIND 9.9.11 right away (without
any "priming" queries first):
% dig @127.0.0.1 plaid.princeton.edu. A
; <<>> DiG 9.11.2 <<>> @127.0.0.1 plaid.princeton.edu. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36618
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: fd499812a3eccac9c0f397a65a8306ab9f85b1ff90ec1460 (good)
;; QUESTION SECTION:
;plaid.princeton.edu. IN A
;; ANSWER SECTION:
plaid.Princeton.EDU. 43200 IN A 140.180.226.197
;; AUTHORITY SECTION:
princeton.edu. 172800 IN NS dikahble.princeton.edu.
princeton.edu. 172800 IN NS auth2.dns.cogentco.com.
princeton.edu. 172800 IN NS adns2.ucsc.edu.
princeton.edu. 172800 IN NS adns1.ucsc.edu.
princeton.edu. 172800 IN NS dns.princeton.edu.
princeton.edu. 172800 IN NS auth1.dns.cogentco.com.
;; Query time: 40 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 13 10:39:23 EST 2018
;; MSG SIZE rcvd: 253
--
Is this expected behavior with forwarding in BIND 9.11.2?
Is it OK?
More information about the bind-users
mailing list