@titanium98118 实测已经生效，广东电信目前可以正确解析到 CDN 的电信节点。

@ksmter V2EX 主域名使用的是 aws route 53 ，且解析量相对较小，是比较慢的主要原因。我们也是针对 V2EX 这种情况做了特殊处理导致在某些地区可能解析的不够准确。

@titanium98118 已经找到原因了，做了一些调整，明天早上回生效。

@titanium98118 看了下，广东电信确实解析到了联通线路，我们看下。

@henglinli 可以聊下，主要还是看做到哪种程度

@erenno1 上面说的岗位也可以放在北京，其他的还有分布式存储后台开发、运营开发等。

@huihui123 这个属于高压线不能细说，但是可以参考目前网络上公开的信息，打一个自己想象，但是实际是没有固定的城市系数比例的，不过可以肯定的是工资 /房价比会比北上广深高很多很多。

@johnjiang85 简化版的递归 NDS -> 简化版的递归 DNS

这个理解有点跑太远了。
首先 114 这里说的是透明代理的 DNS 防护方式，作用层次可以理解为简化版的递归 NDS ，国内有几家厂商提供，包括 114,360,51dns 等。
好处就是可以不改变域名的 NAME SERVER 的前提下（但是要指向防护商的 IP ），使用服务提供商的防攻击和缓存服务。
缺点也非常明显，目前提供此类透明代理方式进行防攻击服务的都不支持 ECS ！！！
腾讯目前确实使用了 114dns 的代理防攻击服务，主要是腾讯自己的域名很少受攻击，不需要常规储备超大空闲带宽，而腾讯旗下的 DNSPod 虽然抗攻击能力很强，但是并没有提供类似代理防攻击服务。

建议：有攻击可以临时用下，在完全死和半死之间徘徊。没攻击的时候就别用了，不支持 ECS 会让人崩溃。

ipv6 没有完善的地址库，一般都作为默认处理。

@loggerhead http://irl.cs.ucla.edu/data/files/papers/res_ns_selection.pdf

@loggerhead RFC2988/6298 有相关内容， bind 部分版本是极大概率选择 rtt 最短的 IP ， unbound 一搬是在最短 RTT 相差 400ms 以内的都认为是质量较好的 IP ，从而平均选择。这里有篇论文可以参考下，有分析。

目前国内比较大的 DNS 服务商已经很难被 D 死了，更大的意义是在被 D 的时候解决国外解析的问题（国际出口影响）。

访问： http://ip.dnspod.cn/,点击检测
或 nslookup xxx.ip.dnspod.net , 其中 xxx 为随机子域名，会返回所使用的ＤＮＳ后端出口 IP,如果使用的 DNS 支持 ecs,会同时返回ｄｎｓ的出口ｉｐ和ｅｃｓ中携带的ｅｃｓ　ｉｐ。

看上去也可能是国内 CDN 的锅。不过阿里为怎么解析到江苏去了，@zhangweifang 你现在还是在青岛吧

现在互联网上所有的 DNS 包基本都用到了压缩，基本意思就是后面的域名如果有与前面的域名全部或部分相同，可以使用 0xc000 的基础上，加上相同部分域名的起始位置在本包中的偏移，来表示后续域名。
举个最简单的例子：
;; QUESTION SECTION:
www.abc.com IN A -- 这里的 www.abc.com 在 DNS 包中是实际的字符串，假设其起始偏移为 1 ， abc.com 的起始偏移为 2

;; ANSWER SECTION:
www.abc.com IN A 1.1.1.1 -- 这里的 www.abc.com 是个指针 0xc001,指向第一个 www.abc.com

;; AUTHORITY SECTION:
abc.com IN NS ns1.abc.com -- 这里的 abc.com 是个指针 0xc002 ，指向第一个 abc.com
abc.com IN NS ns2.abc.com -- 同理

@ivmm 授权 DNS 在国内不是没有，而是不能使用 IPv6 地址，理由如前。

ipv6-only 后端是有 ipv4 出口的，可以解析的。

很多第三方的公共 DNS （或者某些教育网）都有 ipv6 地址，可以使用 ipv6 地址访问，另外递归 DNS 的后端既有 ipv4 也有 ipv6 ，可以向相关的授权 DNS 发起请求，并不需要授权 DNS 必须有 ipv6 地址，所以还是可以解析出来 AAAA 地址。

但是在国内的话非常不建议使用 ipv6 ，用了 ipv6 就不能使用智能解析（分线路）了，跨运营商和跨地区访问就是常态了。我们的授权 DNS 原本是有 ipv6 地址的，但是不能上线，会影响正常的智能解析（比如说在教育网里）。

相关协议中有 RTT 延时选择机制及算法，开源的 BIND 和 UNBOUND 也曾经使用过，但是目前这两个开源的更多的是使用随机选择 IP 的方式，而不是根据 RTT 延时机制去较大概率选择质量好的 IP ，较小概率选择质量差的 IP 。质量差的 IP （即使是完全无应答的 IP ）也会去选择是因为网络总是在变化的，有可能之前较差的慢慢变好，根据算法会调整每个 IP 的选择到的概率， BIND 和 UNBOUND 中的 RTT 延时算法是按照 RFC 实现的，但是在实际的使用中， DNS 选优效果并不好。 DNSPod 的 119.29.29.29 的后端递归也使用了 RTT 延时机制，基本思想参照 RFC 的思想，但是算法经过了优化，可以测试不同 IP 的质量，并线性调整各 IP 的权重。

第二个问题差不多，会随机去选择一个或多个 NS 的一个或多个 IP 去重试，根据递归的不同，选择也会有所不同，重试时同样会有第一个问题了选择哪个 IP 的问题。