Re: New addresses for b.root-servers.net

[Masataka Ohta]

Mark Andrews wrote:

>> If an end and another end directly share a secret
>> key without involving untrustworthy trusted third
>> parties, the ends are secure end to end.

>> An untrustworthy but light weight and inexpensive (or free)
>> PKI may worth its price and may be useful to make IP address
>> based security a little better.


Which you can do with DNSSEC but the key management will be enormous.


Which part of my message, are you responding? First part?

Though you might have forgotten, my initial proposal of DNSSEC
actually allows to use both public and shared keys.

Having hierarchical KDCs (Key Distribution Centers), instead
of hierarchical CAs, key management is not enormous.

Shared key is better than public key, because revocation
is instantaneous. Instead, root KDCs receive large amount
of requests. But, situation is similar to DNS root
servers today and is manageable.

Kerberos relies on KDCs.

However, the shared keys are shared by ends and intermediate
systems of KDCs, which is not end to end security.

Masataka Ohta

Re: New addresses for b.root-servers.net

[Mark Andrews]

Which you can do with DNSSEC but the key management will be enormous. 

-- 
Mark Andrews

> On 21 Jun 2023, at 15:39, Masataka Ohta  
> wrote:
> 
> Matt Corallo wrote:
> 
>>> As PKI, including DNSSEC, is subject to MitM attacks, is
>>> not cryptographically secure, does not provide end to end
>>> security and is not actually workable, why do you bother?
>> It sounds like you think nothing is workable, we simply cannot make anything 
>> secure
> 
> If an end and another end directly share a secret
> key without involving untrustworthy trusted third
> parties, the ends are secure end to end.
> 
>> - if we should give up on WebPKI (and all its faults) and DNSSEC (and all 
>> its faults) and RPKI (and all its faults), what do we have left?
> 
> An untrustworthy but light weight and inexpensive (or free)
> PKI may worth its price and may be useful to make IP address
> based security a little better.
> 
>Masataka Ohta
> 

Re: New addresses for b.root-servers.net

[Masataka Ohta]

Matt Corallo wrote:


As PKI, including DNSSEC, is subject to MitM attacks, is
not cryptographically secure, does not provide end to end
security and is not actually workable, why do you bother?


It sounds like you think nothing is workable, we simply cannot make 
anything secure


If an end and another end directly share a secret
key without involving untrustworthy trusted third
parties, the ends are secure end to end.

- if we should give up on WebPKI (and all its faults) 
and DNSSEC (and all its faults) and RPKI (and all its faults), what do 
we have left?


An untrustworthy but light weight and inexpensive (or free)
PKI may worth its price and may be useful to make IP address
based security a little better.

Masataka Ohta

Re: New addresses for b.root-servers.net

[Matt Corallo]

On 6/20/23 10:20 PM, Masataka Ohta wrote:

Matt Corallo wrote:


So, let's recognize ISPs as trusted authorities and
we are reasonably safe without excessive cost to
support DNSSEC with all the untrustworthy hypes of
HSMs and four-eyes principle.


I think this list probably has a few things to say about "ISPs as trusted authorities" 


I'm afraid you miss the point.

My point is that trusted third parties of CAs including
DNSSEC providers are at least as untrustworthy as ISPs.

- is everyone on this list already announcing and enforcing an exact ASPA policy (or BGPSec or so) 
and ensuring the full path for each packet they send is secure and robust to ensure it gets to its 
proper destination?


I'm afraid that is a hype as bad as HSMs and four-eyes
principle.


Somehow I don't think this model is workable,


As PKI, including DNSSEC, is subject to MitM attacks, is
not cryptographically secure, does not provide end to end
security and is not actually workable, why do you bother?


It sounds like you think nothing is workable, we simply cannot make anything secure - if we should 
give up on WebPKI (and all its faults) and DNSSEC (and all its faults) and RPKI (and all its 
faults), what do we have left?


Indeed, all of those things suck, they have had major hacks, minor hacks, and protocol design issues 
 for years (okay, RPKI less so, but its newer, give it time), but what alternative do we have? I'd 
rather we use the tools we have, in all their faults, than not bother building any security on the 
internet :)


Matt

Re: New addresses for b.root-servers.net

[Masataka Ohta]

Matt Corallo wrote:


So, let's recognize ISPs as trusted authorities and
we are reasonably safe without excessive cost to
support DNSSEC with all the untrustworthy hypes of
HSMs and four-eyes principle.


I think this list probably has a few things to say about "ISPs as 
trusted authorities" 


I'm afraid you miss the point.

My point is that trusted third parties of CAs including
DNSSEC providers are at least as untrustworthy as ISPs.

- is everyone on this list already announcing and 
enforcing an exact ASPA policy (or BGPSec or so) and ensuring the full 
path for each packet they send is secure and robust to ensure it gets to 
its proper destination?


I'm afraid that is a hype as bad as HSMs and four-eyes
principle.


Somehow I don't think this model is workable,


As PKI, including DNSSEC, is subject to MitM attacks, is
not cryptographically secure, does not provide end to end
security and is not actually workable, why do you bother?

Masataka Ohta

Re: New addresses for b.root-servers.net

[Matt Corallo]

On 6/19/23 8:08 PM, Masataka Ohta wrote:

Matt Corallo wrote:
This is totally unrelated to the question at hand. There wasn't a question about whether a user 
relying on trusted authorities can maybe be whacked by said trusted authorities (though there's 
been a ton of work in this space, most notably requiring CT these days),


So, let's recognize ISPs as trusted authorities and
we are reasonably safe without excessive cost to
support DNSSEC with all the untrustworthy hypes of
HSMs and four-eyes principle.


I think this list probably has a few things to say about "ISPs as trusted authorities" - is everyone 
on this list already announcing and enforcing an exact ASPA policy (or BGPSec or so) and ensuring 
the full path for each packet they send is secure and robust to ensure it gets to its proper 
destination?


Somehow I don't think this model is workable, but what do I know, I was just responding to someone 
on this list who mentioned it was dumb to rely on IP destination as being secure :)


Matt

Re: New addresses for b.root-servers.net

[Masataka Ohta]

Matt Corallo wrote:


Note that diginotar was advertised to be operated
with HSMs and four-eyes principle, which means
both of them were proven to be untrustworthy
marketing hypes.


Even more reason to do DNSSEC stapling!


See hypes of HSMs and four-eyes from DNSSEC
operators.

This is totally unrelated to the question at hand. There wasn't a 
question about whether a user relying on trusted authorities can maybe 
be whacked by said trusted authorities (though there's been a ton of 
work in this space, most notably requiring CT these days),


So, let's recognize ISPs as trusted authorities and
we are reasonably safe without excessive cost to
support DNSSEC with all the untrustworthy hypes of
HSMs and four-eyes principle.

it was purely 
about whether we can rely on pure "I sent a packet to IP X, did it get 
to IP X", which *is* solved by DNSSEC.


That's overkill. See above for the proper solution.

Masataka Ohta

Re: New addresses for b.root-servers.net

[Matt Corallo]

On 6/19/23 2:08 AM, Masataka Ohta wrote:

Matt Corallo wrote:


Both in theory and practice, DNSSEC is not secure end to
end


Indeed, but (a) there's active work in the IETF to change that (DNSSEC stapling 
to TLS certs)


TLS? What? As was demonstrated by diginotar, PKI is NOT
cryptographically secure and vulnerable to MitM attacks
on intermediate intelligent entities of CAs.

Note that diginotar was advertised to be operated
with HSMs and four-eyes principle, which means
both of them were proven to be untrustworthy
marketing hypes.


Even more reason to do DNSSEC stapling! It avoids some of the CA issue (well, it would if you could 
make it required, I don't believe the current design is required, sadly).


and (b) that wasn't the point - the above post said "It’s not like you can really trust your 
packets going to B _today_ are going to and from the real B (or Bs)." which is exactly what DNSSEC 
protects against!


As long as root key rollover is performed in time and
intermediate zones such as ccTLDs are not compromised,
maybe, which is why it is not very useful or secure.

The following description

 https://en.wikipedia.org/wiki/DigiNotar
 Secondly, they issued certificates for the Dutch
 government's PKIoverheid ("PKIgovernment") program.
 This issuance was via two intermediate certificates,
 each of which chained up to one of the two "Staat der
 Nederlanden" root CAs. National and local Dutch
 authorities and organisations offering services for the
 government who want to use certificates for secure internet
 communication can request such a certificate. Some of the
 most-used electronic services offered by Dutch governments
 used certificates from DigiNotar. Examples were the
 authentication infrastructure DigiD and the central
 car-registration organisation Netherlands Vehicle
 Authority [nl] (RDW).

makes it clear that entities operating ccTLDs may also
be compromised.


This is totally unrelated to the question at hand. There wasn't a question about whether a user 
relying on trusted authorities can maybe be whacked by said trusted authorities (though there's been 
a ton of work in this space, most notably requiring CT these days), it was purely about whether we 
can rely on pure "I sent a packet to IP X, did it get to IP X", which *is* solved by DNSSEC.


I agree DNSSEC does not solve all issues with client security, but it doesn't have to, it *does* 
solve the issue of a BGP hijack against an authoritative DNS server being able to respond with 
whatever IPs it wants (and then get TLS certs because of it).


Matt

Re: New addresses for b.root-servers.net

[Masataka Ohta]

Matt Corallo wrote:


Both in theory and practice, DNSSEC is not secure end to
end


Indeed, but (a) there's active work in the IETF to change that (DNSSEC 
stapling to TLS certs)


