DNS failures can be the result of some fairly innocuous issues that arise due to fundamental configuration flaws or recent changes (and updates) to a system. This type of event can happen and, for this reason, it is always useful to run through a checklist of sanity checks before you hit the panic button.

So, by starting with a basic tool such as ping, nslookup, or dig, you can begin testing for areas of concern. For example, you can use telnet like this:

# telnet <remote-server-address> 53

The telnet command is a nice and easy tool to use, and if the connection is refused or takes too long, then you can rule out the possibility of RDNS errors by simply renaming the reverse DNS file and trying again.

Now, if you do this, make sure that the forward DNS remains functional and reattempts a telnet connection. If this works, you will know that the RDNS is at fault and you can double-check this by confirming the forward zones with nslookup:

# nslookup...