Subject: [DNSOP] New draft for consideration:

From: Paul Hoffman <[email-masked]>
Date: Sun, 24 Mar 2019 06:42:53 +0000

Greetings again. As y'all have seen over the past few weeks, the discussion of where DNS resolution should happen and over what transports has caused some people to use conflicting terms. As a possible solution to the terminology problems, I am proposing a few abbreviations that people can use in these discussions. The draft below, if adopted by the DNSOP WG, would update RFC 8499 with a small set of abbreviations.

--Paul Hoffman

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Abbreviations for DNS Transports and Location
        Author          : Paul Hoffman
	Filename        : draft-hoffman-dns-terminology-ter-00.txt
	Pages           : 3
	Date            : 2019-03-23

Abstract:
   This document adds abbreviations to "DNS Terminology" (RFC 8499) that
   relate to DNS running over various transports, as well as
   abbreviations for DNS resolution at traditional and non-traditional
   locations.

   [[ This is an early attempt at these terms.  They will probably be
   improved over time. []

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology-ter/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-hoffman-dns-terminology-ter-00
https://datatracker.ietf.org/doc/html/draft-hoffman-dns-terminology-ter-00

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 24 Mar 2019 09:32:12 +0100

The chairs spoke with Paul yesterday, and we are in agreement, if the
working group feels these are useful terms
to be added (and several of them are in common use already), we're good on
adopting and fast tracking the whole
document.

Tim

On Sun, Mar 24, 2019 at 8:02 AM Paul Hoffman <[email-masked]> wrote:

> Greetings again. As y'all have seen over the past few weeks, the
> discussion of where DNS resolution should happen and over what transports
> has caused some people to use conflicting terms. As a possible solution to
> the terminology problems, I am proposing a few abbreviations that people
> can use in these discussions. The draft below, if adopted by the DNSOP WG,
> would update RFC 8499 with a small set of abbreviations.
>
> --Paul Hoffman
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: bert hubert <[email-masked]>
Date: Sun, 24 Mar 2019 11:18:05 +0100

On Sun, Mar 24, 2019 at 06:42:53AM +0000, Paul Hoffman wrote:

> to the terminology problems, I am proposing a few abbreviations that
> people can use in these discussions.  The draft below, if adopted by the
> DNSOP WG, would update RFC 8499 with a small set of abbreviations.

Hi Paul,

Thank you for this, and I have understood the note that the draft is early
and the words will likely improve. 

It may be good to add a note that "DoH is the protocol as defined in
[RFC8484]. The operation of this protocol by browser vendors and cloud
providers is frequently also called 'DoH'. DoH-the-protocol is
therefore frequently conflated with DoH being used to perform
DNS lookups in a different fashion than configured by the network settings
(see DaT and DaO)."

Secondly, I understand the technical need for the wording of the definition
of DaO.  But I had to read this all a few times before I understood that
'DaO' includes what I've referred to as DoC (DNS over Cloud). I think
definitions should be easy to understand because otherwise they don't
function.

I'm also not too hot for conflating "user consciously changes
/etc/resolv.conf or equivalent" with "application makes the choice for the
user". 

Perhaps we should talk about 'Per-application stubs'? Because this is the
nub. 

I'm willing to write text once we have discussed this a bit.

	Bert

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 24 Mar 2019 10:46:28 +0000

> DNS lookups in a different fashion than configured by the network settings

A much better outcome would be that people who are saying DoH when they mean DaT or DaO would use the new terms. That is, this is a forward-looking document because we're making up new terms.

> definitions should be easy to understand because otherwise they don't

I fully agree; proposed changes to this wording are quite welcome. It's a new term, after all.

> /etc/resolv.conf or equivalent" with "application makes the choice for the

The split here is more "someone changes from traditional without the user knowing, when the user cares". If you have a better way to express that, that would be great.

> Perhaps we should talk about 'Per-application stubs'? Because this is the

Maybe, but I'm hesitant to make the break that way because some applications' stubs use the traditional resolver, others don't. I would be hesitant to conflate those two.

> I'm willing to write text once we have discussed this a bit.

Thanks!

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Sun, 24 Mar 2019 12:47:32 +0100

On Sun, Mar 24, 2019 at 11:46 AM Paul Hoffman <[email-masked]>
wrote:

> A much better outcome would be that people who are saying DoH when they
> mean DaT or DaO would use the new terms. That is, this is a forward-looking
> document because we're making up new terms.
>

<no hats>
This is likely to be an annoying comment, but I don't really like the DaO
"acronym", simply because I'm not sure how people will pronounce it -- I
could see people mishearing "DaO" as "DoH", or the other way round --
unfortunately I don't have a better suggestion. Is it just me who has this
issue?

</no hats>
W

> The split here is more "someone changes from traditional without the user
> knowing, when the user cares". If you have a better way to express that,
> that would be great.
>
> Maybe, but I'm hesitant to make the break that way because some
> applications' stubs use the traditional resolver, others don't. I would be
> hesitant to conflate those two.
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Brian Dickson <[email-masked]>
Date: Sun, 24 Mar 2019 04:59:58 -0700

> unfortunately I don't have a better suggestion. Is it just me who has this

It probably isn't just you.
Here's a couple of suggestions to maybe canonicalize some of the terms, and
make them easier to distinguish/say:

DoTR (rather than RDoT): DNS over TLS, Recursive
DoTA (rather than ADoT): DNS over TLS, Authoritative. Or, some kind of
online game played by Millennials, presumably. :-)
DoN (rather than DaO): DNS on Nonstandard
DoS (rather than DaT): DNS on Standard. Risks confusion with Denial of
Service, if there is no provided context (but generally context will exist,
so...)

In anticipation of crazy ideas I might bring up, maybe we can agree on
compounding of lower-case "o" usage, with left-to-right meaning
left-encapsulated-in-right.
E,.g, DoTo53 would be "DNS over TLS, carried via some manner of encoding
within the payload of a Do53 message".

Brian

> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.

---

From: Martin Hoffmann <[email-masked]>
Date: Sun, 24 Mar 2019 13:37:40 +0100

Paul Hoffman wrote:

> discussion of where DNS resolution should happen and over what
> transports has caused some people to use conflicting terms. As a
> possible solution to the terminology problems, I am proposing a few
> abbreviations that people can use in these discussions. The draft
> below, if adopted by the DNSOP WG, would update RFC 8499 with a small
> set of abbreviations.

I would like to boldly suggest to not or at least not only define
abbreviations but proper names for the more general concepts instead.
The ship has probably sailed for the protocols itself and they will now
forever be DoH and DoT, but maybe we can agree on something more
meaningful such as "traditional [name] resolution" v. "alternative
[name] resolution" for the what the draft calls DaT and DaO.

The reasoning here is that proper terms are less confusing and, if
chosen wisely, can be understood by someone not intimately familiar
with the matter. When speaking, they aren’t much more bothersome than
the abbreviation. Writing will be a bit more work but then again, an
extra layer of clarity can help with avoiding misunderstanding.

I will spare you my aesthetic concerns around camel-case abbreviations.

Kind regards,
Mar*shudder*tin

---

From: Olli Vanhoja <[email-masked]>
Date: Sun, 24 Mar 2019 14:52:33 +0100

I don't like it either because DAO is a well known acronym for Data Access
Object.

---

From: Matthew Pounsett <[email-masked]>
Date: Sun, 24 Mar 2019 16:59:00 +0100

> hesitant to conflate those two.

I don't think the current wording for DaO expresses the same point that
you've made here.  In particular, mentioning that DaO might refer to a user
modifying /etc/resolv.conf is inconsistent with the intent that DaO is
sending queries somewhere other than where the traditional configuration
says.  /etc/resolv.conf (and its equivalents in non-unix OSes) *are* the
traditional place to configure that.  Whatever that file says, I think any
resolver that is consulting that file to find its upstreams is doing DaT.

How about:
   DaO: DNS resolution between a stub resolver and a recursive resolver that
   differs from the recursive resolver configured in the traditional
   location(s) for a system.  DaO can be configured by a user changing
where a
   stub resolver gets its list of recursive servers, or an application
running
   RDoT or DoH to a resolver that is not the same as the resolver configured
   in the traditional location for the operating system.

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 24 Mar 2019 09:17:36 -0700

> On Mar 24, 2019, at 08:59, Matthew Pounsett <[email-masked]> wrote:
> 
> 
> 
> I don't think the current wording for DaO expresses the same point that you've made here.  In particular, mentioning that DaO might refer to a user modifying /etc/resolv.conf is inconsistent with the intent that DaO is sending queries somewhere other than where the traditional configuration says.  /etc/resolv.conf (and its equivalents in non-unix OSes) *are* the traditional place to configure that.  Whatever that file says, I think any resolver that is consulting that file to find its upstreams is doing DaT.

I think we’re at the point where using acronyms is is obscuring the detail of what is being described. If and acronym describes a protocol or an architectural feature that is unambiguous, great. 
>    location(s) for a system. 

This describes a multitude of systems of varying implementation. It would seem for example to include bonjour, a tor client, some vpns and many operating system container environments.

> DaO can be configured by a user changing where a
>    stub resolver gets its list of recursive servers, or an application running

---

From: Matthew Pounsett <[email-masked]>
Date: Sun, 24 Mar 2019 22:26:18 +0100

On Sun, 24 Mar 2019 at 17:17, Joel Jaeggli <[email-masked]> wrote:

> I think we’re at the point where using acronyms is is obscuring the detail
> of what is being described. If and acronym describes a protocol or an
> architectural feature that is unambiguous, great.
>
>
> How about:
> This describes a multitude of systems of varying implementation. It would
> seem for example to include bonjour, a tor client, some vpns and many
> operating system container environments.
>

I may be wrong, but I don't believe bonjour uses RDoT or DoH.

The VPNs you reference are, I think, intended to be covered by the term, so
I think the definition works there.

 I don't think I have an opinion on whether Tor should or shouldn't be
covered by the definition (although others might), so if you wanted to
suggest text that excluded it I think people would consider that.

I don't think container environments are included in the definition either,
because in a container environment the container's resolution path is the
traditional point of configuration for that type of system.  Perhaps the
word "traditional" is too ambiguous, and leads people to think more
"historical" than "typical"?

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 25 Mar 2019 09:38:09 +0100 (CET)

> Il 24 marzo 2019 alle 7.42 Paul Hoffman <[email-masked]> ha scritto:
> 
> 

I don't know if these terms are already defined somewhere else, but the distinction that I've found most useful in the DoH discussion is "local resolver" (i.e. the one provided on/by the local network the user connects to) vs "remote resolver" (i.e. any other resolver, requiring traffic to go beyond the Internet access provider's network). Some of the issues happen, and already happen today, as soon as the user adopts a remote resolver, even with plain old DNS.

I agree that another set of problems derives instead from applications using a resolver different than the one configured in the operating system, which may or may not be the local resolver. So it's fine to define a couple of terms like "DaT" and "DaO", though I don't really like these two acronyms :-) In my draft I introduce the terms "network-level name resolution", "application-level name resolution" and "application-level resolver selection". They are not acronyms, but I think they would be more understandable in a discussion than more and more acronyms. 

(I don't even like "Do53", I think "unencrypted DNS" or "plain DNS" is just clearer.)

Ciao,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Mar 2019 09:52:43 +0100

Bonjour uses DNS or mDNS. If it’s using DNS, it can in principle use DoT or
DoH, and indeed “Back to my Mac” was using DoT before it was specified in
an RFC. That functionality is still in the open source mDNSResponder code.

I realize that this is somewhat tangential to the point you were making but
wanted to clarify this detail.

On Sun, Mar 24, 2019 at 22:26 Matthew Pounsett <[email-masked]> wrote:

>>> The split here is more "someone changes from traditional without the
>>> user knowing, when the user cares". If you have a better way to express
>>> that, that would be great.
>>>
>> I think we’re at the point where using acronyms is is obscuring the
>> detail of what is being described. If and acronym describes a protocol or
>> an architectural feature that is unambiguous, great.
>>
>>
>> How about:
> The VPNs you reference are, I think, intended to be covered by the term,
> so I think the definition works there.
>
> I don't think container environments are included in the definition
> either, because in a container environment the container's resolution path
> is the traditional point of configuration for that type of system.  Perhaps
> the word "traditional" is too ambiguous, and leads people to think more

---

From: Patrick McManus <[email-masked]>
Date: Mon, 25 Mar 2019 10:16:53 +0100

ts nice to have a thread where bike shedding of terms is actually on topic,
and the point of the draft.

On Mon, Mar 25, 2019 at 9:39 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> >
> I don't know if these terms are already defined somewhere else, but the
> distinction that I've found most useful in the DoH discussion is "local
> resolver" (i.e. the one provided on/by the local network the user connects
> to) vs "remote resolver" (i.e. any other resolver, requiring traffic to go
> beyond the Internet access provider's network). Some of the issues happen,
> and already happen today, as soon as the user adopts a remote resolver,
> even with plain old DNS.
>
>
I agree with you that this is the important logical distinction. My only
quibble is that local and remote can have varied (and multiple) scopes - so
its a little hard to apply the terms concretely.

I'm thinking more along the lines of Access Network Resolver and Network
Independent Resolver to capture the same idea.

[I originally sent this note by accident to Vittoria without a cc to the
list. Sorry Vittorio for the dup!]

On Mon, Mar 25, 2019 at 9:39 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> I don't know if these terms are already defined somewhere else, but the
> distinction that I've found most useful in the DoH discussion is "local
> resolver" (i.e. the one provided on/by the local network the user connects
> to) vs "remote resolver" (i.e. any other resolver, requiring traffic to go
> beyond the Internet access provider's network). Some of the issues happen,
> and already happen today, as soon as the user adopts a remote resolver,
> even with plain old DNS.
>
> I agree that another set of problems derives instead from applications
> using a resolver different than the one configured in the operating system,
> which may or may not be the local resolver. So it's fine to define a couple
> of terms like "DaT" and "DaO", though I don't really like these two
> acronyms :-) In my draft I introduce the terms "network-level name
> resolution", "application-level name resolution" and "application-level
> resolver selection". They are not acronyms, but I think they would be more
> understandable in a discussion than more and more acronyms.
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 25 Mar 2019 12:02:50 +0000

DoT and DoH seem fine. But maybe skip the acronym for Do53 - just call it conventional DNS or unencrypted DNS, or DNS over Port 53. Compared to RDoT/ADoT/DaT/DaO however, Do53 is the least offensive IMO. 

I don’t think you do much for clarity with RDoT and ADoT - seems mostly to be used because you want more acronyms. ;-) For RDoT this is the stub/client to recursive DoT link of the lookup chain. This is client-to-recursive (C2R DoT? Ha!), whereas ADoT is the recursive server performing recursion to a series of authoritative servers - recursion-to-authoritatives (R2A DoT? Acronym overkill achieved.) So I think those need some work.

