Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

"Ralf Weber" <dns@fl1ger.de> Wed, 30 October 2019 12:49 UTC

Return-Path: <dns@fl1ger.de>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67849120811 for <dns-privacy@ietfa.amsl.com>; Wed, 30 Oct 2019 05:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFrIi97b8TUQ for <dns-privacy@ietfa.amsl.com>; Wed, 30 Oct 2019 05:49:20 -0700 (PDT)
Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF27120145 for <dns-privacy@ietf.org>; Wed, 30 Oct 2019 05:49:20 -0700 (PDT)
Received: by nyx.guxx.net (Postfix, from userid 107) id EC1605F40ADE; Wed, 30 Oct 2019 13:49:17 +0100 (CET)
Received: from [172.19.80.120] (rrcs-98-6-232-98.sw.biz.rr.com [98.6.232.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 8C7DE5F403FC; Wed, 30 Oct 2019 13:49:15 +0100 (CET)
From: Ralf Weber <dns@fl1ger.de>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: Jim Reid <jim@rfc1035.com>, Eric Rescorla <ekr@rtfm.com>, dns-privacy@ietf.org
Date: Wed, 30 Oct 2019 07:49:12 -0500
X-Mailer: MailMate (1.13r5655)
Message-ID: <DBA99928-BB82-40D8-80D5-C68C4427E1BA@fl1ger.de>
In-Reply-To: <CACsn0c=6Kv5j0SKJkTLxSNSPoz_uA62p1vTjWx=ccVJbnv4f7A@mail.gmail.com>
References: <943e3973-f6a7-9f6e-a66a-33aff835bd5e@innovationslab.net> <503df6fb-b653-476f-055f-15c1a668ba36@innovationslab.net> <5fe86408-35a8-16ea-d22a-9c6c4a681057@icann.org> <CA+9kkMBZUPfWov6B+pgLYuFmZh10dTzwF2PdKs5Vozzssqvzjw@mail.gmail.com> <edf53c16-3be9-786c-dcb1-0edc9fd9711c@icann.org> <CA+9kkMC5ynqK+8QO==5Pi_9edjTkJJ3yLHBHqJFOox8fi1_8HQ@mail.gmail.com> <CAHbrMsAAvadukzifKEj9eEWB91aDjmnu775F_YdtBaUHrHwDDQ@mail.gmail.com> <CA+9kkMCVj3Lte1dooNthm0f6eBPFUGbxdQBGyjB62KD8wn+f-g@mail.gmail.com> <CAHbrMsCU4b7yNwEfq1J0qsX3vbij+bLdXpanPMKaF+h6yqkXKw@mail.gmail.com> <CA+9kkMA9=m67w=yPR4=cNmHvMH29ogzBVzA8GZU_HCBkVNUxOg@mail.gmail.com> <CABcZeBMyrW=D+dyoT3FUvfe+9hM7ZCndv=tZ9B2F170U0Z7obw@mail.gmail.com> <CAHbrMsAgR-Andoxs5WRMp2jE3Gf_1EWWpsrAm3eFc-vGhb5A3w@mail.gmail.com> <CABcZeBNTJYQc_1kbK7cL3S8KcHfEzpNsZaeK=OeYopEpjLF9_Q@mail.gmail.com> <CAHbrMsBaGBx-gye+Y+4Ja_a9Dkvkt6kLva3fzyvrzuuzxECZuw@mail.gmail.com> <CABcZeBP64qr81ccw+cbYy6FuQkgArS=G9_itEt8A_UfN8SO7GA@mail.gmail.com> <BDFD7D8F-BB99-46DF-85AC-922DDF25A1D3@rfc1035.com> <CACsn0c=6Kv5j0SKJkTLxSNSPoz_uA62p1vTjWx=ccVJbnv4f7A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/xPTKUpG1TnH3j_T2P4x4OLJ-IH8>
Subject: Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2019 12:49:22 -0000

Moin!

On 30 Oct 2019, at 1:37, Watson Ladd wrote:
> The root zone is data: whether one distributes it via DoT, DoH, IPv6, or
> carrier pigeon is irrelevant to the policies that goven what's in it. And
> furthermore none of the network engineering issues raised against DoH apply
> to recursive to authoritative.
>
> We absolutely can engineer reliable anycast clusters to handle 100,000
> queries a second. That's only 100 cores if each core can do 1000 queries a
> second.
We can and I don’t think Jim questioned that it is technically possible. But
someone has to pay for it and there are layer 9 problems. At some parts of
the DNS infrastructure the margins are thin and increasing your server load
or server foot print for ADoT might be the difference between making a profit
or a loss.

> Akamai handles a substantially greater  volume of considerably more
> expensive HTTPS traffic: the DNS queries are part of the HTTPS.
That is true, but we also have way more servers for HTTPS then for DNS, and
while I don’t want to see DNS traffic inside the same channel that delivers
content for various reason that for sure won’t happen with ADoT as we are
talking about a resolver and not and end client issuing the queries.

> Encryption at the root is very possible.
It for sure is, but it’s not as easy and I see the root probably being one
of the latest adopters of ADoT. In general that does not matter. We have
to design a protocol first and then maybe look at the special cases some
part of the tree might have.

So long
-Ralf
—--
Ralf Weber