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

From: Tony Finch <[email-masked]>
Date: Fri, 5 Jun 2015 01:35:47 +0100

I like the formatting in the new draft, a great improvement! And thanks
for incorporating so many of my suggestions.

I mentioned an alphabetical index in my previous comment - I expect that
will be easier to add during final editing. I want to mention it again
because one of the main questions a reader will have is, does this
glossary define the term I am looking for? An alphabetical index would
help a lot.

I am disappointed by the discussion of this revision in two related ways.
Principally, I was hoping that the comments and questions that I sent to
the WG a month ago would be provocative - the arguments around this draft
have been interesting. But in the absence of any replies I was at least
hoping for point-by-point explanations from the document authors about why
they did not adopt particular suggestions. Two sides to an argument is a
lot more interesting than a huge pile of nitpicking :-) Perhaps we are all
suffering from re-reading fatigue...

The previous version had a note about recursion and iteration that I think
came from one of my earlier suggestions. I tried to flesh out that
suggestion in my message last month, but it wasn't adopted. I would really
like some critical discussion of the "more definitions" section of
http://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html

Three remaining complaints about the draft's contents:

"recursive mode" and "iterative mode". No-one uses those phrases.

The definition of "authoritative data" is still wrong.

I am still unhappy about the description of referrals. (I found them
surprisingly slippery when I was writing my suggestions.)

And I think delegation is more often a noun than a verb.

Nits:

Under SEP, "RRdata" should be "RDATA". Also, I think this sentence from
RFC 6781 section 3.2.3 is important because most key management tooling
implements it - "It is suggested that the SEP flag be set on keys that are
used as KSKs and not on keys that are used as ZSKs."

"child-centric resolver" - kill it.

Finally, I recently found Dyn's terminology list which is pretty nice,
though it include a lot of off-topic headwords. But it is probably worth a
look in case it has anything worth cribbing.
http://pages.dyn.com/rs/dyn/images/EB002_DNS-Terminology_v2.pdf

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Northerly 4 or 5, increasing 6 at times, but easterly 6 to gale 8
in far southeast. Rough, becoming moderate later except in far southeast.
Mainly fair. Good.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Jun 2015 09:50:51 -0700

Thanks again for the in-depth review. A few comments below.

> glossary define the term I am looking for? An alphabetical index would

The indexing tools for RFCs suck in many ways. We assume that if someone is looking at the RFC and wonders if a term in defined, they'll use the search function of their text editor or web browser.

> "recursive mode" and "iterative mode". No-one uses those phrases.

However, RFC 1034 uses those terms, and there was disagreement on what else to use. It would be great for the -bis of this document to have specific definitions for the terms people do use, but we doubt we can get this now, other than by through exhaustion.

> The definition of "authoritative data" is still wrong.

We have done the best we can with this, given that RFC 1034's definition is in dispute.

> surprisingly slippery when I was writing my suggestions.)

So are we. Again, we hope that we can get consensus for this and other slippery terms when we do the -bis.

> Under SEP, "RRdata" should be "RDATA".

Fully disagree. If we are quoting an RFC, we should not change the words, even the spelling.

> Also, I think this sentence from

That is good advice, but not really part of the definition of the definition of SEP, is it?

> "child-centric resolver" - kill it.

Done.

And, in case anyone else is reading this far: we still want more review, although the WG finishes today.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Fri, 12 Jun 2015 02:37:36 +0100

Paul Hoffman <[email-masked]> wrote:

Sorry for being slow to respond - other work intruded.

> The indexing tools for RFCs suck in many ways. We assume that if someone
> is looking at the RFC and wonders if a term in defined, they'll use the
> search function of their text editor or web browser.

Yes, totally. But I was thinking about people browsing without a specific
question, who want to get a quick idea of which terms are included or not.

> However, RFC 1034 uses those terms, and there was disagreement on what
> else to use. It would be great for the -bis of this document to have
> specific definitions for the terms people do use, but we doubt we can
> get this now, other than by through exhaustion.

Right, but my point was that the RFC 1034 terminology is not used any
more, so people aren't going to be using the search function of their text
editor to look for them.

Regarding specific definitions, what about my suggestions under "more
definitions" at
http://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html

> We have done the best we can with this, given that RFC 1034's definition

I thought we had cleared it up. Why not adopt my corrected definition at
http://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html ?

