Posted on by barnesa

DNS, and how to Get (your) Host By Name

Trying to resolve a internet host name, and seeing different responses depending on how you do the lookup?  DNS messing with your head?  Maybe this will help 🙂

The Problem

There are multiple ways to get to a server… using the IP address is one way, but the more popular (and more useful) is using the hostname (or more specifically “FQDN” – the Fully Qualified Domain Name).

Domain Name Services (DNS) is the service that provides the lookup capability, matching a FQDN (eg. host.name.com) to its IP address (eg. 107.162.140.96 … yes, it turns out whatI thought was a made-up FQDN actually resolves!).

But – sometimes, you don’t want to use DNS, and yet you want to be able to resolve a FQDN, perhaps you want to “override” a valid, DNS resolvable, FQDN with a different entry.

Good news, there is a way to do this!

gethostbyname

There is a way around using DNS to resolve the address(es) – this is by making an update to the system’s host file:

  • Linux = /etc/hosts
  • Windows = C:\Windows\System32\Drivers\etc\hosts

This works because the operating system call gethostbyname uses a resolver process the first looks for entries in the local hosts file, followed by DNS (if there is no corresponding entry in the hosts file) ***

Observing the changes in behaviour

There are 2 ways to see the difference behaviour:

  1. telnet host.name.com 443
  2. nslookup host.name.com

There is an expected difference in response between the 2 commands:

In #1, we are explicitly invoking the telnet process – to initiate a connection to the device with FQDN of host.name.com on TCP port 443.  The application process, telnet, defaults the gethostbyname mechanism for resolving the IP address of host.name.com – per above it will check the local hosts file first, and if that fails will attempt a lookup using DNS

In #2, we are doing something specifically different. We are invoking the nslookup process – but the defined purpose of this application is to lookup up query Internet DNS servers interactively.  As such – it does not follow the gethostbyname system call, and instead goes directly to DNS

This is a Good Thing (TM)

While the behaviours are different, they are different by design, and this is most definitely a Good Thing (TM)

Real-World Example:

OK, but why?

Why take you through this journey?  Recently I had a colleague describe to me a problem caused by the (failed) name resolution of an internet facing service - using their default DNS servers.  Making host file changes, as I documented in our corporate Wiki, will allow them to work around this problem.

Is there more?

Which brings us back to network connectivity.  In this particular use-case, the server MUST be able to connect to the internet-facing service on TCP port 443.  They can test this connectivity manually using a “telnet test” from their server to the Fully Qualified Domain Name (FQDN) of the internet-facing service.  If this does not work, they should do a telnet test to the IP(s) of the internet-facing service (having done the DNS lookup manually first).

If both these telnet tests fail, it indicates that their server does not have direct access to the internet-facing service.  In this happens, they have one of 3 options:

  1. Review the network routing configuration for your server, use static routes to force traffic via a specific interface that does have access *****
  2. Open up the firewall rules to permit the outbound traffic
  3. Use a proxy server to make the connection, and then configure their server to use the proxy server

***** They had mentioned to me that their servers have multiple interfaces.  It could be that their traffic needs to go via a different interface.  If this is the case, then they can use traceroute (or tracert for Windows servers) to determine what interface is used by default.  If a change is needed then adding a (permanent) static route for each of the IPs to go via the non-default interface will force the change in traffic behaviour

*** Technically, this behavior can be modified – but is an explicit step and I’d class as “unusual/non-standard”

In conclusion

DNS is awesome, but sometimes you need to play around with things and have a way to bypass.  hopefully the above content, and example, has given a little insight into why different services behave in different ways, and why this is a Good Thing (TM)