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
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 li
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 in
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 softwar
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
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-Nov
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.
>
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
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 theore
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 preven
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.
O
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. . . .
uni
riginal 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
ding 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 t
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 ge
, 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 addre
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.
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
___
Please v
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
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&
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 blan
ed 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 i
In article ,
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.
Did you think it combined the f
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
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 fil
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
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 quer
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
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 fi
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.co
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
>> work
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 troubleshooti
name.com is not 192.168.1.1.
Colin
From: Colin Harvey
To: "wbr...@e1b.org"
Cc: "bind-users-bounces+wbrown=e1b@lists.isc.org"
; bind users
Sent: Tuesday, August 27, 2013 2:13 PM
Subject: Re: redirecting root hints to fake internal root server
Thanks. But
ubject: Re: redirecting root hints to fake internal root server
From: Colin Harvey
> 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.
From: Colin Harvey
> 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
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 fac
ints
>
> 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 m
s
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 do
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 roo
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
omewhere 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
compla
On Thu, Sep 06, 2012 at 08:06:45AM -0400,
Timothe Litt 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 th
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
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
* Tony MacDoodle:
> So in the named.conf file I can get rid of the following:
>
> zone "." { type hint; file "db.cache"; };
Yes, I think 9.6 has built-in root hints. The zone contents is
ignored, except for the NS records and the associated addresses
(because of
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 wrote:
> * Tony MacDoodle:
>
> > 2) Do I need it at all for a local domain
>
> No, configuring a zone using the "zone" statement on all re
* 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 clien
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
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 t
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 addr
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
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
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 f
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
>
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?
> 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
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 "
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
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 d
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
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
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
>>> 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
>&g
t 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 cou
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.co
On 26.01.11 11:20, p...@mail.nsbeta.info wrote:
> 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.
Why won't you include root hints file in named.conf?
While named has builtin default
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
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.is
Hi!
I have a DNSSEC isolated testlab and we simulated signining of a ccTLD. I and
my friends already finished setting up the following:
1. client (resolvers)
2. DNS cache server (having a customized ROOT HINTS)
3. ROOT server (without root hints and with "." zone)
4. primary DNS
68 matches
Mail list logo
