请高手会诊——named死掉的问题

bloodsun

一、环境描述
有两台DNS服务器，两台DNS服务器一主一备。机器型号均为HP RP2405，硬件配置为：1CPU，512MB内存，操作系统为HP-UX 11i，安装的DNS软件为BIND 9.2.3 for HP-UX（注：最先安装的版本是9.2.0，后打补丁升级到9.2.3版本）。
因原来的主DNS服务器（HP RP2405）常出BIND问题，现主DNS服务器已换成HP RP5405，硬件配置为：2CPU，4GB内存

二、故障现象
    从2004年5月起，就开始出现DNS上的named进程死掉，造成DNS域名解析服务中断，直接的后果是无法上互联网。最严重的时候曾经出现过两台HP RP2405都发生named进程死掉的情况。从2004年10月-11月，主DNS服务器出现过几次named进程死掉的情况，HP 800热线的服务人员曾经登录到该服务器上检查过硬件设备，说没有问题。但named进程死掉的原因，HP也查不出来。此种现象出现的频率不固定，有时很长时间都不出问题，有时相隔3－4天就连续出现。在系统日志里面，即便在BIND正常运行期间，也经常出现“dispatch: error: dispatch 406a7c78: shutting down due to TCP receive error: connection reset”的提示，也不清楚原因。
    现已将主DNS服务器上的服务转移到一台HP RP5405上，最近也出现过一次named进程死掉，在HP RP5405的系统日志里也常出现“dispatch: error: dispatch 406a7c78: shutting down due to TCP receive error: connection reset”的提示。
    每次出现DNS进程死掉时，域名无法解析，用户端无法上网，但UNIX并未死机，通过手工启动DNS进程进行恢复。
    最近出问题的一次，是2005年1月13日下午2点，当时DNS服务器（HP RP5405）上的named进程并未死掉，但DNS服务器不能解析域名，登录至DNS本机（HP RP5405）上，本机也无法解析本域及外域域名。当时的应急处理办法还是先手工Kill掉named进程，再手工启动该进程后，情况才恢复正常。检查SYSLOG及BIND日志，没有发现BIND出问题时的任何记录。
    需要说明的是，将DNS主服务器由原来的HP RP2405换成HP RP5405后，每次当BIND出问题时，日志里面都没有“出问题那一时刻”的日志记录，在BIND的日志记录里只能看到BIND重新启动时的启动信息。

三、目前情况
1、对于DNS系统日志里面，常出现“dispatch: error: dispatch 406a7c78: shutting down due to TCP receive error: connection reset”的提示，我曾打电话咨询HP 800热线，但他们的答复是，硬件没有问题，出现这种提示可忽略掉。但这种回答显然很无稽。
2、对于named进程为何会死掉以及2005年1月13日出现DNS的问题，HP 800热线也查不出问题原因。

tomyung

楼主，BIND的LOG是打开的？平时有没有区传送的LOG？如果有的话，查查在最近那次出错的时候BIND有没有区传送动作？因为我记得大大们说过BIND在进行DNS更新的时候用的是TCP。

  主DNS是否有受到攻击？

　你的DNS是在IDC机房吗？能排除线路方面的问题吗？主备DNS之间是直接相连的吗？如果不是，与主DNS直接相连的设备是交换机还是路由器？能否在相关设备端口上查到error记录？


－－－－－
　偶很菜，也很好奇，随便问一下，楼主别见怪

kor

如果想避免出现情况,可以这样:
bind死掉的频率不高的话，建议增加一个shell脚本或者perl程序，监控named进程，死掉的话自动重起。
虽然不能解决故障，但起码不会造成大面积的瘫痪，可以及时恢复服务，慢慢查故障。

abel

樓主的 log 與問題無關,所以我也沒法判斷,
建議您將 logging 設到 debug 級

另外,在這種情 kor 兄的建議對您來說是最實際的
先暫時解決不能服務問題再來找問題

bloodsun

1。BIND的LOG是打开的，“平时有没有区传送的LOG”这个问题我正在落实
    2。查过IDS入侵检测系统的日志记录，主DNS没有受到过攻击
    3。DNS服务器是在中心机房，主备DNS之间不是直接相连，与主DNS直接相连的设备是交换机，相关设备端口上目前还没有查到error记录。
    4。线路没有问题，目前可以排除是DNS服务器的硬件故障。

bloodsun

1月21日下午，DNS服务器又出现了一次故障，现象和1月13日的情况相同，均是不能进行域名解析，但named进程没有死掉。与上次情况相同，这次出现问题时，系统没有产生出错时的日志记录。
    情况如下：
    1、目前基于HP－UX平台的DNS配置参数正常，目前配置成5500用户/秒的吞吐率。
    2、在出现问题时，检查DNS服务器上内存和CPU的占用率都很低，其中内存占用率为4％。
    3、用户讲，在系统日志中常出现的“09:43:50.581 dispatch: error: dispatch 40610468: shutting down due to TCP receive error: connection reset”在DNS刚投入使用时未出现过，后来才出现的，从2004年10月起，出现该提示的次数就越来越多。对这种提示，HP 800热线的人水平太低，根本解决不了。
    4、今天下午正在查这两天中心机房IDS入侵检测系统的日志记录，看是否DNS服务器受到攻击。不过，从前面几次DNS出现问题的情况来看，也没有发现有DNS受到攻击的现象。

    以上情况供参考。



     谢谢各位的意见。
     kor兄的建议是针对named进程死掉的办法，但现在没死，也解析不了。我总不能做个定时重启的shell吧。
    郁闷中~~~


