On Thu, Nov 8, 2018 at 10:06 AM Dan York <y...@isoc.org> wrote: > Brian, > > DY> Upgrading our DNS infrastructure is VERY difficult. Because it is > still massively distributed and decentralized (even though we do have > ongoing centralization/consolidation), getting a new RRTYPE deployed means: > > - upgrading all the authoritative servers to support the new RRTYPE > - upgrading all the *provisioning software* at the thousands of DNS > registries, DNS registrars, DNS hosting operators to support the new RRTYPE > - upgrading the *millions* of recursive resolvers to know what to do they > receive the new RRTYPE in a query response > > Actually, for this specific case, the only places that require support (at least initially) are:
- Authority servers (because, duh), unless they already support it, via hard-coded types and RDATA generically (maybe not overly relevant, but covering all cases) - Authority provisioning systems for DNS hosting services (at least one hosting service has to do so before the type is "live") (also possibly supported by the hard-coded mechanism?) - Clients (because someone has to request the new type) For new RRtypes, registries, registrars, and their provisioning services do NOT need to support them; the new types are in the zones only. New RRtypes which do not require any "additional" processing, do NOT strictly speaking require resolver support, since resolvers handle unknown RRtypes. (Mark A can quote you the RFC, and I think has recently.) On the plus side, I can confirm at least one hosting/authority service will do this as soon as a stable spec is available (i.e. HTTP and a code point early allocation). That should take what, a couple of weeks or so? It'd be nice to ask the browser folks to start using something that is already deployed (however small the initial user base is, with the expectation of viral uptake.) > DY> Which does means we do need to get started NOW [...] > > Thanks for bringing this all together, > Dan > You're welcome, and thanks for participating in the discussion. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
