Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-02.txt

[Paul Hoffman <[e-mail]>]

This message, and some of the earlier in this discussion, says in essence "RFC Foo says the definition of X is Y, but that's wrong". At the beginning of this process, we decided that we should use definitions from the RFCs where possible instead of making up our own. That was a good way to get this document out in a reasonable amount of time.

The authors of the WG document have also floated the idea that there should be a -bis RFC to come later to deal with the important terms for which we cannot get consensus. At this point, I think we should also assume that the -bis document will formally update a bunch of RFCs and say "RFC Foo says the definition of X is Y, but this document updates RFC Foo to say that the definition of X is Z".

That may be a messy process, but it feels like a lot of people on this list agree on some of the updated definitions.

On to Joe's message...

On Jun 15, 2015, at 9:25 AM, Joe Abley <[e-mail]> wrote:
> 2. Names
> 
> "Domain name" receives some attention, but "domain" does not. I find when teaching DNS that there is constant confusion about how "domain" and "zone" are different; the way I explain it is that "domain" is a namespace abstraction, caring nothing about zone cuts, provisioning and resource records; "zone" is the provisioning view, where you need to know about resource records and zone cuts. I think it would be good to have a definition for "domain" in here.

Without specific wording from an RFC, it would be pretty dangerous for us to define "domain" outside of "domain name". We should defer this (and "zone") to the -bis.

> I think that "superordinate" and "subordinate" might be worth mentioning here, with reference to their definitions in EPP.

These seem limited to the EPP RFCs only, so probably not worth bringing up here.

> 3. DNS Header and Response Codes
> 
> The text suggests that RDATA is sometimes called RRdata. I have never heard that before. Is that common enough usage to bother including?

Nope, and the earlier thread with Tony Finch where I said it was used was incorrect. I have removed this.

> I appreciate why FORMERR, SERVFAIL and NXDOMAIN are summarised in a single paragraph, by reference to the IANA registry, but it feels like they would be easier to find if they were presented in hangText sections like the others.

The WG earlier wanted us to just point to the IANA registry. We can go back to having those three defined in this doc if the WG wants.

> "Name Error" as a synonym for NXDOMAIN seems like it is worth including, somewhere.

Are you sure that "name error" always refers to NXDOMAIN? If not, this is not a can of worms we should open.

> I'm not sure why "Zone transfer" is included in this section. I think the definition presented is fine, though. Perhaps it would feel more at home in section 5.

Good catch; fixed.

> 4. Resource Records
> 
> The negative cache TTL is alluded to under SOA field names, but not under TTL. The former also claims a definition of MINIMUM of "the TTL to be used for negative responses", when in fact the TTL to be used for negative responses is the MINIMUM value or the TTL of the SOA RR returned with the negative response, whichever is the smaller. This fact may be familiar to Secure64 and Afilias people :-)

If you want to update RFC 2308, you need to do so separately from this document. (Note to Mark and Joe: if you want to argue about this, please change the name of the thread, since we are not going to make that change in this document.)

> 5. DNS Servers
> 
> There are documented uses of "iterative mode resolvers" to mean exactly "recursive mode resolvers" as defined in this section. I had only ever heard the phrase as a knee-jerk objection to the observation that "recursive servers" don't recurse, they iterate. I mention this just in case "iterative mode" as described here does not have a posse.

This has been deferred to the -bis document because of disagreement.

> There is no mention of "authority-only servers", which I find to be in common usage.

That term appears in exactly one RFC, of which you are co-author.

> Every workshop or tutorial on the DNS I have heard or helped present in the last 15 years or so has characterised "secondary server" as an archaic phrase, and has recommended "slave server" instead. So the assertion that the opposite is true in the "secondary server" section is jarring, for me. What is the basis for saying that common usage has shifted to calling this "secondary"? Ditto-ish for primary vs. master.

Earlier traffic on this list.

> I think under "primary master" it might be worthwhile to point out that the only DNS protocol element remaining that cares about the MNAME is DNS UPDATE. It's meaning in the context of zone distribution is archaic.

Good addition.

> I wonder what the real difference is between "stealth server" and "hidden master". If they are synonyms (I think they are) it might be as well to say so; as it stands they both have the appearance of having different definitions.

The two definitions from the RFCs do not make them seem like synonyms to me. In one, it is a slave, and in the other it is a master.

> I think "open resolver" and "public resolver" are subtly different; the former is usually unintentional and hence can be seen as a configuration error (e.g. prompting RFC 5358) whereas the latter seems more like a conscious choice (e.g. Google public DNS).

Good differentiation; added.

> I wonder whether there's any use in including a reference to anycast in this section, here. Anycast is arguably more commonly found in conversations about the DNS than any other; there's also a reasonable reference (RFC 4786).

Yep, that seems like a good addition, if for no other reason than to get people who want to "anycast DNS" to the right RFC.

> 6. Zones
> 
> The definitions of child and parent here would benefit greatly from judicious use of the word "zone" rather than "domain". A child domain is a subset of a parent domain, whereas a child zone is not a subset of a parent zone. The distinction is important.

...and yet those are the words in the RFCs from which we are quoting.

> In "origin", (a), the usual word for this in my experience is "apex". It would seem as well to mention apex here. If we're able to provide value judgements, we might recommend apex over this use of origin.

"Apex" is defined two terms later".

> In zone cut, I'm not sure what "barely an ostensive definition" is intended to convey. Are you saying that this is not a definition that is made by way of demonstration, or that it is, or that it should be, or something else?

