MX Record and AD Circular Logic

  • Thread starter Thread starter mckeyd
  • Start date Start date
M

mckeyd

If I put a MX record in AD for an Exchange Server that is
inside a private network (I.E. mydomain.com MX
ns1x.mydomain.com) the NSLOOKUP for NS1x ,(from any
outside workstation), returns 192.168.199.80 instead of
the gateway public address that has ports 110 and 25
forwarded to 192.168.199.80. Microsoft Best Practices
tell us not to us CNAME records when dealing with MX
records. How do I tell the WORLD to look for my mail
server at 2xx.xx.xxx.203 without some type of alias?
Microsoft also tells us not to route mail to a pseudo
domain (I.E. mail.mydomain.com) unless "mail" is a FQDN.
I currently fudge the MX record by using the IP address
rather than the FQDN and a "mail" pseudo domain. This
causes problems for many other mail servers that wish to
send me mail, not to mention making all DNS checking
software fail on the MX record. I tried LYING to the DNS
server and adding a second A record for the FQDN of the
Mail server, ( I.E mydomain.com MX
ns1x .mydomain.com AND ns1x A 2xx.xx.xxx.203
and ns1x A 192.168.199.80) but AD corrects this
and eliminates the false record.

I have two internic registered DNS servers. I am Primary
for all of my domains and my ISP is secondary.

Mydomain.com is entirely internal. AD w/Exchange on W2003
Enterprise servers and Multi site/state VPN links and DC
at each site. (WORKS GREAT EXCEPT FOR MX Publication to
the world)

