Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

[Brian Dickson <[e-mail]>]

On Thu, Nov 8, 2018 at 11:47 AM Dan York <[e-mail]> wrote:

> Brian,
>
> > On Nov 8, 2018, at 10:30 AM, Brian Dickson <
> [e-mail]> 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