Different DNS and AD domain structures

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

The company I am with at the moment is planning an AD rollout (using Win2003). They are currently on NT4 domains and are consolidating these into a fewer number of AD domain based on the Business units with an empty root domain.

The AD will be stuctured as 'BusUnit1.AD.company.com' 'BusUnit2.AD.company.com' etc with 'ad.company.com' as the forest root.

Some of the business units have an existing DNS structure that is based on location such as 'london.company.com', 'newyork.company.com' and they want to keep this structure (not sure why... this is coming from the project team in one of the other business units)

I know this should be possible but there is very little information about setting this up or its implications.

What I need to know is what are the advantages of doing it this way and more importantly what are the downsides. Is there any options that dont work or are not as easily managed by doing it this way.
 
In
BillDuff in said:
The company I am with at the moment is planning an AD rollout (using
Win2003). They are currently on NT4 domains and are consolidating
these into a fewer number of AD domain based on the Business units
with an empty root domain.

The AD will be stuctured as 'BusUnit1.AD.company.com'
'BusUnit2.AD.company.com' etc with 'ad.company.com' as the forest
root.

Some of the business units have an existing DNS structure that is
based on location such as 'london.company.com', 'newyork.company.com'
and they want to keep this structure (not sure why... this is coming
from the project team in one of the other business units)

I know this should be possible but there is very little information
about setting this up or its implications.

What I need to know is what are the advantages of doing it this way
and more importantly what are the downsides. Is there any options
that dont work or are not as easily managed by doing it this way.

When designing your DNS infrastructure, it needs to match the AD DNS Domain
naming structure you decided to use. Disjointed namespaces, as what you're
hinting at, where the zone does not match the AD name, won't work. AD uses
DNS to store its resource and service locations in the zone. That zone has
to match AD's name. The netlogon service gets the domain name from AD and
then assembles the data, reads the Primary DNS suffix, then send the
reistration request to the DNS address in your IP properties to registers
that data into that zone. Basically to make it work:

1. Primary DNS Suffix on the machine MUST match the zone name in DNS.
2. Primary DNS Suffix MUST match the AD DNS domain name.
3. Point your DNS addresses in the machines' IP properties to ONLY the
servers hosting the zone.
4. Dynamic updates enabled.

Curious, what is the function of naming your current structure
"london.company.com", newyork.company.com", etc? Is it based on your
external website naming structure?

External naming hierarchy has nothing to do with the internal structure. You
can name the internal anything you want. The only suggestion is to NOT name
it what your external name is due to functionality, adminstrative overhead,
and frankly, headaches. You could name it as you suggested where the start
of the AD structure is ad.company.com if you like, no problem there, just
don't choose company.com, if that is your external name.

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroup so all
can benefit.
This posting is provided "AS-IS" with no warranties and confers no
rights.

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

HAM AND EGGS: A day's work for a chicken; A lifetime commitment for a
pig. --
=================================
 
BillDuff said:
The company I am with at the moment is planning an AD rollout (using
Win2003). They are currently on NT4 domains and are consolidating these into
a fewer number of AD domain based on the Business units with an empty root
domain.
The AD will be stuctured as 'BusUnit1.AD.company.com'
'BusUnit2.AD.company.com' etc with 'ad.company.com' as the forest root.
Some of the business units have an existing DNS structure that is based on
location such as 'london.company.com', 'newyork.company.com' and they want
to keep this structure (not sure why... this is coming from the project team
in one of the other business units)

Perfectly acceptable AS LONG AS you insure that each
DNS client (and this means servers too) can reach a DNS
server which can either resolve every name.

This last means that every DNS server (used by clients)
must be either:

1) Hold all the answers
2) Have a "root hints/cache file" that allows finding a
common ROOT and working down to any possible name
3) Have another DNS server as forwarder which can do
either number 1, 2, or 3 until the name is found.

For instance, if ALL of you zones are children of .Com (direct
or as grandchildren etc.) then .Com can serve as a common
root, but then you get into the issue of how to resolve the
Internet (which is usually and implicit requirement.)

I know this should be possible but there is very little information about
setting this up or its implications.

Just write down ALL of the domains. Find the natural
relationships (parent child), and arrange a common
root or other method for all names to be resolved.

If it gets complicated then post the MINIMAL requirements
succintly here.
What I need to know is what are the advantages of doing it this way and
more importantly what are the downsides. Is there any options that dont work
or are not as easily managed by doing it this way.

Advantage:
You can have more names.

Disavantage:
You have to set it up

Consider this: For EVERYONE who will still resolve "The Internet",
they have this problem to a greater or lesser extent.

Keep this in mind: Clients need a DNS Server which can find ALL
names they might legitimately query.

The 'standard' method of this is for that DNS server to recurse from
the root down until it reaches the answer.

The 'standard' supplement to this is using a "forwarder" to resolve
those names the first DNS server cannot reach.

Win2003 offers even more tools than Win2000 for handling odd
or weird situations ("conditional forwarding" & "stub zones")
and sometimes BIND servers might be helpful as well if it gets
REALLY UGLY.

