[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 546
  • Last Modified:

Unable to bind in dns (Exchange 2003)

Hello, i have 2 DNS server's on my network. An internal and and external. The zones of those two are identical except the ip addresses of the records in the zones (eg: In the zone hellenic-net.gr the Internal server has a www record points to 192.168.0.X but int the external server it points to 80.76.47.X ip address). I dont use secondary zones or stub zones because i want to have them complitely independant.

Now, to the problem. I also have 2 exchange 2003 Server's which host about 5 domains each. The thing is that when a e-mail user of the first exchange tries to send e-mail to a user which has e-mail on the second exchange, the e-mail never arrives. I checked the queues and it report something about "unable to bind in DNS". I checked for the problem in MS and they say (if i understood it correctly :-) )that when an exchange tries to resolve a domain name it expect's an answer from the AUTHORITATIVE DNS Server for the Zone.

Any ideas ?? Sorry but i only have 250 points left :-(
0
alexch_x
Asked:
alexch_x
1 Solution
 
Chris DentPowerShell DeveloperCommented:

Do you have an MX Record for the second mail server in DNS?

To send to that server the DNS your First Exchange uses must be able to find out where the server is from the DNS Entries. Normally this is done through MX, so you'd have something like:

For reference:

Second E-mail Domain: mydomain2.com
Second E-mail Server: mail2.mydomain.com

The Records:

mydomain2.com IN MX 10 mail2.mydomain.com

The format for that is: <Destination Domain> IN MX (Mail Exchanger) <Preference - doesn't matter too much if there's only one> <Responsible Server>

Then you need to tell it the IP Address for the server used in the MX:

mail2.mydomain.com IN A <IP Address>

Does that make sense?
0
 
SembeeCommented:
This seems to be a simple case of the two Exchange servers not being able to communicate. Exchange doesn't need MX records to communicate with another Exchange server unless they are in seperate domains and organisations.

Can the two servers ping each other? By name, IP address, FQDN?

Are the Exchange servers pointing at the internal or the external facing DNS service? Have you configured Exchange to use the External DNS servers instead of the internal ones?

Simon.
0
 
alexch_xAuthor Commented:
Thanks for the response !!

Hi Chris-Dent. Ofcourse there are MX records for these two domains. The servers are in different domains but internally they can ping themselvers, resolve each other normally. to make it more clear ....

(A) Exchange Server named perseas with internal IP 192.168.0.210 in domain example1.com
(B) Exchange Server named axilleas with internal IP 192.168.100.1 in domain office1.com
(C) DNS Server named zeus with internal IP 192.168.0.1 which has the above primary zones (example1, office1) with MX records perseas.example1.com (192.168.0.210) and axilleas.office1.com (192.168.100.1)

The problem maybe is that There is a (D) DNS Server named Pluton which is the main EXTERNAL dns and has the above zones with the canonical IP Addresses and he is the authorative server to answer.

I have setup in (C) the (D) as a forwarded.....

heeellllllpppppp   :-)
0
Restore individual SQL databases with ease

Veeam Explorer for Microsoft SQL Server delivers an easy-to-use, wizard-driven interface for restoring your databases from a backup. No expert SQL background required. Web interface provides a complete view of all available SQL databases to simplify the recovery of lost database

 
Chris DentPowerShell DeveloperCommented:

Do any of your Exchange servers use Pluton directly? I assume you use either Forwarders or Root Hints for handling unresolved requests?

Ideally your Internal servers should be (and I think already are) Start of Authority for the domains you're sending to (since the internal record differs from the external).

It might be worth checking that the mail servers can send and recieve e-mail on those domains by adding a Hosts entry on each Exchange.

The hosts entries would have to be in the form:

192.168.0.210    example1.com

A really nasty work around and hardly a solution in itself.
0
 
Chris DentPowerShell DeveloperCommented:

Oh one more place to check for DNS...

In System Manager open:

Administrative Groups
Servers
<Your Server>
Protocols
SMTP

And under the properties for the Virtual SMTP Server select the Delivery Tab, and Configure External DNS Servers. Just to ensure it's using your Internal ones (nothing there means it uses the ones you've got set on your NIC).
0
 
alexch_xAuthor Commented:
No, they (exchange servers) doesn't use the Pluton directly.

But when i tried that (set exchange server's to use the external DNS for resolving names  )it worked just fine. But this is a waste because if i use the external DNS (pluton) they will connect using external IP's so its a bandwidth waste etc..etc...


No i haven't configure any external DNS server in the SMTP connectors advance tab..
0
 
Chris DentPowerShell DeveloperCommented:

Shame ;)

It only really leaves a configuration problem with the local DNS.

When they send messages between the servers do they use any one of the 5 domain names mentioned above?
0
 
TannerManCommented:
When you state...
C) DNS Server named zeus with internal IP 192.168.0.1 which has the above primary zones (example1, office1) with MX records perseas.example1.com (192.168.0.210) and axilleas.office1.com (192.168.100.1)

what Internal DNS servers handle requests for your clients, and mail server, on network 192.168.100.x ? Isn't this a separate domain and network? Is there a secondary zone for exmaple1 and office1 on subnet x.x.100?

can your exchange server on network x.x.0 send mail to the one on x.x.100, or is the problem in both directions.
0

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now