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