Active Directory Design - DNS

  • Thread starter Thread starter Steve
  • Start date Start date
S

Steve

I have been taught to setup the Domain on a Win2K to
something like abc.local instead of abc.com Can anyone
give me a short explanation and point me to some white
paper detailing why this is necessary?
 
Steve says...
I have been taught to setup the Domain on a Win2K to
something like abc.local instead of abc.com Can anyone
give me a short explanation and point me to some white
paper detailing why this is necessary?
Hi Steve,

the important part is that you should not use a name someone else registered,
and that it's strongly recommended to use a proper domain name instead of a
single-lable domain name (don't use "company", use "company.com" or
"company.local").

If you use a name which you registered in the internet you need to make sure
that your internal servers are able to resolve your servers on the web. This
can usually be done by either using a subzone of your external zone (e.g.
"intern.company.com") or if you really want to use the same zone create A-
Records or a delegation to the external dns-servers. If you use a proxy-server
and you don't need your other systems to resolve DNS-Records outside your net
you can also point the proxy to the external DNS-Servers and configure the
Browser when to use the proxy.

In my eyes the biggest difference between .local and .com is that if you ever
might need to resolve internal adresses from external machines you should use a
officiall registered name or it's subdomain, if you use .local you'll never be
able to resolve that. And who knows what's going on in a few years, after all
the IT infrastructures and services are becoming more integrated and we have
more business processes implemented electronically across organisations.


Gruesse - Sincerely,

Ulf B. Simon-Weidner
 
In my eyes the biggest difference between .local and .com is that if you ever
might need to resolve internal adresses from external machines you should use a
officiall registered name or it's subdomain, if you use .local you'll never be
able to resolve that.

Ulf, that's not true if, as most people do, you are using a NATting
firewall.

