Last Call Review of draft-ietf-dnsop-rfc8109bis-05
review-ietf-dnsop-rfc8109bis-05-secdir-lc-vucinic-2024-07-26-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. Document
editors and WG chairs should treat these comments just like any other last call
comments.

This document updates RFC 8109. It describes the steps needed for Recursive DNS
resolvers to obtain names and addresses of the root servers based on initial
configuration, a common implementation choice.

I believe this document is Ready with Nits. Please find below two questions I
had while going through the document.

Section 4.1: “The priming response MUST have an RCODE of NOERROR, and MUST have
the Authoritative Answer (AA) bit set. Also, it MUST have an NS RRset in the
Answer section (because the NS RRset originates from the root zone), and an
empty Authority section (because the NS RRset already appears in the Answer
section). There will also be an Additional section with A and/or AAAA RRsets
for the root servers pointed at by the NS RRset.”

The original text in RFC 8109 uses the term “expected” to denote the properties
of the priming response. Given that the root server cannot distinguish a
priming query from any other query for the root NS RRset, I don’t see how
changing “expected” used in RFC 8109 to a normative keyword “MUST” makes sense
here?

Section 6: “An on-path attacker who sees a priming query coming from a resolver
can inject false answers before a root server can give correct answers.”

How can an on-path attacker differentiate the normal query from a priming query
if a root server cannot? I guess the text above is valid for any query, not
just for a priming query. Perhaps it should be rephrased to read as such.