DNS name resolution with traceroute

chinadomain-name-systemnetworking

i'm using my computer inside China to connect server outside country.
I tried many days a traceroute command to domain.com, that has ip address 114.157.42.212 and everytime the response is like this:

traceroute to domain.com (0.0.27.223), 64 hops max, 52 byte packets

Everytime i try i get a different Class A address tht begin with 0.0.x.x, but if i use a VPN (such as OpenVPN) the address is right…

Could you help me to understand why?
Due to without VPN traceroute doesn't work, could happen that chinese DNS (and great firewall system), manipulates DNS name resolution and redirect my computer to a different ip address?

Best Answer

Yes, it’s possible to manipulate DNS name resolution. It could be done in the Chinese firewall or somewhere else.

As I found, the IP address you provided is in Japan but it’s not blacklisted by the Chinese firewall.

There’re some resources that can help to test a web-site availability from China, like Blocked in China. Currently, it shows that the domain name reversed from the provided IP address is accessible from anywhere in China.

Related Solutions

Windows 7: Why ‘localhost name resolution is handled within DNS itself’

I checked with a developer on the Windows team, and the actual answer is much more innocuous than the other answers to this post :)

At some point in the future, as the world transitions from IPV4 to IPV6, IPV4 will be eventually be disabled/uninstalled by companies that want to simplfy network management in their environments.

With Windows Vista, when IPv4 was uninstalled and IPv6 was enabled, a DNS query for an A (IPv4) address resulted in the IPv4 loopback (which came from the hosts file). This of course caused problems when IPv4 was not installed. The fix was to move the always present IPv4 and IPv6 loopback entries from the host into the DNS resolver, where they could be independently disabled.

-Sean

Setting the Hostname: FQDN or Short Name?

I would choose a consistent approach across the entire environment. Both solutions work fine and will remain compatible with most applications. There is a difference in manageability, though.

I go with the short name as the HOSTNAME setting, and set the FQDN as the first column in /etc/hosts for the server's IP, followed by the short name.

I have not encountered many software packages that enforce or display a preference between the two. I find the short name to be cleaner for some applications, specifically logging. Maybe I've been unlucky in seeing internal domains like server.northside.chicago.rizzomanufacturing.com. Who wants to see that in the logs or a shell prompt?

Sometimes, I'm involved in company acquisitions or restructuring where internal domains and/or subdomains change. I like using the short hostname in these cases because logging, kickstarts, printing, systems monitoring, etc. do not need full reconfiguration to account for the new domain names.

A typical RHEL/CentOS server setup for a server named "rizzo" with internal domain "ifp.com", would look like:

/etc/sysconfig/network:
HOSTNAME=rizzo
...

/etc/hosts:
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

172.16.100.13   rizzo.ifp.com rizzo

[root@rizzo ~]# hostname 
rizzo

/var/log/messages snippet:
Dec 15 10:10:13 rizzo proftpd[19675]: 172.16.100.13 (::ffff:206.15.236.182[::ffff:206.15.236.182]) - Preparing to               
 chroot to directory '/app/upload/GREEK'
Dec 15 10:10:51 rizzo proftpd[20660]: 172.16.100.13 (::ffff:12.28.170.2[::ffff:12.28.170.2]) - FTP session opened.
Dec 15 10:10:51 rizzo proftpd[20660]: 172.16.100.13 (::ffff:12.28.170.2[::ffff:12.28.170.2]) - Preparing to chroot                
to directory '/app/upload/ftp/SRRID'

Best Answer

Related Solutions

Windows 7: Why ‘localhost name resolution is handled within DNS itself’

Setting the Hostname: FQDN or Short Name?

Related Topic