Standard query response 0xdfca CNAME www.a.shifen.com A 180.97.33.107 A 180.97.33.108
说明是同时返回CNAME和A记录的

方案1：114 在各地建立dns服务器IP都为114.114.114.114，通过 BGP广播你发起的dns查询会自动发送到离你最近的dns服务器。

方案2：同样在各地建立一些dns服务器，不过每个都有自己的ip，114.114.114.114 由单独的一个服务器持有。你的请求发送到 114.114.114.114 后，114.114.114.114 转发给离你最近的 dns服务器，然后这个服务器查询得到域名信息后以114.114.114的名义回应你。

方案3：谷歌DNS扩展协议(EDNS) ，114.114.114.114 查询记录的时候会通过 EDNS 同时提供你的ip，所以可以获得正确的地址。

114 主页上面说用的方案1，但是听说实际用的方案2。方案3的兼容性...

除了方案3，Ns服务器全部是以缓存服务器的Ip地址来确定对应的Cdn服务器的。

@gamexg EDNS0 是 RFC 6891 定义的，什么时候成 Google 的了？

@gamexg 谢谢你的回复
114我也琢磨过,114的确是BGP Anycast ,不过节点少的可怜,国内电信到南京联通到济南,国外的到FDC的芝加哥节点,然后国内我觉得和你说的方案2一样,都是在各个地方的DNS服务器fake 114返回给我结果,因为每次我从114收到的回复TTL都不一样,跨度很大,有这么不稳定的Anycast嘛...相反223.5.5.5返回给的TTL就很稳定.虽然223也应该是在各省有自己的DNS服务器返回结果,不过223.5.5.5的Anycast对于国内电信有两个节点.

对于EDNS嘛 我查了查资料 CDN服务商会说到要用一种特殊的DNS处理,不知道是不是就是EDNS

不过CDN还可以使用HTTP重定向,不一定非要在DNS解析阶段就完成判断,这个我也是搜索才发现的

最后对于Anycat的服务器,是不能作为客户端查询的,比如223.5.5.5电信有青岛杭州两个节点,都是223.5.5.5向NS服务器查询,那解析服务器到底给青岛的还是济南的发回复?

@XiaoxiaoPu 忘记具体名字了，只记得Google推广的，随手搜了一下就拷贝过来了。正确的是
Client subnet in DNS requests
draft-vandergaast-edns-client-subnet-01

http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-01 。Google 通过 EDNS0增加的一个扩展。

@gamexg
@XiaoxiaoPu
感谢各位的回复,疑问已经解决了,最后附上小米运维同学配置edns-client-subnet的博客地址
http://noops.me/?p=653

IP multicast

@callofmx 有些事情澄清一下，114确实是anycast，不过按照根域名服务器的实践方式，anycast分为local 、node、globle三层。如果你的请求每次都到同一层，那么TTL很可能就是一样的，否则就肯定不会相同。114dns几乎等同于ISP默认的dns。南京信封本来就是电信技术服务商，在运营商机房上一个114的主机甚至节点是一件很容易的事情，它的点多了，很容易实现了anycast 的三个层。114dns在国内起步早技术成熟，有相当多的点和覆盖面，短期内递归服务无人能及。
方案2，电信级的dns没有实施范例，想象一下遇到DDOS......
方案3，一年前好像还是草案，因为涉及协议的变更，国内不会很快跟进。

在DNS与CDN质量有影响的方面主要体现在域名（授权）记录与CDN节点的契合程度，递归服务器不是一个决定性因素（但google提出的edns-client-subnet确实提高了非本地递归服务器的CDN服务质量）。

“如果域名Q的记录是一个指向CDN的CNAME记录,那么114DNS会在一个请求里返回给PC域名Q的CNAME记录,并同时返回这个CNAME记录的A记录吗?还是由PC继续向114DNS请求这个CNAME的A记录”

如果114的缓存里面有cname对应的A或AAAA记录（意味着114DNS已经迭代查询到了），那么就要一并返回给用户，否则只返回cname，让用户自己处理。

@callofmx “对于Anycat的服务器,是不能作为客户端查询的,比如223.5.5.5电信有青岛杭州两个节点,都是223.5.5.5向NS服务器查询,那解析服务器到底给青岛的还是济南的发回复?”

anycast递归服务器可以另外有公网单播地址负责向授权（NS）查询，这个不是问题。

@redsonic 是的，关于不能用anycast地址发起请求就是说下，实际上对于114DNS，你说的公网单播地址就是是各省的local DNS对吗？

@redsonic 关于这点在DNS与CDN质量有影响的方面主要体现在域名（授权）记录与CDN节点的契合程度能请您再详细解释下吗？
还有一个疑问，我的ISP是重庆电信，像您说的多层次的anycast，那么我traceroute 114，最后几跳看上去还是到了南京，那么这个traceroute报文到底是探测到谁呢，是114 在西南地区anycast节点吗？
谢谢

