Re: root hints

[Anand Buddhdev]

On 02/05/2018 23:39, Rick Dicaire wrote:

> Thanks for the responses folks...so if I don't need to manage root.hints,
> can I remove the line:
> 
> zone "." IN {type hint;file "root.cache";};
> 
> from named.conf?

Yes, you can remove it.

Regards,
Anand
___
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

Re: root hints

[Rick Dicaire]

Thanks for the responses folks...so if I don't need to manage root.hints,
can I remove the line:

zone "." IN {type hint;file "root.cache";};

from named.conf?
___
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

Re: root hints

[Warren Kumari]

On Wed, May 2, 2018 at 5:02 PM Greg Rivers 
wrote:

> On Wednesday, May 02, 2018 16:48:00 Rick Dicaire wrote:
> > ... what is the official/best practise/recommended way to update
> root.hints?
> >
> https://www.iana.org/domains/root/files
>
> But you don't really need it unless you're running an internal root; as
> stated at that link, "For many pieces of software, this list comes built
> into the software.". As I recall, this is true for BIND.



Yup, this is built into BIND and automagically managed.

Unless you have a *really* good reason to monkey with it, ‘tis best left
alone these days...

W


>
> --
> Greg Rivers
> ___
> 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
>
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
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

Re: root hints

[Greg Rivers]

On Wednesday, May 02, 2018 16:48:00 Rick Dicaire wrote:
> ... what is the official/best practise/recommended way to update root.hints?
>
https://www.iana.org/domains/root/files

But you don't really need it unless you're running an internal root; as stated 
at that link, "For many pieces of software, this list comes built into the 
software.". As I recall, this is true for BIND.

-- 
Greg Rivers
___
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

root hints

[Rick Dicaire]

Hi, used to be you could
dig > root.hints
and use this file in named.conf for root.hints configuration.
Some time around 9.11? the output of dig with no arguments stopped
reporting the ADDITIONAL section that shows the IPs of the root servers.

I've moved on to 9.12 and the dig behaviour is same as above, so for the
time being I'm using:
dig @a.root-servers.net.
to get an output usable for root.hints.

While the above works, what is the official/best practise/recommended way
to update root.hints?

Thanks
___
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

Re: root hints operation

[Tony Finch]

Grant Taylor  wrote:
>
> This quite from Twitter seems appropriate:  DNSSEC only protects you from
> getting bad answers.  If someone wants you to get no answers at all then
> DNSSEC cannot help.

That wasn't from Twitter, that was from me on NANOG.
http://mailman.nanog.org/pipermail/nanog/2015-November/082413.html

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
German Bight, Humber, Thames, Dover: West or northwest, backing southwest for
a time, 6 to gale 8, increasing severe gale 9 at times, perhaps storm 10 later
in German Bight and Humber. Rough or very rough, occasionally high later in
German Bight and Humber. Rain at times. Good, occasionally poor.
___
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

Re: root hints operation

[Joseph S D Yao]

On 2015-11-17 04:21, Ray Bellis wrote:

On 17/11/2015 02:09, Grant Taylor wrote:

On 11/16/2015 06:56 PM, /dev/rob0 wrote:

You either specify a hints file to use, or use the compiled-in root
hints.


Interesting.  I was not aware that it was an exclusive or type 
situation.


It's important that they're exclusive - it would be very much harder 
to
build an isolated test bed (with "fake" root hints) if BIND insisted 
on

always trying to reach all of the compiled-in root hints.

...

Or a real root hints file that differed from the compiled-in version, 
either in the current case (where there is a lot of overlap so it 
actually wouldn't matter that much) or for a private internet 
(lower-case 'i') with no overlap.



Joe Yao
___
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

RE: root hints operation

[Darcy Kevin (FCA)]

No default route to Internet, internal-root architecture; when you think this 
through, it's pretty obvious that the ability to explicitly specify "hints" is 
a mandatory feature of any enterprise-strength DNS product.

- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Joseph S D Yao
Sent: Tuesday, November 17, 2015 10:25 AM
To: Ray Bellis
Cc: bind-users@lists.isc.org
Subject: Re: root hints operation

On 2015-11-17 04:21, Ray Bellis wrote:
> On 17/11/2015 02:09, Grant Taylor wrote:
>> On 11/16/2015 06:56 PM, /dev/rob0 wrote:
>>> You either specify a hints file to use, or use the compiled-in root 
>>> hints.
>>
>> Interesting.  I was not aware that it was an exclusive or type 
>> situation.
>
> It's important that they're exclusive - it would be very much harder 
> to build an isolated test bed (with "fake" root hints) if BIND 
> insisted on always trying to reach all of the compiled-in root hints.
...

Or a real root hints file that differed from the compiled-in version, either in 
the current case (where there is a lot of overlap so it actually wouldn't 
matter that much) or for a private internet (lower-case 'i') with no overlap.


Joe Yao
___
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
___
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

Re: root hints operation

[Grant Taylor]

On 11/17/2015 03:02 PM, Dave Warren wrote:

Or, the IP formerly used as a root server could turn malicious and start
offering an alternate response. This would only impact resolvers that
had outdated root hints, and also happened to try that particular IP
first, but it's at least a theoretical risk.


I read that the old IP that H-root is currently using will stay under 
the Army's control and will never be used for a DNS server again.


Does anyone know if any of the other root servers that have changed 
their address have similarly quarantined the old IPs?




--
Grant. . . .
unix || die
___
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

Re: root hints operation

[Grant Taylor]

On 11/17/2015 03:22 PM, Mark Andrews wrote:

Given the root zone is signed and most of the TLD's are also signed
there is little a rogue operator can do besides causing a DoS if
you validate the returned answers.


This quite from Twitter seems appropriate:  DNSSEC only protects you 
from getting bad answers.  If someone wants you to get no answers at all 
then DNSSEC cannot help.


I think it would be possible for a rogue operator to completely hide 
DNSSEC related records (NODATA) and revert to pre-DNSSEC DNS.  Thus it 
would then be possible to do some nefarious things.


I think the only thing that would help thwart this type of behavior is 
for clients to do DNSSEC validation themselves.  (It's my understanding 
that most do not.)




--
Grant. . . .
unix || die
___
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

Re: root hints operation

[Grant Taylor]

On 11/17/2015 02:15 AM, Cathy Almond wrote:

If someone *could* maliciously replace a file on your DNS server with a
blank one, you have more problems than just a blank root hints file
don't you?


Very likely.  But not guaranteed.  }:->



--
Grant. . . .
unix || die
___
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

Re: root hints operation

[Grant Taylor]

On 11/17/2015 02:21 AM, Ray Bellis wrote:

It's important that they're exclusive - it would be very much harder to
build an isolated test bed (with "fake" root hints) if BIND insisted on
always trying to reach all of the compiled-in root hints.


Valid point.  Thanks Ray.

Otherwise, I might be tempted to leverage some network black magic.


--
Grant. . . .
unix || die
___
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

Re: root hints operation

[Grant Taylor]

On 11/17/2015 04:10 PM, Darcy Kevin (FCA) wrote:

No default route to Internet, internal-root architecture; when you think this through, 
it's pretty obvious that the ability to explicitly specify "hints" is a 
mandatory feature of any enterprise-strength DNS product.


There is noting that prevents me from applying AS112 methodologies to 
the root DNS servers.  (Network black magic.)




--
Grant. . . .
unix || die
___
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

Re: root hints operation

[Mark Andrews]

