V2EX › johnjiang85 的所有回复 › 第 20 页 / 共 25 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 12 13 14 15 16 17 18 19 20 21 ... 25

❮

❯

2016 年 12 月 19 日

回复了 piaoliu 创建的主题 › DNS › 关于 DNS 防护的疑问

@lhbc 明白人，攻击者的真实目的是让 DNS 停止攻击域名的解析，真的打挂 DNS 对攻击者并没有什么好处，所以 DNS query 肯定会打，以便让 DNS 服务商识别到哪个域名被攻击，从而处理被攻击的域名。
不过单纯的 DNS Query Flood 对传统 DNS 也许有效，但是随着 DPDK 和众核在 DNS 解析程序的普及，大家的包处理能力都高到爆表了，对现在的各种高防 DNS 基本没什么效果，所以更常见的方式是 DNS Query 和带宽流量型攻击的混合方式攻击，就是打爆你的带宽， DNS Query Flood 也就剩下让你知道打的是哪个域名的作用了。

2016 年 12 月 14 日

回复了 titanium98118 创建的主题 › DNS › 电信用户， www.v2ex.com 被 119.29.29.29 解析到联通 IP？

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

2016 年 12 月 14 日

回复了 titanium98118 创建的主题 › DNS › 电信用户， www.v2ex.com 被 119.29.29.29 解析到联通 IP？

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

2016 年 12 月 13 日

回复了 titanium98118 创建的主题 › DNS › 电信用户， www.v2ex.com 被 119.29.29.29 解析到联通 IP？

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

2016 年 12 月 13 日

回复了 titanium98118 创建的主题 › DNS › 电信用户， www.v2ex.com 被 119.29.29.29 解析到联通 IP？

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

2016 年 12 月 9 日

回复了 johnjiang85 创建的主题 › 酷工作 › 腾讯云&DNSPod 招 C/C++后台开发

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

2016 年 12 月 8 日

回复了 johnjiang85 创建的主题 › 酷工作 › 腾讯云&DNSPod 招 C/C++后台开发

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

2016 年 12 月 7 日

回复了 johnjiang85 创建的主题 › 酷工作 › 腾讯云&DNSPod 招 C/C++后台开发

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

2016 年 12 月 5 日

回复了 66beta 创建的主题 › DNS › 孤陋寡闻了，刚刚查 httpdns，突然发现 114dns 是腾讯的！

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

2016 年 12 月 5 日

回复了 66beta 创建的主题 › DNS › 孤陋寡闻了，刚刚查 httpdns，突然发现 114dns 是腾讯的！

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

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

2016 年 11 月 29 日

回复了 maxsum 创建的主题 › DNS › 有没有能按 IPv6 分区的智能 DNS？

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

2016 年 11 月 7 日

回复了 mrzhiin 创建的主题 › DNS › 递归时怎么选择最优的 NS？

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

2016 年 11 月 7 日

回复了 mrzhiin 创建的主题 › DNS › 递归时怎么选择最优的 NS？

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

2016 年 10 月 23 日

回复了 anjunecha 创建的主题 › DNS › 设置 Master DNS 和 Slave DNS 的必要性

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

2016 年 10 月 8 日

回复了 hanmeimei 创建的主题 › DNS › 如何检测 dns 是否被篡改

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

2016 年 9 月 20 日

回复了 zhangweifang 创建的主题 › DNS › 因为 DNS 的问题，导致 iTunes12.5.1.21 无法通过 AppStore 更新，大家有遇到么？

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

2016 年 9 月 6 日

回复了 itsme 创建的主题 › DNS › DNS 或 Chinadns 的压缩指针倒是是什么意思？

现在互联网上所有的 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 -- 同理

2016 年 9 月 6 日

回复了 ivmm 创建的主题 › DNS › 设置了 AAAA 解析，但是 DNS 没有 ipv6 的 ip，这样子做有什么意义么？

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

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

2016 年 9 月 6 日

回复了 ivmm 创建的主题 › DNS › 设置了 AAAA 解析，但是 DNS 没有 ipv6 的 ip，这样子做有什么意义么？

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

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

2016 年 9 月 6 日

回复了 mrzhiin 创建的主题 › DNS › 递归时怎么选择最优的 NS？

相关协议中有 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 的问题。

1 ... 12 13 14 15 16 17 18 19 20 21 ... 25

❮

❯