<html><head></head><body><p dir="ltr">In case, i have my hint file in bind configuration and it also have its hard-coded one, who will get the priority.</p>
<p dir="ltr">Means which file will be used by bind for getting responses from root ?</p>
<p dir="ltr">Sent by kansal's device.<br />
</p><br /><br /><br />
<div class="gmail_quote">On Wed, Jun 17, 2015 at 7:17 AM -0700, "Anand Buddhdev" <span dir="ltr"><<a href="mailto:firstname.lastname@example.org" target="_blank">email@example.com</a>></span> wrote:<br />
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<pre>On 17/06/15 15:00, Matus UHLAR - fantomas wrote:
> well, the hard-coded hints file changes whenever new BIND release gets out,
> while the bungled hints file may be updated by packagers or manually.
> I'd say that the bundled hints file is likely to be newer than the
> hard-coded one.
Root name server addresses don't change that often. If you don't keep
your version of BIND up to date, the worst that will happen is that you
have slightly out-fo-date built-in hints. Assuming one of the root name
servers had changed its address in the meantime, the practical effect of
this is that upon startup, your BIND resolver's priming query has a 1 in
24 chance of timing out. If this happens, it will just try another
address and succeed, and all will be well after that.
This is why I prefer to depend on the built-in hints in BIND (and
Unbound too, but that's off-topic), instead of the hassle of installing
and maintaining a separate hints file. It just seems quite pointless.
Finally, let me add that if memory serves me correctly, ISC recommends
the use of built-in hints these days.
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list