In message <564be747.40...@tnetconsulting.net>, Grant Taylor writes:
> On 11/17/2015 03:22 PM, Mark Andrews wrote:
> > Given the root zone is signed and most of the TLD's are also signed
> > there is little a rogue operator can do besides causing a DoS if
> > you validate the returned answers.
> 
> This quite from Twitter seems appropriate:  DNSSEC only protects you 
> from getting bad answers.  If someone wants you to get no answers at all 
> then DNSSEC cannot help.

As I said.  It doesn't protect you from a Denial of Service.
 
> I think it would be possible for a rogue operator to completely hide 
> DNSSEC related records (NODATA) and revert to pre-DNSSEC DNS.  Thus it 
> would then be possible to do some nefarious things.
> 
> I think the only thing that would help thwart this type of behavior is 
> for clients to do DNSSEC validation themselves.  (It's my understanding 
> that most do not.)

If your recursive server is validating then you are protected from a
rogue root server.

If your application is validating then you are protected from a 
rogue root server and a rogue recursive server.

Mark

> -- 
> Grant. . . .
> unix || die
> ___
> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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

Re: root hints operation

[Cathy Almond]

On 17/11/2015 02:31, Grant Taylor wrote:
...
> The idea that a (maliciously) blank root.hints file would prevent BIND
> from using the compiled in version is new to me.

If someone *could* maliciously replace a file on your DNS server with a
blank one, you have more problems than just a blank root hints file
don't you?


___
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

Re: root hints operation

[Ray Bellis]

On 17/11/2015 02:09, Grant Taylor wrote:
> On 11/16/2015 06:56 PM, /dev/rob0 wrote:
>> You either specify a hints file to use, or use the compiled-in root
>> hints.
> 
> Interesting.  I was not aware that it was an exclusive or type situation.

It's important that they're exclusive - it would be very much harder to
build an isolated test bed (with "fake" root hints) if BIND insisted on
always trying to reach all of the compiled-in root hints.

Ray


___
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

Re: root hints operation

[Dave Warren]

On 2015-11-17 14:13, Mark Andrews wrote:

In message <564ba3e3.9060...@hireahit.com>, Dave Warren writes:

On 2015-11-16 18:09, Grant Taylor wrote:

It's my understanding that ALL of the root servers would have to
change all of their addresses at the same time for DNS to be impacted.

Or, the IP formerly used as a root server could turn malicious and start
offering an alternate response. This would only impact resolvers that
had outdated root hints, and also happened to try that particular IP
first, but it's at least a theoretical risk.

Which is why those addresses get held back from reassignment.  It is a
known risk that is mitigated.


Understood and agreed, there's little real-world risk, but it's 
important to understand that this risk is mitigated by policy, not by 
technology.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren


___
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

Re: root hints operation

[Mark Andrews]

In message <564ba3e3.9060...@hireahit.com>, Dave Warren writes:
> On 2015-11-16 18:09, Grant Taylor wrote:
> > It's my understanding that ALL of the root servers would have to 
> > change all of their addresses at the same time for DNS to be impacted. 
> 
> Or, the IP formerly used as a root server could turn malicious and start 
> offering an alternate response. This would only impact resolvers that 
> had outdated root hints, and also happened to try that particular IP 
> first, but it's at least a theoretical risk.

Which is why those addresses get held back from reassignment.  It is a
known risk that is mitigated.
 
> -- 
> Dave Warren
> http://www.hireahit.com/
> http://ca.linkedin.com/in/davejwarren
> 
> 
> ___
> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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

Re: root hints operation

[Mark Andrews]

In message <564ba6e9.2050...@hireahit.com>, Dave Warren writes:
> On 2015-11-17 14:13, Mark Andrews wrote:
> > In message <564ba3e3.9060...@hireahit.com>, Dave Warren writes:
> >> On 2015-11-16 18:09, Grant Taylor wrote:
> >>> It's my understanding that ALL of the root servers would have to
> >>> change all of their addresses at the same time for DNS to be impacted.
> >> Or, the IP formerly used as a root server could turn malicious and start
> >> offering an alternate response. This would only impact resolvers that
> >> had outdated root hints, and also happened to try that particular IP
> >> first, but it's at least a theoretical risk.
> > Which is why those addresses get held back from reassignment.  It is a
> > known risk that is mitigated.
> 
> Understood and agreed, there's little real-world risk, but it's 
> important to understand that this risk is mitigated by policy, not by 
> technology.

Given the root zone is signed and most of the TLD's are also signed
there is little a rogue operator can do besides causing a DoS if
you validate the returned answers.

> -- 
> Dave Warren
> http://www.hireahit.com/
> http://ca.linkedin.com/in/davejwarren
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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

root hints operation

[Grant Taylor]

In light of the upcoming H-root server changing addresses I wanted to 
confirm how BIND uses root hints.


It's my understanding that BIND has a compiled in version of the root 
hints -and- a root hints file that can easily be updated.  This 
information is used to prime named as it starts up in such as it takes 
an IP for one of the root servers and attempts a to query to update the 
root hint server name to IP mappings.  I believe that named will cycle 
through all of the IPs in the root hints file until it finds a server 
that it can query and update all of the root server names / IPs in 
memory.  From and then continues running with that updated information.


As such, I think BIND will continue operating with little, if any, ill 
effect if people don't update their root hints file immediately. 
(Though ideally people should update.)


Will someone take a moment and confirm, or correct, my understanding of 
how root hints work in BIND?




--
Grant. . . .
unix || die
___
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

Re: root hints operation

[/dev/rob0]

On Mon, Nov 16, 2015 at 06:37:36PM -0700, Grant Taylor wrote:
> In light of the upcoming H-root server changing addresses I wanted 
> to confirm how BIND uses root hints.
> 
> It's my understanding that BIND has a compiled in version of the 
> root hints -and- a root hints file that can easily be updated.

You either specify a hints file to use, or use the compiled-in root 
hints.

> This information is used to prime named as it starts up in such as 
> it takes an IP for one of the root servers and attempts a to query 
> to update the root hint server name to IP mappings.  I believe that 
> named will cycle through all of the IPs in the root hints file 
> until it finds a server that it can query and update all of the 
> root server names / IPs in memory.  From and then continues running 
> with that updated information.
> 
> As such, I think BIND will continue operating with little, if any, 
> ill effect if people don't update their root hints file 
> immediately. (Though ideally people should update.)

Since the beginning of DNS, there has not been enough change to root 
hints so as to cause operational problems.

> Will someone take a moment and confirm, or correct, my 
> understanding of how root hints work in BIND?

I think this should answer your questions:

https://www.isc.org/blogs/h-root-will-change-its-addresses-on-1-december-2015-what-does-this-mean-for-you/
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
___
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

Re: root hints operation

[Grant Taylor]

On 11/16/2015 07:20 PM, Barry Margolin wrote:

Did you think it combined the file with the built-in list?


I hadn't given much thought to how the built in would or would not be 
combined with the contents of the root.hints file.


I always took it that BIND would fall back to the compiled in version if 
nothing else succeeded.



It is. I'm not even sure you misunderstood the XOR, since you wrote that
it tries each server in the root hints file until it gets a successful
response. That suggests that you understood that the built-in list is
used in place of the file if no file is provided.


The idea that a (maliciously) blank root.hints file would prevent BIND 
from using the compiled in version is new to me.




--
Grant. . . .
unix || die
___
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

Re: root hints operation

[Grant Taylor]

