Subject: [Doh] Authoritative DoT or DoH

From: "Henderson, Karl" <[email-masked]>
Date: Thu, 14 Mar 2019 19:18:13 +0000

In the last couple of days there has been a lot of activity concerning DNS over HTTPS (DoH) - Hoffman and Alibaba presentations at ICANN and IETF drafts: draft-reid-doh-operator/draft-livingood-doh-implementation-risks-issues/draft-betola-bcp-doh-clients.

These discussions have focused on DoH for client (typically web browser) communication with recursive resolvers, and its comparisons with DoT for this purpose.

Is there any compelling reason at this point to be considering DoH for recursive resolver-to-authoritative name server communications?

As I noted at the DPRIVE interim meeting, the working group needs empirical studies looking at performance and attack vectors for authoritative DNS encryption.

Unless there are compelling reasons to consider Authoritative DoH, I propose the working group focus its authoritative DNS encryption assessments around Authoritative DoT.

In support, I am willing to co-author an Authoritative DoT operational consideration draft in order to outline the operational challenges the community needs to address - similar to the draft-reid-doh-operator draft between client and recursive.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 14 Mar 2019 22:27:39 -0400

There is far less reason to use DoH for connections to authoritative servers.  DoT seems far more appropriate (than both DoH and the unencrypted variants).

I expect there to be a lot of discussion about DoS (not DNS over SCTP, sadly) and load management in any such document.  I don't see much of the stuff that has generated so much heat lately to be relevant in the authoritative context.

On Fri, Mar 15, 2019, at 06:18, Henderson, Karl wrote:
>  
> In the last couple of days there has been a lot of activity concerning 
> DNS over HTTPS (DoH) - Hoffman and Alibaba presentations at ICANN and 
> IETF drafts: 
> draft-reid-doh-operator/draft-livingood-doh-implementation-risks-issues/draft-betola-bcp-doh-clients.
> 
> 
> These discussions have focused on DoH for client (typically web 
> browser) communication with recursive resolvers, and its comparisons 
> with DoT for this purpose.
> 
> 
> Is there any compelling reason at this point to be considering DoH for 
> recursive resolver-to-authoritative name server communications?
> 
> 
> As I noted at the DPRIVE interim meeting, the working group needs 
> empirical studies looking at performance and attack vectors for 
> authoritative DNS encryption.
> 
> 
> Unless there are compelling reasons to consider Authoritative DoH, I 
> propose the working group focus its authoritative DNS encryption 
> assessments around Authoritative DoT.
> 
> 
> In support, I am willing to co-author an Authoritative DoT operational 
> consideration draft in order to outline the operational challenges the 
> community needs to address - similar to the draft-reid-doh-operator 
> draft between client and recursive.
> 
> 
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Erik Kline <[email-masked]>
Date: Thu, 14 Mar 2019 20:23:31 -0700

And on account of the load management issues I would expect some folks to
prefer to try out DoQ (DNS over QUIC), does actually bring things back
around to DoH.

On Thu, 14 Mar 2019 at 19:27, Martin Thomson <[email-masked]> wrote:

> There is far less reason to use DoH for connections to authoritative
> servers.  DoT seems far more appropriate (than both DoH and the unencrypted
> variants).
>
> I expect there to be a lot of discussion about DoS (not DNS over SCTP,
> sadly) and load management in any such document.  I don't see much of the
> stuff that has generated so much heat lately to be relevant in the
> authoritative context.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 15 Mar 2019 07:04:36 -0400

DNS over QUIC (either directly, or as DoH with HTTP/3) will likely exacerbate load problems.  QUIC isn't great about its CPU usage at the current time.  That comes with some advantages, like sharing an encryption context for multiple requests without the head of line blocking inherent in HTTP/2, but it's unlikely to be a total slam dunk.

On Fri, Mar 15, 2019, at 14:23, Erik Kline wrote:
> And on account of the load management issues I would expect some folks 
> to prefer to try out DoQ (DNS over QUIC), does actually bring things 
> back around to DoH.
>

---

From: Ian Swett <[email-masked]>
Date: Fri, 15 Mar 2019 10:56:33 -0400

For a DNS or DoH heavy workload, I'd expect QUIC CPU usage to be very
comparable to DoT or DoH over HTTP/2, but obviously crypto isn't free, so
it would be more expensive than plain DNS.

QUIC CPU really suffers when sending(and to a lesser extent receiving) huge
payloads.

On Fri, Mar 15, 2019 at 7:04 AM Martin Thomson <[email-masked]> wrote:

> DNS over QUIC (either directly, or as DoH with HTTP/3) will likely
> exacerbate load problems.  QUIC isn't great about its CPU usage at the
> current time.  That comes with some advantages, like sharing an encryption
> context for multiple requests without the head of line blocking inherent in
> HTTP/2, but it's unlikely to be a total slam dunk.
>
> > >  I expect there to be a lot of discussion about DoS (not DNS over
> SCTP, sadly) and load management in any such document. I don't see much of
> the stuff that has generated so much heat lately to be relevant in the
> authoritative context.
> > >

---

From: Ted Hardie <[email-masked]>
Date: Fri, 15 Mar 2019 09:06:13 -0700

Speaking about DNS over QUIC, not DNS over HTTP over QUIC, a comment in-line

> it would be more expensive than plain DNS.
For the client-to-recursive-resolver case, the big advantage is that the
traffic bursts of queries can work well with both the multiplexing of QUIC
and with 0-RTT.  You can have a burst of queries each resolved on an
independent stream without head of line blocking, then either a low-effort
quiescent connection or 0-RTT resumption.  For an authoritative server of a
large flat zone (like a TLD), you could get a similar advantage by having
the recursive resolvers talk to anycast instances which would be able to
multiplex parallel queries or use 0-RTT to lower the latency of using the
encrypted transport.  For authoritative servers with deep hierarchies or
low utilization, DNS over TLS seems a better fit, since they are less
likely to need the multiplexing (and will get 0-RTT with TLS 1.3).

regards,

Ted

> QUIC CPU really suffers when sending(and to a lesser extent receiving)
> huge payloads.
>