Solved

Cant telnet to port 25 with dns name

Posted on 2008-09-29
24
302 Views
Last Modified: 2012-05-05
We have a company we own that we have a trust relationship with.  We are having trouble sending mail to them.  I can telnet to their mail server by IP just fine but not by name.  We get delays and then eventually the mail goes through.  I know this is a dns issue, but not sure where, theirs or ours?  Another dynamic which shouldnt matter is we have 2 way trust with them and right now one way is broke.  
0
Comment
Question by:AIT
  • 11
  • 6
  • 3
  • +2
24 Comments
 
LVL 12

Expert Comment

by:bhnmi
Comment Utility
If you can not resolve the name of their server, then you can not send mail. Having a trust should have no effect on mail transport.

Use this site to test the remote server, paste the results here. http://www.mxtoolbox.com/diagnostic.aspx

Also, make sure you can resolve that domain to a mx record.
0
 
LVL 31

Expert Comment

by:LeeDerbyshire
Comment Utility
The name is probably not resolving to the IP address that you think it should.  If you have a forward lookup zone in your internal DNS, then that is the place to check first.  If not, then you may either need to create one (depending upon your shared topology), or modify their public DNS.  I guess the first question, then, is do you see a forward lookup zone for their domain in your internal DNS?
0
 

Author Comment

by:AIT
Comment Utility
webserver-eb.ebtecnica.com.mx Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Mon, 29 Sep 2008 10:28:10 -0600 [141 ms]  
Connect Time: 0.531 seconds - Good
Transaction Time: 5.625 seconds - Warning
Relay Check: OK - This server is not an open relay.
Rev DNS Check: OK - 148.235.89.130 resolves to customer-148-235-89-130.uninet-ide.com.mx
GeoCode Info: Geocoding server is unavailable
Session Transcript: HELO please-read-policy.mxtoolbox.com
250 webserver-eb.ebtecnica.com.mx Hello [192.168.100.254] [94 ms]
MAIL FROM: <test@mxtoolbox.com>
250 2.1.0 test@mxtoolbox.com....Sender OK [78 ms]
RCPT TO: <test@mxtoolbox.com>
550 5.7.1 Unable to relay for test@mxtoolbox.com [4703 ms]
QUIT
221 2.0.0 webserver-eb.ebtecnica.com.mx Service closing transmission channel [78 ms]
 
It works fine from here, when I try to telnet from our Exchange server, I can by IP but now by name. What is strange is that eventually the mail will go out, but it takes 12, 13, 14 hours sometime
0
 
LVL 12

Expert Comment

by:bhnmi
Comment Utility
What are you dns forwarders set too? If you can not resolve this, but the rest of the world can, then you local DNS is not functioning correctly.
0
 
LVL 70

Expert Comment

by:Chris Dent
Comment Utility

> We have a company we own that we have a trust relationship with

Is their domain name the same as the mail domain you're trying to send to?

If you configured name resolution for the trust, can you still resolve MX records for the domain?

Chris
0
 

Author Comment

by:AIT
Comment Utility
Child domain has a forwarder set up to go to their domain. It also has a forwarder to our parent domain which has the exchange server. Mail should be going to the internet though to their public dns
0
 

Author Comment

by:AIT
Comment Utility
No, thier ad name is different.  Right now I am having an issue with the trust, I can validates one way but not the other.  
0
 
LVL 12

Expert Comment

by:bhnmi
Comment Utility
You should have your forwarder set to your locations ISP. The trust issues are probably dns related too. Do you have a zone at this location for the target domain?
0
 
LVL 70

Expert Comment

by:Chris Dent
Comment Utility

That didn't really answer either of my questions ;) Is the domain name the same?

Chris
0
 
LVL 70

Expert Comment

by:Chris Dent
Comment Utility

Okay, sorry, missed the update :)

The forwarders are constrained? That is, they're conditional and not "everything" type?

Chris
0
 

Author Comment

by:AIT
Comment Utility
There is a fowarder to our ISP in the parent domain.  No, we dont have a zone for this location
Chris
Their domain names are not the same.  
0
 

Author Comment

by:AIT
Comment Utility
The forwarders are setup to go the domain with a specific server IP, in this instance there are 2 IP's as they just changed servers not too long ago and broke the trust.  I still dont see how the trust or internal dns should effect this? This should all be internet mail. I am just not sure why I can telnet to their mail server using IP and not name?  I am thinking it is someones public dns.
0
Do email signature updates give you a headache?

Constantly trying to correctly format email signatures? Spending all of your time at every user’s desk to make updates? Want high-quality HTML signatures on all devices, including on mobiles and Macs? Then, let Exclaimer solve all your email signature problems today!

 

Author Comment

by:AIT
Comment Utility
Chris:
Not sure what you mean by constrained?  Sorry if I am not describing this well enough.
0
 
LVL 70

Expert Comment

by:Chris Dent
Comment Utility