Generally though Win2003 DNS is your BEST choice for internal
Windows domains, and Win2000 is second best with BIND in a
somewhat separate third place.
[/QUOTE]
 
Thanks for the answers guys, I always like two competing answers :-)

There is no external connection to the DNS structure used. At the moment there are several sites in the US and a few in the UK that. The UK use a seperate namespace completely at the moment and the US offices have it organised around the locations within the business units.

This is a purely internal structure that is being designed. We are upgrading from NT4 so there is not a lot of use of DNS internally at the moment. Personally I cannot see the logic of breaking away from having the AD and DNS domain reconciled but some others like their current DNS setup so much they want to keep it.

In summing up, would it be fair to say that setting up a disjointed namespace is possible but it is more work to configure and manage and is also more likely to be difficult to troubleshoot in the event of problems.
 
BillDuff said:
Thanks for the answers guys, I always like two competing answers :-)

They were no competing answers.

Ace gave you good advice, from a limited ("Windows only")
perspective, that prevents tyros from screwing themselves up
if they don't take a minute to think DNS through.

My post was about the general case, his is a subset.
There is no external connection to the DNS structure used. At the moment
there are several sites in the US and a few in the UK that. The UK use a
seperate namespace completely at the moment and the US offices have it
organised around the locations within the business units.

This is a purely internal structure that is being designed. We are
upgrading from NT4 so there is not a lot of use of DNS internally at the
moment. Personally I cannot see the logic of breaking away from having the
AD and DNS domain reconciled but some others like their current DNS setup so
much they want to keep it.

That simplifies things since you can use your "forwarding" to reach
another DNS tree instead of the "Internet namespace" IF YOU MUST.

Maybe "simplifies" is the wrong word, but it gives you more flexibility.
In summing up, would it be fair to say that setting up a disjointed
namespace is possible but it is more work to configure and manage and is
also more likely to be difficult to troubleshoot in the event of problems.

No, not really. They key is to AVOID setting up a "disjointed namespace."

The practical definition of a namespace is "all the names that can be
resolved
by one set of DNS servers".

Many people (incorrectly) equat 'namespace' with "DNS tree" -- a tree MIGHT
be a namespace but a namespace may have many subtrees and even ways
to bridge what (at first) appear to be multiple namespaces but are really
only disjoint TREES. (not disjoint namespaces because of that bridging*.)

They key is that ALL OF YOUR DNS server must resovle ALL of the
names in the namespace -- either directly or indirectly through actual
recursion and/or forwarding (etc.)


* 'bridging' is NOT a technical term as used here.
 
In
BillDuff in said:
Thanks for the answers guys, I always like two competing answers :-)

There is no external connection to the DNS structure used. At the
moment there are several sites in the US and a few in the UK that.
The UK use a seperate namespace completely at the moment and the US
offices have it organised around the locations within the business
units.

This is a purely internal structure that is being designed. We are
upgrading from NT4 so there is not a lot of use of DNS internally at
the moment. Personally I cannot see the logic of breaking away from
having the AD and DNS domain reconciled but some others like their
current DNS setup so much they want to keep it.

In summing up, would it be fair to say that setting up a disjointed
namespace is possible but it is more work to configure and manage and
is also more likely to be difficult to troubleshoot in the event of
problems.

You'll have to come up with a common scheme between your London and US
business models/names.

Yes, it can actually work (but not really practical) if you want to mess
with a disjointed namespace, sure, it is ALOT of extra work. I know of one
major European firm ( I will not mention who) that tried it and frankly,
they bagged it when they finally come to realize the extent of what needed
to be done to make it work.

Keep in mind, it won't work with the DCs, they still need to register into
their zone. WIth the clients, you can "fudge" it, but to allow client
logons, you'll need can create whatever zone you like that the clients are
using, but copy and put in the SRV records that belong to the actual Domain
namespace, but the client side extensions would query the DNS for the domain
that its joined to anyway...

Let me know if you get it to work.

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroup so all
can benefit.
This posting is provided "AS-IS" with no warranties and confers no
rights.

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

HAM AND EGGS: A day's work for a chicken; A lifetime commitment for a
pig. --
=================================
 
In
BillDuff said:
Thanks for the answers guys, I always like two competing answers :-)

There is no external connection to the DNS structure used. At the
moment there are several sites in the US and a few in the UK that.
The UK use a seperate namespace completely at the moment and the US
offices have it organised around the locations within the business
units.

This is a purely internal structure that is being designed. We are
upgrading from NT4 so there is not a lot of use of DNS internally at
the moment. Personally I cannot see the logic of breaking away from
having the AD and DNS domain reconciled but some others like their
current DNS setup so much they want to keep it.

In summing up, would it be fair to say that setting up a disjointed
namespace is possible but it is more work to configure and manage and
is also more likely to be difficult to troubleshoot in the event of
problems.

I'm not meaning to disagree with others but you can do this without a
disjointed namespace even if you have one domain, details below.

