[dns-operations] New addresses for b.root-servers.net

[Dave Knight]

> On Jun 2, 2023, at 1:14 PM, Chris Adams <cma at cmadams.net> wrote:
> 
> Once upon a time, Dave Knight <dave at knig.ht> said:
>> Aiui BIND9 uses the root.hints just once on receipt of the first query when starting with an empty cache, whereupon it will use the hints to find a root server to do a priming query, replacing the hints with the result of that.
> 
> It's been a long while since I looked - how is that done?  Do the
> resolvers query multiple servers from their hints (and somehow resolve
> differences), or do they just pick one at random and accept the results?
> 
> It seems like maybe if they'd query multiple and take a majority opinion
> of the results, the potential damage of hijacking of an old IP would be
> minimized.


We don't need to poll the group to validate the data, we have DNSSEC.


I just installed the default bind9 package on Ubuntu 20.04, which got me BIND 9.16.1.

$ dig +noall +answer @localhost version.bind. ch txt 
version.bind. 0 CH TXT "9.16.1-Ubuntu”


It comes with the key material and default configuration to do dnssec validation.

commented out the root hints file in /etc/bind/named.conf.default-zones

run named with debugging output enabled and tcpdump running, it primes itself and validates the priming response at startup


# /usr/sbin/named -u bind -d3 -g 
02-Jun-2023 17:42:03.600 starting BIND 9.16.1-Ubuntu (Stable Release) <id:d497c32>

[..]

02-Jun-2023 17:42:03.876 validating ./NS: starting
02-Jun-2023 17:42:03.876 validating ./NS: attempting positive response validation
02-Jun-2023 17:42:03.876   validating ./DNSKEY: starting
02-Jun-2023 17:42:03.876   validating ./DNSKEY: attempting positive response validation
02-Jun-2023 17:42:03.876   validating ./DNSKEY: verify rdataset (keyid=20326): success
02-Jun-2023 17:42:03.876   validating ./DNSKEY: marking as secure (DS)
02-Jun-2023 17:42:03.876 validating ./NS: in validator_callback_dnskey
02-Jun-2023 17:42:03.876 validating ./NS: keyset with trust secure
02-Jun-2023 17:42:03.876 validating ./NS: resuming validate
02-Jun-2023 17:42:03.876 validating ./NS: verify rdataset (keyid=60955): success
02-Jun-2023 17:42:03.876 validating ./NS: marking as secure, noqname proof not needed
02-Jun-2023 17:42:03.876 resolver priming query complete

[..]


On the wire I see it query a root server for

./IN/DNSKEY?
./IN/NS?

17:42:03.690875 IP6 2610:a1:3004:224::229.50056 > 2001:7fe::53.53: 1260% [1au] DNSKEY? . (40)
17:42:03.691657 IP6 2610:a1:3004:224::229.39158 > 2001:7fe::53.53: 45282 [1au] NS? . (40)


I can then query it for ./IN/NS? and get an authenticated response. 

; <<>> DiG 9.16.1-Ubuntu <<>> @localhost . IN NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57603
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a8a497a0545fd61b01000000647a2a54cb983b8d323a4f9a (good)
;; QUESTION SECTION:
;. IN NS

;; ANSWER SECTION:
. 518296 IN NS f.root-servers.net.
. 518296 IN NS b.root-servers.net.
. 518296 IN NS a.root-servers.net.

[..]

That came from the cache, it sent no more queries to the root servers.


If dnssec-validation is disabled it doesn't do a priming query at startup, instead waiting for an initial query before priming, and it doesn't validate the priming response. Enable validation :)


dave