> slippery terms when we do the -bis.

Grumble. If we just punt this down the field we'll end up with an
annoying and slightly-wrong RFC which is too boring to fix.

I suggested a clearer, less confused definition, based on quotes from
existing RFCs.

> words, even the spelling.

There are plenty of other quotes in your draft that have been fixed up so
that they make more sense.

> > Also, I think this sentence from RFC 6781 section 3.2.3 is important
> > because most key management tooling implements it - "It is suggested
> > that the SEP flag be set on keys that are used as KSKs and not on keys
> > that are used as ZSKs."
>

I think it's the whole point. Abstract of RFC 3757:

   With the Delegation Signer (DS) resource record (RR), the concept of
   a public key acting as a secure entry point (SEP) has been
   introduced.  During exchanges of public keys with the parent there is
   a need to differentiate SEP keys from other public keys in the Domain
   Name System KEY (DNSKEY) resource record set.

i.e. the SEP bit was invented to distinguish KSK and ZSK.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire: Southerly or southwesterly 4 or 5, becoming variable 3
or 4. Slight or moderate. Rain or drizzle at times. Good, occasionally poor.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 13 Jun 2015 11:00:37 -0700

> Sorry for being slow to respond - other work intruded.

No problem. We're still hoping to get as much substantiative review as we can before the chairs send this off to IETF Last Call.

> question, who want to get a quick idea of which terms are included or not.

There is no good way to do that in the current, or future, RFC format without splitting each term into its own sub-section. That could work, but at the expense of a lot more vertical space due to the dozens of extra headers. Our current format (with your earlier suggestion of better indenting) allows skimming fairly well, I think.

> http://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html

Some of those definitions were speculative, and I think it is better to defer them. However, I can probably see adding the first two, which are the ones most strongly backed-up by the RFCs:

   Recursive query -- A query with the Recursion Desired bit set in
   the header. (RD=1) (See RFC 1035 section 4.1.1) If recursive
   service is available and requested via the RD bit in the query, the
   server uses its resolver to answer the query. (RFC 1034 section 4.3.2)

   Non-recursive query -- A query with the Recursion Desired bit unset
   in the header. (RD=0) A server can answer non-recursive queries
   using only local information: the response contains an error, the
   answer, or a referral to some other server "closer" to the answer.
   (RFC 1034 section 4.3.1)

Does anyone object to us adding those two?

> http://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html ?

There was disagreement on the list about your statement:

In RFC 1034, zone cuts are clearly defined to occur between labels, above
each delegation point, so it is correct to define authoritative data as
being above the zone cut, and this unambiguously excludes delegation NS
RRsets.

This topic *should* be revisited in the -bis document, but probably with a few paragraphs of "some people interpreted RFC 1034 as X, while others interpreted it as Y or Z, and here are side-effects of those different interpretations".

> annoying and slightly-wrong RFC which is too boring to fix.

