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?

Jackstraws

If it says so, the Wikipedia article is partly wrong: when there is no MX, the fallback is to an address record (AAAA and A), not just to A records. RFC 5321, section 5.1 – Rory

The quote from the article is: "if no MX record for domain is present, look up for an A RR record, and if such record is present, treat it as an MX record". I'm not guru enough to set the record straight, if required. – Jackstraws

@Rory I've updated the Wikipedia article to correct this. – Gayomart

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.

Gayomart

Interesting side-effect of SRV records for http -- there's a natural failover to an error page (or stale static server) when your primary web server is completely unavailable. We need more of this. – Dresser

true, although in that case you'd want the 'www' entry to fail-over correctly too, which in this example (with an explicit A record) it can't. – Gayomart

@Dresser why there should be any kind of fallback implemented on DNS level? I think DNS software should simply translate names into ip addresses and all that stuff with MX records and SRV is a bloat. This should be realized with other piece of software, like NAT router, which deal with ports and redirections by design. – Tremor

@doc the fallback is not implemented in the DNS, it is recorded in the DNS and is implemented in the higher layers of the stack. – Gayomart

@Gayomart I don't wanna play semantic game here - recorded, implemented, whatever... it's realized with a use of DNS software and that counts. – Tremor

@doc It's not semantics, it's what those of us in protocol design call "layering" (and a "layer violation" when it's done wrong). If the records returned were automatically adjusted based on loading / failure / etc then that would be "implemented on the DNS level" and would be considered a layer violation. Merely publishing a list and letting higher layers do their thing based on that list is absolutely fine. And don't even get me started on having NAT routers do this for you! – Gayomart

@Gayomart what higher layers are you talking about? Isn't it DNS client who reads the list? – Tremor

@doc I'm talking about things like a SIP client (or other protocols that make use of SRV). Think of the "DNS client" as a separate module - it just returns the list of answers to the "real" application. It's then that application's job to decide which hosts to connect to based on the stated priority and then fallback if the first one fails. – Gayomart

@doc on the contrary, IMHO the DNS system as a whole is the most resilient high performance distributed database on the planet. Your argument that DNS should only expose what matters is ludicrous and is contrary to your previous comments - the DNS can't know what matters to the client, so in the case of SRV and NAPTR it takes the sensible approach of presenting a list and allowing the client to chose. Punycode is an unfortunate evil because labels were only defined using US-ASCII and are case insensitive. – Gayomart

@Gayomart DNS can't know and that's why dealing with services should be out of DNS scope. Getting whole list is just as confusing for the client. It is bug prone too and takes from security by exposing unnecessary details. – Tremor

@doc but it doesn't "deal with services". It just lists them. You're way over-complicating this. Now please go read my profile. – Gayomart

@Gayomart then why it lists services in the first place? If it doesn't deal with services then there's no reason to list them. If DNS does not know what to do with it, then leaving this problem for the end application does not help. Application becomes unnecesary complex just to parse and interpret DNS responses. If it's O.K. then DNS could publish as well telephone numbers, prices at McDonalds and random quotes. – Tremor

Actaually, there is such SRV record as stated in RFC-6186 called "Email Submission" and it is used like this _submission._tcp both for non-TLS and for TLS. – Jingo

@SlavikMe that didn't exist when I wrote this answer ;-) – Gayomart

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.

Grassi

Not at all: the main purpose behind the MX records is, as explained by Alnitak, the ability to separate the domain from the host. Backup mail servers are, in the vast majority of cases, useless. – Rory

That I got the main purpose wrong I can accept, but backups are not at all useless. – Grassi

In the majority of cases, yes, they are useless. If you think they are useful, explain why. They complicate the setup (specially the anti-spam setup, most MX secondaries are less protected) and bring no value since the email sender will queue and retry, anyway. – Rory

They increase throughput (if with the same priority) and speed up delivery. – Grassi

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.

Bodywork

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.

Criseyde

Dont you think this issue could have been solved if instead of using MX record, you just created a subdomain to point to another mail server (hence email accounts would be like [email protected] instead of [email protected])? – Cockswain

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.

Guernsey

The hosts file is explicitly not DNS! – Gayomart

It must be nice to be so young. It'd be nicer yet to be young and smart, though. Now, be a good boy and go look up the resolver and how it worked with /etc/HOSTS. – Guernsey

Look me up and stop being so damned patronizing. The system resolver, typically exposed via gethostbyname() would use /etc/hosts and then DNS, and then NIS/YP and other name resolution systems came along and the search order became configurable. However those other systems are not DNS. That term refers specifically to the resolution system that uses UDP and TCP port 53 as documented in STD 13 (RFCs 1034 and 1035 and subsequent updates) and not to the system resolver as a whole. – Gayomart