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

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.

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

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.

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.

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?