On Aug 29, 2018, at 8:10 AM, Eric Rescorla <e...@rtfm.com> wrote: > 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.
If you are referring to draft-ietf-ipsecme-split-dns, the "private DNS domains" in that document have authoritative servers that only reply on one side of the split. > 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? >From each other. Will fix. > 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. This was discussed at length in the WG and this wording was chosen. All options here kinda suck, but the example makes the intended meaning clear. > 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. Good catch, will add. > > > 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. ....or make it worse. This is a recurring topic in DNSOP, and one can hope for a document that describes this in the future. > 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? Yes. > 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? That's not clear from the text. I'm going to propose to the other authors that we simply elide this, particularly because "recursive resolver" is defined immediately after this text. > 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? In most people's estimation, yes. But they tried diligently. > 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? That list is incomplete: (3) give an authoritative answer > Are both of these termed "recursive resolvers"? Yes for #1 and #2, but not for #3. > 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? A hidden master might be used by a local recursive resolver; that is, it could be hidden from the public but not from the local network. > 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. It could in fact make things worse because the text in 4.2.1 is about when you don't have glue, not when you have it. > 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. Good catch, will do. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
