我有一个Ubuntu
Linux 12.04.1服务器,作为一个服务运行bind9用于xxx.local域的名称解析,它将所有其他请求转发到我的Internet提供商的名称服务器.
@H_301_59@这适用于网络中的所有客户端(Windows和Linux),它们可以按预期获得名称解析.
直到昨天,服务器本身也是如此.但我更新了几个包并重新启动它.一切都很好,所以我回家了.今天早上,代理和电子邮件不再有效.事实证明,名称解析是罪魁祸首.客户端上的nslookup仍然正常,但在服务器上它总是超时：
nslookup google.com connection timed out; no servers could be reached nslookup google.com 127.0.0.1 ;; connection timed out; no servers could be reached nslookup google.com 192.168.115.250 ;; connection timed out; no servers could be reached
(其中192.168.115.250是服务器本身的IP地址)
在不同的Linux计算机上它可以工作：
nslookup google.com Server: 192.168.115.250 Address: 192.168.115.250#53 Non-authoritative answer: Name: google.com Address: ....
在Windows XP计算机上,它看起来像这样：
nslookup google.com
*** Der Servername für die Adresse 192.168.115.250 konnte nicht gefunden werden:
Non-existent domain
*** Die Standardserver sind nicht verfügbar.
Server: UnKnown
Address: 192.168.115.250
Nicht autorisierte Antwort:
Name: google.com
Address: ...
(错误意味着“无法找到地址的服务器名称… …这可能意味着反向查找不起作用.我以前从未见过那个.”
如果我在我的服务器上指定了我的Internet提供商的名称服务器之一,它可以工作：
nslookup google.com [IP goes here] Server: [IP goes here] Address: [IP goes here]#53 Non-authoritative answer: Name: google.com Address: ....
我无法弄清楚这里可能出现的问题.由于一切正常,直到昨天,它必须与最新的Ubuntu更新或重新启动有关.
任何提示将不胜感激.
更新：
防火墙不应该是问题：
sudo iptables -L -v -n Chain INPUT (policy ACCEPT 16M packets,6138M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets,0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 13M packets,50G bytes) pkts bytes target prot opt in out source destination
UPDATE2：
由于人们不断要求resolv.conf,我想指出,在上面的nslookup调用中指定名称服务器的IP地址不起作用.但无论如何：
cat /etc/resolv.conf: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 192.168.115.250
(如果我将该IP更改为我的Internet提供商的名称服务器,它可以工作,但这不是解决方案.)
UPDATE3：
netstat -anp | egrep :53 tcp 0 0 192.168.115.250:53 0.0.0.0:* LISTEN 104414/named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 104414/named tcp6 0 0 :::53 :::* LISTEN 104414/named udp 0 0 192.168.115.250:53168 5.9.122.148:123 ESTABLISHED 106273/ntpd udp 0 0 192.168.115.25:53 0.0.0.0:* 104414/named udp 0 0 127.0.0.1:53 0.0.0.0:* 104414/named udp6 0 0 :::53 :::* 104414/named
看起来很好.
UPDATE4：
ip route show table local local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 broadcast 192.168.115.0 dev eth0 proto kernel scope link src 192.168.115.250 local 192.168.115.250 dev eth0 proto kernel scope host src 192.168.115.250 broadcast 192.168.115.255 dev eth0 proto kernel scope link src 192.168.115.250
我不知道如何解释这一点.
UPDATE5：
我刚刚发现了另一个奇怪之处：它不只是命名不起作用而且还有smtpd：
fetchmail: reading message [...] Trying to connect to 127.0.0.1/25...connection Failed. fetchmail: connection to localhost:smtp [127.0.0.1/25] Failed: Connection timed out. fetchmail: Connection errors for this poll: name 0: connection to localhost:smtp [127.0.0.1/25] Failed: Connection timed out. fetchmail: SMTP connect to localhost Failed
