At Wed, 19 Sep 2018 14:55:45 +0100, Tony Finch <d...@dotat.at> wrote:
> I think there's still a need to standardize ANAME, to provide at least > some level of zone file portability between the various existing > proprietary versions of this feature. And to provide something usable > by zone publisters on a much shorter timescale than a nsa SRV-alike. > > So here's a sketch of a reduced ANAME: > > Primary servers / zone provisioning > ----------------------------------- > > For each ANAME record, poll the target address records periodically > (according to the relevant TTLs). When the target addresses don't > match the owner's addresses, UPDATE the zone so they match. I'm not sure how we can expect this model to deploy in practice. With this model, the zone admin will need to develop an additional script or something integrated into whatever the provisioning framework they are using. Is that the assumption? Then I suspect none of existing users of proprietary and non-standard-compliant "ALIAS" will switch to it simply because it's standard compliant. And that will be also the case for those who now want to start "aliasing at a zone apex". Perhaps primary server implementations may eventually have some level of support that makes this provisioning much less painful (in a way other than performing on-demand resolution). If and when many popular implementations do it in a convenient way (at least as convenient as the proprietary alternatives), we may hope the new model with ANAME optimization will start to deploy, eventually with wider deployment of the optimization part as more resolvers support it. Perhaps that's the intended deployment plan? If so, I see some possibility there, but I have to say I'm pessimistic about its reality. -- JINMEI, Tatuya
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
