Thanks for the support for the doc; I hope others chime in as well. On Jan 9, 2024, at 08:33, Paul Wouters <p...@nohats.ca> wrote: > > there are 13 root servers. > > I would really like to see this changed. We keep trying to tell people > that are not DNS insiders that the world does not depend on just 13 > physical machines. This will cause that confusion to strengthen again.
Good catch; fixed. >> It is in DNS master file format >> >> Maybe use "zone file presentation format" instead of "master file format" > > This still stands as well. Agree; fixed. > Perhaps a recommendation could be to check with ZONEMD and do an AXFR, > eg recomend implementing RFC 8806 - "Running a Root Server Local to a > Resolver". > Comes with added bonuses on top of a signature on all the root glue. > > I still think this would also still be good to mention. This would be a very comfusing mention because the resolver isn't really "priming" at that point, it's using a complete root zone. I'll cover this with an addition to the Security Considerations section: <t>This document does not cover the use of (or the need for) priming when serving a copy of the full root zone on the same server as the resolver, such as is described in <xref target="RFC8806"/>. In such a setup, the resolver never really primes its cache because the cache is full as soon as the resolver pulls down a new complete root zone.</t> (Suggestions for better wording are welcome!) > >> [[ This section talks about sending the DO bit, but does not actually >> talk about validating the response to the priming query. This became >> important after the root KSK rollover in 2018 because some resolvers >> apparently were validating and only had the old KSK, but were still >> sending RFC 8145 telemetry even after failing to validate their >> priming response. ]] > > I said before: > > Nothing much can be done here other than advising implementers to check > if the obtained DNSKEY RRset no longer contains any KSK that is > configured as part of the software, and then doing some kind of > exponential back-off to slow down the query rate? > > The comment was removed but no text was added for this ? Should there be? I'm not seeing what adding this would solve. The only possible attack is that the old key was compromised by the machine-in-the-middle attacker, but that is a completely separate issue from priming because the priming response is not (currently) signed. > I also wrote before: > > So now I do think the document is ready, but I think it would be nice to > mention ZONEMD and local root configurations as methods to protect > against spoofed glue. See above. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
