Right, we know how hints files are used, but I think you guys may be missing
the underlying conundrum: why is named querying the NS records of the root zone
more often than the TTL of that RRset? See that there is a “NS? .” query at
15:36:44 and then another one at 15:45:52. At 15:45:52 it should have answered
its client from the data it cached from the answer to the 15:36:44 query (less
than 10 minutes previous).
Is named not seeing a response from the root servers in question? Is the
max-cache-ttl being capped at a ridiculously-small value?
The NS queries of other names besides “.” itself are red herrings. They are all
unique names – dot-terminated octet strings, names in the “.mr” TLD, “comp-HP.”
-- and we wouldn’t expect them to have been cached previously. But an answer to
“NS? .” should be cached for *days*, not just a few minutes.
I’m speculating that this might not be a pure “caching DNS server” after all;
it might be a forwarder with “forward first” defined. In that case, if the
forwarding path experiences occasional delays, then named will fail over to
trying iterative resolution, and if the routing and/or firewall rules were
never set up to allow that, then the symptoms would be as documented, since
named would never get a response from the root servers. General rule: use
“forward only” if you must use forwarders *exclusively*; “forward first” is
only for *opportunistic* forwarding, where you still have the ability to fall
back to iterative resolution, if and when necessary. (Personally, I’m not much
of a fan of “forward first”, since it rarely if ever produces the performance
benefit expected, or, even if it lowers the average query latency, it does so
at the expense of the worst-case latency -- cache miss plus slow authoritative
nameservers and/or misconfigured delegations -- and it’s worst-case that causes
apps to time out, to break, and ultimately, users to show up bearing pitchforks
and burning oil).
- Kevin
From: [email protected]
[mailto:[email protected]] On Behalf Of Leonard Mills
Sent: Monday, June 15, 2015 3:05 PM
To: Gaurav Kansal; [email protected]
Subject: Re: Automatic . NS queries from BIND
The hints hopefully point eventually to an authoritative server for ".".
Whatever that authoritative server says overrides any hints, just like any
other zone's authoritative NS. It does not matter how obsolete a delegation
is, so long as some authoritative NS replies, the data from the delegation
(hints) no longer matters.
HtH
Len
On Monday, June 15, 2015 6:14 AM, Gaurav Kansal
<[email protected]<mailto:[email protected]>> wrote:
Dear Team,
My caching DNS server is generating log of . NS queries to ROOT Servers.
I have a hint file in my bind configuration and the same is up-to date.
The same behavior is occurring in multiple versions of BIND (tested on 9.7, 9.9
and on 9.10).
It must be for some purpose (may be BIND doesn’t trust hint file and cross
check it from root servers).
Can anyone put some light on this.
Sample tcpdump output :-
15:36:42.440831 IP anydnsmby.27938 > k.root-servers.net.domain: 38907 [1au]
NS? . (28)
15:36:43.241203 IP anydnsmby.52261 > f.root-servers.net.domain: 3841 [1au] NS?
. (28)
15:36:43.624041 IP anydnsmby.48889 > k.root-servers.net.domain: 6314 [1au] NS?
. (28)
15:36:44.424047 IP anydnsmby.65507 > c.root-servers.net.domain: 27973 [1au]
NS? . (28)
15:37:42.071574 IP anydnsmby.38958 > i.root-servers.net.domain: 53519 [1au]
NS? 117.240.177.150. (44)
15:40:11.121122 IP anydnsmby.7941 > i.root-servers.net.domain: 62400 [1au] NS?
1.mr. (33)
15:45:52.780062 IP anydnsmby.49432 > e.root-servers.net.domain: 54241+ [1au]
NS? . (28)
15:45:59.341780 IP anydnsmby.34368 > e.root-servers.net.domain: 55928+ [1au]
NS? . (28)
15:46:04.487088 IP anydnsmby.35621 > e.root-servers.net.domain: 7266+ [1au]
NS? . (28)
15:46:35.453029 IP anydnsmby.62875 > i.root-servers.net.domain: 4129 [1au] NS?
comp-HP. (36)
16:16:13.747955 IP anydnsmby.39690 > a.root-servers.net.domain: 8774+ [1au]
NS? . (28)
16:16:20.845363 IP anydnsmby.36994 > e.root-servers.net.domain: 63433+ [1au]
NS? . (28)
16:16:36.746049 IP anydnsmby.42878 > a.root-servers.net.domain: 48439+ [1au]
NS? . (28)
16:16:42.060534 IP anydnsmby.41018 > j.root-servers.net.domain: 5347+ [1au]
NS? . (28)
16:16:49.081649 IP anydnsmby.53661 > e.root-servers.net.domain: 54768+ [1au]
NS? . (28)
16:51:14.034065 IP anydnsmby.38025 > k.root-servers.net.domain: 52771 [1au]
NS? 116.73.202.141. (43)
16:51:14.835539 IP anydnsmby.19616 > i.root-servers.net.domain: 14926 [1au]
NS? 116.73.202.141. (43)
17:25:16.706395 IP anydnsmby.58045 > i.root-servers.net.domain: 30880 [1au]
NS? 2.mr. (33)
17:25:16.707072 IP anydnsmby.38495 > i.root-servers.net.domain: 43451 [1au]
NS? 6.mr. (33)
17:25:16.707989 IP anydnsmby.35834 > i.root-servers.net.domain: 61843 [1au]
NS? 3.mr. (33)
17:56:44.855060 IP anydnsmby.61903 > a.root-servers.net.domain: 23284 [1au]
NS? 172.192.168.2. (42)
Regards,
Gaurav Kansal
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]<mailto:[email protected]>
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
