> Stats are probably available showing how often queries are made for DNS >> operator's zones that indicate a cold cache is being used. Absent a >> compelling case for the cold cache, it does not seem to be worth any effort. >> > > Perhaps we can find some stats, but I think the "cold cache" case is worth > optimizing for reasons of tail latency and consolidation pressure. Cold > cache delegations already resolve slower, so making them even slower is > likely to have a disproportionate impact on tail latency. Low-traffic > nameservers are much more likely to be cold in cache, so increasing the > latency penalty for a cache miss would increase pressure to migrate to > centralized nameservers. >
As far as I am aware of, consolidation/centralization is only an issue when talking about resolvers. I'd be interested in pointers if consolidation by authority operators is a privacy concern. Authority operators only see traffic from resolvers, not from end users, and all of the data served is by definition public. As far as is concerned with cold cache and long tail issues, there are solutions that do not directly impact consolidation. E.g. Operate a domain which serves the name of your name servers, on one or more DNS hosting platforms. Put your A, AAAA, SVCB, TLSA records on that server, which point everything at the actual name server you operate (not hosted by anyone else). Most of the initial portions involved can be in a warm cache. There is no way to eliminate the first A/AAAA lookup, unless the domain-of-interest is fully glued in-bailiwick (which creates problems for establishing a private channel for ADoT using signed TLSA records, i.e. you can't without requiring the TLD to also provide other record types, or relying on non-DNSSEC-signed validation of TLS, and being subject to downgrade attacks.) Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
