Reviewer: Mališa Vučinić Review result: Has Nits 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
