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

From: Suzanne Woolf <[email-masked]>
Date: Fri, 22 Jun 2018 16:01:11 -0400

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

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 26 Jun 2018 19:09:01 +0200

Greetings!

I really like the draft, and I'm sorry to be so late.  I see one minor
issue just below and then a few nitpicks that I don't feel strongly about.

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

"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

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

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

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

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

"NSEC3" definition, this is clearly a typo (missing "3"):

> NSEC resource records require associated NSEC3PARAM resource records.

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

--Vladimir

---

From: Dick Franks <[email-masked]>
Date: Wed, 27 Jun 2018 20:56:16 +0100

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.

Consider the following perl fragment:

    use Net::DNS 1.11;

    my $resolver = new Net::DNS::Resolver();

    my ($rr) = $resolver->query( 'www.example.com.', 'A' )->answer;

    $rr->print;
    print unpack( 'H*', $rr->string ), "\n";

executed in an ASCII-based environment:

  www.example.com.    600    IN    A    93.184.216.34

7777772e6578616d706c652e636f6d2e0936303009494e09410939332e3138342e3231362e3334

in an OS390 EBCDIC environment:

  www.example.com.    600    IN    A    93.184.216.34

a6a6a64b85a781949793854b8396944b05f6f0f005c9d505c105f9f34bf1f8f44bf2f1f64bf3f4

(output converted to ASCII to preserve your sanity)

Suggested replacement text:

      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 ASCII encoded and preceded by a single
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, represented by
      printable characters from the ASCII repertoire, irrespective of the
local
      character encoding used to represent them.
      The component labels are separated by a single "." character.
      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 numerical representation that may be used to
display
      octets for which there is no corresponding ASCII printable character.

Dick Franks
________________________

On 22 June 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).
>
> 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
>