On Thu, 28 Dec 2023, Paul Hoffman wrote:
On Dec 28, 2023, at 13:34, Tim Wicinski <tjw.i...@gmail.com> wrote:
All,
We wrapped up the second working group last call for
draft-ietf-dnsop-rfc8109bis with no comments pro or con.
The chairs can only assume the working group is not interested in moving this
work forward.
We are going to discuss this with Warren on our next steps here.
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? :)
Wearing my co-author hat, I'm interested in what the WG wants to do with 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"
[[ 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. 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.
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.
[[ 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?
[[ 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?
* 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.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
