Nicholas Weaver wrote: > On May 7, 2014, at 10:23 AM, P Vixie <p...@redbarn.org> wrote: > >> Joe... To clarify... Client subnet is not what I an complaining about. It's >> wide area rdns itself that I think is a bad idea. One reason wide area rdns >> is a bad idea is that it needs client subnet options. >> >> Centralized rdns is not necessary and it makes the internet brittle. Better >> alternatives exist. The architecture of DNS assumes localized rdns. If we're >> going to document client subnet then all that advice will have to go into it. > > Not necessarily. "centralized" is often really "anycast". > > E.g. if you look at Comcast there are multiple anycast responders in their > own internal network for 75.75.75.75. Likewise, '8.8.8.8' is insanely > anycasted. This is not brittle, but remarkably robust.
what i mean by brittle isn't well exemplified by the comcast approach, since 8.8.8.8 really will be answered close to the user, and because it's IGP anycast it really will tend to be the closest server to the user. BGP anycast as practiced by googledns and opendns is less predictable. however, even in the comcast case, "rdns fade" due to misconfiguration is likely to affect large populations per "fade" event. when rdns is on-host or on-lan or on-campus, "rdns fade" events are more localized, and strike smaller populations. (and, the RTT tends to be more like the 1ms that's been a design assumption for a long while, vs. 10ms or longer as in the BGP anycast case.) of course, more rdns servers means more opportunities (per universe) for misconfiguration. my assumption is that end users or LAN or campus network operators will provision and monitor according to the importance they place on this service. the number of uncontrollable risks and other people's moving parts you depend on for wide area RDNS is where i get my "brittle" depiction. > In this case, still, edns client subnet is very useful. It is, frankly, a > mess to map "client subnet to recursive resolver", but it is an insanely > powerful optimization when you can. > > edns_client_subnet makes this mapping trivial, and therefore acts to > significantly improve end user performance. services that don't use CDN, or whose CDN does not use what i call "Stupid DNS Tricks", won't see any improvement. so, this is a problem created by ADNS and RDNS operators going off the reservation in the first place, and it only affects those operators and their customers. i'm not saying we shouldn't document it in an RFC. (informational, i guess.) non-interoperable client subnet signalling is even worse in my view than interoperable client subnet signalling. i'm saying it deserves a strong applicability statement, as all controversial technologies do. vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
