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 in-addr.arpa 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 vanginderachter.be
100 mail1.www.ginsys.eu.
300 mail.rollernet.us.
300 mail2.rollernet.us.

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

serge@goldorak:~$ dig +short A mail1.www.ginsys.eu
80.68.91.64

Now, as stated in RFC 1912, that IP needs a reverse lookup entry 64.91.68.80.in-addr.arpa:

serge@goldorak:~$ dig +short PTR 64.91.68.80.in-addr.arpa
skuniboot.www.ginsys.eu.

Or as a short form lookup:

serge@goldorak:~$ dig +short -x 80.68.91.64
skuniboot.www.ginsys.eu.

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

serge@goldorak:~$ dig +short A skuniboot.www.ginsys.eu.
80.68.91.64

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 skuniboot.www.ginsys.eu. 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 skuniboot.www.ginsys.eu. 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
10 mailforwarding.hostbasket.com.
dig +short A mailforwarding.hostbasket.com.
85.255.194.5
85.255.194.6
svg@skuniboot:~$ dig +short -x 85.255.194.5 -x 85.255.194.6
hosted.by.hostbasket.com.
/postfix/hosted.by.hostbasket.com.
svg@skuniboot:~$ dig +short A hosted.by.hostbasket.com.
212.123.6.131
svg@skuniboot:~$ dig +short -x 212.123.6.131
hosted.by.hostbasket.com.

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
# hosted.by.hostbasket.com
195.130.154.125 OK
195.130.154.124 OK

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 195.130.154.125 -x 195.130.154.124
hosted.by.hostbasket.com.
avas4.hostbasket.com.

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

svg@skuniboot:~$ dig +short A avas4.hostbasket.com
85.255.194.5

OK, another IP again, which reverses to hosted.by.hostbasket.com 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 hosted.by.hostbasket.com. 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
50 hotel.openminds.be.
10 tango.openminds.be.
svg@skuniboot:~$ dig +short A hotel.openminds.be. tango.openminds.be.
193.221.125.47
195.47.215.24
svg@skuniboot:~$ dig +short -x 193.221.125.47 -x 195.47.215.24
hotel.openminds.be.
tango.openminds.be.

Simple. Short. Nice configured. Even better than my domain, who users an extra generic, separate A record mail1.www.ginsys.eu. 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!