TLS? What? As was demonstrated by diginotar, PKI is NOT
cryptographically secure and vulnerable to MitM attacks
on intermediate intelligent entities of CAs.

Note that diginotar was advertised to be operated
with HSMs and four-eyes principle, which means
both of them were proven to be untrustworthy
marketing hypes.

and (b) that wasn't the point - the above post 
said "It’s not like you can really trust your packets going to B _today_ 
are going to and from the real B (or Bs)." which is exactly what DNSSEC 
protects against!


As long as root key rollover is performed in time and
intermediate zones such as ccTLDs are not compromised,
maybe, which is why it is not very useful or secure.

The following description

https://en.wikipedia.org/wiki/DigiNotar
Secondly, they issued certificates for the Dutch
government's PKIoverheid ("PKIgovernment") program.
This issuance was via two intermediate certificates,
each of which chained up to one of the two "Staat der
Nederlanden" root CAs. National and local Dutch
authorities and organisations offering services for the
government who want to use certificates for secure internet
communication can request such a certificate. Some of the
most-used electronic services offered by Dutch governments
used certificates from DigiNotar. Examples were the
authentication infrastructure DigiD and the central
car-registration organisation Netherlands Vehicle
Authority [nl] (RDW).

makes it clear that entities operating ccTLDs may also
be compromised.

If its not useful, please describe a mechanism by which an average 
recursive resolver can be protected against someone hijacking C root on 
Hurricane Electric (which doesn't otherwise have the announcement at 
all, last I heard) and responding with bogus data?


As DNSSEC capable resolvers are not very secure, you don't
have to make plain resolvers so secure.


For example, root key rollover is as easy/difficult as
updating IP addresses for b.root-servers.net.


Then maybe read the rest of this thread, cause lots of folks pointed out 
issues with *just* updating the IP and not bothering to give it some 
time to settle :)


In this thread, I'm the first to have pointed out that old IP
addresses of root servers must be reserved (for 50 years).


Masataka Ohta

Re: New addresses for b.root-servers.net

[niels=nanog]

* nanog@nanog.org (Cynthia Revström via NANOG) [Sun 18 Jun 2023, 20:52 CEST]:

Naturally C root is fine on HE over IPv4, the issue is with IPv6.
2001:500:2::c is not reachable over HE.


You're absolutely correct. Maybe their LG defaulting to IPv6 made my 
brain short-circuit. (Their looking glass took longer to render that 
than its own cache timeout.)



-- Niels.

Re: New addresses for b.root-servers.net

[Cynthia Revström via NANOG]

Naturally C root is fine on HE over IPv4, the issue is with IPv6.
2001:500:2::c is not reachable over HE.

-Cynthia

On Sun, Jun 18, 2023 at 8:10 PM  wrote:
>
> * na...@as397444.net (Matt Corallo) [Sun 18 Jun 2023, 19:12 CEST]:
> >If its not useful, please describe a mechanism by which an average
> >recursive resolver can be protected against someone hijacking C root
> >on Hurricane Electric (which doesn't otherwise have the announcement
> >at all, last I heard) and responding with bogus data?
>
> No comment on DNSSEC but lg.he.net indicates that they do in fact
> carry a route to C-root:
> ---
> 1   76 ms   *   *   port-channel2.core2.pao1.he.net (72.52.92.65)
> 2   44 ms   63 ms   78 ms   palo-b24-link.ip.twelve99.net (195.12.255.209)
> 3   55 ms   66 ms   103 ms  cogent-ic-344188.ip.twelve99-cust.net 
> (62.115.174.65)
> 4   74 ms   57 ms   120 ms  be2431.ccr41.sjc03.atlas.cogentco.com 
> (154.54.88.189)
> 5   142 ms  99 ms   79 ms   be3142.ccr21.sjc01.atlas.cogentco.com 
> (154.54.1.193)
> 6   53 ms   75 ms   111 ms  be3176.ccr41.lax01.atlas.cogentco.com 
> (154.54.31.189)
> 7   82 ms   133 ms  85 ms   te0-0-2-0.c-root.lax01.atlas.cogentco.com 
> (154.54.27.138)
> 8   60 ms   152 ms  84 ms   c.root-servers.net (192.33.4.12)
> Entry cached for another 60 seconds. 2023-06-18 17:57:17 UTC
> ---
>
> I don't see any ROAs for AS2149's two originated prefixes, though:
> https://irrexplorer.nlnog.net/prefix/192.33.4.0/24 so hijacks might
> still be easier than they could be.
>
> Regards
>
>
> -- Niels.

Re: New addresses for b.root-servers.net

[niels=nanog]

* na...@as397444.net (Matt Corallo) [Sun 18 Jun 2023, 19:12 CEST]:
If its not useful, please describe a mechanism by which an average 
recursive resolver can be protected against someone hijacking C root 
on Hurricane Electric (which doesn't otherwise have the announcement 
at all, last I heard) and responding with bogus data?


No comment on DNSSEC but lg.he.net indicates that they do in fact 
carry a route to C-root:

---
1   76 ms   *   *   port-channel2.core2.pao1.he.net (72.52.92.65)
2   44 ms   63 ms   78 ms   palo-b24-link.ip.twelve99.net (195.12.255.209)
3   55 ms   66 ms   103 ms  cogent-ic-344188.ip.twelve99-cust.net 
(62.115.174.65)
4   74 ms   57 ms   120 ms  be2431.ccr41.sjc03.atlas.cogentco.com 
(154.54.88.189)
5   142 ms  99 ms   79 ms   be3142.ccr21.sjc01.atlas.cogentco.com 
(154.54.1.193)
6   53 ms   75 ms   111 ms  be3176.ccr41.lax01.atlas.cogentco.com 
(154.54.31.189)
7   82 ms   133 ms  85 ms   te0-0-2-0.c-root.lax01.atlas.cogentco.com 
(154.54.27.138)
8   60 ms   152 ms  84 ms   c.root-servers.net (192.33.4.12)
Entry cached for another 60 seconds. 2023-06-18 17:57:17 UTC
---

I don't see any ROAs for AS2149's two originated prefixes, though: 
https://irrexplorer.nlnog.net/prefix/192.33.4.0/24 so hijacks might 
still be easier than they could be.


Regards


-- Niels.

Re: New addresses for b.root-servers.net

[Matt Corallo]

On 6/18/23 12:53 AM, Masataka Ohta wrote:

Matt Corallo wrote:


That's great in theory, and folks should be using DNSSEC [1],


Wrong.

Both in theory and practice, DNSSEC is not secure end to
end


Indeed, but (a) there's active work in the IETF to change that (DNSSEC stapling to TLS certs) and 
(b) that wasn't the point - the above post said "It’s not like you can really trust your packets 
going to B _today_ are going to and from the real B (or Bs)." which is exactly what DNSSEC protects 
against! It may not protect the client, but it protects the recursive resolver, which is often on 
the same AS as the client (or if its not, its usually connected via DoH/DoT, which is itself a 
secure channel).



and is not very useful.


If its not useful, please describe a mechanism by which an average recursive resolver can be 
protected against someone hijacking C root on Hurricane Electric (which doesn't otherwise have the 
announcement at all, last I heard) and responding with bogus data?


Or, alternatively, describe a mechanism which allows a recursive resolver to not return bogus data 
in the case of *any* authoritative server BGP hijack.



For example, root key rollover is as easy/difficult as
updating IP addresses for b.root-servers.net.


Then maybe read the rest of this thread, cause lots of folks pointed out issues with *just* updating 
the IP and not bothering to give it some time to settle :)


Matt

Re: New addresses for b.root-servers.net

[Masataka Ohta]

Matt Corallo wrote:


That's great in theory, and folks should be using DNSSEC [1],


Wrong.

Both in theory and practice, DNSSEC is not secure end to
end and is not very useful.

For example, root key rollover is as easy/difficult as
updating IP addresses for b.root-servers.net.

Masataka Ohta

Re: New addresses for b.root-servers.net

[Matt Corallo]

That's great in theory, and folks should be using DNSSEC [1], but we all know there's plenty of 
places out there in this wide world that don't do things right, and absolutely *do* rely on packets 
getting to the correct place.