> Not sure what you mean by constrained?  Sorry if I am not describing this well enough.

Sorry, I could have described that better.

When you created the forwarder, it was created as "somedomain.local" -> "some DNS servers"? Rather than "All other DNS domains"?

I assume so, it would be too easy for that to be the issue :)

> I still dont see how the trust or internal dns should effect this?

It shouldn't that was the only reason I asked the question above because if that were the case it would :)

So, public name resolution for it then.

Does your SMTP service use different DNS servers from the internal domain? I ask because they can be set as such in the properties for the SMTP service. That can lead to inexplicable behaviour because command lines tests won't reveal problems there.

If you forward to an ISPs server, take that out and retry name resolution. The two bits we need to work are:

nslookup -q=mx domain.com

Then resolution for each of the A records listed in the MX.

If we don't get anywhere there we can take a look at the name resolution path and chase down exactly where it's breaking up.

Chris
0
 
LVL 16

Accepted Solution

by:
robrandon earned 250 total points
Comment Utility
Perhaps the trust is being broken for the same underlying reason your name resolution is not working.

From your exchange server go to a command prompt and type:
NSLOOKUP
Then at the > prompt:
SET TYPE=MX
Then, the domain name.

Does it resolve?  If not, what computer was listed as the Default Server when you first issued the NSLOOKUP command.  That is the DNS server exchange is using to resolve the name.  Is that server setup correctly to resolve?
0
 
LVL 70

Assisted Solution

by:Chris Dent
Chris Dent earned 250 total points
Comment Utility

Incidentally, if the above fails to find an MX record the SMTP server will attempt to connect to whatever IP address resolves by looking up the domain name.

e.g. If this fails:

nslookup -q=mx domain.com

The mail server will use:

nslookup -q=a domain.com

And try to connect to that IP. A fall-back mechanism.

For us, if the lookup for the mx record fails, can you run:

nslookup
set debug
set type=mx
domain.com

And let me know the RCode returned in the final answer section?

Chris
0
 

Author Comment

by:AIT
Comment Utility
Chris:
Sorry, I could have described that better.

When you created the forwarder, it was created as "somedomain.local" -> "some DNS servers"? Rather than "All other DNS domains"?

Yes, directly to their domain with two server IP's listed
Does your SMTP service use different DNS servers from the internal domain? NO, I dont this anything is specified in there.
If you forward to an ISPs server, take that out and retry name resolution.  I tried this already, no luck.  I will work on the rest
0
 

Author Comment

by:AIT
Comment Utility
nslookup -q=mx domain.com
This times out
0
 

Author Comment

by:AIT
Comment Utility
nslookup -q=a domain.com
This times out also
0
 

Author Comment

by:AIT
Comment Utility
Brandon
From your exchange server go to a command prompt and type:
NSLOOKUP
Then at the > prompt:
SET TYPE=MX
Then, the domain name.

Does it resolve?  If not, what computer was listed as the Default Server when you first issued the NSLOOKUP command.  That is the DNS server exchange is using to resolve the name.  Is that server setup correctly to resolve?
No, it does not.  It uses the exchange server, which has dns forwarders to our ISP.  If I take them out, it still times out
0
 

Author Comment

by:AIT
Comment Utility
OK, well, I fixed it(to some degree) and feel like an idiot.  I cleared the DNS cache on the Exchange server and all the commands now work and the mail goes out.  
0
 
LVL 16

Expert Comment

by:robrandon
Comment Utility
Is your exchange server running DNS?  

If so, can we create a static MX record and zone for that particular domain, or is that something you want to avoid?


If you are running DNS on exchange, and you do want to create the static record, open the DNS MMC.  Create a zone for the particular domain in question, such as partnersdomainname.com.  Within that zone, create an MX record with the IP address of their mail server.

0
 
LVL 16

Expert Comment

by:robrandon
Comment Utility
You can disregard my last post - the one following where you fixed it by flushing the cache.  I didn't see your post as I was typing mine.
0
 
LVL 70

Expert Comment

by:Chris Dent
Comment Utility

> I cleared the DNS cache on the Exchange server and all the commands now work and
> the mail goes out.  

It might be necessary to do a few checks to make sure it doesn't re-occur.

Perhaps check you can talk to each of the name servers for the domain? From the DNS server you would do:

nslookup -q=ns domain.com

Then:

nslookup -q=mx domain.com ns1.domain.com

Where ns1.domain.com is one of the servers returned by the NS query. Repeat that for each name server.

Chris
0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

"Migrate" an SMTP relay receive connector to a new server using info from an old server.
Scam emails are a huge burden for many businesses. Spotting one is not always easy. Follow our tips to identify if an email you receive is a scam.
In this video we show how to create a User Mailbox in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Recipients >> Mailb…
In this video we show how to create a Contact in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Recipients >> Contact ta…

771 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

7 Experts available now in Live!

Get 1:1 Help Now