Greetings! I really like the draft, and I'm sorry to be so late. I see one minor issue just below and then a few nitpicks that I don't feel strongly about.
> NXDOMAIN: > "Name Error - Meaningful only for responses from an authoritative > name server, this code signifies that the domain name referenced in > the query does not exist." (Quoted from [RFC1035], Section 4.1.1.) > [RFC2308] established NXDOMAIN as a synonym for Name Error. I dislike keeping this formulation; it might confuse people. It seems to imply that NXDOMAIN from a resolver isn't "meaningful", and that's clearly not true, at least not nowadays. (I develop a resolver.) "Resolver" definition: I don't think the word really implies it runs on the same machine as the program asking it. In particular, the purpose of stub resolvers is to ask a recursive *resolver* that is typically on another machine. Perhaps I misunderstand that RFC1034 part. I found one comment on this particular point but no reactions: https://mailarchive.ietf.org/arch/msg/dnsop/tCZD120ehRkK52ikTWuZ-t5Tf2w "Authoritative-only server" definition: "ignores requests for recursion" might mislead into thinking the DNS request is not replied to, whereas the server is supposed to return either REFUSED or a referral. Maybe I'd say something like "ignores the RD bit being set to 1". "Slave server", "Master server": I'm surprised to read that current common usage has shifted to "secondary" and "primary" instead, but that is better judged by people working with authoritative servers (and not me). > Open resolver: A full-service resolver that accepts and processes > queries from any (or nearly any) stub resolver. [...] Perhaps not from any "stub resolver" but from any "client". *Who* asks really isn't the point. "Authoritative data" definition: there might be a mention of special cases added later or perhaps switch quotation to one from rfc4033#section-2 "Bailiwick" definition: I have (also) seen use like "in-bailiwick records" in the sense being in a subdomain. I can't really judge how common that usage is, but it has already been discussed wrt. this draft: https://mailarchive.ietf.org/arch/msg/dnsop/MyEdXXdUKKyTTfX3_4_7AnhE3Io My understanding of that thread is that the meaning was planned to be extended in the draft, but the current text seems still restricted to name servers. "NSEC3" definition, this is clearly a typo (missing "3"): > NSEC resource records require associated NSEC3PARAM resource records. I'm not really sure if a best-practice RFC is really allowed to "update" a standards-track RFC (2308), but I assume the authors and chairs know the process much better than me. (From my point of view it's OK.) --Vladimir _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
