Why Web-Based “Easy DNS Checker” Tools Cannot Reliably Troubleshoot Reverse DNS bounces
Posted in Laws by epictetus on April 25th, 2008 DNS can be somewhat complicated — SOAs, glue records, MX records, PTR records, registrars, CNAMEs, etc. It’s a lot to learn, and a lot of engineers don’t understand the tools (whois, nslookup/host, and dig being the three most important ones). I’ve seen a lot of issues recently when people are trying to configure mailservers, and having trouble sending to certain domains (getting bounce messages related to reverse DNS).
So, the engineer visits DNStuff.com or one of these other awful sites, plugs in the domain name, and gets printed out a 12-page report giving them a warning about their mailserver’s reverse DNS and some suggestions on how to fix it.
However, in many many cases, this report is wrong, and here’s why: The way reverse DNS checks typically work, when the mailserver makes an outgoing connection to a foreign server (to deliver a message), the foreign server checks for a PTR/RDNS hostname record associated with the IP your mailserver is connecting from. It then does a forward dns lookup on this hostname and tries to confirm that it resolves to the same IP. If it does, you pass the test. There is absolutely no way, whatsoever, that a web-based DNS tool could possibly know what IP your mailserver makes outgoing connections on. What most of these tools do is check your MX records and assume that the IPs that you receive incoming mail on (from the MX records) are the same as the IPs you send outgoing mail from. Many people these days use incoming mail filters that are not necessarily on the same IP addresses as their outgoing mail server.
The right way to test this is to do the same test manually — first, figure out what external IP your mailserver makes outgoing connections on (by hitting www.whatismyip.org, for example). Then, use nslookup or host to figure out if there is a reverse DNS record for this IP. If there isn’t, that is your problem right there. If there is, then use nslookup again to check the _forward_ lookup on that same hostname — this must match your outgoing connection IP.
