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 ,
 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 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