On 11/16/2015 06:56 PM, /dev/rob0 wrote:

You either specify a hints file to use, or use the compiled-in root
hints.


Interesting.  I was not aware that it was an exclusive or type situation.


Since the beginning of DNS, there has not been enough change to root
hints so as to cause operational problems.


Agreed.

It's my understanding that ALL of the root servers would have to change 
all of their addresses at the same time for DNS to be impacted.



I think this should answer your questions:


I was hoping for a thumbs up or thumbs down, not to be pointed at 
another document.


Based on the way I read the link, I still believe my original post is 
accurate.  (Save for the XOR.)




--
Grant. . . .
unix || die
___
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

Re: root hints operation

[Barry Margolin]

In article <mailman.2932.1447726182.26362.bind-us...@lists.isc.org>,
 Grant Taylor <gtay...@tnetconsulting.net> wrote:

> On 11/16/2015 06:56 PM, /dev/rob0 wrote:
> > You either specify a hints file to use, or use the compiled-in root
> > hints.
> 
> Interesting.  I was not aware that it was an exclusive or type situation.

Did you think it combined the file with the built-in list?

> Based on the way I read the link, I still believe my original post is 
> accurate.  (Save for the XOR.)

It is. I'm not even sure you misunderstood the XOR, since you wrote that 
it tries each server in the root hints file until it gets a successful 
response. That suggests that you understood that the built-in list is 
used in place of the file if no file is provided.

-- 
Barry Margolin
Arlington, MA
___
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

Re: Root hints

[Reindl Harald]

Am 06.10.2015 um 19:42 schrieb Jack Tavares:

Since the H root server IP address will be changing I have a question:
http://h.root-servers.org/renumber.html

how does bind get the root servers these days?
I think the code includes a set.


yes, a hardcoded fallback


Is there a provision to query a known address to get an update?


AFAIK no


(I also know that I can define a hints file locally)


i am using a script like below to deploy the hint-files
well, not terrible happy about non-TLS at the moment

[root@buildserver:~]$ cat /buildserver/distribute-dns-root-zones.sh
#!/usr/bin/bash
if wget --quiet ftp://ftp.internic.net/domain/named.cache 
--output-document=/var/named/chroot/var/named/named.ca; then

 cat /var/named/chroot/var/named/named.ca | grep "last update"
 chmod 0644 /var/named/chroot/var/named/named.ca
 ** rsync to nameservers **
fi



signature.asc
Description: OpenPGP digital signature
___
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

Re: Root hints

[Evan Hunt]

On Tue, Oct 06, 2015 at 05:42:52PM +, Jack Tavares wrote:
> Since the H root server IP address will be changing I have a question:
> http://h.root-servers.org/renumber.html
> 
> how does bind get the root servers these days?
> I think the code includes a set.

There's a copy of the hints built in to named (it's in lib/dns/rootns.c).
We update it periodically (most recently to add an  for D root a few
years ago), and will do so again when the H address changes.  IIRC that
change is planned for the end of this year, so the change will be included
in BIND 9.9.9, 9.10.4, and 9.11.0.

> Is there a provision to query a known address to get an update?

When named starts up, if it's running as an iterative resolver (as opposed
to a forwarder), the first thing it does is send a "priming" query to the
hint servers looking for a new up-to-date NS RRset.

In servers that still have the old hints, H wouldn't respond to the
priming query, but all the other root servers would, and named
would learn the new address for H from one of them, so H will work
fine thereafter.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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

Root hints

[Jack Tavares]

Since the H root server IP address will be changing I have a question:
http://h.root-servers.org/renumber.html

how does bind get the root servers these days?
I think the code includes a set.

Is there a provision to query a known address to get an update?

(I also know that I can define a hints file locally)

Thank you 

--
Jack Tavares
___
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

Re: redirecting root hints to fake internal root server

[Cathy Almond]

On 27/08/13 21:28, Kevin Darcy wrote:
 On 8/27/2013 1:07 PM, Colin Harvey wrote:
 My environment is firewalled from the real world.  For queries on
 zones to which I'm not master, I want to recurse to a corporate
 server.  nslookup some.internal.hostname.com internal.corporate.server
 works fine.
 nslookup is a terrible DNS troubleshooting tool. Try dig. And to mimic
 how your nameserver would talk to the other nameserver, use the options
 +norec and +bufsiz=4096 (unless you've changed your EDNS0 buffer size
 from the default, in which case, plug in that value instead).
 
 Setting . to use this internal server in the root.hints file does
 not.  In fact I do not even see my system trying to recurse.  (I'm
 looking at network traffic with a sniffer.)
 My root.hints:
 .600INNSinternal.corporate.server.
 internal.corporate.server.600INA192.168.1.1
 Do you have recursion enabled?
 Alternatively I've setup a forwarding zone in named.conf to query
 192.168.1.1 for 'internal.hostname.com'.
 Ugh, don't do that. Forwarding is for getting around network
 restrictions or limitations, and you haven't (so far) indicated that you
 have any of those to deal with.

If you're really playing in an internal-only name space with no queries
ever going out to the Internet name space, then in order to do recursion
properly in that environment, you should really have access to a
nameserver that is essentially taking the role of of the root
nameservers - an 'internal root'.  It should be authoritative for .
and then in its root zone, have delegations to your internal namespace
nameservers for the internal top level zones.  It might also be
authoritative for some of those internal zones itself too.

On your recursive server, you configure the internal root nameserver in
your hints zone, and then when you first need to recurse, it will
'prime' the roots by querying that server for the NS records for '.'.
If that server (or those servers) doesn't (don't) respond
authoritatively with the necessary information, then your server isn't
going to be able to do recursion very successfully. :-(

If you don't have internal roots, then you don't really have any option
except to use forwarding to direct queries to another nameserver to deal
with where you don't have something else in place to resolve queries for
that specific zone.  Bear in mind that you (usually!) can't control what
names your clients will query you for if you're 'their' recursive
server, so you need some way to handle anything they throw at you.

For the 'known' other internal zones, you can use zone type static-stub
to 'tell' your recursive server who the authoritative servers are - and
you should just need to configure the top level(s) - everything else
below those should then be resolved recursively, starting with those
static-stub servers as the 'nearest' authoritative servers if there are
none nearer already in cache.

And finally, although this probably isn't the cause of your problems,
you're using an RFC1918 network, so depending on what else you have
configured, you might be tripping over the automatic empty zones that
named loads.  There's also a bug (to be fixed in upcoming releases)
where adding a manually configured zone of type forward as opposed to
any other type isn't disabling the creation of the automatic zone.  Take
a look at disable-empty-zone in the ARM, and also
https://kb.isc.org/article/AA-00800 (you'll need to register to view it,
but registration is open to all).  There's also
https://kb.isc.org/article/AA-00803 that includes a feedback comment
about the bug that was recently uncovered.

And yes - do use dig (from your recursive server) rather than nslookup
for testing - with options that you've previously had recommended to you.

Cathy





___
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

Re: redirecting root hints to fake internal root server

[Kevin Darcy]

On 8/28/2013 5:25 AM, Cathy Almond wrote:

On 27/08/13 21:28, Kevin Darcy wrote:

On 8/27/2013 1:07 PM, Colin Harvey wrote:

My environment is firewalled from the real world.  For queries on
zones to which I'm not master, I want to recurse to a corporate
server.  nslookup some.internal.hostname.com internal.corporate.server
works fine.

