On Fri, 29 Dec 2023, Paul Wouters wrote:
I've missed these calls, my apologies.
I think the document is almost ready to proceed, but contains some
markers of [[unresolved discussion]] that obviously needs resolving
(and should have been resolved before doing a WGLC? :)
Obviously I made a mistake and referred to non-adopted version :)
Some new comments included based on the new diff, and some comments
revised based on them having been done already.
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.
the changes from RFC 8109 that are listed in the latest draft.
1.1. Changes from RFC 8109
This document obsoletes [RFC8109]. The significant changes from RFC
8109 are:
* Added section on the content of priming information.
It is in DNS master file format
Maybe use "zone file presentation format" instead of "master file format"
This still stands.
[[ Need to discuss: when pre-fetching, does the resolver send the
queries to the addresses associated with the . / NS RRset in the
cache, or does the resolver go back to the addresses in the
configuration? ]]
I believe it should treat these as any other pre-fetching queries, so
using the existing cache.
which this version agrees with, yay :)
However, pre-fetching might not be the most
secure method to transfer a lot of glue records that are not signed. It
could decide that upon receiving very many validation errors to TLD
zones, that it might not trust its existing cache and reload from
scratch using the IPs from its configuration file.
This still stands, but could be considered out of scope for the
document.
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 think this would still be good to mention ?
[[ 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. ]]
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?
[[ Describe some common post-priming strategies for picking which RSI
to use for queries sent to the root, such as "always use the
fastest", "create buckets of fastness and pick randomly in the
buckets", and others. ]]
This would be good to add, perhaps current implementers could help
sharing what they do and why and come up with text?
The document moves this mostly out of scope, which is fine.
* Added paragraph about no expectation that the TC bit in responses
will be set.
* Added paragraph about RFC 9471 and requirements on authoritative
servers and the TC bit.
* Changed "man-in-the-middle" to "machine-in-the-middle" to be both
less sexist and more technically accurate.
* Clarified that there are other effects of machine-in-the-middle
attacks.
* Clarified language for root server domain names as "root server
identifiers".
* Added short discussion of post-priming strategies.
* Added informative references to RSSAC documents.
* Added short discussion about this document and private DNS.
* Added discussion of where resolvers that pre-fetch should get the
root NS addresses.
* Elevated the expectations in "Expected Properties of the Priming
Response" to MUST-level.
* Clarified that "currently" means at the time that this document is
published.
These all seem fine to me.
I do hope this document doesn't die here.
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.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
