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.