New addresses for b.root-servers.net

Michael Butler imb at protected-networks.net
Wed Jun 7 19:46:39 UTC 2023


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



More information about the NANOG mailing list