Subject: Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 01 Jul 2018 15:57:23 -0700

On 26 Jun 2018, at 10:09, Vladimír Čunát wrote:

> Greetings!
>
> I really like the draft, and I'm sorry to be so late. 

This is not late, especially if you really like the draft. :-)

> I see one minor
> issue just below and then a few nitpicks that I don't feel strongly 
> about.

I'm marking these in the GitHub repo.

>
>
>> NXDOMAIN:
>>     "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." (Quoted from [RFC1035], Section 4.1.1.)
>> [RFC2308] established NXDOMAIN as a synonym for Name Error.
>
> I dislike keeping this formulation; it might confuse people.  It 
> seems
> to imply that NXDOMAIN from a resolver isn't "meaningful", and
> that's clearly not true, at least not nowadays.  (I develop a 
> resolver.)

The quoted definition makes sense without the "Meaningful only for 
responses from an authoritative name server" phrase, so we can remove it 
and still have it be useful.

> "Resolver" definition: I don't think the word really implies it runs 
> on
> the same machine as the program asking it.  In particular, the 
> purpose
> of stub resolvers is to ask a recursive *resolver* that is typically 
> on
> another machine.  Perhaps I misunderstand that RFC1034 part.  I 
> found
> one comment on this particular point but no reactions:
> https://mailarchive.ietf.org/arch/msg/dnsop/tCZD120ehRkK52ikTWuZ-t5Tf2w

We did indeed miss this. In staring at that longer, I agree that the 
quote from 1034 is not true for the current understanding of a resolver. 
We can remove it.

> "Authoritative-only server" definition: "ignores requests for 
> recursion"
> might mislead into thinking the DNS request is not replied to, whereas 
> the
> server is supposed to return either REFUSED or a referral.
> Maybe I'd say something like "ignores the RD bit being set to 1".

Well, the authoritative server doesn't ignore the RD bit, either: it 
just doesn't do the recursion that was asked for. Thus you want the 
terminology document to (a) update an RFC that (b) is a BCP that (c) was 
co-written by my boss. Trifecta!

Instead of changing the wording of the BCP, we can instead add "In this 
case 'ignores requests for recursion' means 'responds to requests for 
recursion with responses indicating that recursion was not performed'". 
Does this work for you?

> "Slave server", "Master server": I'm surprised to read that current
> common usage has shifted to "secondary" and "primary" instead, but 
> that
> is better judged by people working with authoritative servers (and not 
> me).
>
>
>> Open resolver: A full-service resolver that accepts and processes
>> queries from any (or nearly any) stub resolver. [...]
>
> Perhaps not from any "stub resolver" but from any "client".  *Who* 
> asks
> really isn't the point.

Very good point! In fact, many open resolvers allow forwarding from 
other recursive resolvers.

> "Authoritative data" definition: there might be a mention of special
> cases added later or perhaps switch quotation to one from 
> rfc4033#section-2

Yes; will add pointer there.

> "Bailiwick" definition: I have (also) seen use like "in-bailiwick
> records" in the sense being in a subdomain.  I can't really judge how
> common that usage is, but it has already been discussed wrt. this 
> draft:
> https://mailarchive.ietf.org/arch/msg/dnsop/MyEdXXdUKKyTTfX3_4_7AnhE3Io 
> My understanding of that thread is that the meaning was planned to be 
> extended
> in the draft, but the current text seems still restricted to name 
> servers.

We opened a discussion for bailiwick and incorporated what we could from 
that discussion.

> "NSEC3" definition, this is clearly a typo (missing "3"):
>
>> NSEC resource records require associated NSEC3PARAM resource records.

Good catch!