nslookup is a terrible DNS troubleshooting tool. Try dig. And to mimic
how your nameserver would talk to the other nameserver, use the options
+norec and +bufsiz=4096 (unless you've changed your EDNS0 buffer size
from the default, in which case, plug in that value instead).


Setting . to use this internal server in the root.hints file does
not.  In fact I do not even see my system trying to recurse.  (I'm
looking at network traffic with a sniffer.)
My root.hints:
.600INNSinternal.corporate.server.
internal.corporate.server.600INA192.168.1.1

Do you have recursion enabled?

Alternatively I've setup a forwarding zone in named.conf to query
192.168.1.1 for 'internal.hostname.com'.

Ugh, don't do that. Forwarding is for getting around network
restrictions or limitations, and you haven't (so far) indicated that you
have any of those to deal with.

If you're really playing in an internal-only name space with no queries
ever going out to the Internet name space, then in order to do recursion
properly in that environment, you should really have access to a
nameserver that is essentially taking the role of of the root
nameservers - an 'internal root'.  It should be authoritative for .
and then in its root zone, have delegations to your internal namespace
nameservers for the internal top level zones.  It might also be
authoritative for some of those internal zones itself too.

On your recursive server, you configure the internal root nameserver in
your hints zone, and then when you first need to recurse, it will
'prime' the roots by querying that server for the NS records for '.'.
If that server (or those servers) doesn't (don't) respond
authoritatively with the necessary information, then your server isn't
going to be able to do recursion very successfully. :-(

If you don't have internal roots, then you don't really have any option
except to use forwarding to direct queries to another nameserver to deal
with where you don't have something else in place to resolve queries for
that specific zone.  Bear in mind that you (usually!) can't control what
names your clients will query you for if you're 'their' recursive
server, so you need some way to handle anything they throw at you.
That's a risky choice, since when you forward to another server by 
default, you trust it with your name resolution. As we know, trust isn't 
always transitive. If they forward, and they forward, and so on, 
eventually you may find that your resolution is going out to the 
Internet, your users are forming VPN tunnels over DNS, and bypassing all 
of your security controls.


So, my preference in this situation would be to define a root zone locally.

- Kevin
___
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

Re: redirecting root hints to fake internal root server

[WBrown]

From: Colin Harvey colinedwardhar...@yahoo.com
 My environment is firewalled from the real world.  For queries on 
 zones to which I'm not master, I want to recurse to a corporate 
 server.  nslookup some.internal.hostname.com 
 internal.corporate.server works fine.  Setting . to use this 
 internal server in the root.hints file does not.  In fact I do not 
 even see my system trying to recurse.  (I'm looking at network 
 traffic with a sniffer.)
 
 My root.hints:
 
 .600INNSinternal.corporate.server.
 internal.corporate.server.600INA192.168.1.1
 
 
 Alternatively I've setup a forwarding zone in named.conf to query 
 192.168.1.1 for 'internal.hostname.com'.  When monitoring the 
 network for udp data over port 53, I'm not even seeing the query 
 being forwarded.  Why?

Add these lines to your options section:

forward only;
forwarders {192.168.1.1;};

see 
ftp://ftp.isc.org/isc/bind9/9.9.3-P2/doc/arm/Bv9ARM.ch06.html#id2578567



Confidentiality Notice: 
This electronic message and any attachments may contain confidential or 
privileged information, and is intended only for the individual or entity 
identified above as the addressee. If you are not the addressee (or the 
employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that 
you may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or 
telephone and delete this message from your system.
___
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

Re: redirecting root hints to fake internal root server

[Colin Harvey]

Thanks.  But I already have that option for the internal.hostname.com zone.  
Still not seeing traffic going to 192.168.1.1.
 
Colin

From: wbr...@e1b.org wbr...@e1b.org
To: Colin Harvey colinedwardhar...@yahoo.com 
Cc: bind users bind-users@lists.isc.org; 
bind-users-bounces+wbrown=e1b@lists.isc.org 
Sent: Tuesday, August 27, 2013 1:20 PM
Subject: Re: redirecting root hints to fake internal root server


From: Colin Harvey colinedwardhar...@yahoo.com
 My environment is firewalled from the real world.  For queries on 
 zones to which I'm not master, I want to recurse to a corporate 
 server.  nslookup some.internal.hostname.com 
 internal.corporate.server works fine.  Setting . to use this 
 internal server in the root.hints file does not.  In fact I do not 
 even see my system trying to recurse.  (I'm looking at network 
 traffic with a sniffer.)
 
 My root.hints:
 
 .    600    IN    NS    internal.corporate.server.
 internal.corporate.server.    600    IN    A    192.168.1.1
 
 
 Alternatively I've setup a forwarding zone in named.conf to query 
 192.168.1.1 for 'internal.hostname.com'.  When monitoring the 
 network for udp data over port 53, I'm not even seeing the query 
 being forwarded.  Why?

Add these lines to your options section:

        forward only;
        forwarders {192.168.1.1;};

see 
ftp://ftp.isc.org/isc/bind9/9.9.3-P2/doc/arm/Bv9ARM.ch06.html#id2578567



Confidentiality Notice: 
This electronic message and any attachments may contain confidential or 
privileged information, and is intended only for the individual or entity 
identified above as the addressee. If you are not the addressee (or the 
employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that 
you may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or 
telephone and delete this message from your system.___
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

Re: redirecting root hints to fake internal root server

[Colin Harvey]

 
dig +trace host.internal.hostname.com responds with a list of authoritative 
nameservers for the zone and the error dig: couldn't get address for 
ns1.corporate.hostname.com where the error cycles through all four of the 
authoritative nameservers.
 
Also ns1.corporate.hostname.com is not 192.168.1.1.
 
Colin
 

From: Colin Harvey colinedwardhar...@yahoo.com
To: wbr...@e1b.org wbr...@e1b.org 
Cc: bind-users-bounces+wbrown=e1b@lists.isc.org 
bind-users-bounces+wbrown=e1b@lists.isc.org; bind users 
bind-users@lists.isc.org 
Sent: Tuesday, August 27, 2013 2:13 PM
Subject: Re: redirecting root hints to fake internal root server



Thanks.  But I already have that option for the internal.hostname.com zone.  
Still not seeing traffic going to 192.168.1.1.
 
Colin

From: wbr...@e1b.org wbr...@e1b.org
To: Colin Harvey colinedwardhar...@yahoo.com 
Cc: bind users bind-users@lists.isc.org; 
bind-users-bounces+wbrown=e1b@lists.isc.org 
Sent: Tuesday, August 27, 2013 1:20 PM
Subject: Re: redirecting root hints to fake internal root server


From: Colin Harvey colinedwardhar...@yahoo.com
 My environment is firewalled from the real world.  For queries on 
 zones to which I'm not master, I want to recurse to a corporate 
 server.  nslookup some.internal.hostname.com 
 internal.corporate.server works fine.  Setting . to use this 
 internal server in the root.hints file does not.  In fact I do not 
 even see my system trying to recurse.  (I'm looking at network 
 traffic with a sniffer.)
 
 My root.hints:
 
 .    600    IN    NS    internal.corporate.server.
 internal.corporate.server.    600    IN    A    192.168.1.1
 
 
 Alternatively I've setup a forwarding zone in named.conf to query 
 192.168.1.1 for 'internal.hostname.com'.  When monitoring the 
 network for udp data over port 53, I'm not even seeing the query 
 being forwarded.  Why?

Add these lines to your options section:

        forward only;
        forwarders {192.168.1.1;};

see 
ftp://ftp.isc.org/isc/bind9/9.9.3-P2/doc/arm/Bv9ARM.ch06.html#id2578567



Confidentiality Notice: 
This electronic message and any attachments may contain confidential or 
privileged information, and is intended only for the individual or entity 
identified above as the addressee. If you are not the addressee (or the 
employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that 
you may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or 
telephone and delete this message from your system.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-usersto unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
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
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: redirecting root hints to fake internal root server

[Kevin Darcy]

On 8/27/2013 1:07 PM, Colin Harvey wrote:
My environment is firewalled from the real world.  For queries on 
zones to which I'm not master, I want to recurse to a corporate 
server.  nslookup some.internal.hostname.com 
internal.corporate.server works fine.
nslookup is a terrible DNS troubleshooting tool. Try dig. And to mimic 
how your nameserver would talk to the other nameserver, use the options 
+norec and +bufsiz=4096 (unless you've changed your EDNS0 buffer size 
from the default, in which case, plug in that value instead).


Setting . to use this internal server in the root.hints file does 
not.  In fact I do not even see my system trying to recurse.  (I'm 
looking at network traffic with a sniffer.)

My root.hints:
.600INNSinternal.corporate.server.
internal.corporate.server.600INA192.168.1.1

Do you have recursion enabled?
Alternatively I've setup a forwarding zone in named.conf to query 
192.168.1.1 for 'internal.hostname.com'.
Ugh, don't do that. Forwarding is for getting around network 
restrictions or limitations, and you haven't (so far) indicated that you 
have any of those to deal with.


- Kevin

___
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

Re: Noisy messages from BIND about root hints change

[Cathy Almond]

On 07/01/13 17:14, Chris Thompson wrote:
 One (but only one) of our recursive nameservers, running BIND 9.8.3-P4
 we got a whole lot of messages in the log as a result of last week's change
 of address for d.root-servers.net:
 
 Jan  4 06:24:08 recdns1.csx.cam.ac.uk named[9496]: general: warning:
   checkhints: d.root-servers.net/A (128.8.10.90) missing from hints
 Jan  4 06:24:08 recdns1.csx.cam.ac.uk named[9496]: general: warning:
   checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints
 Jan  4 06:24:09 recdns1.csx.cam.ac.uk named[9496]: general: warning:
   checkhints: d.root-servers.net/A (128.8.10.90) missing from hints
 Jan  4 06:24:09 recdns1.csx.cam.ac.uk named[9496]: general: warning:
   checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints
 
 [... 1972 pairs of messages omitted ...]
 
 Jan  4 08:50:05 recdns1.csx.cam.ac.uk named[9496]: general: warning:
   checkhints: d.root-servers.net/A (128.8.10.90) missing from hints
 Jan  4 08:50:05 recdns1.csx.cam.ac.uk named[9496]: general: warning:
   checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints
 Jan  4 08:50:08 recdns1.csx.cam.ac.uk named[9496]: general: warning:
   checkhints: d.root-servers.net/A (128.8.10.90) missing from hints
 Jan  4 08:50:08 recdns1.csx.cam.ac.uk named[9496]: general: warning:
   checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints
 
 And then they stopped.
 
 Now I can more or less work out what provoked the first message. We had
 already changed our root hints file the previous day (and done an rndc
 reconfig) but the old A record for d.root-servers.net was still in the
 cache (and was still there much later on 4 January as I explicitly did
 an rndc flushname on it for other reasons). One of our regular checking
 jobs at 06:24 will have used this recursive nameserver to look up the
 NS records for . and the address records for the *.root-servers.net
 names so referenced.
 
 But why did it keep going on and on about it? And what made it stop?
 Has anyone else seen anything similar?

I've seen one other report of repeating messages from checkhints - but
they also 'went away' (temporarily seen due to the transition of
addresses, and fixed by fixing the hints file to have D-root's new IPv4
address).

Differences between what's in the hints file and what's returned when
querying the root nameservers should only be 'spotted' by checkhints
when the cache is re-primed with the list of root nameservers - and that
should only happen when the roots have all expired from the cache.

What happens then is that the next time that a root nameserver needs to
be sent a query, named goes back to the hints and uses those to query
for an up-to-date list of root nameservers and their addresses - and
it's then that it will warn on any differences.

Now - on a busy cache, it would not be that unusual not to send queries
to root nameservers very often once you've been up and running for
awhile and have handled queries for all of the main TLDs.

So the theory I have for this is that the caches reporting a spate of
repeated warnings are ones in which there is a fairly conservative
max-cache-size set and then sufficient cache 'thrash' that the root
RRset is getting expired out of cache on the basis of 'least recently
used' (LRU cache management) to make space for other new entries.

Might that ring true in your case?

(Although - by 4th January - the new address should have been being
served by all the official root nameservers.  So it's still a bit odd
why you saw this at all, and moreover that you didn't see it before the
switch - so I'm not entirely convinced by the theory I'm putting forward
to you, and wonder if there was some other factor in play too).

Cathy



___
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

Noisy messages from BIND about root hints change

[Chris Thompson]

One (but only one) of our recursive nameservers, running BIND 9.8.3-P4
we got a whole lot of messages in the log as a result of last week's change
of address for d.root-servers.net:

Jan  4 06:24:08 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (128.8.10.90) missing from hints
Jan  4 06:24:08 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints
Jan  4 06:24:09 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (128.8.10.90) missing from hints
Jan  4 06:24:09 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints

[... 1972 pairs of messages omitted ...]

Jan  4 08:50:05 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (128.8.10.90) missing from hints
Jan  4 08:50:05 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints
Jan  4 08:50:08 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (128.8.10.90) missing from hints
Jan  4 08:50:08 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints

And then they stopped.

Now I can more or less work out what provoked the first message. We had
already changed our root hints file the previous day (and done an rndc
reconfig) but the old A record for d.root-servers.net was still in the
cache (and was still there much later on 4 January as I explicitly did
an rndc flushname on it for other reasons). One of our regular checking
jobs at 06:24 will have used this recursive nameserver to look up the
NS records for . and the address records for the *.root-servers.net
names so referenced.

But why did it keep going on and on about it? And what made it stop?
Has anyone else seen anything similar?

--
Chris Thompson
Email: c...@cam.ac.uk
___
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

Root hints updates

[Timothe Litt]

In doing some system administration, I realized that I have a tool that
might be
generally useful - ISC is welcome to add it to contribs.  Hopefully the
attachment
will make it through the mailing list server.

This is a script to automagically update the root hints file.  There are a
bunch of these floating around the internet; most don't work; those that do
don't work well.  I wrote this several years ago; it's worked for me.

It will FTP the new file - or, if you value speed over comments, will
fabricate
a copy from the existing root servers - yes, it will deal with the case
that a root server is renumbered or returns partial data.  It acts as a
SYS V init script so that it runs on every boot; It's smart enough to
requeue itself hourly if it fails to get data.  It verifies FTP transfers.

It also runs as a cron job monthly to catch any updates.  It will log
actions
to syslog; will also send mail if you like.  It preserves file ownership and
the timestamp of last download.  It knows to run rndc reconfig when it gets
a new file. (And not when nothing has changed.)  

I did some cleanup for this release, but the core logic has run for several
years on Fedora and random embedded Linuxes.  For me, it's install  forget.

README:
Install it (or create a link to it) in /etc/init.d/ as update_root.  E.g. if
it's 
in /usr/local/sbin, then  
   ln -sf ../../../usr/local/sbin/update_root /etc/init.d/ 
Then execute
  /etc/init.d/update_root setup 
and 
  /etc/init.d/update_root  

Create a /etc/sysconfig/update_root file if you want a non-default
configuration.
The most useful configuration variables are:

# Undefined uses FTP (default)
#USEDNS=yes 
# Root file name
HINT=ROOT.HINT
# named control address (undef for none)
NAMEDRNDC=127.0.0.1
# Root file owner
DEFAULTOWNER=named:named (When there's no file; normally copies from old)
# Define for e-mail recipient (default is undef = none)
#TO=hostmas...@example.com
# Cron directories
CRONMONTHLY=/etc/cron.monthly
CRONHOURLY=/etc/cron.hourly
# No IPV6?  This may speed FTP connections.
WGET=$WGET -4

Other parameters are in the first ~80 lines of the script.

The script commands are:
  start - check for update (default if no command)
  setup - run chkconfig and link to monthly queue (don't if you use crontab)
  status - list current file

One caution: Do not copy the script using copy  paste; there are places
where
literal tabs and spaces are important.  [Some environments have very limited
regexps.]

It's freely redistributable, with the usual caveat that there is no warranty
or
promise of support  that you use it at your own risk.

Enjoy.


Timothe Litt
ACM Distinguished Engineer
-
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

 


update_root
Description: Binary data
___
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

Re: Root hints updates

[Stephane Bortzmeyer]

On Thu, Sep 06, 2012 at 08:06:45AM -0400,
 Timothe Litt l...@acm.org wrote 
 a message of 466 lines which said:

 This is a script to automagically update the root hints file. 

Since the first thing BIND does at startup is to check the root NS
set, and since DNSSEC guarantees that it is genuine, is there still an
use for this tool?
___
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

RE: Root hints updates

[Timothe Litt]

 Since the first thing BIND does at startup is to check the root NS set,
and since DNSSEC guarantees that it is genuine, is there still an use for
this tool?

Unless bind updates the hint file as a result of these checks, yes.

It's not a question of authenticity; named has to start somewhere to find
the root NS; this is the bootstrap cache. 

It wouldn't be a bad thing if bind did the update itself (sort of like
DNSSECS's 5011 for keys).  But so far as I know, it doesn't.

Since I run the tool, I can't say that I've ever seen a message from BIND
complaining about the root hints being out of date.  I know there was a root
hints update last June...  Does it sync to what it finds, or just complain?

Until someone authoritative tells me that BIND manages the hints file on its
own, I'm taking the conservative route and letting my tool run

BTW, I do have systems that come on-line every 5 years or so.  Automation is
good :-)

-
This communication may not represent my employer's views,
if any, on the matters discussed. 
 
-Original Message-
From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] 
Sent: Thursday, September 06, 2012 09:08
To: Timothe Litt
Cc: bind-users@lists.isc.org
Subject: Re: Root hints updates

On Thu, Sep 06, 2012 at 08:06:45AM -0400,  Timothe Litt l...@acm.org wrote
a message of 466 lines which said:

 This is a script to automagically update the root hints file. 

Since the first thing BIND does at startup is to check the root NS set, and
since DNSSEC guarantees that it is genuine, is there still an use for this
tool?

___
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

RE: Root hints updates

[Tony Finch]

Timothe Litt l...@acm.org wrote:

 Until someone authoritative tells me that BIND manages the hints file on its
 own, I'm taking the conservative route and letting my tool run
 BTW, I do have systems that come on-line every 5 years or so.  Automation is
 good :-)

Well, I'm not authoritative, but I don't have a root hints file on my
systems. Instead I rely on the hints built in to named, which get updated
when I update BIND. Also it doesn't matter if the hints are out of date
since the root name server list changes very infrequently and you only
need one of them to work for named to start OK.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
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

Re: Root hints updates

[Lyle Giese]

On 09/06/12 07:06, Timothe Litt wrote:

In doing some system administration, I realized that I have a tool that
might be
generally useful - ISC is welcome to add it to contribs.  Hopefully the
attachment
will make it through the mailing list server.

This is a script to automagically update the root hints file.  There are a
bunch of these floating around the internet; most don't work; those that do
don't work well.  I wrote this several years ago; it's worked for me.

It will FTP the new file - or, if you value speed over comments, will
fabricate
a copy from the existing root servers - yes, it will deal with the case
that a root server is renumbered or returns partial data.  It acts as a
SYS V init script so that it runs on every boot; It's smart enough to
requeue itself hourly if it fails to get data.  It verifies FTP transfers.

It also runs as a cron job monthly to catch any updates.  It will log
actions
to syslog; will also send mail if you like.  It preserves file ownership and
the timestamp of last download.  It knows to run rndc reconfig when it gets
a new file. (And not when nothing has changed.)

I did some cleanup for this release, but the core logic has run for several
years on Fedora and random embedded Linuxes.  For me, it's install  forget.

README:
Install it (or create a link to it) in /etc/init.d/ as update_root.  E.g. if
it's
in /usr/local/sbin, then
ln -sf ../../../usr/local/sbin/update_root /etc/init.d/
Then execute
   /etc/init.d/update_root setup
and
   /etc/init.d/update_root

Create a /etc/sysconfig/update_root file if you want a non-default
configuration.
The most useful configuration variables are:

# Undefined uses FTP (default)
#USEDNS=yes
# Root file name
HINT=ROOT.HINT
# named control address (undef for none)
NAMEDRNDC=127.0.0.1
# Root file owner
DEFAULTOWNER=named:named (When there's no file; normally copies from old)
# Define for e-mail recipient (default is undef = none)
#TO=hostmas...@example.com
# Cron directories
CRONMONTHLY=/etc/cron.monthly
CRONHOURLY=/etc/cron.hourly
# No IPV6?  This may speed FTP connections.
WGET=$WGET -4

Other parameters are in the first ~80 lines of the script.

The script commands are:
   start - check for update (default if no command)
   setup - run chkconfig and link to monthly queue (don't if you use crontab)
   status - list current file

One caution: Do not copy the script using copy  paste; there are places
where
literal tabs and spaces are important.  [Some environments have very limited
regexps.]

It's freely redistributable, with the usual caveat that there is no warranty
or
promise of support  that you use it at your own risk.

Enjoy.


Timothe Litt
ACM Distinguished Engineer
-
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

  



___
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

Nice script.  Now my pet peeve timeGRIN.

This file:
http://www.internic.net/domain/named.root

indicates the named.root file should be available at ftp.internic.net or 
rs.internic.net.  It's only at ftp.internic.net.


This page has a pointer to root hints file(via FTP) that does not work 
either.  The http version shows the above mistake.  It's not available 
at rs.internic.net.


http://www.iana.org/domains/root/files

Lyle Giese
LCR Computer Services, Inc.

___
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

Root Hints Data File for a .local Domain

[Tony MacDoodle]

Hello,

I am currently running BIND 9.6.1-P3 and it works fine. My question is
regarding the db.cache file. I am only running a local domain (apps.local)
that does not access the internet for resolution. My current root hints file
is from Internic.

1) Can I use a stripped version of the named.root file

2) Do I need it at all for a local domain


Thanks
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Root Hints Data File for a .local Domain

[Florian Weimer]

* Tony MacDoodle:

 2) Do I need it at all for a local domain

No, configuring a zone using the zone statement on all resolvers is
sufficient.  If the resolver knows about authoritative data, it will
not try to fetch it from the Internet.

You should reconsider using local, though.  Some clients treat it as
a special string.  Use a real domain name, or something under loc or
corp.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Root Hints Data File for a .local Domain

[Tony MacDoodle]

So in the named.conf file I can get rid of the following:

zone . { type hint; file db.cache; };

Thanks



On Wed, Mar 9, 2011 at 9:19 AM, Florian Weimer fwei...@bfk.de wrote:

 * Tony MacDoodle:

  2) Do I need it at all for a local domain

 No, configuring a zone using the zone statement on all resolvers is
 sufficient.  If the resolver knows about authoritative data, it will
 not try to fetch it from the Internet.

 You should reconsider using local, though.  Some clients treat it as
 a special string.  Use a real domain name, or something under loc or
 corp.

 --
 Florian Weimerfwei...@bfk.de
 BFK edv-consulting GmbH   http://www.bfk.de/
 Kriegsstraße 100  tel: +49-721-96201-1
 D-76133 Karlsruhe fax: +49-721-96201-99

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Root Hints Data File for a .local Domain

[Kevin Darcy]

On 3/9/2011 8:32 AM, Tony MacDoodle wrote:

Hello,

I am currently running BIND 9.6.1-P3 and it works fine. My question is 
regarding the db.cache file. I am only running a local domain 
(apps.local) that does not access the internet for resolution. My 
current root hints file is from Internic.


1) Can I use a stripped version of the named.root file

