Can't connect to mail server - DNS Server settings?

Have you discussed your questions with your new ISP?
Perhaps they can shed light.
You might consider shutting down and restarting all network devices to clear any residual settings that might have been retained after your switcheroo.

So I have two questions:

Would that address have been generated automatically
while setting up the AirPort connection on the ibook?

Does the name McLeod USA mean anything to you? I'm
going to guess that the iBook was previously connected
to the Internet via cable modem provided by McLeod USA.
The DNS server would have just been left over.

Why would that supposedly optional DNS Server address
be required for me to connect to our new mail servers
(but not our old ISP mail servers)?

If you moved your domain it sometimes takes a while for
the changes to propogate. Or it could be that your ISP
has a static route - logical while marshall-arts was virtually
hosted within their domain. I don't know who
your ISP is, so I can't tell. But you can. Here's what you do:

At a terminal emulator:

dig @ns1.lunarpages.com mail.marshall-arts.net

You should get an answer 209.200.249.122

Next

dig @xxxx mail.marshall-arts.net

where xxxx is the DNS server of your ISP. If you get a different answer,
you know where the problem is. If you tell them, they will either fix it
or tell you to wait a bit.



Powerbook G4, iMac (Intel), and tons of hardware sitting in the closet Mac OS X (10.4.8)

Powerbook G4, iMac (Intel), and tons of hardware sitting in the closet Mac OS X (10.4.8)

Shawn,
that IP address is critical, since that IP is mail.marshall-arts.net
(your mail server)
Since it sounds like you're not able to resolve it properly, this is a major symptom of your problem.
(What IP address DID you get when you did the 'dig' command?)

It still points back to an Name resolution problem from within your network. As philsmith dotcom suggests, perhaps you can talk to your ISP and have them help you

A great tool on the web for all things DNS:
http://www.dnsstuff.com
snd for basic knowledge:
http://www.howstuffworks.com/dns.htm

Would a paid wi-fi service at a hotel or something
require one to enter an address into the DNS Servers
field?

No, it shouldn't.

We switched over the nameservers to Lunarpages nine
days ago, so I think it'd be propagated by now.

Yes, it should have.

I ran the terminal query as you described for
ns1.lunarpages.com mail.marshall-arts.net. It didn't
come up with the number you've given. What is the
significance of 209.200.249.122?

The last octet might have changed if your DHCP lease got
renewed.

Again, sorry for the ignorance. I'm pretty decent at
creating motion graphics and 3D animation, but this
networking stuff is kind of over my head.

Motion graphics and 3D animation are way cool. Networking
isn't much more conplicated. All data is encoded into
packets, and each packet has addressing information inside.
Each machine on the network has a unique hardware
address. In addition, there's an assignable ip address. It's
the job of all those routers and bridges and switches to
figure out the path from one machine to another, and forward
the packets.

We humans don't want to bother with those numbers, we
want to call the machines by name. So there has to be a
system to translate those names to numbers. It's not
resonable to expect every machine to remember every name/
address lookup, so the system is heirarchical. Basically, a
lookup request is sent to your name server. If it can't answer,
it forwards the request to a server who should know; if that
one doesn't, it sends it up the chain.,,and so on.

By forcing it to use the nameserver at mcleodusa.net, the
iBook came back with the desired response to your name
lookup. By using the default nameserver set by your ISP, you
come up with the wrong name response. The best guess is
that you are using the same name and that your old pop
machine was a virtual machine; an alias to on of the boxes
at your ISP. The DNS server at your ISP must have the wrong
address.

I was recommending that you query it directly and see what
response you got. If the answer was a mchine within the
ISP's domain, the answer is simple: request that they remove
the alias from their lookup table. That way the lookup moves
up the heirarchy and the answer will come from the machine
you want it to.

Qwest is a very large ISP. They have a lot of DNS servers.
That's why it's reasonable to expect it to take a few hours
for changes to propogate. 9 days is not. The concept is simple;
the practice isn't, due to the massive number of lookup
requests generated since the web came into existence.

What is the default DNS server configured in your basestation?


Powerbook G4, iMac (Intel), and tons of hardware sitting in the closet Mac OS X (10.4.8)

Congrats, you are rapidly becoming an expert! Neither dns
server actually answered - directly, anyway. The SERVER
response was just telling you who responded, not giving
you the ip address.