The authors do not find this boring, and apparently neither do you. :-) The real question is whether or not we can come up with -bis wording about different interpretations that is helpful to the reader (whom we don't know, and who might be advanced or novice).

> I suggested a clearer, less confused definition, based on quotes from

Without more agreement from the WG, we can't go with them. We don't have that yet.

> that they make more sense.

This one makes sense in both spellings. The other fixups are (hopefully) only for grammatical or contextual sense. I apologize for being too strong above in my disagreement reasoning.

> i.e. the SEP bit was invented to distinguish KSK and ZSK.

Good point. I took the "it is suggested" in the RFC as really being a suggestion, but it is more "it will only make sense to others if". We will add that extension to the quotation from RFC 6781.

--Paul Hoffman

---

From: John Dickinson <[email-masked]>
Date: Sun, 14 Jun 2015 18:05:41 +0100

> We have done the best we can with this, given that RFC 1034's definition is in dispute.
Typo: I think you mean parent-side not parent-size.

A few other things that have confused me in the past:

In-bailiwick: Informal discussion (in the bar at IETF meetings) suggests 
to me that most people are confused by this term. To me and about 50% of 
the people I have asked it means "Data for which the server is 
authoritative and *not* data for which the server is an authoritative 
ancestor". To me that is more in keeping with the dictionary definition 
of bailiwick. However, at least 50% of people in the bar felt 
differently. IMHO I think this is a term that should be deprecated and 
replaced by "in zone" or "in domain".

Some RR types are described as "class independent" (See RFC4034) I am 
not sure of the exact meaning of this (despite Roy's attempts to educate 
me) and would like to see it defined here.

Also mention of A-Label, U-Label any other IDN terminology might be useful.

regards
John

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 14 Jun 2015 11:24:00 -0700

> Typo: I think you mean parent-side not parent-size.

"No, I'm sorry, you can't have a big NS record like that until you're older and have had kids of your own."

Fixed.

> In-bailiwick: Informal discussion (in the bar at IETF meetings) suggests to me that most people are confused by this term. To me and about 50% of the people I have asked it means "Data for which the server is authoritative and *not* data for which the server is an authoritative ancestor". To me that is more in keeping with the dictionary definition of bailiwick. However, at least 50% of people in the bar felt differently. IMHO I think this is a term that should be deprecated and replaced by "in zone" or "in domain".

We don't get to deprecate commonly-used terms in this document, unfortunately. In the -bis document, we might make a run at that, or at least in saying "if this term confuses you, use X instead". 

> Some RR types are described as "class independent" (See RFC4034) I am not sure of the exact meaning of this (despite Roy's attempts to educate me) and would like to see it defined here.

Good call. Proposed addition:

Class independent: A resource record type whose syntax and semantics are the same for every DNS class. A resource record type that is not class independent has different meanings depending on the DNS class of the record, or the meaning is undefined for classes other than IN.

> Also mention of A-Label, U-Label any other IDN terminology might be useful.

Good call. "A-label" and "U-label" are sometimes bandied about without reference to IDNA, so it would be good to at least add them to the "IDN" entry in this document.

--Paul Hoffman

---

From: "Joe Abley" <[email-masked]>
Date: Mon, 15 Jun 2015 12:25:07 -0400

Hi all!

On 26 May 2015, at 11:31, [email-masked] 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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Jun 2015 11:49:47 -0700

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 <[email-masked]> 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.

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

Done.

Many, many thanks!

--Paul Hoffman

---

From: "Joe Abley" <[email-masked]>
Date: Mon, 15 Jun 2015 15:15:21 -0400

Hi Paul,

On 15 Jun 2015, at 14:49, Paul Hoffman wrote:

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

Quoted entirely to confirm that I have read them. :-)

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

Well, there's a whole section on registration that also makes sole 
reference to those RFCs, no? If we're at least tipping the hat towards 
the intersection between RRR and DNS, they seem useful (and easy) to 
include.

> is not a can of worms we should open.

I was sure until you asked that question. I can do some more research 
and justify my opinion or change my mind, but it might be quicker just 
to wait for Mark Andrews to wake up. :-)

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

RFC 2308 section 3 says exactly:

    Name servers authoritative for a zone MUST include the SOA record of
    the zone in the authority section of the response when reporting an
    NXDOMAIN or indicating that no data of the requested type exists.
    This is required so that the response may be cached.  The TTL of 
this
    record is set from the minimum of the MINIMUM field of the SOA 
record
    and the TTL of the SOA itself, and indicates how long a resolver may
    cache the negative answer.

So I don't think I'm asking for a change to 2308, rather that this 
document not contradict 2308.

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

But Paul, I am the voice of the people! The people must be heard!

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

We ought to note somewhere that servers can easily both slaves and 
masters for the same zone, simultaneously. I often refer to such servers 
as "distribution masters", but only really as a convenience when 
describing a particular platform where the zone distribution graph is 
simple.

In any case, in both cases in this doc they are authoritative servers 
for a set of zones, and do not appear in those zones' NS RRSets (either 
at the zone apex or in the parent). It seems troublesome to me that it's 
trivial to find a production server that could fit either or both of 
those definitions.

But perhaps this is all fine, as you say, and something to be addressed 
in -bis.

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

OK. I guess the main reason for the question was rhetorical; if it's not 
obvious what it means, perhaps "ostensive" could be replaced with a 
merely $1 word in the interests of clarity.

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

I will see what I can do to propose something, then.

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

Perhaps we could agree on some text that confirms that they are 
functionally similar, whilst having quite different approaches to 
achieving that functionality? That seems like it would be better than 
declaring them to be "quite different".

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Jun 2015 14:35:50 -0700