2) Do I need it at all for a local domain

If you're on a completely isolated network, with a DNS-consumer 
population of any significant size, you should set up your own root 
zone, along with defining slaves, setting up master/slave replication, 
and publishing all available nameservers in the NS records of the root 
zone. If, after you've built up that core authoritative infrastructure, 
you want any of your edge resolvers to be caching-only, i.e. with a 
minimal config, then you'd configure them with a root hints file, but 
it wouldn't contain the same contents as the one from Internic -- it 
would contain references to your own internal root nameservers, along 
with their internal addresses.


Someone suggested that .local might be problematic, but we've been 
using various .local domains in our internal DNS for years -- not my 
choice, this is from the Active Directory team of one of our business 
partners -- and not run into any problems so far.




- Kevin





___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root hints

[Mark Andrews]

In message barmar-a10cc5.23122928012...@news.eternal-september.org, Barry Mar
golin writes:
 In article mailman.1562.1296270623.555.bind-us...@lists.isc.org,
  Joseph S D Yao j...@tux.org wrote:
 
  [This does leave a security hole - if a root name server's IP changes,
  and a Bad Guy gets the old one; or on another internet, if the Bad Guy
  gets all the IP addresses in the default file.  It's not just lust for
  control that has me using a visible root hints file.]
 
 I'm sure the folks who run these networks are quite aware of this 
 danger.  If a root server changes, I'll bet it will be several years 
 before the old address goes to some other organization.
 
 How would a Bad Guy get these blocks, anyway?  Since when do 
 organizations return IP blocks.
 
 And if you check the registrations, several of them are assigned 
 specifically to reserve the blocks for root servers.  Presumably the 
 intent is that even if the organizations operating them change, the IPs 
 shouldn't -- they simply route the IPs to someone else.
 
 inetnum:202.12.27.0 - 202.12.27.255
 netname:NSPIXP-2
 descr:  root DNS server
 
 NetRange:   199.7.83.0 - 199.7.83.255
 CIDR:   199.7.83.0/24
 OriginAS:   AS20144
 NetName:L-ROOT
 
 -- 
 Barry Margolin, bar...@alum.mit.edu
 Arlington, MA
 *** PLEASE don't copy me on replies, I'll read them in the group ***
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

