My option: 1) ANAME just configured in zonefile, and anlayzed by authoritative server. 2) Authoritative server response to recursive (or resolver) on its policy as before, such as geo-ip, GSLB, ... 3) No upgrade on recursive and resolver.
Tony Finch <d...@dotat.at> 于2020年2月27日周四 上午1:25写道： > Vladimír Čunát <vladimir.cunat+i...@nic.cz> wrote: > > > > The current ANAME draft specifies new behavior for resolvers, and there > > I'd expect even slower overall upgrades/deployment than in browsers. > > From my point of view that was the least important part of it, > an optional extra that might help out CDNs some time in the future, > and not necessary for deployment. Existing ANAME implementations > work fine without it. > > The ANAME draft is far too complicated. I tried to simplify it but in > retrospect I didn't go far enough. > +1 > > There might still be some value in an ANAME draft that simply specifies > the syntax of the record, just to provide portability of zone files > between implementations that currently have non-standard ANAME or ALIAS > records. In this boiled-dry draft, ANAME would have absolutely no special > normative semantics, just an informative description of the relationship > between the sibling and target address records with no description of how > that should be achieved. (Note a domain might have more than one ANAME, > for existing implementations that support round-robin ANAMEs.) So the > codepoint could be allocated via expert review rather than standards > action. > > Tony. > -- > f.anthony.n.finch <d...@dotat.at> http://dotat.at/ > strengthen the democratic process and ensure that > there is a just and representative system of > government_______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
