Re: [Doh] [Ext] DNS over HTTP/3?

[Paul Hoffman <[e-mail]>]

On Nov 19, 2018, at 2:09 AM, bert hubert <[e-mail]> wrote:
> 
> Hi everyone,
> 
> Now that we are still here, perhaps some work is left for us, but I'm not
> sure. 
> 
> I've observed that the thousands of users of doh.powerdns.org (I also do not
> know how this happened) take around 22 packets per DNS query/response. 

It would be valuable to know if this is this because your DoH server kills the entire connection after every DNS query, or because the clients are doing so.

> Larger scale adoption of TLSv1.3 might improve this somewhat, but it is a
> big number.

DoH was designed for long-lived connections, so the number would normally be smaller after the initial connection.

> I've also personally observed that a "slightly suboptimal" network
> absolutely kills browsing performance in Firefox Nightly using DoH.  A naive
> calculation shows that 0.5% packet loss turns into a 5% failure rate per DoH
> query, which then can cause Head of Line blocking for further queries, which
> cascades into "blank pages" getting rendered. 

When you say "naive calculation", do you mean this is observed in the clients hitting your DoH server? That would indeed be scary. However, the Mozilla numbers tell a very different story. It would be good to know which one is true.

> Of course, once we have HTTP/3, DNS over HTTP/3 would suffer way less from
> incidental packet loss, and in general there would be a lot less packets
> too.
> 
> My question now is, is there any specific work to be done for DoH/3? Are
> there number, priorities, features you'd want or not want to use to make
> things work well?

DoH is just a specification for how to do a normal HTTP interaction, so there should be litter or no changes to DoH if the transport under HTTP changes. We'll know more when HTTP/3 is finished, but probably not before then.

> In other words, to the sound of a groaning camel, do we need a draft? Or a
> section in the HTTP/3 I-D?

We might, but we can't tell now.

> And, perhaps somewhat more provocatively, should we maybe not start pushing
> DoH/2 if it leaves people with a sub-standard experience, causing them to
> disable DoH?

If the implementations on the client or server side make using DoH bad, those implementations should be fixed. If they don't get fixed, we'll certainly hear about it.

> DoH/3 might be somewhat of a wait but it might prevent that
> sour taste from developing.

Without sufficient data, it's hard to say if there really is a sour taste.

--Paul Hoffman