Subject: Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 20 Nov 2018 17:07:17 +0530

On Mon, Nov 19, 2018 at 05:04:14PM +0100, bert hubert wrote:
> On Mon, Nov 19, 2018 at 03:39:16PM +0000, 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 <implementation> 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 authoritative
servers would prefer to do to get rid of state - resolvers can't rely on
having long-lived connections.

This has become a rant but I'm unhappy about the process that is pushing
new DNS features without sufficient evaluation. Modifying the transport
of DNS without studies may affect performance and scalability that we
may come to regret.

		Mukund

---

From: Jacques Latour <[email-masked]>
Date: Tue, 20 Nov 2018 19:38:34 +0000

+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 <[email-masked]> On Behalf Of Mukund Sivaraman
Sent: November 20, 2018 6:37 AM
To: [email-masked]
Subject: Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?

On Mon, Nov 19, 2018 at 05:04:14PM +0100, bert hubert 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.

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 <implementation> 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 authoritative servers would prefer to do to get rid of state - resolvers can't rely on having long-lived connections.

This has become a rant but I'm unhappy about the process that is pushing new DNS features without sufficient evaluation. Modifying the transport of DNS without studies may affect performance and scalability that we may come to regret.

		Mukund

_______________________________________________
dns-privacy mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Christian Huitema <[email-masked]>
Date: Tue, 20 Nov 2018 20:44:42 -0800

> +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…

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

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Nov 2018 11:54:07 +0700

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 <[email-masked]> wrote:
>

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 21 Nov 2018 08:39:52 +0100 (CET)

> Il 21 novembre 2018 alle 5.44 Christian Huitema <[email-masked]> ha scritto:
> 

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
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Christian Huitema <[email-masked]>
Date: Wed, 21 Nov 2018 12:17:42 -0800

> 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, import…

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

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 22 Nov 2018 11:03:10 +0100 (CET)

> Il 21 novembre 2018 alle 21.17 Christian Huitema <[email-masked]> ha scritto:
> 
> 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

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.

> usage patterns to third parties can reveal work in progress, internal

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,
--

---

From: Barry Raveendran Greene <[email-masked]>
Date: Thu, 22 Nov 2018 07:29:58 -0500

> On Nov 21, 2018, at 15:17, Christian Huitema <[email-masked]> 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. 

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.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 22 Nov 2018 16:26:21 +0000

> 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 D…

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, 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 wor…

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.

> 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…

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 22 Nov 2018 16:29:14 +0000

> 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

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 22 Nov 2018 22:38:21 +0100

Moin!

On 22 Nov 2018, at 17:26, Paul Hoffman wrote:
> 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.
Well everybody can send random protocols over the Internet without 
standardisation. It usually works. We still have standards for lots of 
stuff usually because we want it to become ubiquitous. If privacy was 
the only concern there is an older protocol you should be aware of 
(RFC7858 ;-) that can accomplish that. RFC8484 is just adding another 
layer beside it for those who only understand http ;-).

> 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.
Well there is a cost for deploying these protocols. This cost can be 
easily absorbed by the companies that have a large web presence already, 
are distributed worldwide and might even gain a commercial advantage by 
directly talking to the end users. These costs are harder for ISP who 
are used to handle hundreds of thousands of users with a single DNS 
server.

Also on the centralising aspect there are single digit browser vendors, 
maybe double digit OS vendors, but there are multiple thousands of ISP 
around the world and usually also a lot of different ones in a country a 
user can choose from. So any singular decisions on browser or OS vendors 
has a much larger impact than what an ISP can do with it. Pointing this 
out especially as there were steps taken by browser vendors that could 
lead towards that centralisation is a valid point IMHO.

And to be honest I personally think that name resolution is an OS 
function and not something an application should do, but I’m just an 
old grey bearded unix sysadmin.

So long
-Ralf
—--
Ralf Weber

---

From: Paul Wouters <[email-masked]>
Date: Fri, 23 Nov 2018 12:58:49 +0700

> 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

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 23 Nov 2018 11:45:21 +0100 (CET)

>     Il 22 novembre 2018 alle 17.26 Paul Hoffman < [email-masked] mailto:[email-masked] > ha scritto:
> 
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 wh…
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
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 23 Nov 2018 16:45:39 +0000

On Nov 23, 2018, at 2:45 AM, Vittorio Bertola <[email-masked]> wrote:
> 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

---

From: Ray Bellis <[email-masked]>
Date: Mon, 26 Nov 2018 14:31:52 +0000

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Nov 2018 15:37:22 +0000

On Nov 26, 2018, at 6:31 AM, Ray Bellis <[email-masked]> 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.
> 

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.

> the way allow JS web-apps to perform proper DNS lookups.

Fully agree. That is indeed what the RFC says.

> 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

---

From: Ray Bellis <[email-masked]>
Date: Mon, 26 Nov 2018 15:50:41 +0000

> 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

---

From: "John Levine" <[email-masked]>
Date: 26 Nov 2018 13:48:30 -0500

>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.)

> such.  The vast majority of what I'm hearing are complaints about the

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

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 26 Nov 2018 14:35:53 -0800

> >> 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/