@buckethead1 递归服务器可以通过anycast地址（114.114.114.114）接收用户请求，但其递归的时候可以通过某个普通单播地址去各级NS迭代查询。各地local dns不管是哪家提供的，维护权都在ISP手里，他们可能在一个机架上，但任何递归服务器都是从根NS去迭代的，所以他们在数据流上大部分情况下都没有关系。不过有的时候ISP要对某域名解析进行干预，114可能由于一些因素也会跟进。从这个角度看你使用local dns还是114都差不多，之不过后者胆子没这么大，现在也不靠这个挣钱，所以劫持少些。

CDN节点选取依赖DNS，好的原则是CDN 、授权、递归三者资源绑定，实现就近访问（不一定是地理上的）。比如重庆用户请求www.baidu.com到重庆电信 local dns（递归），local dns从本地的ns.baidu.com 获得最终的A记录，整个过程都是依照本地原则（就近原则），最后用户访问的CDN节点就是当初CDN厂商计划好的，对本地用户体验最好的一个。

从上海联通trace的结果：
traceroute to 114.114.114.114 (114.114.114.114), 30 hops max, 60 byte packets
1 192.168.13.1 (192.168.13.1) 0.315 ms 0.430 ms 0.724 ms
2 *
3 139.226.196.153 (139.226.196.153) 947.989 ms 947.975 ms 947.816 ms
4 * 139.226.203.53 (139.226.203.53) 870.823 ms 870.771 ms
5 139.226.193.17 (139.226.193.17) 9.877 ms 139.226.201.73 (139.226.201.73) 8.171 ms 139.226.204.17 (139.226.204.17) 8.014 ms
6 219.158.9.9 (219.158.9.9) 33.012 ms 30.299 ms 30.313 ms
7 219.158.20.166 (219.158.20.166) 41.183 ms 41.025 ms 41.065 ms
8 60.215.131.62 (60.215.131.62) 34.565 ms 34.408 ms 34.602 ms
9 60.217.44.158 (60.217.44.158) 38.830 ms 60.217.42.154 (60.217.42.154) 30.840 ms 30.330 ms
10 public1.114dns.com (114.114.114.114) 38.707 ms 39.099 ms 38.402 ms

实际是山东联通返回的。

可能西部没有114的node，你那里只能fallback 访问anycast最上层的global节点。114在中东部联通的点很多。

@redsonic 谢谢您的回复
不过您不觉得上海联通离南京联通更近吗?为什么trace到了山东联通.
我在这个网站http://www.ipip.net/traceroute.php测试了一下,发现全国的联通trace114DNS都是访问到了山东联通啊.
那实际上到底是不是DNS请求也发送给了山东联通呢?还是说所有traceroute都是fallback到global节点?但是DNS请求到了node或者local节点?

我在http://www.ipip.net/traceroute.php也试了几个省的联通差不多倒数第二跳都是济南、临沂或者烟台。估计联通带宽比较高的节点都在山东。DNS一般部署在骨干网边缘，无论访问者在哪里，访问骨干网边缘的任意节点延迟都在几毫秒内。他们设置路由策略的时候地理位置不是重要因素，更多的考虑的是成本、Qos、节点容量、灾备等等。

电信的也都跑到了南京。

traceroute 默认使用UDP，应该和dns跑一样的路径。

结合https://www.114dns.com/node.html来看，可能现在114这个ip是个入口地址，真正的递归服务器藏在后面遍布各省。用户的请求先到114（南京or山东），然后再根据源地址转发到各省递归。不过这样确实不是anycast了，不知道以前是不是这样。

如果想了解dns anycast可以到https://cloudmonitor.ca.com/en/traceroute.php trace一下f.root-servers.net ，看不同洲的结果，看到有isc字样的差不多就是真正的节点位置。

@redsonic 如您所说 看根服务器的路径是很明显的anycast
不过我还有一个问题,像ipip.net这样的网站,他是怎么识别出114.114.114.114这个ip地址是南京电信还是山东联通的?毕竟IP都是114.114.114.114,AS号也一样.我们可以通过最后几跳的位置来判断,ipip.net也是吗?有这么智能?
谢谢!

@callofmx 我只是看倒数几跳来推测，ipip.net也只是对地址所在地进行如实显示。不过基本跑不了，就算114DNS离骨干网再近也不可能一跳就到很远的地方。

另外关于昨天流量都跑山东和南京的问题，我提出一种猜测并询问一些做数据挖掘的同事觉得有这种可能：因为现在拿DNS盈利已经不在是靠劫持赚广告费，主要是数据挖掘，如果使用anycast结构，日志分散在多地，无论是汇集以后再挖掘还是分片挖掘以后再汇集处理都很麻烦，不如把初始用户请求和应答流量都汇集到几个点写日志再处理方便。但这样确实要冒一些被DDOS的风险，看他们技术应该没问题了。
另外去年听到消息说镇上的某个ISP准备建设DNS的超级节点，各省DNS流量都要汇集到这里处理，原因是为了安全..... 是不是114也响应号召这样做 也就不清楚了。
最好是能找找以前traceroute结果看看情况怎么样。不管怎样114还是比较可靠的，稳坐普通用户第二个备用DNS，本质上也和本地ISP提供的那两个没有什么区别，想劫持也都是HTTP劫持。