Hi Paul, Thanks for your comments and detail expatiation, :-)
*Why I think ECS is actually based on the map of " client subnet -> geolocation (country, province, isp) " ? * Of course, we all read RFC 7871, they said "Topologically Close" , not "Geographically close". Everyone know that geolocation is not precisely equal to realtime network topology. But, the duck test – "If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck". As last mail I replied to Ask, AUTH will not choose to detect network topology connection speed with each subnet one by one, but summarized the subnet into some critical information: AS Number, Country, Province, ISP name. Most of time, AUTH will select some subnets for sample test, then, configure by geolocation area. I don't mean that AUTH decide response based on physical geolocation distance. I mean that AUTH decide response base on *network topology distance between the isp geolocation area.* Imagine that, www.xxxcdn.com build two datacenter in (CHINA, SHANGHAI, UNICOM), (CHINA, LIAONING, UNICOM) - physical distance: BEIJING - SHANGHAI > BEIJING - LIAONING - network topology distance: BEIJING - SHANGHAI < BEIJING - LIAONING the AUTH of www.xxxcdn.com will return (CHINA, SHANGHAI, UNICOM) response to the user from (CHINA, BEIJING, UNICOM). There are some examples: 1) Google Public DNS FAQ : https://developers.google.com/speed/public-dns/faq#locations In addition, Google Public DNS engineers have proposed a technical solution called EDNS Client Subnet <https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/>. This proposal allows resolvers to pass in part of the client's IP address (the first 24/64 bits or less for IPv4/IPv6 respectively) as the source IP in the DNS message, so that name servers can return optimized results *based on the user's location* rather than that of the resolver. To date, we have deployed an implementation of the proposal for many large CDNs (including Akamai) and Google properties. The majority of *geo-sensitive* domain names are already covered. 2) Dyn’s ECS Implementation: https://help.dyn.com/edns-client-subnet-faq-info/ When a DNS query is received by our nameservers, we analyze the query in order to determine what response we provide. During this analysis, we will notice if ECS information is provided and whether a Traffic Director service will be involved in the response. If both is the case, we will *use the ECS information for our geolocation lookup* instead of the source IP address. Once a geolocation is found and a response is selected, Traffic Director will provide a DNS response back to the source IP address. As part of this response we will include information via ECS regarding what subnet the response should be cached for. 3) Amazon Route 53: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html To improve the accuracy of *geolocation routing*, Amazon Route 53 supports the edns-client-subnet extension of EDNS0. (EDNS0 adds several optional extensions to the DNS protocol.) Amazon Route 53 can use edns-client-subnet only when DNS resolvers support it When a browser or other viewer uses a DNS resolver that does support edns-client-subnet, the DNS resolver sends Amazon Route 53 a truncated version of the user's IP address. Amazon Route 53 *determines the location of the user based on the truncated IP address* rather than the source IP address of the DNS resolver; this typically provides a more accurate estimate of the user's location. Amazon Route 53 then responds to geolocation queries with the DNS record for the user's location. 4) Gdnsd (an AUTH software) 's Geoip plugin, which support ECS: https://github.com/gdnsd/gdnsd/wiki/GdnsdPluginGeoip gdnsd-plugin-geoip uses MaxMind's GeoIP binary databases to map address and CNAME results based on *geography* and monitored service availability. It fully supports both IPv6 and the emerging edns-client-subnet standard. *Is geolocation information good for CDN and DNS? * In the mid-1990's, network resource is rare and uneven, network path is inconsistent with geolocation. Therefore, in the mid-1990's, many network operators usually ignored geography. There was a popular sentence for Chinese network topology, decribed similar condition: The distance between China Telecom and China Unicom, is much longer than the distance between China Telecom and United State. However, Internet grow up dramatically since 1990s. Nowadays, Internet is critical information infrastructure, global network path connect every where. Even into remote mountain village, information spread rapidly. With internet network path connect every where, the aerial view network topology distance improve like road path more and more. CDN do best effort to make end user to visit the closest edge server, consider about geolocation more and more. They call that geolocation lookup, geolocation routing, geolocation delivery, and so on. I AGREE WITH this sentence of your post : *it has never been wise to assume that a DNS request's IP source address gives any hint of an end-system Web browser's network location.* This assumption is not correct in theopy, but the reality is that almost all smart-auth-dns-resolution working based on this assumption. So I support ECS's idea : give more precisely information to AUTH. In the mid-1990's, DNS is pure. Not work with CDN that contains 50+ datacenters to choose for dns response. In the mid-1990's, there is not public recursive resolver. Not increase the distance between client ip and resolver ip. Consider about these nowadays problem, ECS is designed, partly change traditional dns query, *give addtional subnet information for AUTH to make a better decision*. ECS can make DNS query & response more satisfied with nowadays content delivery ( one domain -> multiple servers distributed in different location datacenters ), if they don't deploy ip anycast. Again, as I methioned above, AUTH actually use ECS subnet information mapped into geolocation information, then make dns decision. *Why I think EIL can make some revisions to ECS ? * EIL : We tell Authorative servers that, "*I want to know what is most satisfied ip address for clients from (CHINA, BEIJING, UNICOM) at network topology distance*". The (CHINA, BEIJING, UNICOM) is geolocation, but AUTH decide dns response by network topology distance between the geolocation nodes. - *Privacy*: The biggest privacy concern on ECS is that client subnet information is personally identifiable. EIL adjust the sensitive client subnet information to aerial view geolocation information for user privacy protection. - *Operation*: In P-model (details in my *Paper <https://drive.google.com/open?id=0B5gNT4RRJ0xPaG9nZ045VXRrZzg>*), EIL move back the "guess geolocation of client’s IP" work from authoritative server to public recursive resolver, lighten the burden of authoritative server. Anyway, the origin of user latency problem is the public recursive service providers couldn't deploy servers in every country and every ISP's network. - *Cache Size*: The cache size of ECS grows up with the number of client subnets. under future IPv6 environment, huge number of subnet, the cache size of EIL will be smaller than ECS. Paul Vixie <p...@redbarn.org>于2017年3月22日周三 下午6:54写道: > Lanlan Pan wrote: > > ... Because ECS is also based on the map of > > "*client subnet -> geolocation*" information. > > Paul Vixie <p...@redbarn.org>于2017年3月22日周 > > wait, what? > > Lanlan Pan wrote: > > Hi Paul, > > hi. > > > https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/ > > this web page is factually incorrect in that it presupposes that geo-ip > is used. i have added a comment there to this effect. > > the original ECS web site > (http://www.afasterinternet.com/howitworks.htm) is somewhat > marketing-oriented, but says only that "With this more intelligent > routing, customers will have a better Internet experience with lower > latency and faster speeds." in other words, it expects that a CDN will > apply its server-selection logic on an address basis, but using the > truncated client subnet rather than to the DNS request source address. > it does not dictate what the CDN's server-selection logic has to be or do. > > in RFC 7871 (http://www.afasterinternet.com/ietfrfc.htm) we see this > definition: > > > Topologically Close: Refers to two hosts being close in terms of the > > number of hops or the time it takes for a packet to travel from > > one host to the other. The concept of topological distance is > > only loosely related to the concept of geographical distance: two > > geographically close hosts can still be very distant from a > > topological perspective, and two geographically distant hosts can > > be quite close on the network. > > there is an error on page 22 which is directly on-point: > > > o Recursive Resolvers implementing ECS should only enable it in > > deployments where it is expected to bring clear advantages to the > > end users, such as when expecting clients from a variety of > > networks or from a wide geographical area. Due to the high cache > > pressure introduced by ECS, the feature SHOULD be disabled in all > > default configurations. > > from context, it's clear that they meant "topological area". > > actual CDN technology, from as far back as Cisco Distributed Director in > the mid-1990's, has usually ignored geography, for the reasons i gave > up-thread: overlapping and incoherent topology within a geo-ip region > means that geo-location is a very poor predictor of per-path performance. > > let me state (again) for the record that i was and remain opposed to ECS > because it's an obviously bad idea and the apparent need for it merely > proves that Stupid DNS Tricks > (http://queue.acm.org/detail.cfm?id=1647302) did not and could not solve > their chosen problem in the first place. it's architectural > cost-shifting, which is a form of both intellectual conversion and > economic compulsion. sad! > > however, if you're going to propose a replacement for ECS, you should > correctly describe how it works. <<Because ECS is also based on the map > of "*client subnet -> geolocation*">> is not a correct description. if > EIL is geo-based, then it is completely different from ECS. > > -- > P Vixie > > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop