FWIW, there's still always https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/ (also available at https://github.com/aeden/alias-rr-type) which can be revived if there is interest.
Sincerely, Anthony Eden On Wed, Sep 19, 2018 at 9:56 AM 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. > > > Authoritative servers / zone transfers > -------------------------------------- > > No special new behaviour. > > > Additional section processing > ----------------------------- > > This applies to auth and rec servers. In response to an A / AAAA / > ANAME query, include any sibling A / AAAA / ANAME records, and any > ANAME target A / AAAA records. When DO=1, include DNSSEC proofs of > nonexistence for missing RRsets. > > As usual for additional section processing, you don't have to include > records that aren't available, so (for instance) auth servers don't > have to include out-of-zone data in the response. > > > Recursive servers > ----------------- > > When responding to a query with DO=0 or when the ANAME owner's zone is > unsigned, a recursive server can substitute the target addresses in > place of the owner's addresses. > > > Rationale > --------- > > The primary server behaviour is an "as if" description: that's what > it looks like for the purpose of interop with secondary servers and > zone files. > > There doesn't seem to be any point in making secondary servers do > anything: their view of the target address records will be just as > wrong or right as the primary server's. Zone publishers that want > clever auth servers will use some kind of multi-headed CDN distributed > stunt DNS server, and we aren't going to standardize that. > > Putting cleverness in resolvers compensates for the lack of cleverness > in secondary servers. > > > Tony. > -- > f.anthony.n.finch <d...@dotat.at> http://dotat.at/ > Hebrides: Cyclonic 5 to 7 becoming west or southwest 7 to severe gale 9. > Rough > or very rough becoming very rough or high. Showers. Good, occasionally > poor. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- DNSimple.com http://dnsimple.com/ Twitter: @dnsimple
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
