On Thu, Nov 8, 2018 at 11:47 AM Dan York <y...@isoc.org> wrote: > Brian, > > > On Nov 8, 2018, at 10:30 AM, Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > > > > For new RRtypes, registries, registrars, and their provisioning services > do NOT need to support them; the new types are in the zones only. > > DY> (Experiencing a "DUH!" moment.) Yes, of course. It's zone data so > only those entities handling zone data need to care. In my > still-annoyingly-jet-lagged mind, I made the classic mistake of equating > "registrars" with "DNS hosting operators" because so many registrars are > *also* DNS hosting providers. > > No problem - it's very easy to mix up the pure math relationships "one to one" and "onto". (Don't try to, BTW, my brain still hurts from 3rd year pure math in 1986.)
> > 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.) > > DY> Ah, interesting. Where the proposed HTTP RRtype has behavior similar > to the CNAME record, my assumption would be that resolver software would > need to know what to do once it receives the record. For that reason, > wouldn't all the resolvers (or at least an extremely high %) need to be > upgraded to support the new record? > > Yes and no. It requires EITHER the resolver OR the client to handle the name it gets back, and do another query for A/AAAA on that, for whatever the client originally was looking for. I.e. an upgraded client (e.g. browser) could bootstrap the system prior to widespread resolver upgrades. Resolver upgrades would lower their own load, by making the parallel/serial re-queries un-necessary. Thus, it puts at least a modest incentive on resolvers to upgrade. It's kind of like DIY CNAME, except for only one iteration. (If you do a lookup on a name for A or AAAA, and the name is a CNAME-only thing in DNS, resolvers handle that already.) So, if the resolver is upgraded, it would return the HTTP answer plus A and AAAA records. If the resolver was not upgraded, it would return just the HTTP answer (an FQDN), and the client would have to ask for A and/or AAAA records at that name. (The resolver would still handle the chaining if the FQDN was a CNAME.) NB: client stub OS libraries for getaddrinfo return lists of A, AAAA, or both, depending on the AF_* parameter (AF_INET, AF_INET6, AF_ANY). Those might be multiple (parallel, possibly) DNS queries, but the API-calling code would be simple enough. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
