At Wed, 19 Sep 2018 14:55:45 +0100,
Tony Finch <> 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

Reply via email to