DNS Namespace planning 1

[JVKAdmin]

I have a question on DNS namespace planning. I currently am looking at planning a DNS implementation. In my Windows 2000 study book they talk about 4 methods of planning for DNS namespace and not one of them includes naming the domain name for internal to domain.local. Is the only reason to name the internal domain to domain.com for exmaple so that your company can eventually communicate and find other windows 2000/2003 AD domains and join their forests and to only name it domain.local if the company has not future plans to expand their business onto the internet etc ?

I am curious because we are currently looking at using our domain.com for the root AD name. We currently have an ISP hosting our domain.com name (not sure if they use Windows 2000/2003 AD or not). We'd like to have the possiblity of later taking over another company by either joining forests or establishing trusts (over the internet). We also currently have an existing NT4 DNS server on the internal network forwarding to our ISP's DNS for lookups. We also have a DMZ with a Webserver and we are using One to One NAT for it. Our network is a single NT4 domain with DNS, WINS and DHCP (NT4). Currently 3 NT4 servers and 1 Win2K server (standalone - and will stay standalone). 1 PDC and 1 BDC. We also have a firewall with a DMZ and trusted port.

Here are the proposed ideas which I'd like some comments on:

1) Name our root AD domain corp.domain.com for internal and let our ISP hold records for domain.com and forward all requests from internal clients for domain.com to the ISP (will this even work for clients connecting to resources such as our website.domain.com hosted on the DMZ ?).

2) Name our root AD domain.local (does this now limit the possibility of using DNS to find another forest to connect to over the internet?) for internal namespace and like method 1 use the ISP's DNS for external. (what about DMZ webserver, can domain.local hold records for domain.com for internal clients?)

3) Use domain.com for internal as well as the ISP holding our domain.com entries and manually configure the internal domain.com DNS server to point to our

http://www.domain.com

entry. (this currently is what we do on our NT4 DNS set up.)

Another question is what happens when you go and try to upgrade an NT4 BDC (doesn't have DNS) server in a pre-existing NT4 envrionment that has already got a domain.com DNS Server running ? Does AD try to install using the existing DNS server ? Is it better to shut off the exisiting NT4 DNS, let dcpromo install a new DNS server for AD (SOA) and switch over DHCP to assign it as the new DNS server and continue from there?

I'd be really interested in hearing what other companies do in this case

Thanks

Kevin

 

[AlexIT]

1) Name our root AD domain corp.domain.com for internal and let our ISP hold records for domain.com and forward all requests from internal clients for domain.com to the ISP (will this even work for clients connecting to resources such as our website.domain.com hosted on the DMZ ?)."

The child.parent.domain.com relationship allows your server to be authorative for a sub-domain, but parent DNS servers hosts domain.com. The ISP DNS MUST be authorative for the web server in the DMZ because of domain.com. The server in the DMZ is not a member of your domain, but of the parent domain (probably a good idea anyway to keep this guy out of it altogether...) Your internal clients may or may not access domain.com resources, depending on your forwarder settings in DNS, if your ISP permits dynamic DNS traffic, and other variables.

"2) Name our root AD domain.local (does this now limit the possibility of using DNS to find another forest to connect to over the internet?) for internal namespace and like method 1 use the ISP's DNS for external. (what about DMZ webserver, can domain.local hold records for domain.com for internal clients?)"

Your internal namespace (every location) should follow FQDN practice, i.e. children are subdivided from parent - child.parent.domain.local. You will see that M$ kinda forces this in multiple domain in one forest settings. There is no drawback to this method, your webserver is pointed by the ISP. (Just like your PC browsing for .cn or .jp domains...completely outside your DNS realm.)

"3) Use domain.com for internal as well as the ISP holding our domain.com entries and manually configure the internal domain.com DNS server to point to our

http://www.domain.com

entry. (this currently is what we do on our NT4 DNS set up.)"

Internal clients cannot connect to external resources (under domain.com) unless your DNS server has pointers to each external resource. There is a question of authority for the domain.com (you, your ISP, your other locals around the world...) Best to avoid if in your power to do so.

Alex

 

[JVKAdmin]

Alex,

First, thanks for responding but I am still a little confused.

I'm splitting my replies up into sections
--------------------------------------------------------
"1) Name our root AD domain corp.domain.com for internal and let our ISP hold records for domain.com and forward all requests from internal clients for domain.com to the ISP (will this even work for clients connecting to resources such as our website.domain.com hosted on the DMZ ?)."

Alex: The child.parent.domain.com relationship allows your server to be authorative for a sub-domain, but parent DNS servers hosts domain.com. The ISP DNS MUST be authorative for the web server in the DMZ because of domain.com. The server in the DMZ is not a member of your domain, but of the parent domain (probably a good idea anyway to keep this guy out of it altogether...) Your internal clients may or may not access domain.com resources, depending on your forwarder settings in DNS, if your ISP permits dynamic DNS traffic, and other variables