> I'm not really sure if a best-practice RFC is really allowed to 
> "update"
> a standards-track RFC (2308), but I assume the authors and chairs know
> the process much better than me.  (From my point of view it's OK.)

It is indeed OK. BCPs are considered "standards track" themselves.

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 01 Jul 2018 16:03:51 -0700

On 27 Jun 2018, at 12:56, Dick Franks wrote:

> The document appears to be in good shape.
>
> However, I have some difficulty with the wording of these two 
> paragraphs in
> section 2.
>
>       The basic wire format for names in the global DNS is a list of
>       labels ordered by decreasing distance from the root, with the 
> root
>       label last.  Each label is preceded by a length octet.  
> [RFC1035]
>       also defines a compression scheme that modifies this format.
>
>       The presentation format for names in the global DNS is a list of
>       labels ordered by decreasing distance from the root, encoded as
>       ASCII, with a "." character between each label.  In presentation
>       format, a fully-qualified domain name includes the root label 
> and
>       the associated separator dot.  For example, in presentation
>       format, a fully-qualified domain name with two non-root labels 
> is
>       always shown as "example.tld." instead of "example.tld".
>       [RFC1035] defines a method for showing octets that do not 
> display
>       in ASCII.
>
> The character encoding of "presentation format" depends on the context 
> in
> which it is used. The protocol mandates ASCII encoding of labels on 
> the
> wire.
> It cannot say anything about the internal character encoding 
> conventions of
> application programs or related master files, which can, in the 
> general
> case,
> be different.

Well, RFC 1035 *does* say that it is in ASCII, whether we like that or 
not. An application could choose to encode the presentation format using 
a different encoding, but that's outside the scope of the protocol.

--Paul Hoffman

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 2 Jul 2018 11:34:02 +0200

Thanks Paul!

I'm very happy with all the proposed formulation changes (your commit
0fqxn1k41).

--Vladimir

---

From: Dick Franks <[email-masked]>
Date: Tue, 3 Jul 2018 01:45:03 +0100

On 2 July 2018 at 00:03, Paul Hoffman <[email-masked]> wrote

>8

> Well, RFC 1035 *does* say that it is in ASCII, whether we like that or not.

Perhaps we need to remind ourselves what RFC1035 actually *does* say.

ASCII is mentioned in three places only:

2.3.3 para 1, initially about case-insensitive character string
comparisons, but then wanders off-topic:

  However, future additions beyond current usage may need to use the full
binary octet
  capabilities in names, so attempts to store domain names in 7-bit ASCII
  or use of special bytes to terminate labels, etc., should be avoided.

3.1 para 3, supposedly dealing with preferred name syntax, also has another
crack at case-insensitive comparisons:

  Name servers and resolvers must compare labels in a case-insensitive
manner (i.e., A=a), assuming ASCII
  with zero parity.  Non-alphabetic codes must match exactly.

6.1.2 para 3, in a section dealing with nameserver internal data
structures, yet again gets fixated on character case issues:

  One way to solve the case problem is to store the labels for each node
  in two pieces: a standardized-case representation of the label where all
  ASCII characters are in a single case, together with a bit mask that
  denotes which characters are actually of a different case.

3.1 para 1, dealing with domain names in DNS messages, which being an
external interface, one might expect character encoding to be specified,
does not mention ASCII at all.

Furthermore, in the whole of section 5, which specifies the format of
master files, there is no mention of the character encoding of the files
themselves.

There is only one other occurrence of "encoding" remotely relevant to the
present discussion.

5.1 last para, dealing with special characters and escape sequences:

  Because these files are text files several special encodings are
  necessary to allow arbitrary data to be loaded.

There is nothing in the subsequent \DDD description to indicate that the
decimal number represents an ASCII code point, which it clearly must if
labels are ASCII encoded.

The other occurrences of "encoding" are in section 8, and deal with mailbox
addresses and related matters of no interest here.

The proposition that RFC1035 mandates ASCII "presentation format" is
demonstrably false.

>8

> ... An application could choose to encode the presentation format using a
> different encoding, but that's outside the scope of the protocol.

Application programs do not "choose the encoding"; that "choice" is
inflicted upon them by the I/O system provided by the platform on which
they run.  If the platform uses EBCDIC, then "presentation format" is
EBCDIC encoded, constrained (in this instance) to use the same printable
character repertoire as on an ASCII platform.

