感谢匿名人士的投递
新闻来源:原创
最近在CB上看到多篇存在关于DNS故障的文章,其中大多存在谬误,让人产生问题在于DNSPod,而暴风影音是无辜的受害者的错觉。这里我觉得有必要出来说说DNSPod才是无辜受害者,错全在暴风(还有***)。 首先说说DNS是怎么注册的:
新闻来源:原创
最近在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的***以外,大概就是暴风流氓式的程序设计了。
比如新浪注册了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的***以外,大概就是暴风流氓式的程序设计了。
转载于:https://blog.51cto.com/lotson/268237