Forward Confirmed Reverse DNS

Forward Conmed Reverse DNS (FCrDNS) , is when an IP address has both forward (name -> IP) and reverse (IP -> name) DNS entries that match each other. Failing to properly configure FCrDNS is failing to adhere to basic internet rules, as explained in RFC 1912:

Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious. Many services available on the Internet will not talk to you if you aren't correctly registered in the DNS.
Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all. Also, PTR records must point back to a valid A record, not a alias defined by a CNAME.

FCrDNS explains an important point on how DNS should be properly configured, not the least important for mail servers. Let’s check my domain (read the last section on MX checks.)
First of all, let’s verify which are my mail servers.

serge@goldorak:~$ dig +short mx

The primary is of course, the other ones being backup relayers. Let’s dig up this server’s IP address:

serge@goldorak:~$ dig +short A

Now, as stated in RFC 1912, that IP needs a reverse lookup entry

serge@goldorak:~$ dig +short PTR

Or as a short form lookup:

serge@goldorak:~$ dig +short -x

And that hostname A record should point back to that same IP address:

serge@goldorak:~$ dig +short A

Simple enough? In fact, a whole lot of servers are not configured like that. Often they are configured with different A and PTR records and sometimes without an existing PTR record, which can break email reception from them. More and more mail servers are configured to bounce emails from servers with such a broken configuration. As is But as a lot of admins don’t follow the rules, I need to whitelist certain broken servers to be able to receive email from them.

Note that above examples are mostly important for email that is sent by Most of the mails I sent from my personal email address, from my personal home desktop, is sent through my ISP’s relayers? In such case, you better hope your ISP follows the rules. My ISP, Telenet tends to behave pretty well. Other Belgian ISP’s like Belgacom/Skynet don’t always follow the rules. Even big hosting companies which tend to have a good name in the corporate world, like Hostbasket, often break the rules.

svg@skuniboot:~$ dig +short mx somedomain.belgium
dig +short A
svg@skuniboot:~$ dig +short -x -x
svg@skuniboot:~$ dig +short A
svg@skuniboot:~$ dig +short -x

Looks good? Then why do I need to whitelist certain IP’s to be able to receive mail from somedomain.belgium?

svg@skuniboot:~$ less /etc/postfix/access

Hmpf. Another series of IP’s for that domain. Those are ip’s who sent mail from that domain to me. Mail that initially got blocked by postfix’ reject_invalid_hostname and especially reject_unknown_hostname directives to check on the rules I explained above, and that only got through after I whitelested them. Let’s check the PTR records:

svg@skuniboot:~$ dig +short -x -x

Hmpf. The first IP looks good (now), the second gives another A record.

svg@skuniboot:~$ dig +short A

OK, another IP again, which reverses to as we saw above.

All in all, not that bad I must say. But, as you may have noticed, they tend made things a little difficult with their marketing driven A record. The RFC paragraph 2.1 I quoted above also mentioned:

It is highly recommended that you use some software which automates this checking, or generate your DNS data from a database which automatically creates consistent data.

which should not be a problem for such a big hosting company.
One last example? Let’s show some good guys now.

svg@skuniboot:~$ dig +short MX whiplash.commercial
svg@skuniboot:~$ dig +short A
svg@skuniboot:~$ dig +short -x -x

Simple. Short. Nice configured. Even better than my domain, who users an extra generic, separate A record in the MX records. (AFAIK there’s no problem with that and it’s in respect with RFC’s – tell me if otherwise! – but, although it makes it easier to configure things when you want to change a lot of domains to another mail server, I tend to think it’s less clean.)

That’s all folks!