email and DNS

Recently, an organization that I was associated with changed their email server. Lets say that the organizations email addresses were all user@someorg.com. At one point, someorg.com had their internet and email provided by an external ISP, lets say supplier.com. Now they have the same services by a new ISP, lets say newsupplier.com.

When I wanted to check my email at my old account from outside the organization, I used to simply put the DNS name of the mail server in the POP3 and SMTP boxes of my email program. The mail server was mail.supplier.com. But when they switched to newsupplier, the mail server became mail.someorg.com. When I entered that name into the POP3 and SMTP boxes, I could not download my mail. Only when I found out the IP address of mail.someorg.com, could I download my mail.

I thought this was very strange, and tried to access someorg.com by other means – ping, tracert, etc, and everytime nothing turned up.

Here’s my question:

If someorg.com didn’t appear (apparently) in the DNS lists by anyone, how in the world did email that people sent me to curwin@someorg.com continue to arrive? Is there an entirely different system than DNS for email? If so, is there anyway to check it, to see if a mail server exists?

I thought that the DNS was just the server that you used to look up other servers i.e. mail servers, etc.?

Also, from your post, it sounds like you were putting the same thing in both SMTP and POP boxes. They should have different names, like smtp.newhost.com and pop.newhost.com.

Eh, then again, maybe I shouldn’t be here. Someone who knows what they’re talking about will answer your question, I’m sure. :wink:

Mail server names go through DNS just like web site addresses.

It’s possible that the DNS servers were not updated when the switch was made, but then mail to user@someorg.com shouldn’t work. It seems more likely that you have the name of the mail server wrong; have you tried just someorg.com? Or pop3.someorg.com?

It’s faintly possible that something is screwed up in your system’s DNS settings.

From your own post it is obvious that email does not work through DNS the exact same way that web addresses do: otherwise all mail would have to be sent to user@mail.someorg.com.

Anyway, now I see that I can tracert mail.someorg.com, and don’t need to use only the IP address. Apparently the DNS change has been fully published. My settings weren’t wrong before though. In the week or so that it took for the DNS registration to go through, email did not stop arriving at the server at all, and even when I sent mail from other sources, it didn’t bounce back.

The short answer is that DNS updates do take a while to propagate throughout the DNS system. The DNS also uses different records for mail servers than for other random machines. If, for example, you want to go to the web page at http://www.example.com, your browser looks up the “A” record (for Address), and the DNS returns that machine’s IP address. If you want to send email to someone@example.com, this isn’t quite what you need, though. The mail server might be called foobar.example.com or something, and since it would be a pain in the ass for the rest of the world to have to remember that, DNS provides the MX record (for Mail eXchange). So your email program just looks up the MX record for example.com, and the IP address of foobar.example.com is returned.

If you want to know why DNS records take a while to be propagated throughout the net, it’s because DNS is a distributed system. If you want to look up foobar.example.com, your computer starts by asking the local DNS server (you probably entered the IP address(es) for this server when you set up your computer’s networking). More than likely, the local DNS server doesn’t know anything about foobar.example.com, so it goes and asks one of the root DNS servers about it. The root DNS servers don’t really know anybody’s IP address, but they can always tell you who does. So the root server says something like “ns1.example.com is the DNS server for example.com, and here’s its IP address.” The local DNS server then goes and asks ns1.example.com and finally gets an answer, and then passes it on to you.

As you can see, this whole process might (and often does) take a while. In order to speed it up, the DNS system does caching. So when the local DNS server finally gets foobar.example.com’s IP address, it remembers it so that the next time someone asks for it, it can avoid going through the whole searching process again. Each DNS record has a “TTL” (Time To Live) that says how long other DNS servers are allowed to remember it. When the TTL expires, your local DNS server has to “forget” what foobar.example.com’s IP address is.

So that’s why DNS updates don’t take effect immediately. The DNS record might be cached in thousands of DNS servers around the world, and the update won’t be seen by those people until the TTL expires and their name servers are forced to go look up the record from the authoritative source.

It’s common practice to set TTLs to be pretty long (a couple days, say) most of the time to reduce DNS traffic, but to shorten the TTL (to a couple hours, say) before making a DNS change so that the change propagates quickly.

That helps explain it a bit, although what I have to understand from that is that in my case the MX record got updated before the general DNS record. Is there anyway to check an MX record, similar to tracert? I know I can look at the header of a message to see where it came from, but what if I’m on the other side?

On a Unix system, you can do
nslookup -type=MX example.com

I don’t know if Windows has nslookup (or an equivalent), though.

Bobort did a fine job addressing the OP, so I won’t comment on that, but I thought I’d nitpick on the following…

Not necessarily. The SMTP and POP server you point your mail program to should be, of course, the box that handles each for that domain. For large ISPs or other large organizations these typically will be two seperate machines (to split up the amount of work each machine has to do, and so that if something happens to one it won’t effect the other), and so you’ll input a different address for each of those two settings. However, there is certainly no requirement that it be handled on seperate machines, and for smaller organizations the workload associated with each of those tasks is probably not enough to justify spliting it up between two machines. In that case you’d enter the same address for each setting in your mail program. (Well, if you really want to get into it, they could define a different address for each, perhaps in anticipation of being large enough to split up the two, so you might have smtp.newhost.com and pop3.newhost.com where both are just aliases for a single machine mail.newhost.com, but that certainly isn’t a requirement either.)

Oh, and as far as I know, Windows does not come with any sort of nslookup type program. There are programs you can get to do that sort of thing though. Genius 3.0 is a commerical shareware product that will do ns lookups (among other things); there may be entirely free programs that will do the same thing.

Curwin, just because the change for the MX record propagated to you before the hostname record doesn’t mean that change actually was submitted first. The TTL that the intermediate DNS servers use is based on the last time they got the information, not the last time it was changed. Imagine this timeline:

T1: DNS records for hostname and MX are set to initial values.
T2: Someone requests the MX record from your DNS server. The server hangs onto it for the length specified by TTL.
T3: Someone requests the hostname from your DNS server. The server hangs onto this for the length specified by TTL.
T4: hostname record and MX record are updated due to change.
T2+TTL: MX record change can be seen by you
T3+TTL: hostname change can be seen by you

Note that, for people using your DNS server, the MX record change will be seen first, even though the changes were made at the same time. Other people’s experiences may be different, depending on usage patterns on their DNS servers.