Kevin: So basically our ISP would have to have SRV records and be able to communicate with our internal DNS server ? How does this work for internal clients that need to see the web server on the DMZ then since the ISP would be using public addressing and because of NAT internal clients would not be getting private addresses for our DMZ for example ? Does this not also cause a security concern using the the ISP as the SOA ? Is the only way around this to host our own "public" DNS server (outside our firewall)and change our registered entries on Network Solutions to point to our newly public DNS Server (bypassing our ISP's) ? What do other companies typically do in this scenario?

-----------------------------------------------------------

"2) Name our root AD domain.local (does this now limit the possibility of using DNS to find another forest to connect to over the internet?) for internal namespace and like method 1 use the ISP's DNS for external. (what about DMZ webserver, can domain.local hold records for domain.com for internal clients?)"

Alex: Your internal namespace (every location) should follow FQDN practice, i.e. children are subdivided from parent - child.parent.domain.local. You will see that M$ kinda forces this in multiple domain in one forest settings. There is no drawback to this method, your webserver is pointed by the ISP. (Just like your PC browsing for .cn or .jp domains...completely outside your DNS realm.)

Kevin: Okay I understand what you are saying however this would not work with our current NAT set up for our DMZ then because our clients can not access our DMZ using public addressing which is what the ISP's DNS would return to the client. This is the problem with One to One NAT.

-----------------------------------------------------------
"3) Use domain.com for internal as well as the ISP holding our domain.com entries and manually configure the internal domain.com DNS server to point to our

http://www.domain.com

entry. (this currently is what we do on our NT4 DNS set up.)"

Alex: Internal clients cannot connect to external resources (under domain.com) unless your DNS server has pointers to each external resource. There is a question of authority for the domain.com (you, your ISP, your other locals around the world...) Best to avoid if in your power to do so.

Kevin: Can you expand a little more on this about the dis-advantages/problems that can happen with this scenario as this is currently what we are doing for out NT4 environment. I'm curious to know what happens after upgrading to an AD environment and when this scenario scales upward (like merging companies).

-----------------------------------------------------------

 

[AlexIT]

If you have two DNS namespaces (internal/external) the ISP has all records for domain.com and your internal has all records for domain.local (or internal.domain.com.)

Internal clients that need to see the web server on the DMZ would first inquire your internal DNS server, which would forward to the ISP DNS, this request would be answered (and cached locally on your internal DNS.) The server in the DMZ is set with a one-to-one NAT (port forwarding is also possible, this gives more security but requires more maintenece.)

This division reduces security concerns because the ISP is the SOA for domain.com. They are going to keep these records correct.

Alex

 

[JVKAdmin]

Alex,

I understand what your saying but perhaps my explanation is not as good. First off we are using a hardware firewall that has a built in DMZ and built in Trusted port which may or may not make a difference here. My problem is that internal clients are not able to go to the e-commerce site on our DMZ if they get an address reffered to by the ISP's DNS because the client can't go out and then back in again do to the way the routing works (as far as I know). For example my internal (trusted) hosts are 10.x.x.x and my DMZ hosts are 192.168.x.x. As it stands now if I take out the

http://www.domain.com

entry from our current DNS server (internal) to point to 192.168.0.1 for the webserver. The 10.x.x.x clients can't find the webserver from inside our network (outside access still works fine) with the DNS server caching the public address (as this points back to the firewall just on a differentIP address). On our firewall i believe we have port forwarding in use. We configure an external IP (lets say 209.1.1.2 for example)on the firewall to let port 80 traffic NAT'd to our internal address of 192.168.0.1 for example. Our trusted network has a public address of 209.1.1.1 for example.

Anyways All I am getting it is that I wanted to know which namespace method is going to work the best for connecting to external networks with AD as well as allowing our internal clients to access the local DMZ webserver.

I'm going to do some Test Windows AD installs at home this weekend so perhaps I'll get some more insight.

 

[AlexIT]

Ok, if the firewall IP is 209.1.1.1 any port forwarding or DMZ ports on the firewall are going to use this as the public IP. Your webserver in the DMZ is using 192.168.1.1 in its NIC. Your internal lan is 10.1.1.1

You will need to keep a record in your internal DNS to relate the 192.168.1.1 with the webserver by name, but your firewall should automatically route any LAN traffic for this IP address to the DMZ port...

Public DNS will give your webserver as 209.1.1.1.

Alex

 

[JVKAdmin]

Alex,

I completely understand what you've just said so my question is then if the domain (internal DNS) is for domain.local instead of domain.com then how can you add an entry to domain.local to point to

http://www.domain.com

for example in the DMZ ?? Do you have to set up a zone file for domain.com as well as domain.local but not make it the SOA for domain.com ?

Kevin

 

[AlexIT]

I don't have a server available right now, I remember going to the name.local zone and "Add Domain" then Name.com. This might create a new zone, then you add the server as a Host.

It should not matter if you have a SOA for domain.com on your INTERNAL DNS server anyway, you are not communicating between the internal DNS and the outside world (except through a forwarder...)

I will confirm this on my test server when I get it rebuilt...

Alex

 

[JVKAdmin]

Alex,

My question would then be what if we want to communicate through the firewall so that our forest could join another ? would we have to put a DNS server outside the firewall and restrict DNS zone transfer between the internal and external DNS machines ? Also what problems then are associated with doing that ?

This is one area I'd be interested in hearing about as our company may need this ability in the future so planning it now is probably a good idea.

Kevin

 

[AlexIT]

One client I have runs one forest/many domains in multiple locations and internal/external DNS has never been an issue. The seperate locations have ISP's with SOA for their registered domains (corp.com, corp.de, corp.fr...corp.tw coming soon) and records for the public IP address (MX everywhere, some others here and there.) All sites have firewall with port forwarding to route public traffic to correct NAT'd address. On each LAN there is AD with DNS (usa.corp.local, de.corp.local, fr.corp.local, tw.corp.local) with SOA for their xxx.corp.local domains. All LANs are VPN'd together through hardware VPN in their firewalls (interface metric'd for different failovers.) In one location (de, not that it matters...) there are the forest FMSO roles. All the internal zones transfer between internal DNS. You can sit at any machine in any location and ping by name any other machine in the forest.