I'm not saying we shouldn't whack those folks with a cluestick [1] (we should), I'm saying we should 
also not bother making it easier for an attacker to hijack these poor misguided souls.


Matt

[1] $(dig +short pumpkey.net ds) returns nothing here, so I guess you are included in the set of 
folks who should really upgrade their DNS security to stop relying on the trust packets are getting 
to the right place.


On 6/17/23 6:05 PM, Crist Clark wrote:
IP addresses cannot and should not be trusted. It’s not like you can really trust your packets going 
to B _today_ are going to and from the real B (or Bs).


If the security of DNS relies on no one intercepting or spoofing responses of some of your queries 
to a root server, it’s been game over for a long time.



On Sat, Jun 17, 2023 at 10:29 AM Matt Corallo mailto:na...@as397444.net>> wrote:



On 6/17/23 7:12 AM, Tom Beecher wrote:
 > Bill-
 >
 >     Don't say, "We'll keep it up for as long as we feel like it, but at
 >     least a year." That's crap.
 >
 >
 > 30% of the root servers have been renumbered in the last 25 years.
 >
 > h : 2015
 > d: 2013
 > l : 2007
 > j : 2002
 >
 > For these 4 cases, only a 6 month transition time was provided, and the 
internet as we know
it did
 > not fall over in a flaming pile. ( One could argue it was ALREADY a 
flaming pile, but that's a
 > different discussion.)

There’s a huge difference between “no one noticed any issues because 
recursive resolvers will
seamlessly fall back to other root servers if there’s an outage” and “there 
aren’t issues”.

For non-DNSSEC-verifying-resolvers (sheesh, but they still exist), if the 
IPs are eventually
released and someone stands up a DNS server on them you could cause real 
harm.

Does this need to be over-engineered to prevent that? No, though doing a 
few tricks to help the
poor
folks on unmaintained recursive resolvers isn’t bad either.

But lack of visible issues doesn’t mean that users aren’t put at risk. That 
said, I have no idea if
the old number resources were released or no longer announced in the DFZ 
after the previous
renumbers, which would really be the point at which concern is warranted, 
not simply no longer
responding.

Matt

Re: New addresses for b.root-servers.net

[Crist Clark]

IP addresses cannot and should not be trusted. It’s not like you can really
trust your packets going to B _today_ are going to and from the real B (or
Bs).

If the security of DNS relies on no one intercepting or spoofing responses
of some of your queries to a root server, it’s been game over for a long
time.


On Sat, Jun 17, 2023 at 10:29 AM Matt Corallo  wrote:

>
>
> On 6/17/23 7:12 AM, Tom Beecher wrote:
> > Bill-
> >
> > Don't say, "We'll keep it up for as long as we feel like it, but at
> > least a year." That's crap.
> >
> >
> > 30% of the root servers have been renumbered in the last 25 years.
> >
> > h : 2015
> > d: 2013
> > l : 2007
> > j : 2002
> >
> > For these 4 cases, only a 6 month transition time was provided, and the
> internet as we know it did
> > not fall over in a flaming pile. ( One could argue it was ALREADY a
> flaming pile, but that's a
> > different discussion.)
>
> There’s a huge difference between “no one noticed any issues because
> recursive resolvers will
> seamlessly fall back to other root servers if there’s an outage” and
> “there aren’t issues”.
>
> For non-DNSSEC-verifying-resolvers (sheesh, but they still exist), if the
> IPs are eventually
> released and someone stands up a DNS server on them you could cause real
> harm.
>
> Does this need to be over-engineered to prevent that? No, though doing a
> few tricks to help the poor
> folks on unmaintained recursive resolvers isn’t bad either.
>
> But lack of visible issues doesn’t mean that users aren’t put at risk.
> That said, I have no idea if
> the old number resources were released or no longer announced in the DFZ
> after the previous
> renumbers, which would really be the point at which concern is warranted,
> not simply no longer
> responding.
>
> Matt
>
>

Re: New addresses for b.root-servers.net

[Matt Corallo]

On 6/17/23 7:12 AM, Tom Beecher wrote:

Bill-

Don't say, "We'll keep it up for as long as we feel like it, but at
least a year." That's crap.


30% of the root servers have been renumbered in the last 25 years.

h : 2015
d: 2013
l : 2007
j : 2002

For these 4 cases, only a 6 month transition time was provided, and the internet as we know it did 
not fall over in a flaming pile. ( One could argue it was ALREADY a flaming pile, but that's a 
different discussion.)


There’s a huge difference between “no one noticed any issues because recursive resolvers will 
seamlessly fall back to other root servers if there’s an outage” and “there aren’t issues”.


For non-DNSSEC-verifying-resolvers (sheesh, but they still exist), if the IPs are eventually 
released and someone stands up a DNS server on them you could cause real harm.


Does this need to be over-engineered to prevent that? No, though doing a few tricks to help the poor 
folks on unmaintained recursive resolvers isn’t bad either.


But lack of visible issues doesn’t mean that users aren’t put at risk. That said, I have no idea if 
the old number resources were released or no longer announced in the DFZ after the previous 
renumbers, which would really be the point at which concern is warranted, not simply no longer 
responding.


Matt

Re: New addresses for b.root-servers.net

[Tom Beecher]

Bill-

Don't say, "We'll keep it up for as long as we feel like it, but at
> least a year." That's crap.
>

30% of the root servers have been renumbered in the last 25 years.

h : 2015
d: 2013
l : 2007
j : 2002

For these 4 cases, only a 6 month transition time was provided, and the
internet as we know it did not fall over in a flaming pile. ( One could
argue it was ALREADY a flaming pile, but that's a different discussion.)

Why are we so twisted up because this time they are providing a guarantee
for TWICE as much transition time? Have things changed so much since 2015
that a full year is not enough time all of a sudden?


On Thu, Jun 15, 2023 at 11:35 PM William Herrin  wrote:

> On Thu, Jun 15, 2023 at 7:52 PM Wes Hardaker 
> wrote:
> > William Herrin  writes:
> > > At some point, somebody's going to want to do something with the old
> > > /24.
> >
> > You are correct that we did not state we will or will not be returning
> > the address block we have back to ARIN.  We do not plan on returning it
> > for precisely the reasons you've specified.  Even if we were going to,
> > we would certainly stop responding on it for a long time first.  And
> > even if we returned it, I suspect that ARIN itself would consider
> > carefully what to do with a returned address in the critical
> > infrastructure block.
>
> Hi Wes,
>
> Due respect, you should have a better fleshed-out commitment to the
> community than, "Here today, gone tomorrow. Probably not. Maybe." Not
> to put words in your mouth, but try something like, "We will continue
> serving root DNS requests from the old address indefinitely. We will
> notify the community of any change in that disposition at least 1 year
> prior to the change and will describe, at that time, what will
> change."
>
> Don't say, "We'll keep it up for as long as we feel like it, but at
> least a year." That's crap.
>
> > TL;DR: we agree and it's covered.
>
> Say the words. THEN we agree that it's covered.
>
> Regards,
> Bill Herrin
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: New addresses for b.root-servers.net

[David Conrad]

On Jun 15, 2023, at 10:51 PM, Wes Hardaker  wrote:
>> At some point, somebody's going to want to do something with the old /24.
> You are correct that we did not state we will or will not be returning
> the address block we have back to ARIN.  We do not plan on returning it
> for precisely the reasons you've specified.

Long ago, I had suggested that given the peculiar and unique nature or root 
server addresses and their critical sensitivity that their addresses be treated 
as protocol parameters, i.e., that root service was fixed to those addresses by 
protocol specification.  People asked if I had been touched by the Bad Idea 
Fairy (RIP).  I still think it’s a good idea… :)

Regards,
-drc




signature.asc
Description: Message signed with OpenPGP

Re: New addresses for b.root-servers.net

[William Herrin]

On Thu, Jun 15, 2023 at 7:52 PM Wes Hardaker  wrote:
> William Herrin  writes:
> > At some point, somebody's going to want to do something with the old
> > /24.
>
> You are correct that we did not state we will or will not be returning
> the address block we have back to ARIN.  We do not plan on returning it
> for precisely the reasons you've specified.  Even if we were going to,
> we would certainly stop responding on it for a long time first.  And
> even if we returned it, I suspect that ARIN itself would consider
> carefully what to do with a returned address in the critical
> infrastructure block.

Hi Wes,

Due respect, you should have a better fleshed-out commitment to the
community than, "Here today, gone tomorrow. Probably not. Maybe." Not
to put words in your mouth, but try something like, "We will continue
serving root DNS requests from the old address indefinitely. We will
notify the community of any change in that disposition at least 1 year
prior to the change and will describe, at that time, what will
change."

Don't say, "We'll keep it up for as long as we feel like it, but at
least a year." That's crap.

> TL;DR: we agree and it's covered.

Say the words. THEN we agree that it's covered.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: New addresses for b.root-servers.net

[Wes Hardaker]