On Jun 15, 2015, at 12:15 PM, Joe Abley <[email-masked]> wrote:
> Well, there's a whole section on registration that also makes sole reference to those RFCs, no? If we're at least tipping the hat towards the intersection between RRR and DNS, they seem useful (and easy) to include.

Judgement call, and you haven't provided text, so let's leave them out unless others have seen them in the wild and care.

>   This is required so that the response may be cached.  The TTL of this
>   record is set from the minimum of the MINIMUM field of the SOA record
> So I don't think I'm asking for a change to 2308, rather that this document not contradict 2308.

The last paragraph of Section 4 of RFC 2308 says:
   The remaining of the current meanings, of being the TTL to be used
   for negative responses, is the new defined meaning of the SOA minimum
   field.
We used that for the direct quotation in the draft. Again, if you want to update that RFC to clarify it, please do so on a different thread.

> We ought to note somewhere that servers can easily both slaves and masters for the same zone, simultaneously. I often refer to such servers as "distribution masters", but only really as a convenience when describing a particular platform where the zone distribution graph is simple.
> 
> In any case, in both cases in this doc they are authoritative servers for a set of zones, and do not appear in those zones' NS RRSets (either at the zone apex or in the parent). It seems troublesome to me that it's trivial to find a production server that could fit either or both of those definitions.
> 
> But perhaps this is all fine, as you say, and something to be addressed in -bis.

I cannot imagine how we can simply say "servers can easily both slaves and masters for the same zone, simultaneously" without a lot more explanation and some over-riding of earlier RFCs. But this is certainly one of the topics of confusion that should be addressed.

> Perhaps we could agree on some text that confirms that they are functionally similar, whilst having quite different approaches to achieving that functionality? That seems like it would be better than declaring them to be "quite different".

The current text says:
NSEC3:
: The NSEC3 resource record is quite different than the NSEC resource record.
Like the NSEC record, the NSEC3 record also provides authenticated denial of existence; however,
NSEC3 records mitigates against zone enumeration and support Opt-Out.
NSEC3 resource records are defined in {{RFC5155}}.

I think the second sentence says what you want, and the first sentence is factually correct in the that the records themselves really are different.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Tue, 16 Jun 2015 10:56:37 +0100

Paul Hoffman <[email-masked]> wrote:

> Some of those definitions were speculative, and I think it is better to
> defer them.

All of the definitions were based on quotes from RFCs, apart from
"iterative query" (which has an illustrative citation) and "resolution"
which is pervasive but never defined because it has an obvious grammatical
link to "resolver".

> being above the zone cut, and this unambiguously excludes delegation NS

Do you have a link? I didn't see any replies to my message.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger: Variable 3 or 4, becoming southwest 4
or 5, occasionally 6 later. Moderate in Forties, otherwise slight or moderate.
Occasional rain. Good, occasionally poor later.

---

From: John Dickinson <[email-masked]>
Date: Tue, 16 Jun 2015 11:33:10 +0100

> I think the second sentence says what you want, and the first sentence is factually correct in the that the records themselves really are different.
I dislike the current text especially "is quite different than the NSEC 
resource record"

NSEC3: An alternative to NSEC. The NSEC3 RR allows verifiable denial of 
existence. However, is allows the zone signer to "Opt-out" and not 
create an NSEC3 RR at insecure (no DS) delegations. This has the 
advantage of allowing the zone size to scale gracefully with the 
increase in signed delegations. This is especially useful for operators 
of large delegation centric zones. In addition, NSEC3 uses hashed owner 
names in order to make zone enumeration approximately as hard as it 
would be in an unsigned zone.

This make me think that the document should define owner name and 
possibly the NSEC3PARAM RR.

regards
John

---

From: Tony Finch <[email-masked]>
Date: Tue, 16 Jun 2015 11:50:20 +0100

> is not a can of worms we should open.

Absolutely. RFC 1035 section 4.1.1:

RCODE           Response code - this 4 bit field is set as part of
                responses.  The values have the following
                interpretation:

                3               Name Error - Meaningful only for
                                responses from an authoritative name
                                server, this code signifies that the
                                domain name referenced in the query does
                                not exist.

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

I think the definitions in the current draft will cause confusion rather
than clearing it up, and fixing them in -bis will be too late, considering
how non-IETF people treat RFCs like stone tablets handed down on a
mountain.

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

