Tencent has been supporting edns client subnet for nearly a year . On the 
authority side , we benifit so much from ECS for the extra accuracy  of user 
geo-location identification ,which helps a lot for our users' network access 
optimization and our access traffic scheduling at a totally tolerable increased 
query load. The shift process is smooth and nothing goes wrong in the 
production environment .

According to my operation experience with ECS, I think ECS is good for Internet 
Content Providers, CDN vendors and cloud service providers who schedule their 
access traffic based on DNS resolution and making ECS a standard track may help 
them a lot to guide the implementation for both the authority side and the 
recursive side.

Weijian Liao

> 在 2014年5月7日,5:51,Colm MacCárthaigh <c...@allcosts.net> 写道:
> 
> 
>> On Tue, May 6, 2014 at 10:18 AM, Joe Abley <jab...@hopcount.ca> wrote:
>> On the authority side, support for this option has a potential impact on 
>> query load. On the recursive side, support for this option has a potential 
>> impact on cache size.
> 
> Just to add some limited data; CloudFront (a large CDN) has been using EDNS0 
> client subnet for a few months now, and publically announced a month ago. In 
> general, the uptick on the authority side has been surprisingly modest. 
>  
>> With multiple implementations, there are interop issues.
> 
> We've noticed some inconsistency around the subnet lengths being required in 
> responses, but nothing unmanageable. In general, it's been pretty smooth!
> 
> The biggest operational problem is probably a lack of support in diagnostic 
> tools, with an RFC, I'm hopeful we could get a patch into the standard 
> version of dig - which would be useful for debugging and so on.
> 
> There might also be a place for an informational document/rfc on 
> source-dependent answers in general. For example, even for those who believe 
> that source dependent answers has a place, having source-dependent NS, DS 
> records or delegation paths can be just plain unworkable. 
> 
> 
> -- 
> Colm
> _______________________________________________
> 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

Reply via email to