On Fri, Nov 1, 2019 at 9:13 AM Eric Rescorla <[email protected]> wrote:
>
>
> On Thu, Oct 31, 2019 at 11:56 PM Vladimír Čunát <
> [email protected]> wrote:
>
>> Generally speaking, I believe it's fine to add assumptions about DNSSEC
>> validation, if that makes the ADoT protocol "better" in some way. (and
>> I expect it will) It seems that DNSSEC will be much easier than this
>> new stuff.
>>
>
> Easier for who? The advantage of transport security in this setting is
> that the authoritative can just deploy it for all their users without any
> interaction with the user.
>
Perhaps someone who operates authoritatives at scale should speak to this?
Regarding DNSSEC ease of deployment:
1. The DNSSEC deployment/operation constraint is a performance-at-scale
issue. *The majority of the CPU cost of DNSSEC is on the signing, which
does not depend on query volume.*
2. Serving DNSSEC-signed zones may have some overhead due to NSEC/NSEC3
responses for NXDOMAIN or NODATA (no RRTYPE) responses. *Non-NXDOMAIN
responses are larger, which consumes bandwidth but largely has no
incremental CPU cost.*
3. NB: NSEC3 has additional overhead due to the requirement to hash
queries first, which depends heavily on particular NSEC3 parameters.
4. Enabling DNSSEC widely on authoritative servers is primarily a
moderate cap-ex exercise, i.e. provisioning adequate signing capacity.
5. Deploying DNSSEC for all users is very feasible, and *at least one
significant authority operator intends to enable one-click deployment for
all users in the very near term.*
Regarding ADoT ease of deployment:
1. The vast majority of authority traffic is UDP today (e.g. 99% or
more).
2. ADoT requires TCP, and additionally requires TLS.
3. Deploying the certificates required for ADoT is very manageable, i.e.
easy.
4. The operational cost of serving ADoT answers is prohibitive, due to a
number of factors:
1. Maintaining state, for TCP and for TLS
2. Set-up overhead for TLS
3. Ongoing encryption of traffic after set-up, e.g. AES computational
cost, vs "copy bytes" (possible with DMA and no CPU)
4. Deployment of ADoT without providing means for managing these
costs is highly unlikely to happen
5. Developing means to manage ADoT costs (in the standards, and in
implementations) is highly non-trivial.
5. *Deploying ADoT is not cheap, not easy, and won't happen fast*.
(Cheap, easy, fast, choose two, currently zero are available to choose.)
Brian
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