And one can always turn on DNSSEC and then it doesn't matter which server
gives you the information.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root hints

[Joseph S D Yao]

On Fri, Jan 28, 2011 at 11:12:29PM -0500, Barry Margolin wrote:
...
 I'm sure the folks who run these networks are quite aware of this 
 danger.  If a root server changes, I'll bet it will be several years 
 before the old address goes to some other organization.
...


Yah, I know.  May not be true on some private internets, tho.


--
/*\
**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root hints

[pyh]

Joseph S D Yao writes: 





Just because we don't need to, doesn't mean that it's a good practtice
not to.  And it's so easy to create one on a system where DNS is already
set up. 

	dig ns .  root.hints 



I disagree with this.
Few files mean few risk for admin.
How about the case when someone did echo  root.hints by mistake? 


Regards.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: root hints

[Jack Tavares]

I have a question about the hints file.

It is built in to BIND.

Does bind check for updates to this periodically?
If so, where does it get it from ?
I assume it gets it from ftp.isc.org.
Does bind contain a hardcode for that IP address?
or does it use the existing hints to find the address
of ftp.isc.org and then download a new ftp.isc.org?

Thanks
--
jack

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root hints

[Anand Buddhdev]

On 28/01/2011 21:10, Jack Tavares wrote:

 I have a question about the hints file.
 
 It is built in to BIND.
 
 Does bind check for updates to this periodically?
 If so, where does it get it from ?
 I assume it gets it from ftp.isc.org.
 Does bind contain a hardcode for that IP address?
 or does it use the existing hints to find the address
 of ftp.isc.org and then download a new ftp.isc.org?

Hi Jack,

BIND has a built-in copy of the root server hints file. However, each
time it starts up, it sends a query to the root servers to get an up to
date copy of the root servers and their addresses. This is called a
priming query. The priming query is repeated periodically to ensure
that BIND has a fresh copy.

Regards,

Anand Buddhdev
RIPE NCC
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root hints

[Joseph S D Yao]

On Fri, Jan 28, 2011 at 04:40:50PM +0800, p...@mail.nsbeta.info wrote:
 Joseph S D Yao writes: 
  Just because we don't need to, doesn't mean that it's a good practtice
  not to.  And it's so easy to create one on a system where DNS is already
  set up. 
  
  dig ns .  root.hints 
 
 I disagree with this.
 Few files mean few risk for admin.
 How about the case when someone did echo  root.hints by mistake? 
 
 Regards.


Pyh,

We can agree to disagree.  I admit I prefer to have more control over
the configuration, and am uncomfortable with invisible parts of the
configuration.  I like those appliances best where I can log in the
maintenance port and see the whole configuration laid out before me.  It
helps with debugging, too.

As for echo  root.hints, who leaves their configuration files
writable, or does it as the super-user?  That's bound to get you in
trouble.  Use configuration management software that leaves you with a
read-only file!


--
/*\
**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root hints

[Joseph S D Yao]

On Fri, Jan 28, 2011 at 08:10:10PM +, Jack Tavares wrote:
 I have a question about the hints file.
 
 It is built in to BIND.
 
 Does bind check for updates to this periodically?
 If so, where does it get it from ?
 I assume it gets it from ftp.isc.org.
 Does bind contain a hardcode for that IP address?
 or does it use the existing hints to find the address
 of ftp.isc.org and then download a new ftp.isc.org?


To the best of my knowledge, NO.

[If you recognized the BigIP in my last posting, you were right!]


--
/*\
**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root hints

[Joseph S D Yao]

On Fri, Jan 28, 2011 at 09:51:13PM -0500, Joseph S D Yao wrote:
 On Fri, Jan 28, 2011 at 08:10:10PM +, Jack Tavares wrote:
  I have a question about the hints file.
  
  It is built in to BIND.
  
  Does bind check for updates to this periodically?
...
 To the best of my knowledge, NO.


To clarify:

The distinguished gentleman from RIPE is also correct.  Once BIND
starts, IF any of the built-in root name servers is correct [very likely
on the public Internet, unlikely on any other internet], it will get the
complete current list, as this should be identical on all root name
servers.

But the answer to your original question remains, no - it does not
do a file transfer to download any file to keep its boot-time root hints
list persistently current.

[This does leave a security hole - if a root name server's IP changes,
and a Bad Guy gets the old one; or on another internet, if the Bad Guy
gets all the IP addresses in the default file.  It's not just lust for
control that has me using a visible root hints file.]


--
/*\
**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root hints

[Joseph S D Yao]

On Wed, Jan 26, 2011 at 04:16:47PM +, Chris Thompson wrote:
...
 which puts it in BIND 9.2 but not in 9.1. I can't find any indication
 in the CHANGES files or in my memory that BIND 8 ever had compiled-in
 hints.
...


Which just shows that my memory going back to BIND 8 has deteriorated.
I apologize for throwing that in - I know I have no sense of time, and I
should have looked it up if I was going to answer it at all.

But I still think it better to have an explicit root.hints file than
to trust in the invisible file compiled in.


--
/*\
**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root hints

[Joseph S D Yao]

On Thu, Jan 27, 2011 at 09:59:58AM +0800, p...@mail.nsbeta.info wrote:
...
 That means since BIND 9.2 we don't have the need to make a hints file for 
 named. Yep in current days who are running the named version below 9.2?
...


Surprisingly more people than you would imagine.  Is Bill M still doing
his periodic surveys?

Just because we don't need to, doesn't mean that it's a good practtice
not to.  And it's so easy to create one on a system where DNS is already
set up.

dig ns .  root.hints


--
/*\
**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root hints

[Mark Andrews]

In message 20110126003702.c16...@gwyn.tux.org, Joseph S D Yao writes:
 On Wed, Jan 26, 2011 at 11:20:18AM +0800, p...@mail.nsbeta.info wrote:
  
  Hello, 
  
   From what version of bind we won't include the root hints file in 
  named.conf? Since the bind server has been including it inherently. 
 
 
 I could be wrong, but I think that all V9 and even all V8 had this
 feature.  I include them anyway - because sometimes I need to change
 what's hidden in the program.
 
 With current V9 you can 'cp /dev/null $directory/named.conf' and have
 'named' work fine.  But I have only done this once, just for the
 experience.

You don't even need the copy.  named -c /dev/null will do the job
if you just want a recursive server for the local network.
 
 --
 /*\
 **
 ** Joe Yaoj...@tux.org - Joseph S. D. Yao
 **
 \*/
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root hints

