Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
Paul Hoffman writes: > >> During the development of the DoH standard, people from many DNS > >> vendors (including the one you work for) contributed to the spec > >> without objection in the WG. [snip other comments] One issue with the IETF specifications is that we allow for, and should allow for, publication of specifications that enable interoperability. What we fail to do (well) is provide guidance on when a specification is applicable to a problem space, and when it should and when it SHOULD NOT be used. Sometimes on "Operational Considerations" section helps out in this regard, but frequently not fully in part because people/companies/etc find new and unique ways of using new protocols in ways people hadn't thought of. But I digress from the real problem... So the question is: Yes, if it's possible to do DNS over HTTP should everyone use it? This is where the discussion seems to be concentrating, and is what we should be discussing. However, I argue that this has nothing to do with whether or not it should have been published as an RFC. Personally speaking, I don't think it's the right solution for "most uses". Much of the time I may trust my local, small ISP more than the large corporations that are offering some of the global DoH or even generic DNS resolution services. And as I switch places, my trust may change (my local, interdependent coffee shop is a "maybe" but a large chain, "probably not"). I really need a "which do you trust more? A or B?" choice when making network switches (with saving of preference). But, a few wise large entities are making the decisions for us instead. A we large companies are standing up expensive infrastructure and advertising them using easy addresses saying 'use us, use us'. Other organizations are hard(ish)-coding what you should use in their software, often pointing toward these large DoH resolver beds. So now we are trending toward a lot of software sending all DNS queries to a single or a small set of companies implementing global infrastructure. Now, no where above am I saying "this is bad" or "that is bad". I'm not sure which is preferred. Which is better: a light weight protocol with local caching that is potentially manipulated or sniffed by local on-path-attackers (which could be someone you have no choice but to use), or a more complex set of multiple layering protocols that point toward a small number of service providers? The answer is likely different per person, per organization, etc. What I want where I live is likely very different than what I might want behind a border with significant DNS rewriting. So, DoH is hardly "bad" itself. It's the wrong decision for me in some locations at some times. But the standardization of an interoperable specification in an RFC doesn't ramp up use (as Paul has been saying). The use was ramping up because a few smart companies realized they could follow Google's model of standing up a public resolver that everyone would want to use, then negotiating the use of those resolvers with some software companies to get it deployed. I don't object to DoH. I think it's a critically important protocol for protecting the privacy and usability of DNS is certain situations. That doesn't mean I want to use it everywhere, even though that's what we're trending toward. [that was a bit rambly; sorry] -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://blog.capturedonearth.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
In article <57202511-6de3-4bea-b65e-afbcaff40...@bellis.me.uk> you write: >(I meant UKNOF, not UKNOT) > >https://www.youtube.com/watch?v=3tMGD6J04Jk > >Sara took a *lot* of off-mic discussion after that session, too. I gather mandatory DNS blocks like this are common throughout Europe, with targets mostly being child abuse material and terrorism with a smattering of other stuff like Pirate Bay. We may or may not like it, but systematically circumventing the blocks presents issues. (Everyone knows that individuals can switch DNS providers. It's the systematic part that's a problem.) > I'm don't beleive that we are hearing many complaints about the spec as > such. The vast majority of what I'm hearing are complaints about the > deployment model. When I first heard about DoH I understood it to be a way for javascript apps to do DNS queries for SRV and the like, with the queries being sent back to wherever the js code came from. I don't think that's controversial. Using it to systematically circumvent a system's standard DNS resolution (for whatever standard means) is a very different issue. It has both technical problems, e.g., split horizon DNS within organizations, and the political ones. R's, John ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
On 26/11/2018 15:37, Paul Hoffman wrote: Ah! That is interesting to hear. Any links that you have to that would be greatly appreciated. (I meant UKNOF, not UKNOT) https://www.youtube.com/watch?v=3tMGD6J04Jk Sara took a *lot* of off-mic discussion after that session, too. You may feel differently, but I saw no comments during WG or IETF Last Call that indicated that any mismatches still existed. If you feel that they do, the DOH WG is still open, and a draft describing the problems could garner interest. I believe that the protocol level impedance mismatches were resolved by WGLC. The big one of course was the packet size discussion. Then why aren't the objections aimed at that implementer instead of the spec? Any implementer can misuse any spec badly: that doesn't make the spec itself bad. The operational documents that come to the DNSOP WG are often about those situations. I'm don't beleive that we are hearing many complaints about the spec as such. The vast majority of what I'm hearing are complaints about the deployment model. Ray ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
On Nov 26, 2018, at 6:31 AM, Ray Bellis wrote: > > On 23/11/2018 16:45, Paul Hoffman wrote: > >> The current round of pushback, all of which appeared after the standard was >> finished, seems to mostly be coming from DNS vendors, not ISPs or DNS >> operators. > > There was _plenty_ of pushback when this got presented at UKNOT, > especially among those ISPs that are currently using government- > mandated DNS-based blocking of CAI sites. Ah! That is interesting to hear. Any links that you have to that would be greatly appreciated. > >> During the development of the DoH standard, people from many DNS vendors >> (including the one you work for) contributed to the spec without objection >> in the WG. > > I wouldn't say it was "without objection", because there were clearly some > significant impedance mismatches to resolve, both between the HTTP and DNS > people, and between the HTTP and DNS protocols. You may feel differently, but I saw no comments during WG or IETF Last Call that indicated that any mismatches still existed. If you feel that they do, the DOH WG is still open, and a draft describing the problems could garner interest. > Personally, I thought we were working on a means to provide an *ad-hoc* > DNS resolution and validation method in certain environments, and along > the way allow JS web-apps to perform proper DNS lookups. Fully agree. That is indeed what the RFC says. > The objections started when we heard that a particular browser vendor > wanted to make this ubiquitous for *all* DNS lookups. Then why aren't the objections aimed at that implementer instead of the spec? Any implementer can misuse any spec badly: that doesn't make the spec itself bad. The operational documents that come to the DNSOP WG are often about those situations. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
On 23/11/2018 16:45, Paul Hoffman wrote: The current round of pushback, all of which appeared after the standard was finished, seems to mostly be coming from DNS vendors, not ISPs or DNS operators. There was _plenty_ of pushback when this got presented at UKNOT, especially among those ISPs that are currently using government- mandated DNS-based blocking of CAI sites. During the development of the DoH standard, people from many DNS vendors (including the one you work for) contributed to the spec without objection in the WG. I wouldn't say it was "without objection", because there were clearly some significant impedance mismatches to resolve, both between the HTTP and DNS people, and between the HTTP and DNS protocols. Personally, I thought we were working on a means to provide an *ad-hoc* DNS resolution and validation method in certain environments, and along the way allow JS web-apps to perform proper DNS lookups. The objections started when we heard that a particular browser vendor wanted to make this ubiquitous for *all* DNS lookups. Ray ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
On Nov 23, 2018, at 2:45 AM, Vittorio Bertola wrote: >> Please stop with the "IETF is disrupting" stuff. No one forces anyone to use >> DoT or DoH. Both were features that the user communities asked for, and the >> user communities will ask for changes when they get deployed. > Which user communities are you referring to? Users of browsers. > It doesn't look like there is much request for DoH in the ISP and DNS > operator community - actually, I see more and more pushback. The current round of pushback, all of which appeared after the standard was finished, seems to mostly be coming from DNS vendors, not ISPs or DNS operators. During the development of the DoH standard, people from many DNS vendors (including the one you work for) contributed to the spec without objection in the WG. > If you talk about the end-users of the Internet, where and when did they ask > for this, and how many users actually want this? By choosing a browser. That's the best metric we have, unfortunately, since most of them can't choose their ISP based on the type of DNS service their ISP offers. > Because I am quite sympathetic with any dissident community under > authoritarian regimes, but in Europe there currently are millions of > end-users that use DNS-based security and parental control filters, for > example. The ratio would be something like 10'000 people who happily and > voluntarily ask their ISP to, as you say, "lie" on DNS queries (and will lose > this service if their browser starts to direct their DNS queries somewhere > else) We cannot be sure that they will lose such a service: we still have no idea how browser vendors will offer DoH. I suspect that if they offer it in a way that causes users to get fewer of the services that they have now, those browsers will (correctly) get castigated. > for every dissident that absolutely needs Cloudflare to get all his DNS > queries by default because he is planning to overthrow the government but > does not know how to get into Firefox's preferences and manually set the name > server to 1.1.1.1. (Technical note: Firefox never sent DoH queries to 1.1.1.1.) > Sorry if I am being sarcastic, but these DoH "pro user" claims sounds quite > unrealistic to me, and just an excuse for business interests and more Silicon > Valley data greediness - or, as a minimum, they reflect an incomplete, > partial view of what users want. We fully agree here. There are no good metrics for why users pick one browser over another. In their absence, we have to assume gross overall usage which is absolutely "an incomplete, partial view of what users want". But the same is true fo how they pick an ISP based on that ISP's DNS service offerings. As PaulW pointed out earlier in the thread, we know that many ISPs give local addresses to a resolver that simply forwards to 8.8.8.8 (or presumably to other open resolvers). Users have zero visibility to those practices as well. This thread comes down to "we think applications should not do X", as if we have now become the application police. It's fine to say "doing X has these negative effects" so that the application vendors will become aware of that, but we still have no idea if any application will even do X at this point. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
> Il 22 novembre 2018 alle 17.26 Paul Hoffman < paul.hoff...@icann.org > mailto:paul.hoff...@icann.org > ha scritto: > > DoH did not suddenly allow browser vendors to do something new: they've > been able to do exactly what DoH is standardizing for more than 20 years. > Saying that the IETF is reducing the privacy is completely incorrect. What > the DoH standard did is make it so that browser vendors (and, to a much > smaller extent, web applications) could reach a larger variety of DNS servers > in a standardize way. > > If you want to prevent over-centralization of queries going to a small > number of large resolvers, you should be making it easier for resolver > operators of all sizes to become DoH servers. It looks like your company is > doing exactly that: thank you! > Well, we love privacy and user rights, so of course we are all in favour of that extra privacy that comes from encrypting your connection to the resolver - but you could get it without any need to put four global browser makers in charge of the decision on who resolves the names for at least 90% of the entire planet. In my opinion, the only positive way forward from this situation would be that all ISPs deploy DoT and/or DoH on their front-end (and yes, as Ralf Weber is also noting, perhaps that would not even be so necessary for many smaller ISPs, as no one is spying on their last mile connections and the cost/benefit ratio of this deployment is terrible, but now they are basically forced to do so, lest be labeled as government cronies that endanger freedom of expression) and that browser makers commit to using the local resolver as a default and only use their own if the user makes an explicit choice for it. So this is what we are trying to make happen from our side, as one of the resolver software makers, but on the other side, this is not what Mozilla has said they will do. But even in this scenario, even if we had thousands of DoH servers around the world, I am afraid that the centralization would happen all the same, just thanks to the gatekeeper role over the DNS that DoH attributes to popular application makers. I am old enough to remember when Microsoft killed Netscape in a very short time, just by using their control of the operating system to make using Internet Explorer much easier. Nowadays the browsers are the operating system of the Internet for the average user, and they could easily prompt the user to use whatever service they want. > Please stop with the "IETF is disrupting" stuff. No one forces anyone to > use DoT or DoH. Both were features that the user communities asked for, and > the user communities will ask for changes when they get deployed. > Which user communities are you referring to? It doesn't look like there is much request for DoH in the ISP and DNS operator community - actually, I see more and more pushback. If you talk about the end-users of the Internet, where and when did they ask for this, and how many users actually want this? Because I am quite sympathetic with any dissident community under authoritarian regimes, but in Europe there currently are millions of end-users that use DNS-based security and parental control filters, for example. The ratio would be something like 10'000 people who happily and voluntarily ask their ISP to, as you say, "lie" on DNS queries (and will lose this service if their browser starts to direct their DNS queries somewhere else) for every dissident that absolutely needs Cloudflare to get all his DNS queries by default because he is planning to overthrow the government but does not know how to get into Firefox's preferences and manually set the name server to 1.1.1.1. Sorry if I am being sarcastic, but these DoH "pro user" claims sounds quite unrealistic to me, and just an excuse for business interests and more Silicon Valley data greediness - or, as a minimum, they reflect an incomplete, partial view of what users want. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
On Nov 22, 2018, at 19:29, Barry Raveendran Greene wrote: > > > > > The “trade off” to move the DNS architecture away from residents to privacy > is going to get people killed. Since ISPs are doing this themselves already at large scale (use 8.8.8.8 instead of their own), I find the argument for the end user not to do so a little weak. Similarly, having your DNS eavesdropped or filtered by a nation state is putting people at risk too. Enterprise DNS filtering sounds nice until the government uses it as an authoritarian tool. That surely will kill people. Paul ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
On Nov 22, 2018, at 4:29 AM, Barry Raveendran Greene wrote: > The irony is that this work is operationally destabilizing to the Internet > and Telecom. We’re moving to an environment where the strength of a resilient > ASN recovering communications in a disaster will be tested over and over > again. How will an ASN keep critical services on-line when they are > disconnected from the “cloud,” disconnected from their upstream, and now > “disconnected from the DNS resolution path? > > Exasperated customer calling after a hurricane, “ISP customer service, I need > to get to emergency services, but my app will not work.” The ISP responds > with “sorry, that app will not work in a situation where we’re struggling > with emergency services.” > > The “trade off” to move the DNS architecture away from residents to privacy > is going to get people killed. If a browser forces DoH in cases where there are no working DoH servers, that will absolutely be the case. It will even be the case if the user can manually turn off DoH, but only if the user know the correct UI incantation. It is reasonable to assume (but not assured) that browser vendors are aware of this. --Paul smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
On Nov 22, 2018, at 2:03 AM, Vittorio Bertola wrote: > > > >> Il 21 novembre 2018 alle 21.17 Christian Huitema ha >> scritto: >> >> You make it sound like some aggressive attack, but it is a trade-off. >> The IETF is working to enhance the privacy of DNS users, > > I'd argue the opposite - what the IETF is doing is in the overall reducing > the privacy of DNS users, by trading some more privacy in transport with much > less privacy due to more centralization of DNS resolution operations on a > global scale, and to an uncontrollable mess of applications each one starting > to send DNS queries to whatever server they like without the user having any > practical control mechanism, or even knowing what's happening. DoH did not suddenly allow browser vendors to do something new: they've been able to do exactly what DoH is standardizing for more than 20 years. Saying that the IETF is reducing the privacy is completely incorrect. What the DoH standard did is make it so that browser vendors (and, to a much smaller extent, web applications) could reach a larger variety of DNS servers in a standardize way. If you want to prevent over-centralization of queries going to a small number of large resolvers, you should be making it easier for resolver operators of all sizes to become DoH servers. It looks like your company is doing exactly that: thank you! >> and the >> authenticity of DNS responses. Doing so inevitably affects the >> operations that relied on the lack of privacy or lack of security of DNS >> operations. > > Well, no. Except for a few cases (e.g. transparent DNS proxying), DNS-based > security techniques do not rely on the "lack of privacy of DNS operations", > and the proof is that they would continue working perfectly well with DoT or > DoH, as long as the user continued to use the resolver on the local network. Saying that transparent DNS proxying (firewall capture and re-writing) is "a few cases" belies what people in the firewall industry have known for years: DNS rewriting (also known as "DNS lies") is an extremely popular feature in firewalls of all sizes. > Instead, DNS-based security techniques rely on the assumption that there will > be only one name server for all the applications on the user's device, and > that that server will be, at least by default, the one advertised by the > local network. If we had universal deployment of organizational VPNs, that could be true. Even after 20 years, we are sadly far from there. > This is the assumption that the IETF is disrupting, and that breaks a lot of > stuff that has full rights to exist and has nothing to do with invading the > user's privacy. Please stop with the "IETF is disrupting" stuff. No one forces anyone to use DoT or DoH. Both were features that the user communities asked for, and the user communities will ask for changes when they get deployed. > >> Also, if you analyze the enterprise scenarios, you observe a need for >> both management and privacy. Enterprise managers would rather not see >> employees perusing frivolous web pages during work time, but they also >> don't want outside parties to analyze their web activities. Leaking DNS >> usage patterns to third parties can reveal work in progress, internal >> research, etc. > > Which is exactly what happens if the enterprise's users start being > automatically connected to a DNS resolution service outside the local network > and managed by a third party, which is what DoH is doing. If a browser's use of DoH breaks its users resolution of organizational names, it will get fixed or turned off. (I'm betting on the latter, but others have more faith in the browser vendors fixing than I do.) --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
> On Nov 21, 2018, at 15:17, Christian Huitema wrote: > > You make it sound like some aggressive attack, but it is a trade-off. > The IETF is working to enhance the privacy of DNS users, and the > authenticity of DNS responses. Doing so inevitably affects the > operations that relied on the lack of privacy or lack of security of DNS > operations. The irony is that this work is operationally destabilizing to the Internet and Telecom. We’re moving to an environment where the strength of a resilient ASN recovering communications in a disaster will be tested over and over again. How will an ASN keep critical services on-line when they are disconnected from the “cloud,” disconnected from their upstream, and now “disconnected from the DNS resolution path? Exasperated customer calling after a hurricane, “ISP customer service, I need to get to emergency services, but my app will not work.” The ISP responds with “sorry, that app will not work in a situation where we’re struggling with emergency services.” The “trade off” to move the DNS architecture away from residents to privacy is going to get people killed. For those who think I’m being harsh, please go volunteer some time during a communications recovery operation. Go see what happens during/after a hurricane, flood, or one of the many other increasing chaotic environmental consequences. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
> Il 21 novembre 2018 alle 21.17 Christian Huitema ha > scritto: > > You make it sound like some aggressive attack, but it is a trade-off. > The IETF is working to enhance the privacy of DNS users, I'd argue the opposite - what the IETF is doing is in the overall reducing the privacy of DNS users, by trading some more privacy in transport with much less privacy due to more centralization of DNS resolution operations on a global scale, and to an uncontrollable mess of applications each one starting to send DNS queries to whatever server they like without the user having any practical control mechanism, or even knowing what's happening. > and the > authenticity of DNS responses. Doing so inevitably affects the > operations that relied on the lack of privacy or lack of security of DNS > operations. Well, no. Except for a few cases (e.g. transparent DNS proxying), DNS-based security techniques do not rely on the "lack of privacy of DNS operations", and the proof is that they would continue working perfectly well with DoT or DoH, as long as the user continued to use the resolver on the local network. Instead, DNS-based security techniques rely on the assumption that there will be only one name server for all the applications on the user's device, and that that server will be, at least by default, the one advertised by the local network. This is the assumption that the IETF is disrupting, and that breaks a lot of stuff that has full rights to exist and has nothing to do with invading the user's privacy. > Also, if you analyze the enterprise scenarios, you observe a need for > both management and privacy. Enterprise managers would rather not see > employees perusing frivolous web pages during work time, but they also > don't want outside parties to analyze their web activities. Leaking DNS > usage patterns to third parties can reveal work in progress, internal > research, etc. Which is exactly what happens if the enterprise's users start being automatically connected to a DNS resolution service outside the local network and managed by a third party, which is what DoH is doing. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
On 11/20/2018 11:39 PM, Vittorio Bertola wrote: >> Il 21 novembre 2018 alle 5.44 Christian Huitema ha >> scritto: >> >> Maybe. Over time various entities have developed control techniques that >> work by limiting which domains are resolved in a particular context, and >> how they are resolved. But at the same time, the DNS is a widely >> distributed database accessible through thousands of servers. Given this >> wide availability, do you really believe that these control techniques >> are stable in the long run? > I would actually reverse the question: do you really think that the IETF > should work to destabilize these control techniques (as it has been doing), > rather than to make them more stable and, importantly, more transparent, > standardized and accessible to everyone? You make it sound like some aggressive attack, but it is a trade-off. The IETF is working to enhance the privacy of DNS users, and the authenticity of DNS responses. Doing so inevitably affects the operations that relied on the lack of privacy or lack of security of DNS operations. At the same time, I observe that the techniques that try to block access to DNS data from the middle of the network are fundamentally unstable, because DNS data is widely available. If DTLS or DoH were not available, users that want the data would just use private VPNs or a variety of private proxies. The real challenge is thus to provide management techniques that do not require intercepting traffic in flight, in particular for the enterprise scenario in which the clients "opts in" management control. Also, if you analyze the enterprise scenarios, you observe a need for both management and privacy. Enterprise managers would rather not see employees perusing frivolous web pages during work time, but they also don't want outside parties to analyze their web activities. Leaking DNS usage patterns to third parties can reveal work in progress, internal research, etc. -- Christian Huitema ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
> Il 21 novembre 2018 alle 5.44 Christian Huitema ha > scritto: > > Maybe. Over time various entities have developed control techniques that > work by limiting which domains are resolved in a particular context, and > how they are resolved. But at the same time, the DNS is a widely > distributed database accessible through thousands of servers. Given this > wide availability, do you really believe that these control techniques > are stable in the long run? I would actually reverse the question: do you really think that the IETF should work to destabilize these control techniques (as it has been doing), rather than to make them more stable and, importantly, more transparent, standardized and accessible to everyone? Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
With dnssec yes. The publisher is then the only one in control. This is why it is so problematic that the browsers have pushed back instead of working with the dns people. When personal VPNs became a thing, it didn’t take long for 90% of the VPN “apps” to become malicious, redirecting DNS, monitor DNS, change DNS. It will be the same with all the DoH and DoT services. Now more then ever do we need origin authentication that dnssec offers, and which is why I push back on everyone saying DoH/DoT offers a dnssec replacement. Sent from mobile device > On Nov 21, 2018, at 11:44, Christian Huitema wrote: > >> On 11/20/2018 11:38 AM, Jacques Latour wrote: >> >> +1 & I don't like the path is going as well, and specifically from an >> enterprise security point of view. Having DNS resolution that can bypass >> traditional enterprise security mechanisms is adding another layer of >> complexity to manage, you can't have a free for all in domain name >> resolution in enterprise networks. I could go on, but I just want to say " >> I don't like the path is going". > > Maybe. Over time various entities have developed control techniques that > work by limiting which domains are resolved in a particular context, and > how they are resolved. But at the same time, the DNS is a widely > distributed database accessible through thousands of servers. Given this > wide availability, do you really believe that these control techniques > are stable in the long run? > > -- Christian Huitema > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
On 11/20/2018 11:38 AM, Jacques Latour wrote: > +1 & I don't like the path is going as well, and specifically from an > enterprise security point of view. Having DNS resolution that can bypass > traditional enterprise security mechanisms is adding another layer of > complexity to manage, you can't have a free for all in domain name resolution > in enterprise networks. I could go on, but I just want to say " I don't like > the path is going". Maybe. Over time various entities have developed control techniques that work by limiting which domains are resolved in a particular context, and how they are resolved. But at the same time, the DNS is a widely distributed database accessible through thousands of servers. Given this wide availability, do you really believe that these control techniques are stable in the long run? -- Christian Huitema ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
+1 & I don't like the path is going as well, and specifically from an enterprise security point of view. Having DNS resolution that can bypass traditional enterprise security mechanisms is adding another layer of complexity to manage, you can't have a free for all in domain name resolution in enterprise networks. I could go on, but I just want to say " I don't like the path is going". Jack -Original Message- From: dns-privacy On Behalf Of Mukund Sivaraman Sent: November 20, 2018 6:37 AM To: dns-privacy@ietf.org Subject: Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3? On Mon, Nov 19, 2018 at 05:04:14PM +0100, bert hubert wrote: > On Mon, Nov 19, 2018 at 03:39:16PM +, Paul Hoffman wrote: > > > It does around 2 DNS queries per HTTPS connection on average > > > dnsdist-doh keeps open an HTTP/2 connection for 10 seconds if it becomes > > > idle. > > > > Thanks, that seems to be your problem. Can the dnsdist DoH server > > package be configured to have an idle timeout that is more > > representative of typical browser use, such as on the order of minutes? > > I have measured with timeout of 100 seconds and 300 seconds. In both > cases, the packets per query ratio drops to 12, from 22. This is still > around 6 times more than UDP, and I now carry around hundreds of > additional filedescriptors. But ok. This is not specifically about DoH, but I don't like the path DNS is taking. I don't like the general push to heavy protocols for DNS and have often commented about it on dprive and dnsop. DNS historically has been mostly a light-weight single-request single-response stateless protocol (TCP is used as a last resort vs. UDP that's used in preference). The addition of a privacy layer could add more weight, but we seem to be uninterested in exploring other stateless or low-state ideas, outside TLS and even QUIC. After the resolver work, the phase-2 introduction for resolver<->auth communications[1] started with TLS which seemed illogical to me. There must be empirical studies of consequences before protocols push through to RFC. People such as Sara Dickinson at Sinodun have been studying the performance and scalability of the privacy layer in DNS implementations which is very commendable. [1] https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth-01 Some people such as Brian Haberman have taken an initiative to gather requirements for resolver-auth privacy instead of jumping directly to design which is again commendable. dnsop and dprive should study this before pushing drafts to RFCs. What is the worst case on resource utilization, number of round-trips and number of packets to implement these layers? What could happen on average in practice? Large operators who plan ahead ask these questions. Can handle TCP and DNS over TLS and DNS over HTTPS in a future world at rates similar to UDP now? I can picture the overhead for UDP and TCP, but it is a lot more complicated with the extra layers. It's not ok to assume and hand-wave away that optimizations such as TCP fastopen will avoid roundtrips and make up for performance. A TCP client may not have a cookie for the average nameserver case for the SYN except if it is for a "CDN/cloud" concentrated nameserver. I'm afraid these things will encourage more concentration for performance vs. keeping the internet distributed. Facilities such as TCP fastopen are also experimental and we should not rely on them until more time has passed. Server-side support for it is still turned off by default in current versions of popular Linux distributions (a system-level setting that can't be enabled by applications such as a nameserver). Resolvers such as BIND have not yet implemented TCP fastopen for making connections. fastopen also suggests downgrades globally to regular 3-way TCP handshake from fastopen when there is a flood, which is not an attack in the regular sense, but loses the fastopen optimization if DNS relies on it to perform satisfactorily. DNS is not a special protocol, but it is at the head of every internet activity. It has to perform well and scale well. The chairs should encourage studies into stateless methods to do privacy with low roundtrip overhead. Other protocols pay heed to stateless methods, e.g., DNS COOKIE is stateless on the server side. TCP fastopen is also stateless on the server side. There is unexpected advice in RFCs too. When TCP fastopen is available for the DNS over TCP case, it seems better for the TCP connection to be closed than it be kept open because the open connection would revert to slow-start phase after an idle period with typical DNS query traffic patterns (unlike replies to a browser's HTTP requests that are typically much larger and more in sequence) unless it is continually active. In a greedy world, closing idle connections is something that