Say my internal IP is 192.168.2.37. My external address might be
aa.bb.cc.dd. You can set up the firewall to pass all port 80 incoming
requests to 192.168.2.37 port 80. The external DNS is set to, say,
www.company.com which resolves to aa.bb.cc.dd. Packets go to
aa.bb.cc.dd (the address of the router/firewall and get NATted to
192.168.2.37. Internal DNS can then resolve www.comany.local to
192.168.2.37.

It just means that the two DNS (internal and external) have different
names for the same machine, and they have to be maintained by hand.

That's the way we handle our mail server. It's NATted from outside but
visible by a different local name from inside.

Cheers,

Cliff
 
Enkidu says...
Ulf, that's not true if, as most people do, you are using a NATting
firewall.

Say my internal IP is 192.168.2.37. My external address might be
aa.bb.cc.dd. You can set up the firewall to pass all port 80 incoming
requests to 192.168.2.37 port 80. The external DNS is set to, say,
www.company.com which resolves to aa.bb.cc.dd. Packets go to
aa.bb.cc.dd (the address of the router/firewall and get NATted to
192.168.2.37. Internal DNS can then resolve www.comany.local to
192.168.2.37.

It just means that the two DNS (internal and external) have different
names for the same machine, and they have to be maintained by hand.

That's the way we handle our mail server. It's NATted from outside but
visible by a different local name from inside.

Cheers,

Cliff
Hi Cliff,

yes, that's true, forgot to mention the NAT-Firewall thing. However, I think
deciding for a DNS-Domain name is with todays technologies a more permanent
thing than deciding for a IP-Segment. That's the reason why I'd prefer a DNS-
Name which does not _prevent_ me in the future from resolving some internal
machines (perhaps in the DMZ) from the public internet. I don't really believe
this will be necessary in the very close future, but you never know, and if you
have to do so you don't want to hazzle with a domain rename or restructure.

Gruesse - Sincerely,

Ulf B. Simon-Weidner
 
yes, that's true, forgot to mention the NAT-Firewall thing. However, I think
deciding for a DNS-Domain name is with todays technologies a more permanent
thing than deciding for a IP-Segment. That's the reason why I'd prefer a DNS-
Name which does not _prevent_ me in the future from resolving some internal
machines (perhaps in the DMZ) from the public internet. I don't really believe
this will be necessary in the very close future, but you never know, and if you
have to do so you don't want to hazzle with a domain rename or restructure.

Gruesse - Sincerely,
Ulf, we'll have to agree to disagree on this. I use an internal Domain
Name that is not registered, and I have never had any problems in
making visible internal machines that I wish to be seen from the
Internet via NAT and vice versa. It's a fairly standard setup, and
even IPv6 is not going to make any difference that I can see.

Cheers,

Cliff
 
From my understanding of the reasons for using split horizion DNS was to
keep your internal DNS info private to you. Yes this means maintaining two
DNS systems but why put all the extra info about your company's hosts on the
internet? So you set your internal clients to resolve names from your
internal DNS. So when they go to www.youdomain.com they get 10.0.0.1, but
when some one from the internet goes there they get your vaild external IP
address. You can still use the youdomain.local but make sure your users know
to use that instead of yourdomain.com as most firewalls won't route traffic
back inside once it leaves....IP spoofing security risk....

Oh one more thing, if you use internal DNS, just remove the root zone and
configure your internal DNS servers to forward the requests it can't answer
to your external ones. That way you can still resolve external stuff..

Hope this helps.

Jason
 
Enkidu says...
Ulf, we'll have to agree to disagree on this. I use an internal Domain
Name that is not registered, and I have never had any problems in
making visible internal machines that I wish to be seen from the
Internet via NAT and vice versa. It's a fairly standard setup, and
even IPv6 is not going to make any difference that I can see.
Hi Cliff,

I don't say go this way, but I'd prefer it. Actually I prefer to have the
internal DNS completely separate from the external DNS (there's usually no need
for pure dns-resolution of external hosts, this is where we use proxies).
However it does usually not hurt to use a namespace which _would_ enable me in
the future to open up whatever I want. Using a .local will prevent that - and
I'd never use a name which is not registered to me due to legal and technical
difficulties.

Gruesse - Sincerely,

Ulf B. Simon-Weidner
 
Hi Jason,

Yeah, that was about what I was suggesting. However, your internal
users don't have to know your internal Domain Names. If the DNS suffix
search order is set up properly they can just use host names and the
correct Domain suffix will be added automatically.

Cheers,

Cliff

From my understanding of the reasons for using split horizion DNS was to
keep your internal DNS info private to you. Yes this means maintaining two
DNS systems but why put all the extra info about your company's hosts on the
internet? So you set your internal clients to resolve names from your
internal DNS. So when they go to www.youdomain.com they get 10.0.0.1, but
when some one from the internet goes there they get your vaild external IP
address. You can still use the youdomain.local but make sure your users know
to use that instead of yourdomain.com as most firewalls won't route traffic
back inside once it leaves....IP spoofing security risk....

Oh one more thing, if you use internal DNS, just remove the root zone and
configure your internal DNS servers to forward the requests it can't answer
to your external ones. That way you can still resolve external stuff..

Hope this helps.

Jason
 
How would you manage the search suffixes for an environment with a few
hundred child zones? We have one per branch location so that users can
access local resources by simply accessing "server", for example. Since
search suffixes can't be setup via DHCP, it's quite a challenge for us.
Hi Jason,

Yeah, that was about what I was suggesting. However, your internal
users don't have to know your internal Domain Names. If the DNS suffix
search order is set up properly they can just use host names and the
correct Domain suffix will be added automatically.

Cheers,

Cliff
 
Yes, you are right. My suggestion applies more to a smallish setup
than a large one. I'd be interested in how you are trying to solve it.

Cheers,

Cliff
 
Enkidu says...
Hi Jason,

Yeah, that was about what I was suggesting. However, your internal
users don't have to know your internal Domain Names. If the DNS suffix
search order is set up properly they can just use host names and the
correct Domain suffix will be added automatically.

Cheers,

Cliff
Bwaah - search suffixes - that's like you try your key on every house in the
street - isn't it enough to try the key on each door in your house?

Gruesse - Sincerely,

Ulf B. Simon-Weidner
 
Back
Top