I find DaT and DaO rather confusing. I feel like you may be trying too hard on acronyms and these will become very difficult for others to understand. Really the difference is between network-assigned DNS, user-assigned DNS, and client-assigned DNS - so 3 separate primary use cases of assignment of your resolver. I would maybe focus on the difference between the manner of assignment/configuration and not worry too much (at least for now) over some sort of acronym, since it seems at this early stage of discussions that the acronym may cause more confusion that more straightforward (but longer) terms.

I think you could also add definitions for Centralised (Recursive) Do53/DoH/DoT, as well as Distributed (Recursive) Do53/DoH/DoT. This refers to how widely distributed or centralized the group of operators of the recursives are or are not. I took a stab at that definition in my draft you could work from if you wish.

Jason

---

From: Joe Abley <[email-masked]>
Date: Mon, 25 Mar 2019 06:37:27 -0700

On Mar 24, 2019, at 07:42, Paul Hoffman <[email-masked]> wrote:

> Greetings again. As y'all have seen over the past few weeks, the discussion of where DNS resolution should happen and over what transports has caused some people to use conflicting terms. As a possible solution to the terminology problems, I am proposing a few abbreviations that people can use in these discussions.

I like the idea in general of trying to anticipate and avoid problems
before they happen. However, I wonder in this case whether a lexicon
is going to help.

The problems with the conversation today (I would say) are more
fundamental than terminology. It's long been my observation that
finding a name for something has the potential to suck all the air
from the room. The room we are in is perhaps stuffy enough already.

Joe