☰

进一步阅读

tag-icon • tag-icon ping traceroute nslookup
进一步阅读

我们有一个 Centos 托管服务器，最近它开始表现出奇怪的行为：

root@server [/tmp]# ping www.google.com
PING www.google.com (172.217.8.196) 56(84) bytes of data.
64 bytes from ord37s09-in-f4.1e100.net (172.217.8.196): icmp_seq=1 ttl=53 time=24.8 ms

所以这看起来相当不错。

这里就变得很奇怪了。我们有自己的服务器而不是谷歌服务器！

root@server [/tmp]# traceroute www.google.com
traceroute to www.google.com (75.102.21.14), 30 hops max, 60 byte packets
 1  server.plannersys.net (75.102.21.14)  0.041 ms  0.017 ms  0.015 ms

不过，Nslookup 看起来不错：

root@server [/tmp]# nslookup
> www.google.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   www.google.com
Address: 172.217.8.196
> ^C

而且wget和lynx也为我们提供了自己的服务器。

root@server [/tmp]# wget https://www.google.com
--2017-12-04 11:50:56--  https://www.google.com/
Resolving www.google.com... 75.102.21.14
Connecting to www.google.com|75.102.21.14|:443... connected.
ERROR: no certificate subject alternative name matches
        requested host name “www.google.com”.
To connect to www.google.com insecurely, use ‘--no-check-certificate’.

And with lynx:
SSL error:host(www.google.com)!=cert(troutaccess.com)-Continue? (y)

这可能是什么原因？为什么traceroute和wget和lynx使用不同的地址？

答案1

您没有使用完全合格的域名。 www.google.com不是完全合格的（人类可读形式）域名。它不以点结尾。

您还可以在 DNS 客户端库中配置搜索路径plannersys.net.和 的通配符 DNS 资源记录*.plannersys.net.。

作为这些结果，wget我们tranceroute查找了完全合格的域名www.google.com.plannersys.net.并收到了 IP 地址 75.102.21.14 作为结果。请记住，您的 DNS 客户端库使用配置的搜索路径将非完全限定域名转换为完全限定域名，然后发出对完全限定名称的查找。

nslookup不同之处在于它使用不同的内部 DNS 客户端库。有趣的是，这是一个例子没有与 不同ping，但这可能是因为您的 DNS 客户端库配置了多个代理 DNS 服务器，这些服务器并不都呈现相同的 DNS 命名空间视图，或者您有类似的systemd-resolved组合正在动态更改您的 DNS 客户端配置。您的问题中有关您的 DNS 客户端库的信息为零，因此您没有提供足够的信息供任何人确定具体原因。

进一步阅读

相关内容