MX record in a reverse zone

Question

I am taking a DNS course on Linux Academy. In one of the lab, they define a reverse zone. In this zone they add MXs records. Does it make sense to have MX record defined in a reverse zone?

Details:

For this they do

vim /etc/named.conf

zone "1.0.10.in-addr.arpa" {
    type master;
    file "/var/named/1.0.10.db";
};

And content of /var/named/1.0.10.db is:

TTL    86400
@       IN      SOA     nameserver.myserver.com. root.myserver.com. (
                          10030         ; Serial
                           3600         ; Refresh
                           1800         ; Retry
                         604800         ; Expiry
                          86400         ; Minimum TTL
 )
; Name Server
@        IN      NS       nameserver.myserver.com.
; PTR Record Definitions
240         IN      PTR       nameserver.myserver.com.
241         IN      PTR       mailprod.myserver.com.
242         IN      PTR       mailbackup.myserver.com.
; which is last octet of my IP
; Mail Exchange Records
@        IN    MX    10    mailprod.myserver.com.
@        IN    MX    20    mailbackup.myserver.com.

Similarly I try to add a A record in reverse but it is not relevant because a look up would be possible by doing:

nslookup <dns-name>.1.0.10.in-addr.arpa localhost

Doing

ns lookup <dns-name>.mylabserver.com localhost

would not work, (or if it is, it is a non authoritative answer, DNS recursion ). Am I correct?

I understand from https://en.wikipedia.org/wiki/MX_record that defining a MX record, requires a A record. As a consequence we can do a reverse lookup of MX with a PTR?

Thus I am wondering if adding a MX records in reverse zone makes sense, how we would retrieve this MX then?

What did I miss?

This part I cannot comprehend: "As a consequence we can do a reverse lookup of MX with a PTR?" — Håkan Lindqvist, Jun 12 '20 at 09:49
I wouldn't add anything besides PTR records in a reverse zone other than the mandatory SOA and NS records. But from the perspective of DNS syntax a zone file is a zone file. There are no special "classes" zone files with different requirements for forward and reverse zones, so all record types that are normally valid and seen in forward zones can still be used in reverse zones. Even if they won't actually make sense there — Bob, Jun 12 '20 at 09:50
As a consequence we can do a reverse lookup of MX with a PTR? It is not clear indeed. What I meant is: given that we usually have a A record matching a MX record. We will do the reverse look with the help of the PTR record matching the A record. — scoulomb, Jun 16 '20 at 18:36

score 5 · Accepted Answer · answered Jun 12 '20 at 09:51

It would only make sense if you want to receive mail addressed to eg scoulomb@1.0.10.in-addr.arpa (which seems more than a little unusual).

dig 1.0.10.in-addr.arpa MX should work for retrieving the MX record (given the zone in the question).

I would guess that this might rather be a case of them using the same template for every zone, or something along those lines. It's certainly not the typical thing to do in a reverse zone.

score 1 · Answer 2 · edited Oct 07 '21 at 07:59

I believe what you likely missed is a common spam handling trick which is fairly widely deployed.

When a connection is made to an SMTP server, some servers will do a reverse lookup on the IP address that connected to it, and then a forward lookup on that address, and check that this forward and reverse DNS match.

I am dubious as to how effective this technique is, but the idea is that if the domain name does not have reverse dns, or reverse and forward DNS don't match, the sending IP is likely not a legitimate mail server, and the mail should be considered spam. This technique is covered in RFC2505, section 1.4 (which dates to February 1999). The given reason is

When we suggest use of FQDNs rather than IP addresses this is because FQDNs are intuitively much easier to use. However, all such usage depends heavily on DNS and .IN-ADDR.ARPA (PTR) information. Since it is fairly easy to forge that, either by false cache information injected in DNS servers or spammers running their own DNS with false information in them, host and domain names must be used with care, e.g. verified so that the translation address->name corresponds to name->address."

How does this relate to the `MX` record in the reverse zone, though? — Håkan Lindqvist, Jun 12 '20 at 10:04
@HakanLinqvist that zone is either a nonsense or a actually referred to twice in named.conf once for forward, once for reverse. — davidgo, Jun 12 '20 at 12:18

MX record in a reverse zone

2 Answers2