6

I'm a bit confused about what has happened with one of my client's email accounts.

My client registered a domain at dotster.com. She wanted to start using email for that domain before we had her website up, so I set her up through Google Apps mail, and added the appropriate MX records to her dotster account.

When her website was ready, I hosted it on dreamhost and pointed to Dreamhost's nameservers for the domain in the dotster account. (e.g. Domain hosted at dotster pointed to Dreamhost nameservers for web hosting). MX records stayed the same as before, and everything worked fine for a while.

Today, she told me her email started bouncing. " error that the other server returned was: 554 554 5.7.1 : Recipient address rejected: Access denied (state 14)". When I did a traceroute, the MX records didn't show, but the text record did (also set at dotster).

So I went over to Dreamhost and added the MX records there. Now her email is working again.

My Questions:

1) Do the MX records have to be set at the place where the nameservers are pointed to? I thought they were independent.

2) I'm also pretty sure her email was working for a good amount of time after I pointed the nameservers to dreamhost. So why would it just suddenly stop working?

I am a front-end web designer/developer, so keep that in mind in terms of how much you assume I already know. :) (Server-related stuff generally stumps me more than anything else).

Kerri
  • 183
  • 1
  • 2
  • 7

2 Answers2

7
  1. Yes
  2. DNS caching. Once the timeout has expired things started going to hell.

Each domain has what is called an SOA record. It defines, among other things, how long other servers should cache information about where to request records for said domain.

As an example:

@   IN  SOA     nameserver.place.dom.  postmaster.place.dom. (
                       1            ; serial number
                       3600         ; refresh   [1h]
                       600          ; retry     [10m]
                       86400        ; expire    [1d]
                       3600 )       ; min TTL   [1h]

Once a query is made for something at place.dom (MX, TXT, etc), the location of where to make all future requests is cached for a maximum of 1 day. In your case it was much longer so you didn't notice because the SOA was cached.

To get more information about the SOA record for a domain try this from the command line:

~$ nslookup
> set type=soa
> set debug
> zaplabs.com
Server:     192.168.1.1
Address:    192.168.1.1#53

------------
    QUESTIONS:
    zaplabs.com, type = SOA, class = IN
    ANSWERS:
    ->  zaplabs.com
    origin = dns1.name-services.com
    mail addr = info.name-services.com
    serial = 2002050701
    refresh = 10001
    retry = 1801
    expire = 604801
    minimum = 181
    AUTHORITY RECORDS:
    ADDITIONAL RECORDS:
------------
Non-authoritative answer:
zaplabs.com
        origin = dns1.name-services.com
        mail addr = info.name-services.com
    serial = 2002050701
    refresh = 10001
    retry = 1801
    expire = 604801
    minimum = 181

Authoritative answers can be found from:
>
h0tw1r3
  • 2,746
  • 18
  • 17
  • Well, I guess that about sums it up. How long can DNS caching a separate thing from the length of time it takes to propagate changes across the internet? Because I'm pretty sure it was a good couple of weeks before her email stopped working (though she hardly uses it, so she could have just noticed a long time after it started happening…) – Kerri Jun 16 '11 at 23:18
  • Also: Is there harm in the MX records still residing with the registrar? Should I delete those, or does it matter? Thanks. – Kerri Jun 16 '11 at 23:19
  • 1
    There might be harm in that... anyone who uses those DNS servers as their primary (which may be nobody) would always get your old records. It's always best to completely remove your old DNS records when changing DNS providers. – Flimzy Jun 16 '11 at 23:25
  • 1
    When switching nameservers, I always maintain both the old and new with identical records for a minimum of 48 hours. After you're confident that caching won't be an issue, always remove your domains from the old nameserver. – h0tw1r3 Jun 16 '11 at 23:37
  • What h0t1r3 says [is an important step that must not be omitted](http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-switching-content-servers.html#ChangingOld). You've experienced why, and how long _indefinitely_ can turn out to be. – JdeBP Jun 17 '11 at 15:02
6

1) Absolutely. When a DNS lookup is done (in this case, to see where to send mail), that lookup is done from the nameservers. So if your nameservers don't have the MX record listed, the lookup will result in nothing.

It's the same as a phone book--except imagine that you can only list your phone number in one phone book at a time. So you tell your friends "Look me up in the Acme phone book." So when they want to contact you, they look your phone number up in the Acme phone book, find your listing, and call you. But then if you move your listing to the "OtherGuys Phone Book", but don't tell OtherGuys what your phone number is, when your friends look you up in OtherGuys, they won't see your phone number--because it's listed in the Acme book instead.

2) This is because the nameserver records for your client domains were cached for a while (typically for several hours, possibly up to several days--the timeout is configurable). This means (roughly) that anyone who did an MX lookup prior to you switching nameservers, kept the old information in memory for a while, so they wouldn't have to look it up again. But eventually, that information expired, so when they tried to look the information up again--this time from the new server--they got "nothing", so the mail started bouncing.

Flimzy
  • 2,375
  • 17
  • 26