Automatic . NS queries from BIND

Mon Jun 15 20:29:25 UTC 2015

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: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Leonard Mills
Sent: Monday, June 15, 2015 3:05 PM
To: Gaurav Kansal; bind-users at lists.isc.org
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 <gaurav.kansal at nic.in<mailto:gaurav.kansal at nic.in>> 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
bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20150615/24be44d2/attachment-0001.html>