DNS Terminology
draft-ietf-dnsop-terminology-bis-14

Note: This ballot was opened for revision 12 and is now closed.

Deborah Brungard Yes

Comment (2018-08-28 for -13)
No email
send info
Thanks for writing! Agree with the suggested tweaks, Spencer's, clarifying "update" and Ben's comments.

On Informational vs. BCP, I'm leaning towards BCP. As noted in the Shepherd writeup, this is based on practice and improving interoperability, to me, it is a different "type" of terminology document than others which are labeled informational.

(Ben Campbell) Yes

Comment (2018-08-28 for -13)
No email
send info
Many thanks to the authors for making what I expected to be a dry terminology document into an adventure of discovery.

I agree with Mirja's assessment about whether this really updates 2308. I also agree with Alvaro's wish to rethink the BCP status (including his disinclination to stand in the way of publication this far into the process.)

§2"
- Definition of "Domain Name": I don't profess to be a naming expert, but this definition doesn't seem very satisfying.  It potentially defines things that I wouldn't consider domain names. Is there no representation, intent, or other context that distinguishes an ordered list of labels that is a domain name from your garden variety ordered lists of labels? (or is the point of this that they cannot be distinguished?)

- Definition of IDN: 'The current standard, normally called "IDNA2008"...'
That may not age well. I suggest  something to the effect of "The current standard at the time of this writing, ..."

(Spencer Dawkins) Yes

Comment (2018-08-27 for -13)
No email
send info
This is definitively a labor of love. Thanks for doing the work!

I have some musings. Do the right thing, of course. 

Thank you for producing this valuable doc. 

In this text, 

2.  Names

...

      The common display format is used in applications and free text.
      It is the same as the presentation format, but showing the root
      label and the "." before it is optional and is rarely done.  For
      example, in common display format, a fully-qualified domain name
      with two non-root labels is usually shown as "example.tld" instead
      of "example.tld.".  Names in the common display format are
      normally written such that the directionality of the writing
      system presents labels by decreasing distance from the root (so,
      in both English and C the root or TLD label in the ordered list is
      right-most; but in Arabic it may be left-most, depending on local
      conventions).

I bet I know what you mean by "C", but I'm guessing. Perhaps it's worth providing a reference, for all the Javascript and Python programmers who skipped over C? 

I'm looking at 

     Administration of names -- Administration is specified by
      delegation (see the definition of "delegation" in Section 7).
      Policies for administration of the root zone in the global DNS are
      determined by the names operational community, which convenes
      itself in the Internet Corporation for Assigned Names and Numbers
      (ICANN).  The names operational community selects the IANA
      Functions Operator for the global DNS root zone.  At the time this
      document is published, that operator is Public Technical
      Identifiers (PTI).  (See <https://pti.icann.org/> for more
      information about PTI operating the IANA Functions.)  The name
      servers that serve the root zone are provided by independent root
      operators.  Other zones in the global DNS have their own policies
      for administration.

and wondering what the stability of an ICANN URL that refers to the name of the current IANA Functions Operator will be in 5-10 years. I'm not sure what else you can do to make that more useful if a different operator is selected, but if you can do something, maybe that would be useful. 

I'm looking at this text:

  Passive DNS:  A mechanism to collect DNS data by storing DNS
      responses from name servers.  Some of these systems also collect
      the DNS queries associated with the responses, although doing so
      raises some privacy concerns.  

and thinking that the problem isn't collecting DNS queries associated with responses, it's that it's possible to collect DNS queries associated with responses (so, if one of these systems stops collecting DNS queries, you still have an exposure; it's just not happening now). Is that wrong?

I'm looking at this text:

  Privacy-enabling DNS server:  "A DNS server that implements DNS over
      TLS [RFC7858] and may optionally implement DNS over DTLS
      [RFC8094]."  (Quoted from [RFC8310], Section 2)

