DNS is traditionally used to resolve a domain name to an IP address, this is known as forward resolution. Reverse DNS (rDNS) is the opposite of this whereby an IP address is resolved to a domain.
rDNS uses the arpa (address and routing parameter area) top level domain (TLD). The in-addr.arpa domain is used for IPv4 while ip6.arpa is used for IPv6 addresses.
This all sounds very backwards, let me explain…
The hosts file is stored on a computer or device to provide local entries for DNS lookup. Normally when you try to resolve a hostname or domain, your computer will consult your specified DNS server to discover the IP address that it points to. This requires that there is an existing DNS server out there with the record that you require, with the hosts file you can fake DNS entries that will resolve only on the local machine.
Why would you want to do this? It’s great for testing or troubleshooting. You may want to use a specific hostname that no DNS exists for, though ideally you should create DNS records where possible as they can be centrally managed. It can help you get around DNS propagation issues, for example if a DNS record has been updated but had a TTL of 24 hours you may have to wait up to this long (assuming the cache cannot be cleared) before the record will resolve to the new IP address. By adding a temporary host file entry you can resolve to the new IP address straight away as the hosts file takes precedence over external DNS.
Most of us would be familiar with the simple ICMP based ‘ping’ command which allows us to test for a basic response from some network connected device. While great for basic troubleshooting it does not allow us to confirm if the particular host at the other end is responding on TCP or UDP ports where the majority of services are likely to be provided.
Ping isn’t the be all and end all of network troubleshooting, if a firewall blocks inbound ICMP traffic then a ping will not succeed which can produce a false perception that the host is down as it is not responding to the ping, however other services could still be responding fine.
Alternatively while ping may come back fine with a response it doesn’t indicate if a web server is responding on port 80 for HTTP requests, the web server may have failed and no longer be responding.
So if ping is ICMP based, can we hit a TCP or UDP port for response instead? The answer is yes, let’s take a look.
While trying to transfer templates within Citrix CloudPlatform (Apache CloudStack) between different zones I received the below error:
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
This post covers how to fix this.