Re: [DNSOP] [Ext] Re: New draft for consideration:
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 wrote: > > > On Sun, 24 Mar 2019 at 17:17, Joel Jaeggli wrote: > >> >> >> On Mar 24, 2019, at 08:59, Matthew Pounsett wrote: >> >> >> >> On Sun, 24 Mar 2019 at 11:46, Paul Hoffman >> wrote: >> >>> >>> > I'm also not too hot for conflating "user consciously changes >>> > /etc/resolv.conf or equivalent" with "application makes the choice for >>> the >>> > user". >>> >>> 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 >>> > nub. >>> >>> 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 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. >> >> >> 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. >> >> >> 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"? > > >> >> 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. >> >> ___ > 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
Re: [DNSOP] [Ext] Re: New draft for consideration:
On Sun, 24 Mar 2019 at 17:17, Joel Jaeggli wrote: > > > On Mar 24, 2019, at 08:59, Matthew Pounsett wrote: > > > > On Sun, 24 Mar 2019 at 11:46, Paul Hoffman wrote: > >> >> > I'm also not too hot for conflating "user consciously changes >> > /etc/resolv.conf or equivalent" with "application makes the choice for >> the >> > user". >> >> 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 >> > nub. >> >> 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 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. > > > 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. > > > 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"? > > 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. > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: New draft for consideration:
> On Mar 24, 2019, at 08:59, Matthew Pounsett wrote: > > > >> On Sun, 24 Mar 2019 at 11:46, Paul Hoffman wrote: >> >> > I'm also not too hot for conflating "user consciously changes >> > /etc/resolv.conf or equivalent" with "application makes the choice for the >> > user". >> >> 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 >> > nub. >> >> 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 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. > > 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. 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 >RDoT or DoH to a resolver that is not the same as the resolver configured >in the traditional location for the operating system. > > ___ > 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
Re: [DNSOP] [Ext] Re: New draft for consideration:
On Sun, 24 Mar 2019 at 11:46, Paul Hoffman wrote: > > > I'm also not too hot for conflating "user consciously changes > > /etc/resolv.conf or equivalent" with "application makes the choice for > the > > user". > > 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 > > nub. > > 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 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: New draft for consideration:
I don't like it either because DAO is a well known acronym for Data Access Object. On Sun, Mar 24, 2019 at 12:49 PM Warren Kumari wrote: > > > On Sun, Mar 24, 2019 at 11:46 AM Paul Hoffman > wrote: > >> On Mar 24, 2019, at 11:18 AM, bert hubert >> wrote: >> > 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)." >> >> 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. >> > > > 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? > > > W > > > >> >> > 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 fully agree; proposed changes to this wording are quite welcome. It's a >> new term, after all. >> >> > I'm also not too hot for conflating "user consciously changes >> > /etc/resolv.conf or equivalent" with "application makes the choice for >> the >> > user". >> >> 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 >> > nub. >> >> 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 >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > > -- > 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 > ___ > 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
Re: [DNSOP] [Ext] Re: New draft for consideration:
On Sun, Mar 24, 2019 at 4:49 AM Warren Kumari wrote: > > > On Sun, Mar 24, 2019 at 11:46 AM Paul Hoffman > wrote: > >> On Mar 24, 2019, at 11:18 AM, bert hubert >> wrote: >> > 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)." >> >> 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. >> > > > 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? > 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 > > > W > > > >> >> > 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 fully agree; proposed changes to this wording are quite welcome. It's a >> new term, after all. >> >> > I'm also not too hot for conflating "user consciously changes >> > /etc/resolv.conf or equivalent" with "application makes the choice for >> the >> > user". >> >> 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 >> > nub. >> >> 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 >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > > -- > 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 > ___ > 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
Re: [DNSOP] [Ext] Re: New draft for consideration:
On Sun, Mar 24, 2019 at 11:46 AM Paul Hoffman wrote: > On Mar 24, 2019, at 11:18 AM, bert hubert > wrote: > > 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)." > > 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. > 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? W > > > 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 fully agree; proposed changes to this wording are quite welcome. It's a > new term, after all. > > > I'm also not too hot for conflating "user consciously changes > > /etc/resolv.conf or equivalent" with "application makes the choice for > the > > user". > > 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 > > nub. > > 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 > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: New draft for consideration:
On Mar 24, 2019, at 11:18 AM, bert hubert wrote: > 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)." 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. > 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 fully agree; proposed changes to this wording are quite welcome. It's a new term, after all. > I'm also not too hot for conflating "user consciously changes > /etc/resolv.conf or equivalent" with "application makes the choice for the > user". 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 > nub. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