[Rodney Joffe]

Please excuse my prior noise. Fat finger and head replied to wrong email. But 
feel free to call if you feel the need ;-)



On Jan 26, 2011, at 6:49 AM, Mark Andrews ma...@isc.org wrote:

 
 In message 20110126003702.c16...@gwyn.tux.org, Joseph S D Yao writes:
 On Wed, Jan 26, 2011 at 11:20:18AM +0800, p...@mail.nsbeta.info wrote:
 
 Hello, 
 
 From what version of bind we won't include the root hints file in 
 named.conf? Since the bind server has been including it inherently. 
 
 
 I could be wrong, but I think that all V9 and even all V8 had this
 feature.  I include them anyway - because sometimes I need to change
 what's hidden in the program.
 
 With current V9 you can 'cp /dev/null $directory/named.conf' and have
 'named' work fine.  But I have only done this once, just for the
 experience.
 
 You don't even need the copy.  named -c /dev/null will do the job
 if you just want a recursive server for the local network.
 
 --
 /*\
 **
 ** Joe Yaoj...@tux.org - Joseph S. D. Yao
 **
 \*/
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
 -- 
 Mark Andrews, ISC
 1 Seymour St., Dundas Valley, NSW 2117, Australia
 PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root hints

[Rodney Joffe]