The telling part is in the authority section. Essentially,
lunarpages said that if it didn't directly have an address it
would go to a list of top-level-domain servers. But aracnet
listed ns and hostmaster as authorities, and that is where
your problem lies. I can't get to hostmaster.aracnet.com,
but I bet if I could, it would give me the wrong ip address.
Good detective work!

-Phil

Would you explain the relationship between the DNS
Server address that were provided by our ISP and
entered into our AirPort Extreme base station and
this mystery McLeod DNS Server address I have to have
entered in the computers that are dynamically
configured (DHCP), getting their IP addresses from
the AirPort Extreme base station?

Hi Shawn,

Did you know DNS stands for Deceptively Nasty Sadism? 🙂
In theory, it's a very simple system. In practice, it becomes
very complicated. Generally, you actually get back multiple
answers to your request. It's the first answer that's used.

The heart of the system is a bit of code called a resolver.
The resolver first looks the host file on its machine to find
a name/address pair. Say you're looking for foo.fum.org.
If the hosts file has an entry

foo.fum.org 123.45.67.89

the resolver can just return 123.45.67.89. Without an entry,
it goes to its resolv.conf file to find the address of a
nameserver. So if there's a line in the resolv.conf file

nameserver 9.8.76.54

it makes a request to the resolver on that machine. A
similar process occurs on that machine, and so forth. This
sounds good in theory, but eventually the heirarchy ends
at a root server, and there would be a huge bottleneck there
if not for some of the practices we use today. Hey, it's a kludgy
system, but before DNS we used to have to uucp a file from
our service provider with all the names of all the machines we
could look up.

Because it is possible that the nameserver could be unreachable,
you are allowed to enter multiple nameservers. For example,
the resolv.conf file could have:

nameserver 192.168.0.1
nameserver 9.8.76.54

Anyway, the answer to your question is that the resolver on
your machine will check the hosts file, and when it doesn't
find the host, it will look up the resolv.conf file and query the
first nameserver. If that times out, it will query the next and
so forth.

One or more of those nameserver lines will have been added
by DHCP, and some or none will have been added locally. On
a Mac, I don't think you're supposed to modify the file directly,
but if you look at the file /etc/resolv.conf you can see the
order in which the resolver will make DNS requests.

This answer was so long I forgot the question!

When looking for our marshall-arts.net mail server,
does it go to our first DNS Server address in the
AirPort and then, not finding it, go to our second
DNS Server address in the AirPort, and then still not
finding it, go to the mystery McLeod DNS Server
address I have entered in the TCP/IP settings of the
various computers?

Oh, I answered that one, anyway! One of the nameservers
on your local machines should be the Airport.

I'm also trying to understand the info the dig
queries are returning. When I dig our mail at
ns1.lunarpages.com I get that list of servers in the
Authority section and their addresses in the
additional section, but it doesn't actually return an
answer with our mail address (209.200.249.122).
Shouldn't the Lunarpages name servers know the
address of our mail, or am I not understanding the
relationship?

I'm sorry, we didn't ask it. I ddn't know you'd look into this
so deeply. To get the address we need to add IN-ADDR to
to end of the dig command. This stuff gets exponentially
more complex the deeper we go. I just wanted to show you
the different paths that are taken.

However, when I dig our mail at .lunarservers.com
it correctly returns our marshall-arts.net mail
address (209.200.249.122) in the Answer Section.

Oh. It was there in the cache.

I'm not understanding why our problem lies with
Aracnet listing ns.aracnet.com and
hostmaster.aracnet.com in its Authority section. Is
it not looking at other name servers for the address
and just giving up?

No, I think they had the wrong answer. Sorry about the confusion,
I realize I should have had you see the address - I thought it was
irrelevant, but you're a deeper thinker.

An authority is a server which will take responsiblity for providing
an answer. lunarpages returned the 13 root servers. This is a
whole 'nother story for another day. When your request is sent
to a root server for your zone - .net - it then determines the
authority for the domain - marshall-arts - and requests it to
find the machine - mail - and so forth from right to left in the
address.

What it looked like to me was that the authority was "hijacked"
by your ISP. Actually, it's a normally desired to keep traffic away
from the root servers. The best thing to do overall is to add a
line to your /etc/hosts file. Of course, you have to edit it if the
address ever changes. That way your resolver never goes to the
net. Faster, too.

Sorry for the rambling. I'm getting to be an old-timer and
sometimes I get carried away tellin' people how things used
to be.

-Phil

Powerbook G4, iMac (Intel), and tons of hardware sitting in the closet Mac OS X (10.4.8)