--Dick

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 3 Jul 2018 12:00:00 +0100

Hi all, 

Two questions came up recently when writing the DNS Privacy BCP with respect to terminology (and on the dns-operations list):

1) What do folks think about adding a new definition to this document for a shortened term for DNS-over-TLS? Since  we now have DoH I’ve often taken to referring to DNS-over-TLS as DoT in talks and presentations. But this isn’t an acronym used in any standard and it is also potentially confused with meaning DNS-over-TCP  (and there is also a DOTS WG at IETF). DoTLS and DoTCP have also been proposed which work well in written form, but don’t sound as good, so we could consider DoT and DoTCP? Other ideas?

2) The second questions is if it is worth including DoH client/server definitions here and also updating the definition of 'Privacy-enabling DNS server’ from RFC8310 in this draft to include servers that implement DoH and/or DNS-over-TLS. I suspect having one term for such servers might make some of the anticipated DRUI work easier, but I realise including DoH could create dependancy problems  :-)

Regards

Sara. 

> On 22 Jun 2018, at 21:01, Suzanne Woolf <[email-masked]> wrote:
> 
> Colleagues,
> 
> This begins the working group last call for draft-ietf-dnsop-terminology-bis-10, "DNS Terminology”. The document has gotten significant feedback and the editors have worked hard to document current terminology usage, both among practitioners and for broader audiences; we’d like to advance it.
> 
> We’re seeking consensus to advance it to the IESG with an intended status of Best Current Practice. Note that it’s intended to obsolete RFC 7719 ( the earlier “DNS Terminology” document). 
> 
> If you support it, please say so. If you don’t, please say why.
> 
> The current version is at: https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/
> 
> Last Call will run for two weeks, closing on Friday July 6. This will allow for discussion of any major outstanding issues at IETF 102.
> 
> 
> thanks,
> Suzanne, Tim, & Benno
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 3 Jul 2018 09:11:37 -0400

This is not a complete review of the latest revision.. I'm hoping to get to
that in a day or two.   But I've got a question about whether something
should be added to the document..

A question came up in conversation recently about the use of the verb "to
publish" in reference to managing DNS data.  It quickly became clear that
there may be a common overloading of terms, where the same word means
different things to different people.  I wasn't sure this fell into the
scope of the terminology document, but I just checked and it does use
"publish" in reference to DNS data, so perhaps we should come up with a
definition for that.

To me, publishing DNS data has always meant the generation of the zone and
the data it contains, as distinct from distributing the zone (to name
servers, possibly though zone transfer) and serving the zone (making it
available to be queried on a name server).  To the person I was speaking
to, "publishing" meant putting that data on Internet-facing name servers
that would answer queries about it.

However, using such a broad definition of "publishing" seems, to me, to
introduce confusion in that it removes a clear distinction between the
steps of generating data, distributing those data, and then making them
available to be queried.  To draw a comparison, one might look to the steps
of writing, publishing, distributing, and selling a book (although I'm not
sure how the first two would map differently to publishing DNS data.. they
seem like the same step to me in this context).

---

From: Joe Abley <[email-masked]>
Date: Tue, 3 Jul 2018 11:40:35 -0400

On 3 Jul 2018, at 09:11, Matthew Pounsett <[email-masked]> wrote:

> This is not a complete review of the latest revision.. I'm hoping to get to that in a day or two.   But I've got a question about whether something should be added to the document..
> 
> A question came up in conversation recently about the use of the verb "to publish" in reference to managing DNS data.  It quickly became clear that there may be a common overloading of terms, where the same word means different things to different people.  I wasn't sure this fell into the scope of the terminology document, but I just checked and it does use "publish" in reference to DNS data, so perhaps we should come up with a definition for that.
> 
> To me, publishing DNS data has always meant the generation of the zone and the data it contains, as distinct from distributing the zone (to name servers, possibly though zone transfer) and serving the zone (making it available to be queried on a name server).  To the person I was speaking to, "publishing" meant putting that data on Internet-facing name servers that would answer queries about it.

