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

From: Eric Rescorla <[email-masked]>
Date: Wed, 29 Aug 2018 05:10:35 -0700

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.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 31 Aug 2018 15:20:28 +0000

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

If you are referring to draft-ietf-ipsecme-split-dns, the "private DNS domains" in that document have authoritative servers that only reply on one side of the split.

>From each other. Will fix.

> Perhaps you should say "less specific" or "closest to the root" are

This was discussed at length in the WG and this wording was chosen. All options here kinda suck, but the example makes the intended meaning clear.

> It might be worth noting that whole component matches are required

Good catch, will add.
> or two about what a CNAME is for woudl help.

...or make it worse. This is a recurring topic in DNSOP, and one can hope for a document that describes this in the future.

> So to be clear, the QNAME (final) is always one of the QNAME

Yes.

>>        another recursive server and the other does not, in practice it is

That's not clear from the text. I'm going to propose to the other authors that we simply elide this, particularly because "recursive resolver" is defined immediately after this text.

>>        [RFC4697] tried to differentiate between a recursive resolver and

In most people's estimation, yes. But they tried diligently.

> (2) resolve the query entirely itself using iterative queries

That list is incomplete:
(3) give an authoritative answer

> Are both of these termed "recursive resolvers"?

Yes for #1 and #2, but not for #3.

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

A hidden master might be used by a local recursive resolver; that is, it could be hidden from the public but not from the local network.

> An example might help here.

It could in fact make things worse because the text in 4.2.1 is about when you don't have glue, not when you have it.

> disclose the keys, as opposed to just creating them.

Good catch, will do.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 31 Aug 2018 16:22:47 +0000

Ekr pinged me in Jabber after I sent this, and I wanted to clarify something bigger-picture on this document. We know that there are a number of definitions that are not clear. In the WG discussion, we tried hard to get them clarified, and often met resistance in the form of "I have always thought it meant X" vs. "I have always thought it meant Y" that could not be resolved. On some of the terms that Ekr asked for clarity on, we had even done separate threads. In the end, there was reasonably strong WG consensus that the document was the best we could do, even thought most of the folks who said that probably had at least one bit that they didn't like in the document.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 31 Aug 2018 09:57:02 -0700

That's understandable. I think it would be most helpful to somehow tag
those cases so that the reader can see that they are ambiguous rather than
just rereading and being confused.

-Ekr

On Fri, Aug 31, 2018 at 9:22 AM, Paul Hoffman <[email-masked]>
wrote:

> Ekr pinged me in Jabber after I sent this, and I wanted to clarify
> something bigger-picture on this document. We know that there are a number
> of definitions that are not clear. In the WG discussion, we tried hard to
> get them clarified, and often met resistance in the form of "I have always
> thought it meant X" vs. "I have always thought it meant Y" that could not
> be resolved. On some of the terms that Ekr asked for clarity on, we had
> even done separate threads. In the end, there was reasonably strong WG
> consensus that the document was the best we could do, even thought most of
> the folks who said that probably had at least one bit that they didn't like
> in the document.
>
> --Paul Hoffman