Automatic . NS queries from BIND

Wed Jun 17 10:27:45 UTC 2015

Hi Cathy,

Thanks for nice explanation of the things.

I am using a latest hint file available on IANA server.

Just one more question, as we know that bind doesn't trust hint file
completely and goes to Root Servers for cross check the things (Root servers
which are defined in that hint file itself).

Now suppose, I am giving  a hint file (which has customized entry, means
having different IPs then the actual) and the servers which are defined in
that file are also giving customize information.

So how come checking with Root Servers help BIND in making trust.

At most, what I can make sure is my hint file is up-to-dated with this cross
check.

Pl. correct me if I am wrong.

Regards,

Gaurav Kansal

-----Original Message-----
From: bind-users-bounces at lists.isc.org
[mailto:bind-users-bounces at lists.isc.org] On Behalf Of Cathy Almond
Sent: Wednesday, June 17, 2015 1:52 PM
To: bind-users at lists.isc.org
Subject: Re: Automatic . NS queries from BIND

On 16/06/2015 01:51, Kevin Oberman wrote:

> On Mon, Jun 15, 2015 at 1:29 PM, Darcy Kevin (FCA) 

> < <mailto:kevin.darcy at fcagroup.com%20%3cmailto:kevin.darcy at fcagroup.com>
kevin.darcy at fcagroup.com <mailto:kevin.darcy at 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.

It sometimes happens that a recursive server 'learns' a new RRset for the
root servers as a result of something like an upward delegation by an old
DNS server.  Clearly this information is not as trustworthy as the list of
root nameservers obtained directly from the root nameservers themselves - so
just in case, named goes back and re-primes its list.

That's usually why the root server list is being refreshed more often than
the TTL.

There's one other reason which is less usual (but might indeed happen on a
server that is predominantly forwarding and not using the roots), and that
is if there is limited cache space, then the root server RRset could end up
being pushed out to make space for newer entries by means of the LRU (least
recently used) algorithm.

But I think my first explanation is more likely in this case.

Cathy

_______________________________________________

Please visit  <https://lists.isc.org/mailman/listinfo/bind-users>
https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this
list

bind-users mailing list

 <mailto:bind-users at lists.isc.org> bind-users at lists.isc.org

 <https://lists.isc.org/mailman/listinfo/bind-users>
https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20150617/4e262891/attachment.html>