One domain company.com, every machine in this domain has a Primary DNS
suffix company.com
Each location has a connection specific suffix based on location e.g.
london.company.com
Each DC at each location has a zone for company.com, the active directory
domain, that replicates forest wide.
Also each location has a zone based on location e.g. london.company.com that
replicates forest wide.
Now, each location has two DNS names company.com and location.company.com
The only problem, you can only have one machine name per forest. But each
location zone can have a (same as parent folder) record that points to the
IP of a main server at each location.
 
In
BillDuff said:
Thanks for that Kevin, I am still waiting on details on how the guys
in the US are implementing this but I suspect its as you have
described.

The main reason behind my questions was WHY??. The DNS for each
domain will not be that large (max 1,500 records mostly dynamic PC's
through DHCP), as it is being broken down to Business units anyway,
and I am wondering if it is worth the extra admin effort to set up
'location' zones underneath the business units.

If there was a clear advantatge, either in functionality
oradministration/support, I could go with it but no-one has given me
one yet.

One way you can also do this, DNS registration in the AD Domain zone is not
a requirement for client members. The clients can have a disjointed
namespace but you need a zone for the client to register in.

For Domain controllers on the other hand, their Primary DNS suffix _must_
match the Active Directory Domain name.
 
In
No, not really. They key is to AVOID setting up a "disjointed
namespace."

The practical definition of a namespace is "all the names that can be
resolved
by one set of DNS servers".

Many people (incorrectly) equat 'namespace' with "DNS tree" -- a tree
MIGHT be a namespace but a namespace may have many subtrees and even
ways


I agree, the namespace can start anywhere in the subtree.
Also agree not to do this.



--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroup so all
can benefit. This posting is provided "AS-IS" with no warranties and
confers no rights.

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

HAM AND EGGS: A day's work for a chicken; A lifetime commitment for a
pig. --
=================================
 
In
Kevin D. Goodknecht Sr. [MVP] in said:
In

I'm not meaning to disagree with others but you can do this without a
disjointed namespace even if you have one domain, details below.

One domain company.com, every machine in this domain has a Primary DNS
suffix company.com
Each location has a connection specific suffix based on location e.g.
london.company.com
Each DC at each location has a zone for company.com, the active
directory domain, that replicates forest wide.
Also each location has a zone based on location e.g.
london.company.com that replicates forest wide.
Now, each location has two DNS names company.com and
location.company.com The only problem, you can only have one machine
name per forest. But each location zone can have a (same as parent
folder) record that points to the IP of a main server at each
location.

Kevin, with your scenario you're depicting one domain, but different child
domains based on locations, which will work fine for the clients, just
altering the Primary DNS Suffix and accomdating the search suffix, (as you
pointed out later), but not for the DCs.


--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroup so all
can benefit. This posting is provided "AS-IS" with no warranties and
confers no rights.

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

HAM AND EGGS: A day's work for a chicken; A lifetime commitment for a
pig. --
=================================
 
Many people (incorrectly) equat 'namespace' with "DNS tree" -- a tree
I agree, the namespace can start anywhere in the subtree.
Also agree not to do this.

I think you get it -- but it might confuse someone else who does
not already understand it, so:

A (sub) tree is NOT a namespace when it is part of a larger
tree (or really when the namespace is larger than just that tree.)

A subtree is a namespace when it exists in isolation -- that is,
when you cannot resolve names outside of it.

Too many people use the word namespace for the latter.
 
In
I think you get it -- but it might confuse someone else who does
not already understand it, so:

A (sub) tree is NOT a namespace when it is part of a larger
tree (or really when the namespace is larger than just that tree.)

A subtree is a namespace when it exists in isolation -- that is,
when you cannot resolve names outside of it.

Too many people use the word namespace for the latter.


True. I remember a conversation we had last year about this.

As long as everyone remembers that a namespace can start anywhere in the
subtree, but a subtree is not necessarily the start of a namespace,
depending on how the zone is created or whether its already part of a
namespace. Hope that wasn't too confusing for everyone.


--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

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

HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.
 
True. I remember a conversation we had last year about this.
As long as everyone remembers that a namespace can start anywhere in the
subtree,

That is not really a useful way to say it -- too misleading.

If a namespace starts "anywhere in the subtree" is it NOT
a subtree since that means it is part of a large tree which
would be the enclosing namespace.

If you say, "a namespace does not have to be rooted at the
'.' or Internet root" then you will be close to explaining it
clearly.

but a subtree is not necessarily the start of a namespace,

In fact, if it is really a subtree it is NOT a namespace but
only a subsection of one.
depending on how the zone is created or whether its already part of a
namespace. Hope that wasn't too confusing for everyone.

Just a little.
 
In
Herb Martin in said:
That is not really a useful way to say it -- too misleading.

If a namespace starts "anywhere in the subtree" is it NOT
a subtree since that means it is part of a large tree which
would be the enclosing namespace.

If you say, "a namespace does not have to be rooted at the
'.' or Internet root" then you will be close to explaining it
clearly.



In fact, if it is really a subtree it is NOT a namespace but
only a subsection of one.


Just a little.

I know, :-). That's what lead to our conversation last year about this.


Ace
 
Back
Top