********************

snail1981

我也遇到过与bloodsun一样的问题。SUN_SOLARIS平台，机器硬件性能不高。据我观察named总在log中出现“09:43:50.581 dispatch: error: dispatch 40610468: shutting down due to TCP receive error: connection reset”后死掉；named死掉后cpu空闲为零，sys 与usr的占用都不高，但wio总高达80%~90%，内存空闲也小于总物理内存的1/64。
因为wio高，又出现shutting down due to TCP receive error: connection reset的log，一直怀疑是网线网卡或路由器端口问题，但是网卡网线都换过（端口因资源问题未更换）问题还是一样出现。

现在怀疑是否是做区域传输时硬盘瓶颈造成的？

另：BIND版本是9。2。2，运行一直正常，也是04年10月左右开始出现此问题。

snail1981

关于“09:43:50.581 dispatch: error: dispatch 40610468: shutting down due to TCP receive error: connection reset”这条LOG伴随出现的问题在网上总找不到一个正面、完整的解释。GOOGLE上搜到800多条看了前100多，不是没回复就是none sense。还希望这里的高手给点建议。多谢了！

cicc

dns1
os:redhat as3 u2,双超线程至强2.0 ，2G内存
dns2
os:redhat as3 u2,双p3 800，2G内存
bind 9.3.0
两个机器都有过named当掉的情况，不定时的named还在跑，就是不能解析
telnet 53端口正常。log没问题。
有很少几次是在区传送结束后。
业务量不大，查询量在每秒2000-4000
有个有趣的问题就是至强的机器比p3的机器发生的频率大很多，至强机器平均每天都有2-3次，p3机器平均3天一次
我现在正在找机会把至强机器的超线程禁用掉看看，因为我发现每次named down掉的时候从sysstat sar读到的cpu是跑满的，就是至强机器是25%，p3机器是50%，不知道是否算系统的bug或者这个bug是否会影响named
我把lameserver干掉了，iowait就没什么了
以上是我的情况，请各位大牛参考

tomyung

....看起来这种情况没有什么针对性阿，可惜偶水平不够，不过偶想问问楼上的各位，你们放置DNS的环境怎样呢？DNS服务器周围或是与DNS服务器直接相连的设备有什么大型用电设备吗？在DNS出现故障的时候，有没有其它的什么服务器或设备也出现异常？

我在网上也找了一下，觉得http://dev.csdn.net/Develop/article/article/30/30851.shtm这篇文章不错，里面有提到connection reset的情况，不知道和大大们说的情况是否相似（我觉得差不远了 :wink: ）

我在BIND的源代码中找到这么几段，大大们看下：

1.         if (tcpmsg->;result != ISC_R_SUCCESS) {
   
2.                 switch (tcpmsg->;result) {
   
3.                 case ISC_R_CANCELED:
   
4.                         break;
   
5.                        
   
6.                 case ISC_R_EOF:
   
7.                         dispatch_log(disp, LVL(90), "shutting down on EOF");
   
8.                         do_cancel(disp, NULL);
   
9.                         break;
   
10. 
    
11.                 default:
    
12.                         dispatch_log(disp, ISC_LOG_ERROR,
    
13.                                      "shutting down due to TCP "
    
14.                                      "receive error: %s",
    
15.                                      isc_result_totext(tcpmsg->;result));
    
16.                         do_cancel(disp, NULL);
    
17.                         break;
    
18.                 }

复制代码

位置是在bind-9.2.3\liib\dns\dispatch.c

1. typedef struct dns_tcpmsg {
   
2.         /* private (don't touch!) */
   
3.         unsigned int                magic;
   
4.         isc_uint16_t                size;
   
5.         isc_buffer_t                buffer;
   
6.         unsigned int                maxsize;
   
7.         isc_mem_t               *mctx;
   
8.         isc_socket_t               *sock;
   
9.         isc_task_t               *task;
   
10.         isc_taskaction_t        action;
    
11.         void                       *arg;
    
12.         isc_event_t                event;
    
13.         /* public (read-only) */
    
14.         isc_result_t                result;
    
15.         isc_sockaddr_t                address;
    
16. } dns_tcpmsg_t;

复制代码

位置在bind-9.2.3\lib\dns\include\dns\tcpmsg.h
还有

1.         dns_tcpmsg_t                tcpmsg;                /* for tcp streams */

复制代码

位置也在bind-9.2.3\liib\dns\dispatch.c

我对编程了解不多，一看BIND的源代码就头晕...但结合上面的信息来看，我还是认为各位大大的DNS受到攻击的可能性比较大。。。大大们认为呢？还请赐教，谢谢。