就算真的把骨干网、出口拖慢了，然而yt，gog不可能来镇上建CDN，有一种规律叫做低洼效应，不是谁想挡就能挡的住的。如果按照这种逻辑，不久以后要限制出国游，到不同国家要给海关交不同的过门费，哪怕我什么都不带。
镇上内容做不强，文化输出不成功还不允许镇上的人出去看看。
现在统计局不是总统计人均数据吗，明年要统计一下人均带宽、分国内和国外两种。
另外讲一个耳月 言某 论，美帝准备推镇的高墙，这一限，等于先把青蛙放温水里，时间久了，有效阻止里应外合。

我觉得今天联通把带宽切一部分给了上海电信，联通今天丢包上升了不少。

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

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

我在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字样的差不多就是真正的节点位置。

2002开头的是6to4专用地址，6to4是ipv6 over ipv4隧道。这种隧道只能访问同样是2002地址的节点，（除非该节点有6to4中继），本来访问限制很大（和墙不墙没关系），一般只用作高校、企业实验用。世界上没有哪个ISP拿它做商用。估计广东电信是拿它忽悠上面领导的，完成年度ipv6过渡任务指标。

这个是给移动APP使用的，不是给传统的web应用准备的，不需要客户端。APP开发者要自己去写代码实现域名解析。好像没有什么规范可言，在朝内八仙过海各显神通。

@vibbow 在法庭上作为证据的时候不同。当然在天朝只能呵呵。有一点需要留意，因为ipv6的单播地址几乎无限，朝内的ISP再也不会因为成本问题而延迟部署端到端的接入认证机制。就算是蹭wifi也赖不掉了。

请求删除该主题。
另外国内ISP开通ipv6接入服务可以想象到查水表更容易了，等同于实名制。

@raincious 是不是因为墙对入口流量也有审核呢？ 另外某g开头的开源项目导致墙把google的ip都封的差不多了，是不是也会对GAE的访问质量造成影响？

LZ试一下systemctl reboot，以后systemd将接管电源管理。

@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在中东部联通的点很多。

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

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

@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，让用户自己处理。

“OpenDNSCrypt，无效；” 那就说明铁通把该网站域名的授权都劫持了，这个牛大了。换ISP估计都没用。

RFC1035规定每级域名最多63个字符，整个域名不能超过255个字符，域名无论长短 解析过程都一样的。

2.3.4. Size limits

Various objects and parameters in the DNS have size limits. They are
listed below. Some could be easily changed, others are more
fundamental.

labels 63 octets or less

names 255 octets or less

TTL positive values of a signed 32 bit number.

UDP messages 512 octets or less

3. DOMAIN NAME SPACE AND RR DEFINITIONS

3.1. Name space definitions

Domain names in messages are expressed in terms of a sequence of labels.
Each label is represented as a one octet length field followed by that
number of octets. Since every domain name ends with the null label of
the root, a domain name is terminated by a length byte of zero. The
high order two bits of every length octet must be zero, and the
remaining six bits of the length field limit the label to 63 octets or
less.

To simplify implementations, the total length of a domain name (i.e.,
label octets and label length octets) is restricted to 255 octets or
less.

Although labels can contain any 8 bit values in octets that make up a
label, it is strongly recommended that labels follow the preferred
syntax described elsewhere in this memo, which is compatible with
existing host naming conventions. Name servers and resolvers must
compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
with zero parity. Non-alphabetic codes must match exactly.

之前任何域名回复的都是servfail ，现在应答是正常了，但我觉得实际上有些省份都已经被劫持了，都不是真正的google回的。这种情况下用8888都是心里安慰。

@tabris17 人生赢家啊

我曾经也有这样的一段时期，但时间长了我觉得是在浪费自己的时间，一次能够做对做好的事情为什么要坑一次才修正。现在什么都讲速度，你多一次试错别人可能就超越自己一点。而且试错往往带着一群人，浪费的资源要比个人多N倍。LZ年龄轻的话倒可以借此积累些经验，知道最终谁的是错谁的是对，但以后领悟和感性认识多了以后就不要这样了，毕竟岁月不饶人。