and seeing a race condition with https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ (which isn't news to the authors who contributed to both specifications). Is it worth a mention here, given that the DOH draft is already in the RFC Editor queue?

I may be misreading this text:

  Parent:  "The domain in which the Child is registered."  (Quoted from
      [RFC7344], Section 1.1) Earlier, "parent name server" was defined
      in [RFC0882] as "the name server that has authority over the place
      in the domain name space that will hold the new domain".  (Note
      that [RFC0882] was obsoleted by [RFC1034] and [RFC1035].)
      [RFC0819] also has some description of the relationship between
      parents and children.

but I'm reading it as "the definition in RFC 882 was obsoleted by RFC 1034-5 in 1987, and there was no definition until RFC 7344 in 2014". If that's what's intended, great, but if that's not your point, perhaps we should talk …

"Ostensive" is a perfectly good word according to https://www.merriam-webster.com/dictionary/ostensive, but I didn't know what it meant without Googling it. You guys know your intended audience, of course …

In this text,

  Closest provable encloser:  "The longest ancestor of a name that can
      be proven to exist.  Note that this is only different from the
      closest encloser in an Opt-Out zone."  (Quoted from [RFC5155],
      Section 1.3)

"Opt-Out zone" wasn't familiar to me, but it's defined later in the document. Perhaps adding a pointer to Section 10 would be helpful to readers who lack clue as I do.

Warren Kumari Yes

(Terry Manderson) Yes

Alexey Melnikov Yes

Comment (2018-08-30 for -13)
No email
send info
Thank you for this document!

I was also confused by many of comments raised by Ekr. So I think some minor changes/clarifications would be useful.

Ignas Bagdonas No Objection

Benjamin Kaduk No Objection

Comment (2018-08-27 for -13)
No email
send info
First off, thank you all for the effort that went into this document -- it's quite helpful to
have a central resource to refer to.

I agree with Mirja about further clarity for the 2308 updates being nice, and about the "primary master"
definition's clarification.  (The latter seems like it would meet a DISCUSS criterion, as internal inconsistency
makes it difficult to have a clear specification.  But it would be absurd to apply it here when the fix is clear.)

I appreciate that "privacy of names" and "privacy of data associated with names" are called out as potential
facets of a naming system to consider, but I would like to understand better why they are not given more treatment
in this document.  The surrounding text seems to imply that they are not needed to describe the DNS and that
a pure lexicon need not explore the privacy considerations of the terms being defined; is this correct, and was
there much discussion on this question?

In a similar vein, it was a little surprising to only see the facets be expounded upon for the global DNS and not
the other related naming systems, though it's unclear that there would be much non-overlap for the other systems
considered.

In Section 6:

I'm a little confused about the interaction between "stealth server"
and "hidden master" -- if a hidden master is a stealth server, it is "like
a slave" and would thus be expected to get its configuration from yet
another master?  But this doesn't jibe with being listed as the MNAME.
I accept that DNS terminology is a complicated area and there may not
be a right answer, of course.

The "privacy-enabling DNS server" definition seems too narrowly scoped to
particular existing technologies as opposed to describing the properties
provided (or mentioning the possibility for future protocols to be
included).  Is a DNS-over-HTTP server "privacy-enabling"?  How about DNS-over-QUIC?

Section 8

Interesting to see the term "Opt-Out zone" used but not defined in this
document.  (No action needed, and I do see the definition of "Opt-Out".)


Finally, I am somewhat sympathetic to the indications that this document may
(also) be appropriate as Informational; I look forward to seeing how that discussion
unfolds.

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

Comment (2018-08-24 for -13)
No email
send info
I'm actually not sure if this doc really updates RFC2308 because the two definitions (Forwarder and QNAME) only say someting like "it is used differently today" but seem not really to actually update the existing definitions. I would recommend to either not use the "update" tag or clarify these definitions.  

Thanks for the clarification added based on the TSV-ART review (and thanks Allison!).

(Potential) nits:
1) OLD:
A set of resource records with the same label, class and
      type, but with different data.  (Definition from [RFC2181])
MAYBE use quotes here at least for the last part of the sentence:
A set of resource records "with the same label, class and
      type, but with different data."  (Definition from [RFC2181])

2) s/Section 4.3.1 of of [RFC1034] /Section 4.3.1 of [RFC1034]/

