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 🙂
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. 18.104.22.168 … 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!
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:
- telnet host.name.com 443
- 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)
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:
- Review the network routing configuration for your server, use static routes to force traffic via a specific interface that does have access *****
- Open up the firewall rules to permit the outbound traffic
- 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”
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)