Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Odd DNS issue 1

Status
Not open for further replies.

offred

MIS
Nov 7, 2006
6
US
I am trying to email a domain in Korea. The domain I query has 3 NS records, ns6.domain.com, ns7.domain.com, and ns8.domain.com. There appears to be a problem with ns6.domain.com

Depending on which looking glass I use, the IP of ns6.domain.com resolves to either "ns6.domain.com" or "mail5.domain.com"

Querying ns6.domain.com by its IP times out, so it must indeed be a email server though I have not tried a port 25 telnet to it.

My question is, even though I'm querying what is probably an email server, shouldn't my query just skip to the next NS after the timeout?

The next two NS records resolve OK, but why doesn't the query go to the next NS?

Email to this domain just gets returned NDR as Unable to Connect to Destination Server.

 
What's the MX record for the domain? Does it have a backup MX?

nslookup
set type=MX
domain.com

Your query for MX (by your SMTP host) is probably being resolved, but if the mailserver isn't responding, you'll get the error you're getting.

The error you are getting is not a DNS related error, it's an availability error.

ShackDaddy
 
I'm still having some understanding issues about resolution.

I know the DNS I am trying to get an MX from has two machines with the same IP address, one is a mail server and the other is a name server.

This is obviously a config problem, they were informed.

Our SMTP tries what it thinks is a NS, but it really is a mailserver. Since the misconfigured email/NS name starts with a "M" and the next NS on the list starts with an "N", I guess if they both have the same IP, the resolver will try the "M" first as alphabetical. I guess.

What I truly don't get is exactly how a resolver "jumps" to the next NS record, if there is no reply from the first NS, or if this is really done at all.

The resolver is in the host here, in my case, the SMTP engine. In the case of a browser, it would seem to be the "DNS Search Order". I am guessing the SMTP engine uses the TCIP stack's "DNS Search Order" as well, or am I missing some magical mechanism here?

My DNS Search Order is NOT configured to use this particular (misconfigured) authoratative DNS nameserver's next NS.

So....

How exactly is the SMTP supposed to "know" how to jump to the next NS? By IP? By name? I can't find any RFC that is clear on this. Some posts say it is done, but not how. It is suggested by these posters that if the first NS does not respond, the next one is tried and so forth.

It obviously does NOT jump to the next NS in my case, otherwise resolution would occur since the next NS is in fact configured properly, so the MX record should be retrieved from the next NS and the email delivered.

Instead, an "Unable to Connect to Destination Server.." NDR is generated.

This would suggest there really is NO mechanism for the resolver to "jump" to another NS if the first fails or does not respond.

Can anyone clear this up?
 
You have some errors in your thinking about this. Here are some corrections.

1. A single server with a single IP can have two (or a hundred) names and host a potentially vast number of different services. Thus NS6 can be both a DNS and a mail server. There are not two machines with the same IP address, and there is no misconfiguration evident.

I think NS6 is offline and is not responding to either DNS or SMTP connections.

2. When you use NSLOOKUP and point it directly at a name server, it's not going to query any other name server if the name server you are pointed at does not respond. But a normal resolver like a web browser would use will query name servers until it gets a response from one. Once it gets a response, ANY response, it won't ask another.

But you aren't being clear about the tools you are using. Unless you define what a "looking glass" is and what having different looking glasses means, it's not going to be easy for anyone to explain exactly what you are seeing.

If you open NSLOOKUP at type the following:
server ns8.domain.com
set type=MX
domain.com

What is returned as the MX record, and are there more than one MX record?

3. Your local system's search order has absolutely nothing to do with the remote domain's name servers. Your local search order has to do with which local DNS servers you will use to make recursive queries for you. If the first one you try to contact isn't reachable, the next one will be used, and your resolver will continue to use that one until that one is unavailable or your system reboots.

When your SMTP resolver attempts to reach a remote mail host, it doesn't ask the remote name servers for the MX record itself. It asks the DNS server that's currently resolving queries for it (one of the ones in the local DNS settings) to find the IP for the remote mail host. Then your local DNS server queries the remote name servers, probably starting with NS6 and moving on to NS7 if NS6 doesn't respond. Then NS7 tells it which host is handling mail for the domain, and that information is passed back to your system, which then asks its local DNS to resolve the mail host's name to its IP address. Once that is done, your SMTP client makes its first REAL direct connection to the remote domain's systems and tries to open up an SMTP connection.

What NSLOOKUP does is let you bypass your local DNS servers if you use the SERVER command.

The answer to your connectivity issue isn't with the remote nameservers. It's with the remote mail host. If the mail server running on NS6 is offline, then there may be a second backup mailserver, which an MX query with NSLOOKUP will show you. The only problem that may exist as far as DNS is that the remote DNS servers don't have the proper MX records and corresponding A records configured.

If I were you, and you still want to pursue this here, I'd actually tell us what the target mail domain is so that anyone wanting to pitch in and help you can do their own NSLOOKUP queries, post the results, and explain them to you.

ShackDaddy
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top