3) Probably the first sentence should be removed:
"The idea of a primary master is only used by [RFC2136],
      and is considered archaic in other parts of the DNS.

      The idea of a primary master is only used in [RFC1996] and
      [RFC2136]. "

4) Why is there (a) and (b) for the definition of Origin?

(Eric Rescorla) No Objection

Comment (2018-08-29 for -13)
No email
send info
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3131



IMPORTANT
S 6.
>         [RFC5358]
>   
>      Split DNS:  The terms "split DNS" and "split-horizon DNS" have long
>         been used in the DNS community without formal definition.  In
>         general, they refer to situations in which DNS servers that are
>         authoritative for a particular set of domains provide partly or

What about ones that aren't authoritative. Apparently this exists in
VPN settings.

COMMENTS
S 2.
>      learn the DNS by reading this document.
>   
>   2.  Names
>   
>      Naming system:  A naming system associates names with data.  Naming
>         systems have many significant facets that help differentiate them.

From each other? Or from other systems that aren't naming systems?


S 2.
>         The need for the term "fully qualified domain name" comes from the
>         existence of partially qualified domain names, which are names
>         where one or more of the earliest labels in the ordered list are
>         omitted (for example, a name of "www" derived from
>         "www.example.net").  Such relative names are understood only by
>         context.

I think we agree here but I had to read it several times, because
"earliest" in the list is not earliest in the presentation format.
Perhaps you should say "less specific" or "closest to the root" are
omitted  instead.


S 2.
>      Subdomain:  "A domain is a subdomain of another domain if it is
>         contained within that domain.  This relationship can be tested by
>         seeing if the subdomain's name ends with the containing domain's
>         name."  (Quoted from [RFC1034], Section 3.1).  For example, in the
>         host name "nnn.mmm.example.com", both "mmm.example.com" and
>         "nnn.mmm.example.com" are subdomains of "example.com".

It might be worth noting that whole component matches are required
here.


S 2.
>   
>      Canonical name:  A CNAME resource record "identifies its owner name
>         as an alias, and specifies the corresponding canonical name in the
>         RDATA section of the RR."  (Quoted from [RFC1034], Section 3.6.2)
>         This usage of the word "canonical" is related to the mathematical
>         concept of "canonical form".

This paragraph didn't seem very clear. Perhaps an explanatory sentence
or two about what a CNAME is for woudl help.


S 4.
>            the name originally queried, or a name received in a CNAME
>            chain response.
>   
>         *  QNAME (final): The name actually resolved, which is either the
>            name actually queried or else the last name in a CNAME chain
>            response.

So to be clear, the QNAME (final) is always one of the QNAME
(effective) sets?


S 6.
>         name server side (which is what answers the query) and a resolver
>         side (which performs the resolution function).  Systems operating
>         in this mode are commonly called "recursive servers".  Sometimes
>         they are called "recursive resolvers".  While strictly the
>         difference between these is that one of them sends queries to
>         another recursive server and the other does not, in practice it is

Which one does which?


S 6.
>         general, a recursive resolver is expected to cache the answers it
>         receives (which would make it a full-service resolver), but some
>         recursive resolvers might not cache.
>   
>         [RFC4697] tried to differentiate between a recursive resolver and
>         an iterative resolver.

Did it fail?


S 6.
>         client to another server and lets the client pursue the query
>         there.  (See Section 2.3 of [RFC1034].)
>   
>         In iterative resolution, the client repeatedly makes non-recursive
>         queries and follows referrals and/or aliases.  The iterative
>         resolution algorithm is described in Section 5.3.3 of [RFC1034].

This may just be my confusion, but it seems like this is still a bit
hard to follow.

Say that I send a query to a server X with the recursive bit set, and
that server in fact decides to give me a full answer (as opposed to
failing). At that point it could either:

(1) send the query to another server with the recursive bit set
(2) resolve the query entirely itself using iterative queries

Am I right so far?

Are both of these termed "recursive resolvers"?




