BIND 转发超时的问题

给好几个客户做了 BIND 转发服务，其中一个老是出各种幺蛾子，今天又碰上。

客户多个出口断开，但不是所有，但全网 DNS 服务全断了， DNS 服务器本身访问内外网络正常，配置如下：

options { 
    recursion yes;
    blackhole {  };
    forward only;
    allow-query { any; };
    forwarders { a.a.a.a;b.b.b.b; };
}

......

zone "taobao.com" { 
type forward;
forwarders { a.a.a.a;b.b.b.b; }; 
};

.....

BIND 的选择算法之前还真没仔细分析过，当其中一个转发目标不可用时，另一个转发目标被启用，但是有个超时时间，我搜索到下面的文章：

http://blog.csdn.net/midsum/article/details/21477975

“ 直到客户遇到了这样的问题。该客户有两个转发服务器 A 和 B ，现在是 A 正常， B 超时并且一直超时，也就是说， B 在每一次被重试之后，都被重新设定为 20000 ，之后都会转发给 A ，直到 B 乘以 0.98 的数次之后又小于 A ，才又被重试。但是，根据客户的计算， 20000 的值在 150 多次之后将会减小到 A 值相同的值（即： 20000 * 0.98^150 < A->srtt ），而 B 因为超时，每次往 B 的转发都会长达 30 秒钟（默认设定重试时间为 30 秒）。而当访问量很大时， 150 次的查询只需要几秒钟（该客户好像是每分钟上万次的查询）。这样就造成了这么一种感觉，即几秒钟的反应之后，接着是 30 秒钟的超时，然后又是几秒， 30 秒....，整体上看来，就是绝大多数时间里， DNS 都是不可用的状态。”

我的客户也正好是碰到这个问题，断开的出口恢复后， DNS 转发也立即恢复了，但是预期的多个转发备份功能失效了。本来客户同时有两个转发服务器，但出口断了，全部都是一样的问题，

那么如何更好的解决这个问题，避免全网投诉。

jamiesun

2016-05-14 11:42:21 +08:00

@bobopu 谢谢，我现在想明白了不少，给客户做的这个服务确实做得不够周到，覆盖几万用户的服务，后端对 DNS 转发服务是必须做一个可用性检测的，而不能仅仅依赖 BIND 本身的算法机制。

我现在计划做一个定时检测模块，对所有转发服务地址定时检测可用性，也是通过域名解析实现，一旦发现某个 DNS 转发服务地址不可用，立即从全局配置中剔除（并用其他可用公共 DNS 替换），标记状态不可用，并刷新配置；当检测到服务恢复时，再重新配置并刷新，标记状态可用。

另外再做一些关键域名的解析检测，用个算法来判断当前 DNS 服务器的综合健康指数。