New addresses for b.root-servers.net

Wed Jun 7 15:41:19 UTC 2023

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.  

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