To me, DNS data is published when it is made available to actors who wish to consume it. That means serving the data (i.e. having servers with the data available to answer queries). I have never heard "publish" used to mean zone generation. A zone, once generated, is not published until it is available for access by others.

If there is actually widespread confusion about this I agree it might make sense to clarify (but if there's widespread difference in usage, the best we can probably do in a non-prescriptive dictionary is describe the conflicting uses, and I have my doubts that that in and of itself will reduce confusion).

Joe

---

From: Kal Feher <[email-masked]>
Date: Wed, 4 Jul 2018 22:11:12 +1000

> If there is actually widespread confusion about this I agree it might make sense to clarify (but if there's widespread difference in usage, the best we can probably do in a non-prescriptive diction…
That has been my colloquial use of 'publish'. Until my discussion with 
Matt I had not encountered an alternative meaning. But his use seemed 
equally sensible. I don't feel strongly about either interpretation.

The context of our discussion was making a zone available from the edge 
of a DNS network. It seems to me you could also quite intuitively use 
the term to describe making the zone available to systems within that 
network. Since there will also be consumers of the zone within that DNS 
network. So in my use, publishing has been done by a single system or a 
collective of systems depending on perspective.

-- 
Kal Feher
Melbourne, Australia

---

From: Dick Franks <[email-masked]>
Date: Thu, 5 Jul 2018 10:11:37 +0100

On 3 July 2018 at 16:40, Joe Abley <[email-masked]> wrote:

> > This is not a complete review of the latest revision.. I'm hoping to get
> to that in a day or two.   But I've got a question about whether something
> > A question came up in conversation recently about the use of the verb
> "to publish" in reference to managing DNS data.  It quickly became clear
> that there may be a common overloading of terms, where the same word means
> > To me, publishing DNS data has always meant the generation of the zone
> and the data it contains, as distinct from distributing the zone (to name
> To me, DNS data is published when it is made available to actors who wish
> to consume it. That means serving the data (i.e. having servers with the
> data available to answer queries). I have never heard "publish" used to
> mean zone generation. A zone, once generated, is not published until it is
> available for access by others.
>

agree, the word carries the usual dictionary meaning:

 publish  v.t. to make public; to divulge; to announce; to proclaim; to set
forth to the public;
   to put forth and offer for sale orig. any article, now books,
newspapers, etc.;
   to put into circulation.

zone generation without the "setting forth" does not appear to qualify.

Dick

---

From: George Michaelson <[email-masked]>
Date: Fri, 6 Jul 2018 09:38:40 +1000

Only the zone authority can publish a DNSSEC signed zone.

Anyone can claim to publish a view of a non-DNSSEC signed zone.

On Thu, Jul 5, 2018 at 7:11 PM, Dick Franks <[email-masked]> wrote:
>> > available to be queried on a name server).  To the person I was speaking to,
>> > "publishing" meant putting that data on Internet-facing name servers that
>> > would answer queries about it.
>>
>> data available to answer queries). I have never heard "publish" used to mean
>> zone generation. A zone, once generated, is not published until it is
>    to put forth and offer for sale orig. any article, now books, newspapers,
> etc.;
>    to put into circulation.
>

---

From: Joe Abley <[email-masked]>
Date: Thu, 5 Jul 2018 21:15:25 -0700

> Only the zone authority can publish a DNSSEC signed zone.

I don't know what this means exactly, but I think it's wrong. I will
illustrate my thinking by using some of these words (like "publish")
in the way that I understand them, to see if that helps. So I am not
arguing; I'm describing different usage.

Any nameserver can publish any zone they want. There is no claim,
there is only do. DNSSEC RRSets are not special in this regard. They
are just RRSets.

A client might send a query to a particular server because it was sent
that way by referrals or by local configuration. Clients might not
send queries to a server at all. The server can still be said to
publish a zone.

Only someone able to exercise the private key that corresponds to a
published trust anchor can generate signatures that anybody can
validate. Signing RRSets is a different function from publishing a
zone.

Multiple copies of a private key might be exercised by multiple
different actors who can each produce different signed zones with the
same alex owner name, which clients can successfully validate using
the same trust anchor. You could argue that such a key is not very
private, and I might agree. (See also the multiple-ZSK experiments
conducted in the Yeti project for other examples.)

Root server operators publish the signed root zone. They are not able
to exercise private keys used by PTI and Verisign to generate the
various RRSIGs in the root zone. That is ok.

Many TLD operators generate signed zones that are published on
nameservers operated by third parties (e.g. as commercial DNS
operators, for fee). Those third party operators publish the zones,
but don't have access to the private key. That is ok.

> Anyone can claim to publish a view of a non-DNSSEC signed zone.

I don't know what "publish a view" means. A "view" is BIND8/9
terminology that describes which zone data to publish to particular
sets of clients. The things being published are the zone data, not the
views.

Joe

---

From: william manning <[email-masked]>
Date: Thu, 5 Jul 2018 21:57:16 -0700

---------- Forwarded message ----------
From: william manning <[email-masked]>
Date: Thu, Jul 5, 2018 at 9:55 PM
Subject: Re: [DNSOP] Working Group Last Call on
draft-ietf-dnsop-terminology-bis
To: George Michaelson <[email-masked]>

true enough,  there is a single, canonical dnssec signed zone which can
only be generated with explicit, auditable permission of the zone
authority.

/Wm

On Thu, Jul 5, 2018 at 4:38 PM, George Michaelson <[email-masked]> wrote:

> mean
> newspapers,

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 9 Jul 2018 19:28:15 -0400

Thanks to all who commented. The WGLC is over and the chairs have seen strong support for this document and lots of participation in getting it right, so we’ll be advancing it for publication.

The authors will be spinning up a new version, incorporating the last call comments, and we’ll submit that revision.

Best,
Suzanne
(For the chairs)

> On Jun 22, 2018, at 4:01 PM, Suzanne Woolf <[email-masked]> wrote:
> 
> Colleagues,
>

---

From: [email-masked]
Date: Wed, 11 Jul 2018 00:49:01 +0900 (JST)

Thanks to Vladimír,

> From: Vladimír Čunát <[email-masked]>
> common that usage is, but it has already been discussed wrt. this draft:
> My understanding of that thread is that the meaning was planned to be extended
> in the draft, but the current text seems still restricted to name servers.

I missed updating the part. It's too late, but if possible, I would
like to update the part a follows.

-----------------------------------------------
"In-bailiwick" is an adjective indicating that a domain name is
a subdomain of or (rarely) the same as another domain name.
"Out-of-bailiwick" is the antonym of in-bailiwick.
(The term "bailiwick" means the district or territory where a bailiff or policeman has
jurisdiction.)

"In-bailiwick" and "out-of-bailiwick" are usually used for name servers' names.
"In-bailiwick" name server is a name server whose name
is either a subdomain of or (rarely) the same as the origin
of the zone that contains the delegation to the name server.
In-bailiwick name servers may have glue records in their parent
zone (using the first of the definitions of "glue records" in the definition above).

"In-bailiwick" names are divided into two type of name server names:
"in-domain" names and "sibling domain" names.

In-domain:
sibling domain:

examples
---------------------------------------------

--
Kazunori Fujiwara, JPRS <[email-masked]>

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 16 Jul 2018 07:36:31 -0400

On 9 Jul 2018, at 19:28, Suzanne Woolf wrote:

> Thanks to all who commented. The WGLC is over and the chairs have seen 
> strong support for this document and lots of participation in getting 
> it right, so we’ll be advancing it for publication.
>
> The authors will be spinning up a new version, incorporating the last 
> call comments, and we’ll submit that revision.

We have now turned in -11; please turn the crank so that this can go to 
IETF Last Call and become RFCized.

--Paul Hoffman