You should never point your MX
to a IP address to be RFC compliant. Make an A
record for the IP address instead and point the MX
record to it.
Then the zone should look like this,
@ IN MX 1 ASPMX.L.GOOGLE.COM.
@ IN MX 5 ALT1.ASPMX.L.GOOGLE.COM.
@ IN MX 5 ALT2.ASPMX.L.GOOGLE.COM.
@ IN MX 10 ASPMX2.GOOGLEMAIL.COM.
@ IN MX 10 ASPMX3.GOOGLEMAIL.COM.
@ IN MX 10 ASPMX4.GOOGLEMAIL.COM.
@ IN MX 10 ASPMX5.GOOGLEMAIL.COM.
@ IN A 10.24.233.214
mailer IN A 10.24.233.214
mailer IN MX 10 mailer.cranketywidgets.com.
Contrary to what Wooble says, the wording is quite sensible. The case that it addresses, of course, is fairly obvious with a little thought: Someone adjusts the name server records to switch from another company's content DNS hosting service to Network Solutions' content DNS hosting service without copying any of the existing other records across, and all of a sudden HTTP and SMTP go awry, as the world at large is no longer told the right places to contact for these services.
Yes, people sometimes do not know that it's necessary to transfer the database across from one publisher to another when one switches publishers.
And contrary to what spacehunt says, things will not soft fail if you switch the servers before copying the database. In the absence of MX
resource records, SMTP Relay clients will fall back to A
and AAAA
resource records, per RFC 2821 § 5. They won't be there, of course, since you haven't copied them over either. The SMTP Relay clients will bounce all queued mail as undeliverable. Soft failures occur in the event that DNS query resolution fails to get an answer at all, not in the event that query resolution succeeds and gives a zero records answer.
In a similar vein, do you know that it isn't necessary to switch DNS hosting companies if all that you want to do (This is what you've told us.) is point HTTP service somewhere else? As you've explained it, what you're doing seems entirely unnecessary. You have company A providing SMTP mail service and content DNS service for the client, and company B providing content HTTP service. To make company B's services known to the world, it's not necessary at all to replace company A with a company C — Network Solutions. Just go to the current content DNS service provider and enter the necessary A
and AAAA
resource records into the database.
Best Answer
An
MX
always points (RFC 1035, 3.3.9) to a hostname rather than an IP address. Then, according to RFC 2181, 10.3, that hostname should have anA
record instead ofCNAME
. SoMX
points to self, which is also the fallback if there is noMX
defined, changingA
affects.MX
points to anywhere else, which is the whole point whyMX
records were invented in the first place, then changing theA
record doesn't affect.Also,
TXT
and other additionalRR
s aren´t affected by changingA
. But if you'd also like to addCNAME
to the domain root, then everything gets ruined (RFC 1034, 3.6.2). Forget I even mentioned it.