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= 40open-xchange....@dmarc.ietf.org> 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= 40open-xchange....@dmarc.ietf.org> wrote: > > Il 24 marzo 2019 alle 7.42 Paul Hoffman <paul.hoff...@icann.org> ha > scritto: > > > > > > 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. > > 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 > vittorio.bert...@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