In your situation you may have the extra host records to point to the DMZ server ip address (for internal client resolution) but that would be the only difference I would expect.

Alex

 

[JVKAdmin]

Alex,

So how do differnet companies find each other through DNS then ? Do they need to have the SRV record entry at their ISP or is the ISP just forwarding the DNS request to the firewall which sends it through NAT to the local AD DNS ? Also if company 1 (domain1.com) wants to find company 2 (domain2.com) and join their forest what domain do they look for ? (ie domain2.local or domain2.com ?) At that point do you then add a domain entry for domain2.com with an SRV record (if they are looking for domain2.com) ?

This has been a very enlightening discussion and i want to tell you that I appreciate the dialogue.

Kevin

 

[AlexIT]

You are confusing public and private DNS. There is nothing at (any) ISP except what is required for public traffic to find your public IP. So they will have MX record pointing mail to your public IP, a SRV record pointing web to your (same) public IP, etc. Your firewall is NAT'ing certain ports from your public IP to each server requiring public traffic (pub.lic.ip.addr:25 = pri.vate.ip.addr1:25 Mail Server, pub.lic.ip.adddr:80 = pri.vate.ip.addr2:80 Web Server, etc...assuming you run mail and web on different servers.)

The site.corp.local AD DNS servers domains are zone transferring (all are part of the same forest, might work with two trusted forest but I never tried this...M$ made the forest idea in 2000 to get rid of some of the complicated trusts that NT4.0 required between domains.) So you have a VPN, which is hard programmed with all the public IP addresses, that is handling routing between each site subnet (ALL sites MUST be on different subnets but you knew that...) DNS traffic from usa.corp.local to de.corp.local is ONLY through VPN (secure, well secure enough.)

Alex

 

[JVKAdmin]

Alex,

So ISP's do have SRV records then pointing to public address's on your firewall (for example) ? Okay I think I understand the internal external thing now. It still sounds like there is a lot of manual DNS entry work that would have to be done for DNS issues for resolving services on the DMZ for internal clients either

So in a typical situation if understand this particular scenario correctly:

1) company 1 goes to buy company 2

2) both have namespaces of company1.com and company2.com respectively

3) company1 then needs to establish a VPN connection with company2 in order for (assuming they have a windows 2000 AD installation) setting up 2 way trusts since company1 now owns company2 and needs access to their resources.

4) After the VPN is set up both companies can talk to each other privately through the tunnel and all DNS traffic external still remains the same. company1's internal AD name is company1.local , company2's AD name was company2.com <they weren't as smart as company1>

Does company 1 simply do a migration, add their servers to the company1 forest, re-do their AD name to be company2.local, set up Zone transfers between the two private DNS servers and slowly migrate all of their servers to the new company2.local domain in the new forest ?

Kevin

 

[AlexIT]

So ISP's do have SRV records then pointing to public address's on your firewall (for example)?"

You probably would not use SRV records (my bad example), an address record "A" works for web, mail exchange "MX" is for mail...

"It still sounds like there is a lot of manual DNS entry work that would have to be done for DNS issues for resolving services on the DMZ for internal clients"

You use fixed IP addresses for the servers, so this is really only done once (for each private DNS, then this info is zone transfered.)

In your company buys another example:
First, get the VPN connection setup. You must at least be able to ping by IP address.
Now install a new AD server "company2.local" that is a new domain in existing forest (existing company1 forest.) Now migrate all the other company2 servers, clients, users, etc. to this new domain.
Then setup the zone transfer (if needed AD sometimes does this as part of new domain in existing forest install it seems) between this new company2.local and company1.local DNS.

You should have minimal downtime for the company2 public servers (they are in DMZ and should NOT part of comapny2.com domain, or company2.local so they don't get touched.)


Alex