最近在CB上看到多篇存在关于DNS故障的文章，其中大多存在谬误，让人产生问题在于DNSPod，而暴风影音是无辜的受害者的错觉。这里我觉得有必要出来说说DNSPod才是无辜受害者，错全在暴风（还有黑客）。
首先说说DNS是怎么注册的：
一个域名注册成功以后上级域名的拥有者把这个域名的解析授权（Delegate）给用户指定的域名服务器，此时该服务器成为该域的权威（Authoritative）服务器，一切到该域名的查询以此服务器提供的结果为准。（也存在不授权只设置NS记录的情况。）
比如新浪注册了sina.com，向VeriSign交了钱以后，VeriSign在他们的根域名服务器里面添加如下的记录：
sina.com. 60 IN NS ns3.sina.com.cn.
sina.com. 60 IN NS ns1.sina.com.cn.
sina.com. 60 IN NS ns2.sina.com.cn.
ns1.sina.com.cn. 37305 IN A 202.106.184.166
ns2.sina.com.cn. 37305 IN A 61.172.201.254
ns3.sina.com.cn. 37305 IN A 202.108.44.55
然后我们看如何解析：
因为DNS是非常基础的服务直接关系到网络访问的效率，所以DNS是采用多级缓存的方式运作的。通常一个程序发出DNS请求以后，系统会先搜索自己的DNS 缓存，没有找到则会向网络设置中的DNS服务器发出请求。对一个电信用户来说这个服务器被DHCP协议自动配制成电信指定的服务器。
电信的DNS服务器在收到请求后还是检查自己的缓存，与个人电脑的缓存机制不同的是，一般公共DNS服务器为了加快解析减少流量，都将一个成功的解析缓存域名记录中指定的最长时间（即TTL值，常见的是3600秒）。但如果缓存里没有这个域名的记录，此时根据配置不同有两种选择：一是向自己的上级DNS服务器请求（Forwarder），二是从root-hints开始逐级向下解析。比如当收到www.sina.com的请求的时候，DNS发现缓存里有.com的域名的NS（域名服务器指向）记录，随即向该服务器请求sina.com，获得一个新浪的域名的NS记录以后转而向该服务器请求 www.sina.com。新浪的服务器返回结果，解析成功并将结果返回用户，同时将中间所有的结果都缓存下来以备下次使用。
从上面的过程可以看出，绝大多数的用户频繁访问的域名都已经在比较低级的DNS缓存了，一般几小时才会向该域名 的权威服务器发送请求。
再来看看此次断网事件：
首先DNSPod被攻击了，其实在断网前几天DNSPod的Web服务器（和NS1）也被攻击过。因为流量巨大，当地电信在骨干网上封掉了他们电信主域名服务器的IP。
3600 秒以后，缓存在各地DNS服务器上的暴风的记录过期，但此时暴风指向DNSPod的NS记录还没有过期（一般是24小时），于是各地的DNS继续向已经被封掉IP的服务器发送查询。由于域名查询使用UDP协议，服务器不会马上意识到对方主机已经下线（也可能与电信封IP的方式也有关，没有返回ICMP 包），在超时以后才放弃查询。但由于DNS服务器一般被配置为不缓存失败的查询，所以下一个DNS请求来的时候它还是得去向那个封掉的IP发送查询。
（注意此时DNSPod的IP被电信封了，后续所有的内容都和DNSPod无关。）
然后我们看看暴风客户端在干什么，首先它很”无辜“地向自己的服务器请求一个广告或者升级，于是需要解析服务器的域名。电信的DNS服务器收到请求以后，等待两秒没收到结果，只好对客户端说sorry。可是暴风客户端马上开始重试重试再重试，于是全国上亿的暴风用户都向DNS服务器发出的请求。由于这些服务器始终无法解析出域名，这些请求逐渐被堆积在内存里。最悲哀的是每个请求需要有一个请求ID以对应每一个客户端，而这个ID数量是有限的，当并发请求数达到一定数量的时候内存或者ID耗尽，服务器拒绝服务了。
从以上可以看出，此次的元凶除了最早攻击DNSPod的黑客以外，大概就是暴风流氓式的程序设计了。
首先说说DNS是怎么注册的：
一个域名注册成功以后上级域名的拥有者把这个域名的解析授权（Delegate）给用户指定的域名服务器，此时该服务器成为该域的权威（Authoritative）服务器，一切到该域名的查询以此服务器提供的结果为准。（也存在不授权只设置NS记录的情况。）
比如新浪注册了sina.com，向VeriSign交了钱以后，VeriSign在他们的根域名服务器里面添加如下的记录：
sina.com. 60 IN NS ns3.sina.com.cn.
sina.com. 60 IN NS ns1.sina.com.cn.
sina.com. 60 IN NS ns2.sina.com.cn.
ns1.sina.com.cn. 37305 IN A 202.106.184.166
ns2.sina.com.cn. 37305 IN A 61.172.201.254
ns3.sina.com.cn. 37305 IN A 202.108.44.55
然后我们看如何解析：
因为DNS是非常基础的服务直接关系到网络访问的效率，所以DNS是采用多级缓存的方式运作的。通常一个程序发出DNS请求以后，系统会先搜索自己的DNS 缓存，没有找到则会向网络设置中的DNS服务器发出请求。对一个电信用户来说这个服务器被DHCP协议自动配制成电信指定的服务器。
电信的DNS服务器在收到请求后还是检查自己的缓存，与个人电脑的缓存机制不同的是，一般公共DNS服务器为了加快解析减少流量，都将一个成功的解析缓存域名记录中指定的最长时间（即TTL值，常见的是3600秒）。但如果缓存里没有这个域名的记录，此时根据配置不同有两种选择：一是向自己的上级DNS服务器请求（Forwarder），二是从root-hints开始逐级向下解析。比如当收到www.sina.com的请求的时候，DNS发现缓存里有.com的域名的NS（域名服务器指向）记录，随即向该服务器请求sina.com，获得一个新浪的域名的NS记录以后转而向该服务器请求 www.sina.com。新浪的服务器返回结果，解析成功并将结果返回用户，同时将中间所有的结果都缓存下来以备下次使用。
从上面的过程可以看出，绝大多数的用户频繁访问的域名都已经在比较低级的DNS缓存了，一般几小时才会向该域名 的权威服务器发送请求。
再来看看此次断网事件：
首先DNSPod被攻击了，其实在断网前几天DNSPod的Web服务器（和NS1）也被攻击过。因为流量巨大，当地电信在骨干网上封掉了他们电信主域名服务器的IP。
3600 秒以后，缓存在各地DNS服务器上的暴风的记录过期，但此时暴风指向DNSPod的NS记录还没有过期（一般是24小时），于是各地的DNS继续向已经被封掉IP的服务器发送查询。由于域名查询使用UDP协议，服务器不会马上意识到对方主机已经下线（也可能与电信封IP的方式也有关，没有返回ICMP 包），在超时以后才放弃查询。但由于DNS服务器一般被配置为不缓存失败的查询，所以下一个DNS请求来的时候它还是得去向那个封掉的IP发送查询。
（注意此时DNSPod的IP被电信封了，后续所有的内容都和DNSPod无关。）
然后我们看看暴风客户端在干什么，首先它很”无辜“地向自己的服务器请求一个广告或者升级，于是需要解析服务器的域名。电信的DNS服务器收到请求以后，等待两秒没收到结果，只好对客户端说sorry。可是暴风客户端马上开始重试重试再重试，于是全国上亿的暴风用户都向DNS服务器发出的请求。由于这些服务器始终无法解析出域名，这些请求逐渐被堆积在内存里。最悲哀的是每个请求需要有一个请求ID以对应每一个客户端，而这个ID数量是有限的，当并发请求数达到一定数量的时候内存或者ID耗尽，服务器拒绝服务了。
从以上可以看出，此次的元凶除了最早攻击DNSPod的黑客以外，大概就是暴风流氓式的程序设计了。
Leave a comment