Re: [Doh] Authoritative DoT or DoH

[Ted Hardie <[e-mail]>]

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

On Fri, Mar 15, 2019 at 7:56 AM Ian Swett <ianswett=
[e-mail]> wrote:

> 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.
>
>
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.
>
> 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
>>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>