> 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
