Skip to main content

Telechat Review of draft-ietf-dnsop-rfc8109bis-06
review-ietf-dnsop-rfc8109bis-06-dnsdir-telechat-mevzek-2024-08-19-00

Request Review of draft-ietf-dnsop-rfc8109bis
Requested revision No specific revision (document currently at 07)
Type Telechat Review
Team DNS Directorate (dnsdir)
Deadline 2024-08-20
Requested 2024-08-05
Authors Peter Koch , Matt Larson , Paul E. Hoffman
I-D last updated 2024-08-19
Completed reviews Dnsdir Early review of -00 by Di Ma (diff)
Genart Last Call review of -05 by Dale R. Worley (diff)
Dnsdir Last Call review of -05 by Di Ma (diff)
Opsdir Last Call review of -05 by Joe Clarke (diff)
Secdir Last Call review of -05 by Mališa Vučinić (diff)
Dnsdir Telechat review of -06 by Patrick Mevzek (diff)
Intdir Telechat review of -06 by Dirk Von Hugo (diff)
Opsdir Telechat review of -06 by Joe Clarke (diff)
Assignment Reviewer Patrick Mevzek
State Completed
Request Telechat review on draft-ietf-dnsop-rfc8109bis by DNS Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/dnsdir/uv17F8wFuK17zWip-8SZFcvGbyE
Reviewed revision 06 (document currently at 07)
Result Ready w/nits
Completed 2024-08-19
review-ietf-dnsop-rfc8109bis-06-dnsdir-telechat-mevzek-2024-08-19-00
I reviewed draft-ietf-dnsop-rfc8109bis-06 which was current version at time of
review.

The document, updating RFC 8109, does not introduce changes in the DNS protocol
or specifications, but gives guidance on best operational behavior for a
recursive server.

I have only few nitpicks to report below, but I also do concur with the
previous DNSDIR review at
https://datatracker.ietf.org/doc/review-ietf-dnsop-rfc8109bis-05-dnsdir-lc-ma-2024-07-16/
around precision needed for DNSSEC in case of specific trust anchors defined.
Maybe it could be as simple as taming the sentence on whole control of the TLD
space by adding something like “in absence of other specific protections
configured at the resolver” or anything better in that direction.

In reading chronological order, mostly nitpicks/suggestions (feel free to
discard) for the document “as if” standalone and new, irrespective of the fact
it updates RFC8109.

> This document only deals with recursive name servers (recursive resolvers,
resolvers) for the IN class.

Possibly take the opportunity to reference here RFC 9499 on DNS terminology so
that there is convergence on what term to use, and hence use only one, removing
the part in ()?

> A priming query is a DNS query whose response provides root server names and
addresses.

To keep the terminology just introduced before this, I believe it should be
instead “provides root server identifiers and addresses.”

> The priming query can be sent over either UDP or TCP.

Is there a specific need here to kind of restrict protocols, instead of like
allowing the server to try any protocols it may believe or is agreeing to try
(like DoH/DoT/DoQ, which technically are “over UDP or TCP” but I have the
feeling that “UDP or TCP” is kind of meaning just usual Do53)? The difference
might be moot right now as root servers are not necessarily reachable over
anything else than Do53 but it could change in the future perhaps and if the
document already covers that use case, it avoids a change. I don't see anyway a
specific need to restrict a resolver somehow for his priming activity in regard
to the transport used, in the face of multiple possibilities.

>  such as when the resolver starts with an empty cache or when the NS RRset
for the root zone has expired.

But what about the TTLs on the IP addresses themselves?
(they are the same right now for NS/A/AAAA at the root, but I see nothing
making that mandatory)

> Although there is no harm to adding these names, they are not useful in the
root priming process.

This is the only case in the document where it is stated *root* priming.
To reduce confusion, it is needed there? But also, can't this also open a part
about discussing other kind of priming, like some or all of TLD's NS recordsets
(or just explicitly rejecting that discussing and specifying from the beginning
this document is only for root level priming).

> However, because at the time this document is published the
"root-servers.net" zone is not signed, the root name server A and AAAA RRsets
cannot be validated.

I have mixed feelings on this because it seems to imply that the only missing
things is the `root-servers.net` zone to be signed. But even if it was, a
simple `. NS` query wouldn't help to validate the IPs as they are in the
ADDITIONAL section, hence not covered by DNSSEC. So a whole new separate
process would then be needed with explicit query for A/AAAA per root server
identifier to validate each.

> Resolver software SHOULD NOT expect 13 NS RRs because, historically, some
root servers have returned fewer.

If so, maybe also add generic advice on not having any specific expectations of
the number of IPv4 or IPv6 in total and per server (specifically since there
could be truncation, and no possible reliance on TC bit as explained in §4.2,
so a receiver can never have a strong guarantee to have gotten ALL IPs in the
Additional section)?

> An on-path attacker who sees a priming query coming from a resolver

Yet earlier we had: “A priming query is a normal DNS query. Thus, a root server
cannot distinguish a priming query from any other query for the root NS RRset.”
I believe the “cannot distinguish” extends to any on-path observer of traffic,
attacker or not. So here, how and why does an attacker know it is a priming
query? Because it didn't see traffic from this resolver since “some time ago”
so inferring it may have just started (or refreshing its cache)? How could or
would an attacker change behavior between a “priming query” and “any other
query for NS . recordset, not being a priming query”.

Patrick Mevzek