Re: [Doh] Authoritative DoT or DoH

[Ian Swett <[e-mail]>]

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 <[e-mail]> 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.
>
> 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.
> >
> > On Thu, 14 Mar 2019 at 19:27, Martin Thomson <[e-mail]> 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.
> > >
> > >  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
> > >  > [e-mail]
> > >  > https://www.ietf.org/mailman/listinfo/doh
> > >  >
> > >
> > >  _______________________________________________
> > >  Doh mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/doh
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>