Re: [DNSOP] Minimum viable ANAME

[Olli Vanhoja <[e-mail]>]

On Tue, Mar 26, 2019 at 9:20 PM Brian Dickson
<[e-mail]> wrote:
>
>
>
> On Tue, Mar 26, 2019 at 8:31 PM Olli Vanhoja <[e-mail]> wrote:
>>
>> On Tue, Mar 26, 2019 at 7:23 PM Brian Dickson
>> > We need to start with the base requirements, which is, "I want an apex RR that allows HTTP browser indirection just as if there was a CNAME there".
>> > Sibling records do not behave like CNAMEs, no matter what extra hacks get applied; CNAME processing is done by the resolver.
>> > The options are, new RRtypes that require resolver upgrades, or RRtypes that are handled by the client application (browser), which benefit from (but do not require) resolver upgrades.
>> >
>>
>> I see a huge problem there, let's call it IPv6 problem. During the
>> transition phase to this new RR we need to have a fallback, right? How
>> long do we need to have that fallback for old resolvers and browsers?
>
>
> I don't follow you.
>
> I'm advocating the latter of the two options, because it does not require resolver upgrades.
> Thus, the "old resolvers" is a moot issue, as they would continue to be compatible with the new types.
> The only expectation is that new resolvers would be more efficient, thus the incentive (not requirement) is for the resolver operators. Or not, if they don't particularly care.
>
> I also don't follow the "transition phase" logic, either.
>

Perhaps I misunderstood you. That's exactly what I'm hoping for,
compatibility with the old resolvers.

> I'm not sure how you see this involving DoH; it is an issue orthogonal to the transport or the choice of recursive.

I mean, if there is something new that the client side needs to do to
get an IP address for a domain, then it could be implemented on a DoH
server. Though maybe in that case the client is updated already. Maybe
it would happen at an ISP instead over traditional DNS.

> An upgraded browser (which understands the new RRtype) would be able to resolve the new type using an old resolver.
> Resolvers do not require upgrades to serve new types, as long as the new types don't require special handling.
> These new types would not require special handling by the resolver, but rather would have the special handling done by the browser.
> (That's kind of the whole point - eliminate the need for resolver upgrades.)
>

Well that's my point, if you need to do something new on the client
side, is it a resolver change or a browser change, it will make it
much slower transition. Would a big multinational company change to
this new way of resolving an IP address (and stop serving A records on
selected names) any time soon and risking losing possible customers?
The fallback here would be to just somehow serve a normal A record
that a client already understands.