MyOtherdomain.net has both Names servers on live
internet addresses (with Dual NICS (one private and one
public {NOT BRIDGED}). AD on W2000 Enterprise servers

CURRENT WORKING (ALTHOUGH FUDGED DNS)
Name Type Data
(same as parent folder) Start of Authority (SOA)
[2003112735], mcdc1.mydomain.com.,
dnsadmin.mydomain.com.
(same as parent folder) Responsible Person (RP)
dnsadmin.mydomain.com.
(same as parent folder) Name Server (NS)
ns2.swbell.net.
(same as parent folder) Name Server (NS)
ns1.myOTHERdomain.com.
(same as parent folder) Name Server (NS)
mcdc1.mydomain.com.
(same as parent folder) Name Server (NS)
dns1.myOTHERdomain.com.
mail Mail Exchanger (MX) [10] 2xx.xx.xxx.203.
www Host (A) 2xx.xx.xxx.204
pam Host (A) 192.168.1.111
ns1x Host (A) 192.168.199.80
mcdc1 Host (A) 192.168.199.203
ManServ Host (A) 192.168.1.160
mail Host (A) 216.61.180.203
keith-console Host (A) 192.168.1.110
console Host (A) 192.168.199.230
(same as parent folder) Host (A) 2xx.xx.xxx.203
(same as parent folder) Host (A) 192.168.199.203
TAPI3Directory
Please help
Les
mansfield
ForestDnsZones
DomainDnsZones
_udp
_tcp
_sites
_msdcs
 
You kind of answered your own question about mail records. Fudging and
munging DNS records just don't work. An Alias for MX an record also just
doesn't work.

Actually, you would need a separate DNS server for your internal network and
keep using your current one for hosting your domain name(s) on the Internet.

The reason is you just can't mix public and private records on one MS DNS
server. Period. BIND has the capability to mix with a feature called "views"
which will respond with an answer based on the -querying client's IP
address. In that scenario, any external queries would get the public IP, and
vice-versa.

Your internal DNS in your scenario would only host the AD zone name. All
clients and DCs *ONLY* use this one. This server has the private IPs that
your clients can resolve and connect to. Including Exchange. No need for an
MX records internally.

It is very important that all your internal DCs and clients only use your
internal DNS ONLY. Then in your "internal" DNS server properties, configure
a forwarder to your "External" DNS server(s). This way all clients will
always only ask your internal DNS. Any records it cannot resolve, will be
sent to your other ones. Suggest they also have forwarders configure to your
ISP's DNS.

On the two "external" DNS servers hosting your public records, create an A
record called mail. Then create an MX record, leave the hostname portion
blank, then in the next box, type in mail.yourExternalDomainName.com. That's
it.

You'll find now that all will work smoothly.

--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
--
=================================

mckeyd said:
If I put a MX record in AD for an Exchange Server that is
inside a private network (I.E. mydomain.com MX
ns1x.mydomain.com) the NSLOOKUP for NS1x ,(from any
outside workstation), returns 192.168.199.80 instead of
the gateway public address that has ports 110 and 25
forwarded to 192.168.199.80. Microsoft Best Practices
tell us not to us CNAME records when dealing with MX
records. How do I tell the WORLD to look for my mail
server at 2xx.xx.xxx.203 without some type of alias?
Microsoft also tells us not to route mail to a pseudo
domain (I.E. mail.mydomain.com) unless "mail" is a FQDN.
I currently fudge the MX record by using the IP address
rather than the FQDN and a "mail" pseudo domain. This
causes problems for many other mail servers that wish to
send me mail, not to mention making all DNS checking
software fail on the MX record. I tried LYING to the DNS
server and adding a second A record for the FQDN of the
Mail server, ( I.E mydomain.com MX
ns1x .mydomain.com AND ns1x A 2xx.xx.xxx.203
and ns1x A 192.168.199.80) but AD corrects this
and eliminates the false record.

I have two internic registered DNS servers. I am Primary
for all of my domains and my ISP is secondary.

Mydomain.com is entirely internal. AD w/Exchange on W2003
Enterprise servers and Multi site/state VPN links and DC
at each site. (WORKS GREAT EXCEPT FOR MX Publication to
the world)

MyOtherdomain.net has both Names servers on live
internet addresses (with Dual NICS (one private and one
public {NOT BRIDGED}). AD on W2000 Enterprise servers

CURRENT WORKING (ALTHOUGH FUDGED DNS)
Name Type Data
(same as parent folder) Start of Authority (SOA)
[2003112735], mcdc1.mydomain.com.,
dnsadmin.mydomain.com.
(same as parent folder) Responsible Person (RP)
dnsadmin.mydomain.com.
(same as parent folder) Name Server (NS)
ns2.swbell.net.
(same as parent folder) Name Server (NS)
ns1.myOTHERdomain.com.
(same as parent folder) Name Server (NS)
mcdc1.mydomain.com.
(same as parent folder) Name Server (NS)
dns1.myOTHERdomain.com.
mail Mail Exchanger (MX) [10] 2xx.xx.xxx.203.
www Host (A) 2xx.xx.xxx.204
pam Host (A) 192.168.1.111
ns1x Host (A) 192.168.199.80
mcdc1 Host (A) 192.168.199.203
ManServ Host (A) 192.168.1.160
mail Host (A) 216.61.180.203
keith-console Host (A) 192.168.1.110
console Host (A) 192.168.199.230
(same as parent folder) Host (A) 2xx.xx.xxx.203
(same as parent folder) Host (A) 192.168.199.203
TAPI3Directory
Please help
Les
mansfield
ForestDnsZones
DomainDnsZones
_udp
_tcp
_sites
_msdcs
Click to expand...
 
m> How do I tell the WORLD to look for my mail
m> server at 2xx.xx.xxx.203 without some type of alias?

Use "split horizon" DNS service to serve up one set of
data to machines on your LAN and a different set of data
to the rest of Internet.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/dns-split-horizon.html>

m> I currently fudge the MX record by using the IP address [...]
m> This causes problems for many other mail servers [...]

Of course it does. That's because you are _not_ entering an IP
address. You are entering a _domain name_ that just happens to
resemble the human-readable form of an IP address. The public
DNS database contains no mappings from such domain names to IP
addresses.

[C:\]dnsgeta 216.61.180.203
IUZ0031: The domain name "216.61.180.203." does not exist.
[C:\]

When attempting to locate your SMTP Relay server, SMTP Relay clients
attempt to look up the name->address mapping for that domain name.
Because the domain name does not exist, there is no mapping, the SMTP
Relay clients are unable to locate your SMTP Relay server, and they
are thus unable to transport mail to you.

(Some proxy DNS server softwares intercept queries against such domain
names and fabricate answers for them, generating the name->address
mappings themselves, instead of performing query resolution. SMTP
Relay clients that just happen to use such proxy DNS servers will
be able to locate your SMTP Relay server. But this is not true for
all proxy DNS server softwares.)
 
Back
Top