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

["Joe Abley" <[e-mail]>]

Hi all!

On 26 May 2015, at 11:31, [e-mail] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations Working 
> Group of the IETF.
>
>      Title           : DNS Terminology
>      Authors         : Paul Hoffman
>                        Andrew Sullivan
>                        Kazunori Fujiwara
> 	Filename        : draft-ietf-dnsop-dns-terminology-02.txt
> 	Pages           : 23
> 	Date            : 2015-05-26

TL;DR: I found some text I think could be improved. I mainly haven't 
suggested changes to the text, since I have no way of knowing whether my 
prejudices are shared by anybody else, but I'm happy to suggest words 
for any or all of these if that seems helpful.

By section, then:

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.

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

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?

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.

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

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.

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 :-)

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.

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

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.

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.

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.

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).

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).

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.

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.

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?

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

"root zone": let's not use the word "origin" here; "apex" is better. 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.

"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.

"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.

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.

"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.

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.

"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).

"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).

"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.

"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.

"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.

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

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.

10. IANA Considerations

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


Joe