On Feb 26, 2020, at 2:01 PM, Evan Hunt <e...@isc.org<mailto:e...@isc.org>> wrote:
On Wed, Feb 26, 2020 at 03:34:55PM +0100, Vladimír Čunát wrote: I don't think it's so simple. The current ANAME draft specifies new behavior for resolvers, and there I'd expect even slower overall upgrades/deployment than in browsers. I agree with this. Browsers often upgrade themselves these days; resolvers sit for years. (A few years ago there were still BIND 4 instances ticking away out there.) Very much agree with this. A few years ago a couple of us wrote a draft about all the pieces of the DNS infrastructure that need to be updated to support a new DNSSEC algorithm: https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-06 While a new RR type is obviously different from a crypto algorithm, the “system upgrade” is similar: - resolvers have to be upgraded to support the new behavior of the ANAME record - authoritative servers need to upgraded to process the ANAME record - DNS hosting providers (which can often also be registrars) need to have updated software to allow customers to enter ANAME records - DNSSEC signing software may need to be updated to sign the ANAME record (section 4.2 in the ANAME draft notes the sibling resolution that must occur before signing) All of that will take some time, and probably a long time in the case of resolvers and the GUIs of DNS hosting providers. Now, some element of this will ALSO be true for rolling out the HTTPSVC record, (ex. DNS configuration GUIs) but it may not be quite as challenging as getting resolvers updated. (For example, all the resolvers found in “home routers” distributed by ISPs.) Which is not to say that we shouldn’t pursue ANAME or other new RR types… we just have to acknowledge that it may be a loooonnnngggg time before the functionality is available to a large number of users. Dan
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
