New addresses for b.root-servers.net

Mailman List Mirror (Read Only)
1

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 <at> isi.edu.

Regards,
Robert

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

2

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

3

Jan Schaumann via NANOG <nanog@nanog.org> 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]: New IPv6 address for b.root-servers.net
[2]: B-Root's IPv4 address to be renumbered 2017-10-24

4

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

5

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.

6

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.

7

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
8

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.

9

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

10

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

11

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 :slight_smile:

Matt

12

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

13

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

14

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. 3600000 IN
  A 199.9.14.201\n"
bind-9.18.15/lib/dns/rootns.c: "B.ROOT-SERVERS.NET. 3600000 IN
  AAAA 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

15

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.

16

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

Hi Izaac,

Perhaps you missed my subsequent message where I pointed out that the
IP address is hard-coded in Bind which will use it by default unless
configured not to.

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.

Like well known default passwords, for which there are many CVEs, it's
a vulnerability.

Regards,
Bill Herrin

17

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

Hi Izaac,

Perhaps you missed my subsequent message where I pointed out that the
IP address is hard-coded in Bind which will use it by default unless
configured not to.

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.

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.

There is already a issue raised for updating the compiled in address.

I suspect that most of the distributions that include named will have had
or will have similar issues raised. Many distributions include their own
set of hints and do not rely on the compiled in set.

Named will log any differences between its configured root servers (names
and addresses) and those returned when priming.

18

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

19

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.

20

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

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.

It's an instance of CWE - CWE-344: Use of Invariant Value in Dynamically Changing Context (4.11)
and you can see a similar sort of error in play in
CWE - CWE-798: Use of Hard-coded Credentials (4.11)

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

A quick search of CVE - Search CVE List 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.

Regards,
Bill Herrin