Re: [dns-privacy] [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

[Lanlan Pan <[e-mail]>]

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 <[e-mail]>于2017年3月22日周三 下午6:54写道：

> Lanlan Pan wrote:
> > ... Because ECS is also based on the map of
> > "*client subnet -> geolocation*" information.
>
> Paul Vixie <[e-mail]>于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