S 6.
>         Internet; it is not listed in the NS RRset."  (Quoted from
>         [RFC6781], Section 3.4.3).  An earlier RFC, [RFC4641], said that
>         the hidden master's name "appears in the SOA RRs MNAME field",
>         although in some setups, the name does not appear at all in the
>         public DNS.  A hidden master can also be a secondary server for
>         the zone itself.

I'm not understanding this last sentence. Can you elaborate?


S 7.
>         if the name server's name is 'below' the cut, and are only used as
>         part of a referral response."  Without glue "we could be faced
>         with the situation where the NS RRs tell us that in order to learn
>         a name server's address, we should contact the server using the
>         address we wish to learn."  (Definition from [RFC1034],
>         Section 4.2.1)

An example might help here.


S 10.
>         Policy (if such exists), and it states how the management of a
>         given zone implements procedures and controls at a high level."
>         (Quoted from [RFC6841], Section 2)
>   
>      Hardware security module (HSM):  A specialized piece of hardware that
>         is used to create keys for signatures and to sign messages.  In

It's probably worth mentioning that the idea here is that it doesn't
disclose the keys, as opposed to just creating them.

Alvaro Retana No Objection

Comment (2018-08-27 for -13)
No email
send info
I agree with Mirja on her point about this document not seeming to Update rfc2308.

Both the IETF Last Call thread [1] and the Shepherd's writeup point at having this document not be Informational so it can Update rfc2308.  Putting that point aside, I don't think this document needs to be published as a BCP to reflect the current evolution of the DNS vocabulary.  I would prefer it if the status was reconsidered.

Given that we're already past IETF LC, I won't stand in the way as I am probably in the rough.  I am then balloting "No Objection" because I think this is a clear and important document.

[1] https://mailarchive.ietf.org/arch/msg/dnsop/9KsgYjBAxz5kzdeFLbht0IWjPkM

Adam Roach No Objection

Comment (2018-08-30 for -13)
No email
send info
Thanks for the time and effort that went into this document. I agree with other
reviewers that this document is well-presented and informative.

---------------------------------------------------------------------------

General:

The document seems to omit a definition for the term "class," although it is
used in many places an clearly has a very precise meaning in DNS parlance. It
would be nice to see one added, as I got a bit confused when I hit the
definition for "Class independent" in section 5 and realized that I'd been
conflating "RR type" with "Class" -- and couldn't find guidance in this document
to clarify the difference.

---------------------------------------------------------------------------

§2:

>  Multicast DNS:  "Multicast DNS (mDNS) provides the ability to perform
>     DNS-like operations on the local link in the absence of any
>     conventional Unicast DNS server.

This definition seems to be a little oversimplified in light of the mechanisms
described by draft-ietf-dnssd-hybrid and draft-ietf-dnssd-mdns-relay.

---------------------------------------------------------------------------

§5:

>  Master file:  "Master files are text files that contain RRs in text
>     form.  Since the contents of a zone can be expressed in the form
>     of a list of RRs a master file is most often used to define

Nit: "...list of RRs, a master..."
                    ^

---------------------------------------------------------------------------

§5:
>  Owner:  The domain name where a RR is found ([RFC1034], Section 3.6).

Nit: "...an RR..." (see RFC 7322 §1, CMOS 10.9)

---------------------------------------------------------------------------

§6:

>     The idea of a primary master is only used by [RFC2136],
>     and is considered archaic in other parts of the DNS.
>
>     The idea of a primary master is only used in [RFC1996] and
>     [RFC2136].

These sentences seem redundant and partially contradictory. I suspect the first
one should be removed.

---------------------------------------------------------------------------

§6:

>  Privacy-enabling DNS server:  "A DNS server that implements DNS over
>     TLS [RFC7858] and may optionally implement DNS over DTLS
>     [RFC8094]."  (Quoted from [RFC8310], Section 2)

This definition seems incomplete in light of the mechanism defined in
draft-ietf-doh-dns-over-https.

---------------------------------------------------------------------------

Acknowledgements:

>  The following is the Acknowledgements for RFC 7719.  Additional
>  acknowledgements may be added as this draft is worked on.

This feels out of date. Consider removing.