"authoritative-only" appears in 7 RFCs. There's a reasonable definition in
RFC 4697 section 2.4

   [...]
   "authoritative-only" name servers, which only serve authoritative
   data and ignore requests for recursion.  Such an entity will not
   normally generate any queries of its own.  Instead it answers non-
   recursive queries from iterative resolvers looking for information in
   zones it serves.

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

I agree with Joe. Even if the RFC 1034 definition is problematic for
implementers, it's perfectly good for getting the point across to
hostmasters.

   Wildcard: Special treatment is given to RRs with
     owner names starting with the label "*".  Such RRs are called
     wildcards. Wildcard RRs can be thought of as instructions for
     synthesizing RRs. (quoted from [RFC1034] section 4.3.3) For an
     extended discussion of wildcards see [RFC4592].

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

I agree with Joe, I think the first sentence of the NSEC3 definition
doesn't actually add any information to what is covered by the rest of the
definition.

Possibly worth adding:

   [RFC7129] provides additional background commentary and some
   context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide
   authenticated denial-of-existence responses.

(quoted from its abstract)

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

   Opt-out:  The Opt-Out Flag indicates whether this NSEC3 RR may cover
      unsigned delegations.  (Quoted from [RFC5155], section 3.1.2.1.)

      Opt-out tackles the high costs of securing a delegation to an
      insecure zone.  When using Opt-Out, names that are an insecure
      delegation (and empty non-terminals that are only derived from
      insecure delegations) don't require an NSEC3 record or its
      corresponding RRSIG recors. Opt-Out NSEC3 records are not able to
      prove or deny the existence of the insecure delegations. (Adapted
      from [RFC7129] section 5.1)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher: Northwest 5 or 6, backing west 4 or 5, backing southwest 5 or 6 later.
Moderate. Rain later. Good, occasionally moderate later.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 17 Jun 2015 17:03:11 +0100

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

To the extent it doesn't, such usage is not in line with STD 13.
NXDOMAIN is the neologism here.  RFC 1035 names RCODE 3 as "Name
Error".

> "Apex" is defined two terms later".

I think Joe is right that people usually use "apex" to mean "origin"
in the way the document defines it.  I think we are attempting to
reinforce a distinction that used to be in the RFCs but that seems to
have blurred over time: the difference between the graph-theoretic
space of the DNS and the implementation.  It might be worth adding a
sentence, however, that notes the way the terms are often used
interchangably.

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

If I recally correctly, it was excluded on socio-political grounds.

A
-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Jun 2015 15:41:01 -0700

> NXDOMAIN is the neologism here.  RFC 1035 names RCODE 3 as "Name

I'll add a note about that.

> sentence, however, that notes the way the terms are often used

I'll add a note to that effect to each of the definitions, and move the two definitions to be adjacent.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Jun 2015 16:38:34 -0700

On Jun 16, 2015, at 3:33 AM, John Dickinson <[email-masked]> wrote:
> I dislike the current text especially "is quite different than the NSEC resource record"

OK, I'm hearing that we should remove that phrase. But, as someone who thought that the NSEC3 record would look like the NSEC record because versioning, I assure you that they really are quite different. :-)

> 
> NSEC3: An alternative to NSEC. The NSEC3 RR allows verifiable denial of existence. However, is allows the zone signer to "Opt-out" and not create an NSEC3 RR at insecure (no DS) delegations. This has the advantage of allowing the zone size to scale gracefully with the increase in signed delegations. This is especially useful for operators of large delegation centric zones. In addition, NSEC3 uses hashed owner names in order to make zone enumeration approximately as hard as it would be in an unsigned zone.

I'm hesitant to list "advantages", particularly ones that are only true for some kinds of zones.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Jun 2015 16:43:39 -0700

>                                domain name referenced in the query does

Got it. Added to the current meager text for NXDOMAIN.

> how non-IETF people treat RFCs like stone tablets handed down on a

The latter is a good point. Because we are pretty sure there will be a -bis, and that it will have new material not just corrections, we should say so right at the top of this document.

>   recursive queries from iterative resolvers looking for information in

That sounds good. Added.

>     extended discussion of wildcards see [RFC4592].

OK, we can add this, at the risk of confusing folks more.

> doesn't actually add any information to what is covered by the rest of the

Noted; removed.

>   authenticated denial-of-existence responses.

Good addition, yes.

>      from [RFC7129] section 5.1)

That seems like a good addition as well. Thanks!

--Paul Hoffman