[DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Wed, 29 August 2018 12:10 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87548130E9F; Wed, 29 Aug 2018 05:10:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: "The IESG" <iesg@ietf.org>
Cc: dnsop@ietf.org, suzworldwide@gmail.com, dnsop-chairs@ietf.org, Suzanne Woolf <suzworldwide@gmail.com>, draft-ietf-dnsop-terminology-bis@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153554463554.14882.8129348448370636392.idtracker@ietfa.amsl.com>
Date: Wed, 29 Aug 2018 05:10:35 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sdIraXh3n_3mHAzxrCSl3DcYDWE>
Subject: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Aug 2018 12:10:36 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-dnsop-terminology-bis-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.