Hi all!
On 26 May 2015, at 11:31, internet-dra...@ietf.org 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
