On Tue, 2020-11-17 at 23:30 +0000, Tony Finch wrote: > Peter van Dijk <[email protected]> wrote: > > The incremental cost for a resolver (doing a full resolution process > > for the TLSA records of one or more NS names) is not small, and neither > > are the latency costs. For 'popular' name servers, this cost can mostly > > be amortised, leaving the penalty with any domain hosted on a NSset > > that only has a few domains. > > Yes. However I think the relative cost of TLSA lookups is much less when a > resolver implements delegation revalidation because then it's fetching > authoritative A and AAAA anyway, so it can fetch TLSA concurrently. > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/
As I understand the draft, the revalidation can happen in parallel to the actual query the user is waiting for. Any setup/discovery of secure transports would have to happen before that, so I'm not sure we can say 'on top of delegation revalidation, TLSA lookups are basically free'. > > > Using TLSA records at _853._tcp.<NS_NAME> in a signed zone provides an > > > unambiguous signal to use optionally TLSA, in a downgrade-resistant > > > manner. > > > > Not downgrade-resistant, until NS names in delegations become signed. > > Or until the parent nameservers support authenticated encrypted > transports. The design choice that DNSSEC did not make, a long time ago. > Even so I think delegations should be signed. It would solve a *lot* of problems. > A (the?) major issue with this whole ADoT effort is the bad trade-off > between a delegation-centric design (where the DoT signal is in the parent > zone) which has really formidable deployment obstacles, and really > troublesome scalability issues; or a DNS-hosting-provider-centric design > which has poor performance and downgrade weaknesses. I know DOTPIN has been rejected/shelved/not-adopted for the deployment/scalability reasons you mention, and also because the problem space was not mapped out well enough yet, but I still wonder if perhaps it makes sense to have two solutions to the DPRIVE charter - one with short paths, few extra queries (like DOTPIN), and one that works well with '500k domains delegated to one party' - with delegations signed, or a non-pinning signal (that does not take part in key rollovers) on the 500k domains, etc. > If (big if) we think it's worth upgrading the DNS delegation model (and > EPP, and all the registries and registrars, and all the IPAM databases and > user interfaces, and documentation and textbooks), can we also tackle the > scalability problem? By "scalability" I mean the need for a hosting > provider to update NNNNN delegations when a server cert changes. And there > are decades old problems keeping delegation NS and glue and DS records > correct. (A large chunk of the "it's always DNS" meme comes from how hard > it is to understand delegations and update them correctly.) This whole > area is a massive pain in the arse sorely in need of universal automation. +100. I've referred to this in other threads - if CloudFlare had gotten anywhere with their attempts to solve the operator / registrant / registrar / registry disconnect problem, all of this would be so much easier. > Any serious attempt at improving delegations needs to deal convincingly > with the quesion of why support for CDS, CDNSKEY, and CSYNC is so > appallingly bad. Yes, or in the broader sense, my previous paragraph. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
