Why have MX records? [closed]

Question

I previously asked a question regarding MX records (and appreciate the thoughtful answers I received from SO'ers). Now that that problem is resolved, I want to step back and ask why there are MX records in the first place.

Specifically: Why does SMTP get special treatment by DNS?

We don't have HX records for HTTP or FX records for FTP. It seems like every other Internet protocol gets along just fine with DNS' A record. Indeed, the Wikipedia article on MX records states that the current SMTP spec says that if an MX record does not exist for a receiver, the server should fall back on an A record. It also mentions some accommodations SMTP made in a pre-DNS world, but that was 25 years ago. Do we really need MX records any more?

Answer 1

MX records were used because there was a need for SMTP traffic to user@domain to be routed differently to other traffic for that domain, and SRV records hadn't been invented yet.

The modern convention that you can type http://example.com/ in your browser without a www prefix and still get to the required website is actually a bit odd. To explain in more detail, consider how a zone would normally be setup to achieve this prefix-less access:

$ORIGIN example.com
@        IN A   192.168.1.1
         IN MX mail.example.com
www      IN A  192.168.1.1
mail     IN A  192.168.1.2

So, any traffic addressed to example.com goes to that IP address, regardless of the protocol in use (unless it's e-mail which will use the MX record).

In practise it would be preferable for all applications to make use of SRV records, and then we could do away with the application specific prefixes all together, and use A records for their real purpose - specifically mapping real hostnames to IP addresses.

If SRV records were used in this way that zone file would look instead like:

$ORIGIN example.com
_http._tcp IN SRV 0 0 80 www.example.com
_smtp._tcp IN SRV 0 0 25 mail.example.com
www        IN A 192.168.1.1
mail       IN A 192.168.1.2

This assumption that the primary A record at a domain is actually for HTTP service is also part of the reason why Verisign's SiteFinder "service" caused as many problems as it did when it was (briefly) introduced in 2003. By intercepting all DNS A record lookups for unknown domains and returning one of their own addresses, Verisign broke all sorts of protocols that assumed that they could fail-over to other address database mechanisms if the DNS lookup failed.

Answer 2

The main purpose behind the MX records is the ability to specify machine(s) to handle a specific protocol for the entire domain, and also to specify backup mail servers (with different priorities.) That way, if one server fails you can still reach the next server in line to deliver email to that domain. Neither can be done with plain A records, which map directly a full name with a host.

It can now be done with SRV records (dated 8 years ago, not 25) as Frank points out. Back then there weren't many other standard protocols massively available.

Answer 3

It seems like every other Internet protocol gets along just fine with DNS' A record.

Well, the SRV record type is available for those.

Probably if SMTP was being written today it would use that.

Answer 4

In addition to allowing the specification of backup exchangers, observe that not every domain has its own mail server, so it is necessary to be able to specify a mail server which exists on another domain as authorized to exchange mail so that administrative and system messages addressed to postmaster, root or any technical/administrative contacts listed in the DNS WHOIS records can be delivered, even if they do not exist on the current domain.

You just don't need that for ftp and http because those services do not initiate outbound connections like MX nor are they considered official points of contact.

Answer 5

Never neglect the "historical reasons" explanation. Back in the early 80's, SMTP was pretty much the only publically known protocol that had to be available to map for an entire site -- and the DNS lookup was done with the common HOSTS file on many systems.