The former.

> "in-bailiwick": s/the name of which/whose name/ feels like it requires slightly fewer mental gymnastics to parse, at the risk of anthropomorphising.

It sounds cleaner, yes.

> "root zone": let's not use the word "origin" here; "apex" is better.

Given the RFC 2181 definition of "origin", I agree.

> If zones have names, perhaps we could just describe its name as being a single, zero-length label and avoid either of the other terms. Since various definitions from 1034/1035 refer to nodes in the namespace tree, perhaps we could tie that in, e.g. by describing it as the zone whose apex node is also the apex of the entire namespace tree.

This seems over-wroght compared to what we have now.

> "Wildcard" does not actually have a definition listed; just a note that earlier attempts at providing a definition have been problematic. While the text here seems entirely agreeable, it seems like it would be nice to present at least a cursory definition in this document, even if it needs provisos and references.

Maybe for the -bis.

> "Fast flux DNS": the use of "domain" and "bound" in this definition seems woolly. Are we talking about an A or AAAA RRSet each containing multiple RRs and a low TTL? Are we talking about delegations to nameservers whose A/AAAA RRSets have that character? The sentence "It is often to deliver malware" seems lonely and hard to parse (what is "it"?) "Because the addresses change so rapidly..." what addresses are changing? I think this definition could do with a re-write. I wouldn't object if it was dropped entirely actually, since unlike the majority of other terms that are called out, this one has precious little to do with the protocol.

There was agreement to add it, and we have one RFC from which to quote.

> 7. Registration Model
> 
> This whole section talks about "registration of names in a zone", which I think encourages a kind of conflation between database and DNS operations that keeps cropping up and always causes headaches.
> 
> The RRR (or RR or RRRR, with a reseller layer, even) structure exists to maintain uniqueness in a database. Information present in that database is used to publish one or more zones in the DNS, but the interactions between the Rs are better characterised in database terms than DNS terms.

Without specific proposed text, we can't fix this in this round.

> "WHOIS" is defined in this section by reference to 3912, which makes it a protocol. I applaud this definition (although I object slightly to the capitalisation chosen, as if it's a mnemonic), but I'll note that these days there's a very small number of us who are clapping. "WHOIS" to the rest of the room is the data maintained by the RR/RRR/RRRR process, which is sometimes retrieved using EPP, more widely by HTTP and only by 43/tcp by crotchety old bastards who detest the youth of today with their snapchats and their bookface, DAMN THEM ALL, GET OFF MY LAWN.

The definition is still valid today, but barely. The -bis will probably talk more about the protocol, the new protocol, the data, and so on.

> 8. General DNSSEC
> 
> DNSSEC-aware and DNSSEC-unaware: the phrase "In specific" is missing a noun. Perhaps s/\.  In specific,/, including/ -e s/ are all defined\.//, if you sed what I mean.

Unwrapped.

> "Signed zone": it feels like there ought to be some way to link opt-out sections to NSEC3, or otherwise strengthen the meaning of relevant in "relevant RRSets in the zone are signed".
> 
> "Unsigned zone" makes mention of NSEC but not NSEC3 (which is understandable, given the source of the quoted text).

It's true that quoting from 403x about NSEC is confusing. I'll add text to "NSEC3" with the note from RFC 6840 saying that 5155 is part of the DNSSEC document series, and add 5155 to the list of documents at the top of this section.

> "NSEC3": whether not NSEC3 is "quite different" from NSEC depends on your context. Functionally, in the narrow sense of "allows verifiable denial of existence", they are identical. I think it would be clearer to focus on their functional similarities, and point out the additional features of NSEC3 (opt-out and making zone enumeration harder), observing that any particular signed zone must use exactly one of these, not both (so, they are alternatives, and one of them is required).

Disagree. Even in the "allows verifiable denial of existence", they are quite different in that the processing needed is very different. The "fundamental similarities" are only in what is achieve, not in the way of achieving it.

> "Opt-out": It would be helpful I think to include a sentence or two that illustrates the point of opt-out, e.g. that in a delegation-centric zone with relatively few secure delegations, use of opt-out can reduce the overhead of DNSSEC on zone size.

I searched for supporting material in RFC 5155 that could explain why to use opt-out in words that would make sense in this document; I failed. If you find some, that would be great.

> "Key signing key (KSK)": I have noticed confusion about the KSK can often be avoided by confirming that it's a key pair, not a single key. This helps people understand why if we're storing it in a safe with armed guards, we're also publishing it in the DNS.

I have found that either people understand public/private keys implicitly, or trying to describe it in a sentence doesn't help.

> "Zone signing key (ZSK)": I don't think it's uncommon for signers to sign the apex DNSKEY RRSet with the ZSK as well as the KSK, regardless of how useful anybody imagines that to be. It doesn't feel right to say definitively that the ZSK doesn't sign the DNSKEY RRSet when we can see it happening.

A note to that effect would be good.

> "Secure Entry Point (SEP)": I really don't like "RRdata". :-)

Nuked.

> 9. DNSSEC States
> 
> Given that the definitions of the states are different, I think this would be a great opportunity to choose one over another. Merely pointing out that there are two conflicting definitions without giving any guidance as to which is better seems less than ideal.

See the note at the top of this message.

> 
> 10. IANA Considerations
> 
> RFC 5226 recommends the sentence "This document has no IANA actions".

Done.

Many, many thanks!

--Paul Hoffman