1

We have a managed server with centos, recently it starts showing strange behavior:

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

So this looks quite good.

And here it becomes strange. We get our own server instead of the google server!

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, however, looks good:

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

And wget and lynx also give us our own server.

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)

What can be the reason for this? Why do traceroute and wget and lynx use different addresses?

  • 3
    ask your sysadmin. – Ipor Sircer Dec 5 '17 at 10:15
2

You did not use fully-qualified domain names. www.google.com is not a fully-qualified (human readable form) domain name. It does not end with a dot.

You also have a search path of plannersys.net. configured in your DNS client library and a wildcard DNS resource record for *.plannersys.net..

As a consequence of these, wget and tranceroute looked up the fully qualified domain name www.google.com.plannersys.net. and received the IP address 75.102.21.14 as the result. Your DNS client library, remember, turns non-fully-qualified domain names into fully-qualified domain names using the configured search paths and then issues lookups for the fully-qualified names.

nslookup differed because it uses a different, internal, DNS client library. Amusingly, this is one instance where it did not differ from ping, but that is probably because your DNS client library is configured with multiple proxy DNS servers that do not all present the same view of the DNS namespace, or you have something like systemd-resolved in the mix that is changing your DNS client configuration on the fly. There is zero information about your DNS client library in your question, so there is not enough information from you for anyone to determine exactly why this is.

Further reading

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.