Re: [DNSOP] Minimum viable ANAME

[Matthijs Mekking <[e-mail]>]

On 3/26/19 5:10 PM, Tony Finch wrote:
> Matthijs Mekking <[e-mail]> wrote:
>>
>> I think that would be the wrong direction.  I believe there is a need to
>> standardize the ANAME resolution process and so my suggestion would be to
>> reduce the scope by focusing just on how to do that on the provisioning side
>> (and leave secondary servers and resolvers out of scope for now).
> 
>>From past discussions, I didn't think there was any way we could get
> consensus on the provisioning side.
> 
> Dynamic lookups on authoritative servers are out, because it has to be
> compatible with traditional secondaries.
> 
> Updates on the primary are out, because that doesn't scale to large
> numbers of zones.
> 
> Sometimes a system might have known fallback addresses, but often it won't
> (e.g. whether the DNS setup is or isn't coupled to a web provisioning
> system).

All these things are contentious which is the reason why removing it 
from the scope will hopefully aid progress.  These can be resolved in a 
follow up document.

> But I think it's reasonable to allow whatever provisioning mechanisms
> there might be, provided the meaning of answers from auth -> rec have a
> consistent meaning that resolvers can use. >
> It's also really imortant that ANAME can work in multi-provider setups, so
> there needs to be something approaching interoperable semantics for
> importing a zone file into a provisioning system. (Though I think the
> semantics will have to be very loose in this case, to allow for variations
> between existing systems.)
> 
> I haven't seen any objections to support for ANAME in recursive servers
> so I'm surprised you think that is problematic enough to be removed. My
> understanding was that recursive support is seen as better than trying to
> do all the tricks on authoritative servers.

Except for the slow deployment issue.


> Tony.
>