MX Records confusion - possible noobishness
I'm using Google Apps, but also have postfix, so my phpbb forums can still send notification emails & a couple of webforms can still send email to my site staffers. It's mostly working beautifully - emails to external addresses are going out from phpbb just fine.
I used dig mx to check what was going on, and despite the MX records being updated in the Linode DNS manager 3 days ago, it returned the records for the old server. I am perplexed - I would have thought that linode's own records would be updated by now? Checking the MX records on IPTools.com produces the new ones.
So, I'm really out of my depth at this point. How do I get those MX records up to date? Any help gratefully received! I feel like I may have overlooked something terribly obvious…
edit: Just in case it's relevant, I'm using Ubuntu 10.04.
5 Replies
If the old DNS manager doesn't have anything else left of your domain, you can always try verifying that everything's correct in Google Apps. Since I don't use Google Apps, I don't know if you would have to change anything, though you would need to make sure that you inserted the MX records they provide into your Linode's DNS manager (and make sure that you remove them from your old DNS manager).
EDIT: Make sure that you set the correct priorities for all of your MX records. You should make sure that the priorities in Linode's DNS manager match up to the priorities you used in the old DNS manager.
If the likely issue is the continued existence of the old DNS manager, though, it suggests that it'll resolve itself on October 1st when the account disappears completely. Which is, at least, only a few more days of this craziness!
Thanks for the suggestions, I appreciate it.
cached
You can check the TTL of the record from your home machine.
$ dig dotat.at mx
; <<>> DiG 9.3.2 <<>> dotat.at mx
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11934
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 4
;; QUESTION SECTION:
;dotat.at. IN MX
;; ANSWER SECTION:
dotat.at. 3600 IN MX 1 mx.cam.ac.uk.
;; ADDITIONAL SECTION:
mx.cam.ac.uk. 86400 IN A 131.111.8.148
mx.cam.ac.uk. 86400 IN A 131.111.8.149
mx.cam.ac.uk. 86400 IN A 131.111.8.146
mx.cam.ac.uk. 86400 IN A 131.111.8.147
;; Query time: 494 msec
;; SERVER: 205.133.7.2#53(205.133.7.2)
;; WHEN: Wed Sep 28 01:12:14 2011
;; MSG SIZE rcvd: 118
In this example, the TTL for the dotat.at MX record is 3600 seconds. This means that if the record changed, it would take an hour before the old record expired and I saw the new address.
There's not much you can do to retroactively reduce the TTL of an existing record. You could switch to a different nameserver on your home machine (this is defined in /etc/resolv.conf), but this would only solve the problem for you, not anyone else out there who may have cached the old record.
The moral is: when you are going to change DNS entries, plan ahead and reduce the TTL of the corresponding records a few days (or weeks) before, so that any cached entries will have time to expire.
Oh, you may also want to check your /etc/hosts file to make sure you haven't hard-coded the old address in there.