• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 328
  • Last Modified:

Cant telnet to port 25 with dns name

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
AIT
Asked:
AIT
  • 11
  • 6
  • 3
  • +2
2 Solutions
 
bhnmiCommented:
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
 
LeeDerbyshireCommented:
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
 
AITAuthor Commented:
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
Veeam and MySQL: How to Perform Backup & Recovery

MySQL and the MariaDB variant are among the most used databases in Linux environments, and many critical applications support their data on them. Watch this recorded webinar to find out how Veeam Backup & Replication allows you to get consistent backups of MySQL databases.

 
bhnmiCommented:
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
 
Chris DentPowerShell DeveloperCommented:

> 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
 
AITAuthor Commented:
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
 
AITAuthor Commented:
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
 
bhnmiCommented:
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
 
Chris DentPowerShell DeveloperCommented:

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

Chris
0
 
Chris DentPowerShell DeveloperCommented:

Okay, sorry, missed the update :)

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

Chris
0
 
AITAuthor Commented:
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
 
AITAuthor Commented:
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
 
AITAuthor Commented:
Chris:
Not sure what you mean by constrained?  Sorry if I am not describing this well enough.
0
 
Chris DentPowerShell DeveloperCommented:

> 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
 
robrandonCommented:
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
 
Chris DentPowerShell DeveloperCommented:

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
 
AITAuthor Commented:
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
 
AITAuthor Commented:
nslookup -q=mx domain.com
This times out
0
 
AITAuthor Commented:
nslookup -q=a domain.com
This times out also
0
 
AITAuthor Commented:
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
 
AITAuthor Commented:
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
 
robrandonCommented:
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
 
robrandonCommented:
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
 
Chris DentPowerShell DeveloperCommented:

> 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 Use the Help Bell

Need to boost the visibility of your question for solutions? Use the Experts Exchange Help Bell to confirm priority levels and contact subject-matter experts for question attention.  Check out this how-to article for more information.

  • 11
  • 6
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now