Tried both numbers. 

I'm available 602-418-6471. 



On Jan 26, 2011, at 6:49 AM, Mark Andrews ma...@isc.org wrote:

 
 In message 20110126003702.c16...@gwyn.tux.org, Joseph S D Yao writes:
 On Wed, Jan 26, 2011 at 11:20:18AM +0800, p...@mail.nsbeta.info wrote:
 
 Hello, 
 
 From what version of bind we won't include the root hints file in 
 named.conf? Since the bind server has been including it inherently. 
 
 
 I could be wrong, but I think that all V9 and even all V8 had this
 feature.  I include them anyway - because sometimes I need to change
 what's hidden in the program.
 
 With current V9 you can 'cp /dev/null $directory/named.conf' and have
 'named' work fine.  But I have only done this once, just for the
 experience.
 
 You don't even need the copy.  named -c /dev/null will do the job
 if you just want a recursive server for the local network.
 
 --
 /*\
 **
 ** Joe Yaoj...@tux.org - Joseph S. D. Yao
 **
 \*/
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
 -- 
 Mark Andrews, ISC
 1 Seymour St., Dundas Valley, NSW 2117, Australia
 PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root hints

[Chris Thompson]

On Jan 26 2011, Joseph S D Yao wrote:


On Wed, Jan 26, 2011 at 11:20:18AM +0800, p...@mail.nsbeta.info wrote:


Hello, 

 From what version of bind we won't include the root hints file in 
named.conf? Since the bind server has been including it inherently. 



I could be wrong, but I think that all V9 and even all V8 had this
feature. 


The relevant CHANGES file entry for BIND 9 would seem to be

701. [func]   Root hints are now fully optional.  Class IN
  views use compiled-in hints by default, as
  before.  Non-IN views with no root hints now
  provide authoritative service but not recursion.
  A warning is logged if a view has neither root
  hints nor authoritative data for the root. [RT #696]

which puts it in BIND 9.2 but not in 9.1. I can't find any indication
in the CHANGES files or in my memory that BIND 8 ever had compiled-in
hints.

--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root hints

[pyh]

Chris Thompson writes:


The relevant CHANGES file entry for BIND 9 would seem to be 


701. [func]   Root hints are now fully optional.  Class IN
  views use compiled-in hints by default, as
  before.  Non-IN views with no root hints now
  provide authoritative service but not recursion.
  A warning is logged if a view has neither root
  hints nor authoritative data for the root. [RT #696] 


which puts it in BIND 9.2 but not in 9.1. I can't find any indication
in the CHANGES files or in my memory that BIND 8 ever had compiled-in
hints. 



Thanks Chris.
That means since BIND 9.2 we don't have the need to make a hints file for 
named. Yep in current days who are running the named version below 9.2?

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

root hints

[pyh]

Hello, 

From what version of bind we won't include the root hints file in 
named.conf? Since the bind server has been including it inherently. 

Thanks in advance. 


Regards.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root hints

[Joseph S D Yao]

On Wed, Jan 26, 2011 at 11:20:18AM +0800, p...@mail.nsbeta.info wrote:
 
 Hello, 
 
  From what version of bind we won't include the root hints file in 
 named.conf? Since the bind server has been including it inherently. 


I could be wrong, but I think that all V9 and even all V8 had this
feature.  I include them anyway - because sometimes I need to change
what's hidden in the program.

With current V9 you can 'cp /dev/null $directory/named.conf' and have
'named' work fine.  But I have only done this once, just for the
experience.


--
/*\
**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users