I can't help but note that people all over the Internet do various flavors of ANAME now, and the DNS hasn't fallen over. Let us not make the same mistake we did with NAT, and pretend that since we can't find an elegant way to do it, we can put our fingers in our ears and it will go away.
In article <cah1icirxysyb3sao8f1jy-q4melmqapsfo-7x5iddufdt_u...@mail.gmail.com> you write: >The requirement on update rate, is imposed externally by whichever entity >operates the ANAME target. In other words, this is not under the direct >control of the zone operator, and is potentially a potentially (and very >likely) UNBOUNDED operational impact/cost. "Something very bad will happen if I do that." "OK, so don't do that." My aname-ish code has a maximum update rate, and I expect everyone else's does too. Yeah, the ANAMEs won't be in sync with the hostile remote server, but I can't get too upset about that. >Third, there is an issue with the impact to anycast operation of zones with >ANAMEs, with respect to differentiated answers, based on topological >locations of anycast instances. How is this different from CNAMEs via to 8.8.8.8 and other anycast caches? The cache has no relation to the location of the client unless you use one of the client location hint hacks. I'm not wedded to the current ANAME spec but we have plenty of experience showing that it's possible to implement without causing disasters? R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
