> On Jun 2, 2023, at 1:14 PM, Chris Adams <[email protected]> wrote: > > Once upon a time, Dave Knight <[email protected]> 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 _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
