这适用于网络中的所有客户端(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