Eric Rescorla has entered the following ballot position for draft-ietf-dnsop-terminology-bis-13: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3131 IMPORTANT S 6. > [RFC5358] > > Split DNS: The terms "split DNS" and "split-horizon DNS" have long > been used in the DNS community without formal definition. In > general, they refer to situations in which DNS servers that are > authoritative for a particular set of domains provide partly or What about ones that aren't authoritative. Apparently this exists in VPN settings. COMMENTS S 2. > learn the DNS by reading this document. > > 2. Names > > Naming system: A naming system associates names with data. Naming > systems have many significant facets that help differentiate them. >From each other? Or from other systems that aren't naming systems? S 2. > The need for the term "fully qualified domain name" comes from the > existence of partially qualified domain names, which are names > where one or more of the earliest labels in the ordered list are > omitted (for example, a name of "www" derived from > "www.example.net"). Such relative names are understood only by > context. I think we agree here but I had to read it several times, because "earliest" in the list is not earliest in the presentation format. Perhaps you should say "less specific" or "closest to the root" are omitted instead. S 2. > Subdomain: "A domain is a subdomain of another domain if it is > contained within that domain. This relationship can be tested by > seeing if the subdomain's name ends with the containing domain's > name." (Quoted from [RFC1034], Section 3.1). For example, in the > host name "nnn.mmm.example.com", both "mmm.example.com" and > "nnn.mmm.example.com" are subdomains of "example.com". It might be worth noting that whole component matches are required here. S 2. > > Canonical name: A CNAME resource record "identifies its owner name > as an alias, and specifies the corresponding canonical name in the > RDATA section of the RR." (Quoted from [RFC1034], Section 3.6.2) > This usage of the word "canonical" is related to the mathematical > concept of "canonical form". This paragraph didn't seem very clear. Perhaps an explanatory sentence or two about what a CNAME is for woudl help. S 4. > the name originally queried, or a name received in a CNAME > chain response. > > * QNAME (final): The name actually resolved, which is either the > name actually queried or else the last name in a CNAME chain > response. So to be clear, the QNAME (final) is always one of the QNAME (effective) sets? S 6. > name server side (which is what answers the query) and a resolver > side (which performs the resolution function). Systems operating > in this mode are commonly called "recursive servers". Sometimes > they are called "recursive resolvers". While strictly the > difference between these is that one of them sends queries to > another recursive server and the other does not, in practice it is Which one does which? S 6. > general, a recursive resolver is expected to cache the answers it > receives (which would make it a full-service resolver), but some > recursive resolvers might not cache. > > [RFC4697] tried to differentiate between a recursive resolver and > an iterative resolver. Did it fail? S 6. > client to another server and lets the client pursue the query > there. (See Section 2.3 of [RFC1034].) > > In iterative resolution, the client repeatedly makes non-recursive > queries and follows referrals and/or aliases. The iterative > resolution algorithm is described in Section 5.3.3 of [RFC1034]. This may just be my confusion, but it seems like this is still a bit hard to follow. Say that I send a query to a server X with the recursive bit set, and that server in fact decides to give me a full answer (as opposed to failing). At that point it could either: (1) send the query to another server with the recursive bit set (2) resolve the query entirely itself using iterative queries Am I right so far? Are both of these termed "recursive resolvers"? S 6. > Internet; it is not listed in the NS RRset." (Quoted from > [RFC6781], Section 3.4.3). An earlier RFC, [RFC4641], said that > the hidden master's name "appears in the SOA RRs MNAME field", > although in some setups, the name does not appear at all in the > public DNS. A hidden master can also be a secondary server for > the zone itself. I'm not understanding this last sentence. Can you elaborate? S 7. > if the name server's name is 'below' the cut, and are only used as > part of a referral response." Without glue "we could be faced > with the situation where the NS RRs tell us that in order to learn > a name server's address, we should contact the server using the > address we wish to learn." (Definition from [RFC1034], > Section 4.2.1) An example might help here. S 10. > Policy (if such exists), and it states how the management of a > given zone implements procedures and controls at a high level." > (Quoted from [RFC6841], Section 2) > > Hardware security module (HSM): A specialized piece of hardware that > is used to create keys for signatures and to sign messages. In It's probably worth mentioning that the idea here is that it doesn't disclose the keys, as opposed to just creating them. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
