On Mon, Jun 15, 2015 at 1:29 PM, Darcy Kevin (FCA) <kevin.da...@fcagroup.com > wrote:
> 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 > There is more to than TTL expiry involved. TTL on the root is pretty long (60 days). There are also the regular and far more frequent checks for fastest response. These are performed according to an algorithm in BIND that I have not seen documented. It i possible that these queries are responsible, especially as queries are going out to multiple root servers. That said, I admit that I see a real possibility that Kevin is right. I also dislike "forward first". Since I am retired, I no longer manage a BIND server, so I have no logs to check on the behavior of "my" server. It would be interesting to see any documentation on the algorithm used to detect the "closest" root server as well as the log of someone else running a similar setup. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com On Monday, June 15, 2015 6:14 AM, Gaurav Kansal <gaurav.kan...@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 > -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com
_______________________________________________ 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