William Herrin  writes:

Hi Bill,

> I acknowledge that you'd prefer it be, "forever and a day," and
> perhaps that's what the answer should be, but in all due respect the
> document you cite is completely mute on the use of addresses which are
> -no longer- root DNS servers.

I cited the document to discuss the fact that we can not do what you
suggested:

> Not a bad idea, you could also put a nice warning page up informing
> them that their DNS resolver is broken and not enforcing DNSSEC while
> you're at it :)

as this would require us to return a different answer to a query than
what is in the IANA maintained root zone (IE, we'd be synthesizing
address records and hoping that the querier was using a web-browser
which has been tried by many companies and is heavily frowned upon.
Other options like returning a special loopback address have been better
appreciated [2] but this would still require returning answers that did
not match the IANA distributed root zone data which we will not do.

As to your other point:

> At some point, somebody's going to want to do something with the old
> /24.

You are correct that we did not state we will or will not be returning
the address block we have back to ARIN.  We do not plan on returning it
for precisely the reasons you've specified.  Even if we were going to,
we would certainly stop responding on it for a long time first.  And
even if we returned it, I suspect that ARIN itself would consider
carefully what to do with a returned address in the critical
infrastructure block.  TL;DR: we agree and it's covered.

-- 
Wes Hardaker 
USC/ISI

Re: New addresses for b.root-servers.net

[William Herrin]

On Thu, Jun 15, 2023 at 7:03 PM Wes Hardaker  wrote:
> All root server operators have made a strong commitment to only serving
> the DNS root as managed by IANA [1], I'm afraid this option is off the
> table.  Although you could use some wiggle-ling to try and say this
> principle doesn't apply to "old addresses", I would not be willing to
> take that wiggle on behalf of b.root-servers.net.

Hi Wes,

As I recall, the statement which started the thread could be
paraphrased as one of those root server operating saying, "Hey
Community, we'll continue to treat the old address as still a root DNS
server for a year, maybe more, but no promises."

I acknowledge that you'd prefer it be, "forever and a day," and
perhaps that's what the answer should be, but in all due respect the
document you cite is completely mute on the use of addresses which are
-no longer- root DNS servers.

At some point, somebody's going to want to do something with the old
/24. If they didn't, nothing would stop them from committing to
continue its use as a root DNS server (in addition to the new official
address) for the remaining lifetime of the b-root service. The extra
configuration and extra route announcement just don't have a high
enough cost not to.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: New addresses for b.root-servers.net

[Wes Hardaker]

Nathan Ward  writes:

Hi Nathan,

[Sorry for the delay -- this was ICANN week and I'm just getting unburied]

> Do you have query rates over time for the old and new addresses since
> this change in 2017?

We do indeed still get traffic on the older addresses, and its not an
insignificant amount and its not just priming queries either.  

> Even if you end up with the same answer of 12mo, data supporting it
> may give comfort to the community.

As my colleague Robert Story said in a separate thread, we are still
serving our old address and will almost certainly continue to serve our
current address long beyond the promise date we put into the
announcement.  Our intent is to continue serving it longer than the
announced end date, but we do not offer a promise to do so.

-- 
Wes Hardaker 
USC/ISI

Re: New addresses for b.root-servers.net

[Wes Hardaker]

Matt Corallo  writes:

[Sorry for the delay -- this was ICANN week and I'm just getting unburied]

> > Perhaps make it a false responder in the last of those 9 years so that
> > anybody who is truly that far behind on their software updates gets
> > enough of a spanking to stop sending you packets. You'll have problems
> > repurposing the address and its subnet until folks stop sending you
> > DNS query packets, even if you don't respond to them.
> 
> Not a bad idea, you could also put a nice warning page up informing
> them that their DNS resolver is broken and not enforcing DNSSEC while
> you're at it :)

Responding to this topic specifically:

All root server operators have made a strong commitment to only serving
the DNS root as managed by IANA [1], I'm afraid this option is off the
table.  Although you could use some wiggle-ling to try and say this
principle doesn't apply to "old addresses", I would not be willing to
take that wiggle on behalf of b.root-servers.net.

[1] https://www.icann.org/en/system/files/files/rssac-055-07jul21-en.pdf
-- 
Wes Hardaker 
USC/ISI

Re: New addresses for b.root-servers.net

[Masataka Ohta]

Mark Andrews wrote:


The commitment to maintain service for 1 year after the new LACNIC
addresses are switched in to the root.hints from IANA does not mean that
this is a cutoff date and that we intend to turn off service on the
older addresses after a year.  We currently have no plans to do so for
the foreseeable future. In fact, the possibility has not even been
suggested or discussed at all.


Such total lack of advance and public discussion and preparation
on a substantial change on critical infrastructure is a serious
problem, I'm afraid.



I'm curious about what more discussion you want to happen than has
happen in the past. Over the last 20 years there have been lots of
address changes.


If such changes are performed without proper transition plans
even after DNS became critical infrastructure (when?), they
also are serious problems.


None of them have caused operational problems.


Thank you for a devil's proof. That you haven't noticed any
problem does not mean there actually was no problem.

Masataka Ohta

Re: New addresses for b.root-servers.net

[Mark Andrews]

> On 9 Jun 2023, at 14:29, Masataka Ohta  
> wrote:
> 
> Robert Story wrote:
> 
>> The commitment to maintain service for 1 year after the new LACNIC
>> addresses are switched in to the root.hints from IANA does not mean that
>> this is a cutoff date and that we intend to turn off service on the
>> older addresses after a year.  We currently have no plans to do so for
>> the foreseeable future. In fact, the possibility has not even been
>> suggested or discussed at all.
> 
> Such total lack of advance and public discussion and preparation
> on a substantial change on critical infrastructure is a serious
> problem, I'm afraid.
> 
> Masataka Ohta

I’m curious about what more discussion you want to happen than has
happen in the past. Over the last 20 years there have been lots of
address changes.  None of them have caused operational problems.
None required more that has already happened for this change.

Mark

4781.   [maint] B.ROOT-SERVERS.NET is now 199.9.14.201. [RT #45889]

4633.   [maint] Updated  (2001:500:200::b) for B.ROOT-SERVERS.NET.

4490.   [maint] Added  (2001:500:12::d0d) for G.ROOT-SERVERS.NET.

4457.   [maint] Added  (2001:500:a8::e) for E.ROOT-SERVERS.NET.

4423.   [maint] Added missing IPv6 address 2001:500:84::b for
B.ROOT-SERVERS.NET. [RT #42898] 
 
4333.   [maint] L.ROOT-SERVERS.NET is now 199.7.83.42 and
2001:500:9f::42.

4261.   [maint] H.ROOT-SERVERS.NET is 198.97.190.53 and 2001:500:1::53.
[RT #40556]

3794.   [maint] Added  for C.ROOT-SERVERS.NET.

3556.   [maint] Added  for D.ROOT-SERVERS.NET.

3441.   [maint] D.ROOT-SERVERS.NET is now 199.7.91.13.

2918.   [maint] Add  address for I.ROOT-SERVERS.NET.

2870.   [maint] Add  address for L.ROOT-SERVERS.NET.

2328.   [maint] Add  addresses for A.ROOT-SERVERS.NET,
F.ROOT-SERVERS.NET, H.ROOT-SERVERS.NET,
J.ROOT-SERVERS.NET, K.ROOT-SERVERS.NET and
M.ROOT-SERVERS.NET.

2255.   [maint] L.ROOT-SERVERS.NET is now 199.7.83.42.

1567.   [maint] B.ROOT-SERVERS.NET is now 192.228.79.201.

1397.   [maint] J.ROOT-SERVERS.NET is now 192.58.128.30.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: New addresses for b.root-servers.net

[Masataka Ohta]

Robert Story wrote:


The commitment to maintain service for 1 year after the new LACNIC
addresses are switched in to the root.hints from IANA does not mean that
this is a cutoff date and that we intend to turn off service on the
older addresses after a year.  We currently have no plans to do so for
the foreseeable future. In fact, the possibility has not even been
suggested or discussed at all.


Such total lack of advance and public discussion and preparation
on a substantial change on critical infrastructure is a serious
problem, I'm afraid.

Masataka Ohta

Re: New addresses for b.root-servers.net

[Robert Story]

On Wed 2023-06-07 15:34:12-0700 Matthew wrote:
> If the goal is increased robustness by having addresses present from a
> different RIR, wouldn't it make this whole tempest in a teapot moot
> if, instead of *reunubering*, you simply *added* a second set of IPs,
> but continued to answer queries on the original addresses as well?

Hi Matt,

That is exactly what we've done. We are currently answering requests on
the new LACNIC addresses, the current ARIN address which we renumbered
to in 2017, and even the addresses from before that (cerca 2004). 

The commitment to maintain service for 1 year after the new LACNIC
addresses are switched in to the root.hints from IANA does not mean that
this is a cutoff date and that we intend to turn off service on the
older addresses after a year.  We currently have no plans to do so for
the foreseeable future. In fact, the possibility has not even been
suggested or discussed at all.

In short: Keep calm, and query on. :-)


Regards,
--
Robert Story 
USC Information Sciences Institute 
Networking and Cybersecurity Division

Re: New addresses for b.root-servers.net

[Masataka Ohta]

Mark Andrews wrote:


It announces itself to an address which remains under the control of
USC/ISI the current and on going root server operator for b.root-servers.net.
So apart from leaking that the root hints have not been updated I don’t
see a big risk here.  The address block, as has been stated, is in a reserved
range for critical infrastructure and, I suspect, has special controls placed
on it by ARIN regarding its re-use should USC/ISI ever release it / cease to
be a root-server operator.  I would hope that ARIN and all the RIRs have
the list of current and old root-server addresses and that any block that
are being transferred that have one of these addresses are flagged for
special consideration.


I'm afraid that "old root-server addresses" will not
be considered for "critical infrastructure" at least
by those people who can't see operational difficulties
to change the addresses.

Masataka Ohta

Re: New addresses for b.root-servers.net

[Matthew Petach]

Hi Robert,

If the goal is increased robustness by having addresses present from a
different RIR,
wouldn't it make this whole tempest in a teapot moot if, instead of
*reunubering*, you
simply *added* a second set of IPs, but continued to answer queries on the
original
addresses as well?

Is there any reason at all to unconfigure the original IPs from the servers
after the LACNIC
IP addresses are added to the servers?  I mean, it's perfectly normal for
servers to have
multiple IP addresses on them, we've been doing it for decades, and IPv6
has really hammered
home that it's normal and expected for hosts to have multiple IP addresses
on them, often from
different providers.

Thanks!

Matt


On Sun, Jun 4, 2023 at 8:06 AM Robert Story  wrote:

> On Sat 2023-06-03 23:00:33+0200 Terrence wrote:
> > Forgive me if I'm missing something obvious, but why are you
> > renumbering at all?
> >
> > Of course the diversification of RIRs is a good thing, but couldn't
> > that be accomplished just as well by transferring the current
> > allocation to LACNIC?
>
> Hi Terrence,
>
> DNS Root Server addresses from ARIN are assigned from the critical
> infrastructure pool, and ARIN policy does not allow them to be
> transferred to another RIR. The relevant policy section is:
>
> 8.4. Inter-RIR Transfers to Specified Recipients
>
> [...]
>
> Conditions on source of the transfer:
>
> [...]
> Address resources from a reserved pool (including those designated
> in Section 4.4 and 4.10) are not eligible for transfer.
>
> Regards,
> --
> Robert Story
> USC Information Sciences Institute 
> Networking and Cybersecurity Division
>

Re: New addresses for b.root-servers.net

[Izaac]

On Wed, Jun 07, 2023 at 02:45:05PM -0700, William Herrin wrote:
> [more stuff]

I've unpacked what a vulnerability is and is not for you.
I've unpacked how you can't be violating confidentiality in a protocol
which doesn't guarantee confidentiality for you.
I've unpacked how abusing the vulnerability reporting system for
something which isn't actually a security vulnerability dilutes the
effectiveness of that reporting system for you.
I've unpacked basic definitions of basic terms like "hard-coded" for
you.

Each time, you've just quietly picked up the goal posts and moved them
downrange.  Your argument has gotten increasingly ridiculous.  It's
obvious that you're more interested in "winning" than anything.

I've dispensed the last of my advise.  File your CVE.  I look forward to
tracking its progress.

-- 
. ___ ___  .   .  ___
.  \/  |\  |\ \
.  _\_ /__ |-\ |-\ \__

Re: New addresses for b.root-servers.net

[Izaac]

On Wed, Jun 07, 2023 at 01:52:45PM -0700, William Herrin wrote:
> [stuff]

Put it in your CVE.

-- 
. ___ ___  .   .  ___
.  \/  |\  |\ \
.  _\_ /__ |-\ |-\ \__

Re: New addresses for b.root-servers.net

[Izaac]

On Wed, Jun 07, 2023 at 03:46:39PM -0400, Michael Butler wrote:
> > No.  I will not indulge your invention of terms.  "Hard-coded" means you
> > need to recompile to change it.  This is a default value.  A
> > configuration option takes precedence.
> 
> BIND-9.18.14 requires recompilation to update the embedded defaults ..
> 
> bin/named/config.c: 2001:500:200::b;# b.root-servers.net\n\
> bin/named/config.c: 199.9.14.201;   # b.root-servers.net\n\
> lib/dns/rootns.c:   "B.ROOT-SERVERS.NET. 360 IN  A
> 199.9.14.201\n"
> lib/dns/rootns.c:   "B.ROOT-SERVERS.NET. 360 IN  
> 2001:500:200::b\n"

Don't comprehend what a vulnerability is.
Don't recognize the distinction between a logic issue and a
configuration issue.
Don't understand the difference between "hard-coded" and a default
value.
Don't recognize that these defaults are overridden by a existing
configuration file that is often shipped by the operating system
distribution.
Don't read the code.

Be a co-author with Bill on the CVE.  Go for it.

-- 
. ___ ___  .   .  ___
.  \/  |\  |\ \
.  _\_ /__ |-\ |-\ \__

Re: New addresses for b.root-servers.net

[Michael Butler via NANOG]

On 6/7/23 15:13, Izaac wrote:

On Wed, Jun 07, 2023 at 09:30:36AM -0700, William Herrin wrote:

Data embedded in the binary is hard-coded. That's what hard-coded
means. If it makes you happier I'll qualify it as a "hard-coded
default," to differentiate it from settings the operator can't
override with configuration.


No.  I will not indulge your invention of terms.  "Hard-coded" means you
need to recompile to change it.  This is a default value.  A
configuration option takes precedence.


BIND-9.18.14 requires recompilation to update the embedded defaults ..

bin/named/config.c: 2001:500:200::b;# b.root-servers.net\n\
bin/named/config.c: 199.9.14.201;   # b.root-servers.net\n\
lib/dns/rootns.c:   "B.ROOT-SERVERS.NET. 360 IN  A 
199.9.14.201\n"
lib/dns/rootns.c:   "B.ROOT-SERVERS.NET. 360 IN   
2001:500:200::b\n"




It's an instance of https://cwe.mitre.org/data/definitions/344.html


No, it is not in any respect.  The code you grepped out generates a
default configuration hints file when one does not exist.

The CWE you cite specifically refers to default values for things like
cryptographic RNG seeds and salts and TCP sequence number generators and
the like.  Viz something like
https://www.debian.org/security/2008/dsa-1571 from 2008.


A quick search of https://cve.mitre.org/cve/search_cve_list.html shows
between 600 and 3700 CVEs related to default configurations that are
either directly insecure or unexpectedly become insecure when some but
not all of the defaults are changed by the operator. The vast majority
of these CVEs exhibit, as you say, no flaw in the computational logic.


You literally just gave me a link to the CVE search page, waved your
hand, and said, "See?"  Well, I'll admit to not being as good at
conducting CVE research as you.  So, as an expert on the topic: How many
of these "between 600 and 3700 CVEs" are related to a violating the
baseless expectation of confidentially in a protocol which does not
guarantee confidentiality?  Somewhere between 0 and 2000?

But you know what, go ahead.  Submit the CVE.  Be the hero that you
believe yourself to be.

Re: New addresses for b.root-servers.net

[Izaac]

On Wed, Jun 07, 2023 at 09:30:36AM -0700, William Herrin wrote:
> Data embedded in the binary is hard-coded. That's what hard-coded
> means. If it makes you happier I'll qualify it as a "hard-coded
> default," to differentiate it from settings the operator can't
> override with configuration.

No.  I will not indulge your invention of terms.  "Hard-coded" means you
need to recompile to change it.  This is a default value.  A
configuration option takes precedence.

> It's an instance of https://cwe.mitre.org/data/definitions/344.html

No, it is not in any respect.  The code you grepped out generates a
default configuration hints file when one does not exist.

The CWE you cite specifically refers to default values for things like
cryptographic RNG seeds and salts and TCP sequence number generators and
the like.  Viz something like
https://www.debian.org/security/2008/dsa-1571 from 2008.

> A quick search of https://cve.mitre.org/cve/search_cve_list.html shows
> between 600 and 3700 CVEs related to default configurations that are
> either directly insecure or unexpectedly become insecure when some but
> not all of the defaults are changed by the operator. The vast majority
> of these CVEs exhibit, as you say, no flaw in the computational logic.

You literally just gave me a link to the CVE search page, waved your
hand, and said, "See?"  Well, I'll admit to not being as good at
conducting CVE research as you.  So, as an expert on the topic: How many
of these "between 600 and 3700 CVEs" are related to a violating the
baseless expectation of confidentially in a protocol which does not
guarantee confidentiality?  Somewhere between 0 and 2000?

But you know what, go ahead.  Submit the CVE.  Be the hero that you
believe yourself to be.

-- 
. ___ ___  .   .  ___
.  \/  |\  |\ \
.  _\_ /__ |-\ |-\ \__

Re: New addresses for b.root-servers.net

[Izaac]

On Sun, Jun 04, 2023 at 01:19:18PM -0700, William Herrin wrote:
> Perhaps you missed my subsequent message where I pointed out that the

I did not. 

> IP address is hard-coded in Bind which will use it by default unless
> configured not to.

It is not "hard coded."  It is a default configuration.  You can change
it.  You are *supposed* to change it.

> > It's also not a vulnerability.  A vulnerability, as defined by MITRE for
> > CVE is:
> >
> > "A weakness in the computational logic (e.g., code) found in software
> > and hardware components that, when exploited, results in a negative
> > impact to confidentiality, integrity, or availability.
> 
> At an absolute minimum there's an impact to confidentiality since it
> causes Bind to announce itself to an IP address that is not a root
> server. If the user configured bind with DNSSEC validation disabled,
> it's also a negative impact to integrity and availability since the
> potential false responder can steer bind away from the true DNS tree.

First, you have completely ignored the argument: THERE IS NO FLAW IN
COMPUTATIONAL LOGIC.  There is no vulnerability.

Second, the DNS protocol offers no guarantee of confidentiality.  Is the
protocol itself a vulnerability?  Would you like to file a CVE against
that?

You are recommending embarking on a ludicrous journey ad absurdum.
How about the web browser that makes a GET request via HTTP on port 80
before being 301'd over to HTTPS on 443?  Or the web server that
defaults to LISTEN on 80 and offer its success page without further
configuration?  Do I even need to cast a sideways glance at BGP?

Perhaps you missed my message where I advised against abusing the
already fragile de facto security notification mechanisms to propagate
your desired configuration change.  If the CVE process becomes inundated
with configuration change notifications, it will cease to enjoy the
timely attention which ought to be reserved for real, pants-soiling zero
day vulnerabilities.

But let's indulge a what-if: If some malicious party were to somehow
wrestle control of the old address and begin offering false returns
(which I cannot believe to be any worse than that some members on here
already do with NXDOMAINs to their customers,) that situation will be
handled by simply repeating the advisory of a configuration change.

There exist mechanisms for notifying about network configuration
changes.  You are participating in at least one right now.

In summary, it's not a vulnerability.  Stop pushing CVE as an answer.
It breaks far more than it would fix.  All IANA can do (or is supposed
to do) is publish the notice.  

-- 
. ___ ___  .   .  ___
.  \/  |\  |\ \
.  _\_ /__ |-\ |-\ \__

Re: New addresses for b.root-servers.net

[William Herrin]

On Sun, Jun 4, 2023 at 4:57 PM Mark Andrews  wrote:
> > On 5 Jun 2023, at 06:19, William Herrin  wrote:
> > At an absolute minimum there's an impact to confidentiality since it
> > causes

> I don’t see a big risk here.

Hi Mark,

I agree. CVEs are nevertheless issued for security problems where the
risk is categorized as low. They often describe the mitigations
available to address the risk as well, like installing an updated root
hints file to override the compiled-in defaults.

My point was not that there's some significant security risk to the
root servers changing IP addresses. There isn't. My point is that
there's enough of a security risk to a root server changing its IP
address to merit CVEs against software statically distributed with the
old address. That observation should be taken into account in any
planning for the retirement of a root dns server's IP address. Such as
the b-root change announced in this thread.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: New addresses for b.root-servers.net

[Robert Story]

On Sat 2023-06-03 23:00:33+0200 Terrence wrote:
> Forgive me if I'm missing something obvious, but why are you
> renumbering at all?
> 
> Of course the diversification of RIRs is a good thing, but couldn't
> that be accomplished just as well by transferring the current
> allocation to LACNIC?

Hi Terrence,

DNS Root Server addresses from ARIN are assigned from the critical
infrastructure pool, and ARIN policy does not allow them to be
transferred to another RIR. The relevant policy section is:

8.4. Inter-RIR Transfers to Specified Recipients

[...]

Conditions on source of the transfer:

[...]
Address resources from a reserved pool (including those designated
in Section 4.4 and 4.10) are not eligible for transfer.

Regards,
--
Robert Story 
USC Information Sciences Institute 
Networking and Cybersecurity Division

Re: New addresses for b.root-servers.net

[Izaac]

On Sat, Jun 03, 2023 at 04:17:41PM -0700, William Herrin wrote:
> It *is* a security update. That's a really great point that I
> completely missed. After some period of time, the folks running
> b.root-servers.net should file a CVE against implementations still
> using the deprecated IP address. The CVE makes it a security issue
> compelling vendors of any still-supported software to issue an update.

It's not a security update.  It's a configuration change.

It's also not a vulnerability.  A vulnerability, as defined by MITRE for
CVE is:

"A weakness in the computational logic (e.g., code) found in software
and hardware components that, when exploited, results in a negative
impact to confidentiality, integrity, or availability. Mitigation of the
vulnerabilities in this context typically involves coding changes, but
could also include specification changes or even specification
deprecations (e.g., removal of affected protocols or functionality in
their entirety)."

Do not leverage the already fragile de facto security notification and
tracking mechanisms to propagate your desired configuration change.  Use
the fragile de facto configuration change notification mechanism, e.g.
this list, to handle it.

If NS operators are not have updated their configurations, they will be
the ones to bear the suffering.  If the IP is snatched up and employed
for malicious purposes, it will again be those who failed to update
their configuration who will suffer.  Especially if they aren't doing
the DNSSEC verifications which would make such an attack moot.

-- 
. ___ ___  .   .  ___
.  \/  |\  |\ \
.  _\_ /__ |-\ |-\ \__

Re: New addresses for b.root-servers.net

[William Herrin]

On Sat, Jun 3, 2023 at 8:46 PM Matt Corallo  wrote:
> On 6/3/23 4:17 PM, William Herrin wrote:
> > It *is* a security update. After some period of time, the folks running
> > b.root-servers.net should file a CVE against implementations still
> > using the deprecated IP address.
>
> Not really sure how you go about filing a CVE for a file that isn't usually a 
> part of a standard
> software project -

https://downloads.isc.org/isc/bind9/9.18.15/bind-9.18.15.tar.xz

grep -ri b.root-servers.net bind-9.18.15/
bind-9.18.15/lib/dns/rootns.c:  ".   518400  IN
  NS  B.ROOT-SERVERS.NET.\n"
bind-9.18.15/lib/dns/rootns.c:  "B.ROOT-SERVERS.NET. 360 IN
  A   199.9.14.201\n"
bind-9.18.15/lib/dns/rootns.c:  "B.ROOT-SERVERS.NET. 360 IN
  2001:500:200::b\n"
bind-9.18.15/bin/named/config.c:2001:500:200::b;#
b.root-servers.net\n\
bind-9.18.15/bin/named/config.c:199.9.14.201;   #
b.root-servers.net\n\

So, when 199.9.14.201 stops being a root DNS server, bind 9.18.15
legitimately has a CVE because that IP address is hard-coded.

I would bet that the other major DNS server software also has some
sort of mechanism for including the root hints instead of making the
packager or user go fetch it. This is not a bad thing. Filing a CVE
against it does not reflect badly on the programmers. It's a
reasonable notification path for security folks to discover and
address external changes that impact the security of the software they
operate.

-Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: New addresses for b.root-servers.net

[Matt Corallo]

On 6/3/23 4:17 PM, William Herrin wrote:

On Sat, Jun 3, 2023 at 12:46 PM Matt Corallo  wrote:

I assume RHEL would ship a root hints update during that time, but such things 
can slip through
pretty easily as its not a security update.


Hi Matt,

It *is* a security update. That's a really great point that I
completely missed. After some period of time, the folks running
b.root-servers.net should file a CVE against implementations still
using the deprecated IP address. The CVE makes it a security issue
compelling vendors of any still-supported software to issue an update.


Mmm, good point, it is indeed.

Not really sure how you go about filing a CVE for a file that isn't usually a part of a standard 
software project - I guess that would require some nontrivial amount of work to figure out which 
distro(s) are still shipping an old copy of the hints file and nag them to upgrade (not sure a CVE 
would move the needle).


Sadly your usual method of getting CVE notifications for software you run probably wouldn't show for 
"DNS Root Hint file". You could maybe try just doing it blanket against older resolvers as they also 
distribute the hints file, but that's kinda rude given its not really an issue in their software and 
the hints file distributed with bind isn't the one Debian/Fedora are gonna use.


Matt

Re: New addresses for b.root-servers.net

[William Herrin]

On Sat, Jun 3, 2023 at 12:46 PM Matt Corallo  wrote:
> I assume RHEL would ship a root hints update during that time, but such 
> things can slip through
> pretty easily as its not a security update.

Hi Matt,

It *is* a security update. That's a really great point that I
completely missed. After some period of time, the folks running
b.root-servers.net should file a CVE against implementations still
using the deprecated IP address. The CVE makes it a security issue
compelling vendors of any still-supported software to issue an update.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: New addresses for b.root-servers.net

[Terrence de Kat]

Forgive me if I'm missing something obvious, but why are you renumbering at all?


Of course the diversification of RIRs is a good thing, but couldn't that be 
accomplished just as well by transferring the current allocation to LACNIC?


It seems to me that there are a lot of reasons why, when it concerns root 
servers, renumbering should be a last resort. Especially when you already 
renumbered relatively recently and when an administrative solution rather than 
an operational one is available.


I administer a few public IRC servers for EFnet, and when I assign a /24 for 
such a server I consider the subnet unfit for any other purpose from that point 
forward. Practically lost for normal use.


Now, a DNS root server is obviously not the same as an IRC server, but I'd 
guess that there is a lot in common concerning threats and mitigation of those 
threats. Only the scale is much larger and the service (much) more critical 
(though people on IRC will fight me for saying that :).


So, it seems to me that you'd also like to avoid renumbering unless absolutely 
necessary, if only because it's a waste of a perfectly good subnet.


NB. Apologies for top-posting, a script that is supposed to fix this is started 
corrupting my emails after an update and I haven't been able to find the 
problem.

-- 
Regards,
   Terrence de Kat, PhD/MTh/BPsy
     Darkness Reigns (Holding) B.V.

Please quote relevant replies.

From: Robert Story 
Sent: Tuesday, 30 May 2023 18:19
To: NANOG
Subject: New addresses for b.root-servers.net

>
> USC/ISI is renumbering both its IPv4 and IPv6 addresses for 
> b.root-servers.net on 2023-11-27. Our new IPv4 address will be 
> 170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b. 
> USC/ISI will continue to support root service over our current IPv4 and 
> IPv6 addresses for at least one year (until 2024-11-27) in order to 
> provide a stable transition period while new root hints files are 
> distributed in software and operating system packages. 
>
> We are renumbering to increase the resilience of the Root Servers 
> System by further diversifying the number of Regional Internet 
> Registries (RIRs) that have allocated IP addresses to Root Server 
> Operators. Our addresses will be the first in the Root Server System to 
> have been allocated by LACNIC and our routes will be verifiable through 
> LACNIC’s Resource Public Key Infrastructure (RPKI) Trust Anchor 
> Location (TAL). We thank LACNIC for helping make this renumbering 
> possible, and ARIN for supporting our prior addressing assignments. 
>
>
> The LACNIC announcement, with English, Spanish and Portuguese 
> translations, can be found on their website here: 
>
> https://www.lacnic.net/6868/1/lacnic/lacnic-asigna-recursos-de-numeracion-al-servidor-raiz-de-usc_isi
>  
>
> Please direct any comments or questions to b-poc  isi.edu. 
>
> Regards, 
> Robert 
>
> P.S. Apologies to anyone receiving multiple copies of this announcement. 
>
> -- 
> Robert Story 
> USC Information Sciences Institute <http://www.isi.edu/> 
> Networking and Cybersecurity Division 

Re: New addresses for b.root-servers.net

[Matt Corallo]

On 6/1/23 3:57 PM, William Herrin wrote:

Certainly we would appreciate other opinions about what the right length
of a change-over time would be, especially from the operational
communities that will be most impacted by this change.


A server generation is about 3 years before it's obsolete and is
generally replaced. I suggest making the old address operable for two
generations (6 years) and black-holed for another generation (3 more
years).


I'm not convinced it should be based entirely on physical server rollovers, but certainly you could 
look at it through the lens of DNS resolver software security update support timelines. As far as 
I'm aware, RHEL is one of the longest-available support timelines, with RHEL 6 released in 2010 
still supported into 2026 (per Wikipedia).


I assume RHEL would ship a root hints update during that time, but such things can slip through 
pretty easily as its not a security update.


You could also look at the DNSSEC KSK rollover as a natural cutoff point - the KSK rollover in 
October 2018 used a KSK created in October 2016, which is a substantially more aggressive timeline 
than a 3 year physical server rollover (I'm gonna bet you can find *tons* of folks on this list 
running physical servers way older than 3 years with production DNS resolvers on them) or 15+ year 
RHEL support timeline.


As properly configured resolutions will fail after a new KSK rollover, its probably not unreasonable 
to stop responding (correctly) after a future KSK rollover.


Not sure what the operation cost is to keep responding on another IP block, but I'm gonna assume its 
not a whole lot, so absent a strong reason ISTM its easy to air on the side of responding for a 
long, long time rather than not responding.



Perhaps make it a false responder in the last of those 9 years so that
anybody who is truly that far behind on their software updates gets
enough of a spanking to stop sending you packets. You'll have problems
repurposing the address and its subnet until folks stop sending you
DNS query packets, even if you don't respond to them.


Not a bad idea, you could also put a nice warning page up informing them that their DNS resolver is 
broken and not enforcing DNSSEC while you're at it :)


Matt

Re: New addresses for b.root-servers.net

[Matthew Petach]

On Fri, Jun 2, 2023 at 10:40 AM William Herrin  wrote:

> On Fri, Jun 2, 2023 at 9:57 AM Jim  wrote:
> > A major concern would be if the IP address were eventually re-assigned
> to something else that
> > ended up reporting false answers due to a malicious or misconfigured DNS
> service.
>
> Hi Jim,
>
> That's one reason I suggested intentionally making it a false
> responder for the final year of its post-service hold. Return wildcard
> A and  records for all queries pointing to a web site which
> responds to any URL with, "Hey buddy, your DNS software is so grossly
> out of date that now it's broken and will stay broken until you fix
> it."
>
> Anybody still sending queries after that gets what they get and
> deserves it -- as long as the time that passes until the final year is
> long enough that only the most reckless and incompetent users are
> still sending queries.
>

I think you underestimate the time frames involved in some projects.
My older brother was deeply involved in the James Webb space telescope
project.
At one point, while visiting him at the giant clean room in Redondo Beach,
we started talking about the specifications on the computers onboard the
telescope.  I was aghast at how out-of-date the systems being installed
were,
and noted I could pop over to Fry's and pick up something with 20x the
memory,
running 10x as fast with pocket money.
He countered by pointing out there were thousands of subcontractors
involved
in the project, and everything had to come together smoothly at the end.
Once
the design work was completed, *everything* was frozen; no changes were
allowed,
no matter how well-intentioned, because there could be unanticipated ripple
effects
on other components being worked on by completely independent
subcontractors.
The end result being that what was being launched was based on hardware and
software that was finalized nearly two decades earlier.

It's a bit unkind to think that only "reckless and incompetent users" will
still be
sending queries years later, when there are plenty of projects like the
James
Webb space telescope where the elements were locked in years before any
decision to renumber root servers might have been made.

I agree with Jim.  Once a block was in use by a root server instance,
encoded
in root hints files, it should be forever reserved as such.  If we want to
make
use of different RIRs and distribute responsibility around the planet,
transfer
the ownership of a block from one RIR to another; don't count on everything
on and off the planet being able to update their root hints.

Thanks!

Matt

Re: New addresses for b.root-servers.net

[William Herrin]

On Fri, Jun 2, 2023 at 9:57 AM Jim  wrote:
> A major concern would be if the IP address were eventually re-assigned to 
> something else that
> ended up reporting false answers due to a malicious or misconfigured DNS 
> service.

Hi Jim,

That's one reason I suggested intentionally making it a false
responder for the final year of its post-service hold. Return wildcard
A and  records for all queries pointing to a web site which
responds to any URL with, "Hey buddy, your DNS software is so grossly
out of date that now it's broken and will stay broken until you fix
it."

Anybody still sending queries after that gets what they get and
deserves it -- as long as the time that passes until the final year is
long enough that only the most reckless and incompetent users are
still sending queries.

Regards,
Bill Herrin

--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: New addresses for b.root-servers.net

[Jim]

On Thu, Jun 1, 2023 at 5:59 PM William Herrin  wrote:

A server generation is about 3 years before it's obsolete and is
> generally replaced. I suggest making the old address operable for two .
> generations (6 years) and black-holed for another generation (3 more  
>

As you mention.. there is No TTL for the root hints.  The TTL is Infinite.
And not
all users will be retired after 3 years... there are DNS resolvers online
running
10-year old code and there are DNS resolvers on the internet that may not
see a roots hint
update in the next 10 years.It is unlikely that there is any practical
way of giving notice
to the operators of such servers.

Therefore, I would suggest IP Addresses that ever appeared in the official
root hints
should be reserved permanently and exclusively for official root service,
then blackholed indefinitely once service
is not in operation anymore to prevent any DNS service other than an
official root server appearing at
that IP at any point in time in the future  no matter how many years have
elapsed (Infinite TTL).

A major concern would be if the IP address were eventually re-assigned to
something else that
ended up reporting false answers due to a malicious or misconfigured DNS
service.

DNS resolvers can handle no answer by trying other servers,  but
a false answer from an unauthorized and malicious root service being
received by non-validating
resolvers would be fairly certain to be capable of causing total failure in
the resolver;
while an IP address being offline would more likely only cause impairment
or delays.

It's understandable if some root service IP addresses stop providing
service years after
the end of service, and resolvers should still be able to function at some
level with
reduced resiliency and increased errors  if only a small number have
changed.


> Regards,
> Bill Herrin
>
--
-JH

Re: New addresses for b.root-servers.net

[Jared Mauch]

I know when I did the openresolver project stuff I saw a number that would send glue or referrals from before they moved to the root servers domain names. - Jared Sent via RFC1925 compliant deviceOn Jun 2, 2023, at 8:49 AM, Nathan Ward  wrote:

On 2/06/2023 at 10:22:46 AM, Wes Hardaker  wrote:



2. I'll note that we are still serving DNS requests at the addresses thatwe switched away from in 2017 [1][2].  At that time we actually onlypromised 6 months and we've doubled that time length with our latestannounced change.  But we do need a date after which we can turn offservice to an address block if some reason demands it.



Hi Wes,Seems to me that this could be heavily informed by historical data from this earlier renumbering.Do you have query rates over time for the old and new addresses since this change in 2017?Even if you end up with the same answer of 12mo, data supporting it may give comfort to the community.Maybe you make a call that once it’s at say 1% or 0.1% or something like that, then it’s OK to turn off - and make a prediction for when that might be based on the historical data.--Nathan Ward

Re: New addresses for b.root-servers.net

[Nathan Ward]

On 2/06/2023 at 10:22:46 AM, Wes Hardaker  wrote:

>
> 2. I'll note that we are still serving DNS requests at the addresses that
> we switched away from in 2017 [1][2].  At that time we actually only
> promised 6 months and we've doubled that time length with our latest
> announced change.  But we do need a date after which we can turn off
> service to an address block if some reason demands it.
>

Hi Wes,

Seems to me that this could be heavily informed by historical data from
this earlier renumbering.

Do you have query rates over time for the old and new addresses since this
change in 2017?

Even if you end up with the same answer of 12mo, data supporting it may
give comfort to the community.

Maybe you make a call that once it’s at say 1% or 0.1% or something like
that, then it’s OK to turn off - and make a prediction for when that might
be based on the historical data.

--
Nathan Ward

Re: New addresses for b.root-servers.net

[Masataka Ohta]

William Herrin wrote:


Certainly we would appreciate other opinions about what the right length
of a change-over time would be, especially from the operational
communities that will be most impacted by this change.


Considering the possibility that, in a long run, remaining
12 sets (4 and 6) of IP addresses will also change, the proper
length should be determined assuming all the 13 sets of
addresses will change (not necessarily at the same time).


A server generation is about 3 years before it's obsolete and is
generally replaced. I suggest making the old address operable for two
generations (6 years) and black-holed for another generation (3 more
years).


You are assuming managed servers under Moore's law.

But, after Moore, a server generation will be longer.

Moreover, a linux-based black box, vendor of which has
disappeared, may be used for 10 or 20 years without being
managed.

Then, another important period is the period to reserve
the IP addresses once used for root servers. If the
addresses are reused by some bad guys, systems
depending on them can easily be compromised.

For the reservation period, 50 years of reservation
period of ISO3166 country codes seems to be reasonable.

And, if the addresses are reserved, there is no
reason not to keep using the addresses as
alternative addresses of active root name servers.

Masataka Ohta

PS

First of all, it is a bad idea to change the
addresses of root servers. For political ceremony, it
is enough to transfer address blocks to LACNIC.

Re: New addresses for b.root-servers.net

[William Herrin]

On Thu, Jun 1, 2023 at 3:22 PM Wes Hardaker  wrote:
> 1. There is some definite disagreement in opinions we've heard at this
> point, where we've heard from the other extreme opinion where they
> actually wish we wouldn't support the old addresses beyond the TTL at
> the time of the changeover (IE, a bit longer than 48 hours).

Why? Are they fans of breaking the Internet? There is no TTL on the
root hints file and software update cycles are generally a lot longer
than 48 hours. Yes, I know resolvers are supposed to discard the hints
once they have the authoritative NS and A records, but you'd just be
begging for unintended consequences.


> 2. I'll note that we are still serving DNS requests at the addresses that
> we switched away from in 2017 [1][2].  At that time we actually only
> promised 6 months and we've doubled that time length with our latest
> announced change.
>  But we do need a date after which we can turn off
> service to an address block if some reason demands it.
>
> Certainly we would appreciate other opinions about what the right length
> of a change-over time would be, especially from the operational
> communities that will be most impacted by this change.

A server generation is about 3 years before it's obsolete and is
generally replaced. I suggest making the old address operable for two
generations (6 years) and black-holed for another generation (3 more
years).

Perhaps make it a false responder in the last of those 9 years so that
anybody who is truly that far behind on their software updates gets
enough of a spanking to stop sending you packets. You'll have problems
repurposing the address and its subnet until folks stop sending you
DNS query packets, even if you don't respond to them.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: New addresses for b.root-servers.net

[Wes Hardaker]

Jan Schaumann via NANOG  writes:

> > USC/ISI is renumbering both its IPv4 and IPv6 addresses for
> > b.root-servers.net on 2023-11-27. Our new IPv4 address will be
> > 170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b.
> > USC/ISI will continue to support root service over our current IPv4 and
> > IPv6 addresses for at least one year (until 2024-11-27) in order to
> > provide a stable transition period while new root hints files are
> > distributed in software and operating system packages.
> 
> I know it says "at least", but support for the old
> addresses for only one year seems like a very short
> time in this context.  I hope USC/ISI will be able to
> keep the old addresses functional for much longer.

Greetings Jan,

A few points on this matter:

1. There is some definite disagreement in opinions we've heard at this
point, where we've heard from the other extreme opinion where they
actually wish we wouldn't support the old addresses beyond the TTL at
the time of the changeover (IE, a bit longer than 48 hours).

2. I'll note that we are still serving DNS requests at the addresses that
we switched away from in 2017 [1][2].  At that time we actually only
promised 6 months and we've doubled that time length with our latest
announced change.  But we do need a date after which we can turn off
service to an address block if some reason demands it.

Certainly we would appreciate other opinions about what the right length
of a change-over time would be, especially from the operational
communities that will be most impacted by this change.

[1]: https://b.root-servers.org/news/2017/06/01/new-ipv6.html
[2]: https://b.root-servers.org/news/2017/08/09/new-ipv4.html

-- 
Wes Hardaker 
USC/ISI

Re: New addresses for b.root-servers.net

[Jan Schaumann via NANOG]

Robert Story  wrote:
> 
> USC/ISI is renumbering both its IPv4 and IPv6 addresses for
> b.root-servers.net on 2023-11-27. Our new IPv4 address will be
> 170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b.
> USC/ISI will continue to support root service over our current IPv4 and
> IPv6 addresses for at least one year (until 2024-11-27) in order to
> provide a stable transition period while new root hints files are
> distributed in software and operating system packages.

I know it says "at least", but support for the old
addresses for only one year seems like a very short
time in this context.  I hope USC/ISI will be able to
keep the old addresses functional for much longer.

-Jan

New addresses for b.root-servers.net

[Robert Story]

USC/ISI is renumbering both its IPv4 and IPv6 addresses for
b.root-servers.net on 2023-11-27. Our new IPv4 address will be
170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b.
USC/ISI will continue to support root service over our current IPv4 and
IPv6 addresses for at least one year (until 2024-11-27) in order to
provide a stable transition period while new root hints files are
distributed in software and operating system packages.

We are renumbering to increase the resilience of the Root Servers
System by further diversifying the number of Regional Internet
Registries (RIRs) that have allocated IP addresses to Root Server
Operators. Our addresses will be the first in the Root Server System to
have been allocated by LACNIC and our routes will be verifiable through
LACNIC’s Resource Public Key Infrastructure (RPKI) Trust Anchor
Location (TAL). We thank LACNIC for helping make this renumbering
possible, and ARIN for supporting our prior addressing assignments.


The LACNIC announcement, with English, Spanish and Portuguese
translations, can be found on their website here:

https://www.lacnic.net/6868/1/lacnic/lacnic-asigna-recursos-de-numeracion-al-servidor-raiz-de-usc_isi

Please direct any comments or questions to b-poc  isi.edu.

Regards,
Robert

P.S. Apologies to anyone receiving multiple copies of this announcement.

--
Robert Story 
USC Information Sciences Institute 
Networking and Cybersecurity Division