Proposed DNS Infra. (pre-AD)

[Bobsi]

Hello there,

Hopefully the MVP's or those in-the-know can scan over
this proposal and point out any possible pitfalls or un-
recommended practises.

THE ENVIRONMENT:
- Currently in a Windows NT 4 multiple domain environment
stretched across the UK via SMDS links and WAN circuits.
- There are no trust relationships between domains
- MS Exchange 5,5 is currently deployed, all connected via
X-400 across UK.
- Name resolution is NetBIOS only, and replication is
regionalised e.g. someone on a network in Scotland cannot
resolve names at a connected network in the south-west
(this is by design).
- A common IP address scheme (class B) exists across the
UK, and no address spaces have been duplicated.

THE PROPOSAL:
- to introduce a DNS structure now, before moving to AD 6-
12 months later
- External and internal namespaces will remain completely
separate, with clients using MS Proxy for web-based DNS
queries.
- HQ will be the TLD (comp.ad)
- second level will be regionalised (region.comp.ad)
- third level will be city (city.region.comp.ad)
- forth level will be networkid (admin.city.region.comp.ad)
- the DNS servers will be Windows 2000 based
- we will use primary/secondary zone types as no AD exists
(yet)
- we will have two DNS servers per city (1 * PRI, 1 * SEC)
- Forwarders and root hints will be configured on each
server
- DHCP will register DNS on behalf of clients that aree
unable to perform dynamic updates

THE FUTURE:
- plan to upgrade to Windows 2000/3 infrastructure within
6-12 months, creating one single forest with multiple
domains.
- Plan to use AD-integrated DNS zones (for security and
replication topology benefits)

MY QUERIES:
- Would it be possible to upgrade these DNS servers to use
AD-integrated zones after running DCpromo? Anything I need
to be aware of when doing that? (apart from the creation
of '.' root zones)
- When considering NetBIOS, if a comp (compA) is in one
domain and another comp (compA) is part of a different
domain but both domains are part of the same forest, would
the NetBIOS registrations clash? If so, which other
security principles should I consider in order to preserve
uniqueness?
- Would this DNS infrastructure support AD successfully
bearing in mind that it may not reflect the AD design
exactly?
- Should the TLD change, would it be recommended to start
a completely new namespace using separate DNS servers, and
gradually phase the old ones out?
- Again, should the TLD change I assume all clients would
have to have their primary domain suffix manually altered?
could I push out a new primary DNS domain suffix via
Windows 2000 DHCP Server to the clients?
- Ideally speaking, should the DNS namespace be designed
around the network infrastructure?

Sorry for the amount of info here and thanks for taking
the time to read this.

Any help or advice would be gratefully received,

Regards

 

[Ace Fekay [MVP]]

Inline...

Hello there,

Hopefully the MVP's or those in-the-know can scan over
this proposal and point out any possible pitfalls or un-
recommended practises.

THE ENVIRONMENT:
- Currently in a Windows NT 4 multiple domain environment
stretched across the UK via SMDS links and WAN circuits.
- There are no trust relationships between domains
- MS Exchange 5,5 is currently deployed, all connected via
X-400 across UK.
- Name resolution is NetBIOS only, and replication is
regionalised e.g. someone on a network in Scotland cannot
resolve names at a connected network in the south-west
(this is by design).
- A common IP address scheme (class B) exists across the
UK, and no address spaces have been duplicated.

THE PROPOSAL:
- to introduce a DNS structure now, before moving to AD 6-
12 months later
- External and internal namespaces will remain completely
separate, with clients using MS Proxy for web-based DNS
queries.
- HQ will be the TLD (comp.ad)
- second level will be regionalised (region.comp.ad)
- third level will be city (city.region.comp.ad)
- forth level will be networkid (admin.city.region.comp.ad)

Why are you making multiple levels? In your scenario, unless I missed
something, and trying to keep with the separate administration entities you
currently have, it would seem to make more sense to create an empty forest
root to give you a contiguous namespace for the organization, such as
comp.ad, and then create domains based on each location only. This includes
headquarters, such as:
corp.comp.ad
Then base your regions on 1st level child domains too, such as:
region1.comp.ad
region2.comp.ad
region3.comp.ad
region4.comp.ad.

Then create OUs per City and delegate to the specific admins in each city FC
on each OU. This is more of a common standard design based on location then
function.

ANother note, you currently don't have full mesh access, which I'm assuming
based on security. You could also, if you want to be MORE secure, create one
BIG domain, and then create OUs to reflect regional and city boundaries and
delegate as such. One BIG advantage of this is you minimize Domain
Administrators, which can, thru a back door, alter Forest data thru
ADSIEdit. This has been a design oversight in the product. Matter of fact
the US military based their design on one domain and each base have OUs
which have been delegated FC to the COs of each respective base. Prevents
this loophole.

Keep in mind, domains are a logical boundary as well as a security boundary
and require separate administration per domain. What you're proposing can be
overdoing it and wind up being an administration overhead. It seems from
what you've posted so far that it would make sense and fit the bill if you
just keep with 1st level childs, unless you have that many offices with that
many administrators, much like large corporations as Intel or HP. We try to
use the KISS method as much as possible. Or just go with ONE big domain for
maximum security.

If you go with the child domains, as I suggested, you would delegate the
zone authority of the child to the DNS servers in the child domain, and from
the child domains, configure a forwarder back to the Forest Root DNS
servers. This will allow resolution throughout the forest. From the Forest
Root, configure a forwarder to your ISP's. This will allow all forest
members efficient Internet resolution.

Have you read the AD Migration Cookbook or any design criteria for AD?
Chapter 4 - Active Directory Design:
http://www.microsoft.com/technet/tr...change/exchange2000/reskit/part2/c04names.asp

AD Architecting a Secure and Scalable Infrastructure:
http://www.windowsitlibrary.com/Documents/Book.cfm?DocumentID=617

Active Directory:
http://www.microsoft.com/technet/prodtechnol/windows2000serv/plan/int2ksrv/intro11.asp

Domain Migration Cookbook - Index and Cover:
http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/cookbook/cookintr.asp

- the DNS servers will be Windows 2000 based
- we will use primary/secondary zone types as no AD exists
(yet)

Keep in mind that AD Integrated zones, in Win2k, will only replicate with
other DCs of the same name domain only since the zone data is stored in the
DomainNC partition of that specific domain and not in the Config or Schema
containers.. W2k3 gives allows you to replicate your zone info to other
domain application partitions in a forest.

- we will have two DNS servers per city (1 * PRI, 1 * SEC)

Good for fault tolerance.

- Forwarders and root hints will be configured on each
server

See above about child delegation. Be careful if you do it otherwise. A
possible forwarding loop may occur and you wouldn't want that, besides the
fact that it may not be able to support forest wide resolution, which AD
requires for proper replication of forest data.

- DHCP will register DNS on behalf of clients that aree
unable to perform dynamic updates


THE FUTURE:
- plan to upgrade to Windows 2000/3 infrastructure within
6-12 months, creating one single forest with multiple
domains.

That was your previous proposal to have mutliple domains in one forest. Tell
you what, since W2k3 is out now, it's better off doing it now in one shot
instead of the headaches of leapfrogging.

- Plan to use AD-integrated DNS zones (for security and
replication topology benefits)

See my previous comments on this above.

MY QUERIES:
- Would it be possible to upgrade these DNS servers to use
AD-integrated zones after running DCpromo?

Yes, with stipulations in W2k as already mentioned.

Anything I need
to be aware of when doing that? (apart from the creation
of '.' root zones)

If the servers have Internet access, DCPROMO will NOT create the root zone.
You'll need to delete them if you don't have current access to allow
forwarding. If in a Proxy or ISA network, then I would still delete them to
allow forwarding to the Root in a child delegation scenario.

- When considering NetBIOS, if a comp (compA) is in one
domain and another comp (compA) is part of a different
domain but both domains are part of the same forest, would
the NetBIOS registrations clash?

Yes, as long as NetBIOS resolution is supported across the infrastructure.

If so, which other
security principles should I consider in order to preserve
uniqueness?

Use a regional identifier as a prefix for the names.

- Would this DNS infrastructure support AD successfully
bearing in mind that it may not reflect the AD design
exactly?

Yes, provided you go with delegation.That is the most common and easiest
method. Otherwise, who knows, depending on what you do.

- Should the TLD change, would it be recommended to start
a completely new namespace using separate DNS servers, and
gradually phase the old ones out?

Once you name your Root, that;'s it. It can;t be changed in W2k. In W2k3 it
can. however with stipulations and limitations. Plan this out right the
first time. Why would it change anyway? Usually a stable company offers
stable naming convention. If you go with an empty root, you can change the
child domains by adding/substracting domains, but with added adminstration
overhead.

- Again, should the TLD change I assume all clients would
have to have their primary domain suffix manually altered?

It's not that easy. You're talking about a complete reinstall or revamp.
Plan carefully.

could I push out a new primary DNS domain suffix via
Windows 2000 DHCP Server to the clients?

Thru GPO or scripting, yes. But for what you're asking, it;s NOT that
simple.

- Ideally speaking, should the DNS namespace be designed
around the network infrastructure?

AD's DNS namespace must reflect the AD domain hierarchy, not the physical
topology.

Sorry for the amount of info here and thanks for taking
the time to read this.

Any help or advice would be gratefully received,

Regards
..

I think you have some things to ponder and rethink here. With all due
respect, have you attended any classes or courses on this? I think with this
monumental task at hand, that it would be highly beneficial for you to do
so. There are three courses that would be highly beneficial that I can
suggest based on W2k AD. First one is MOC (MS Official Curriculum) #2154
Implementing and Administrating an AD Infrastrucure, and the other is MOC
#1561, designing an AD Infrstructure, and the other is 2010, Migrating NT4
to W2k. If you were to take these 3 courses, 99% of your questions will be
answered.


--
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

 

[Steve Duff [MVP]]

To Ace's excellent suggestions, let me add: the MS Press book:

"Building Enterprise Active Directory Services: Notes from the Field".

Steve Duff, MCSE
Ergodic Systems, Inc.

 

[Ace Fekay [MVP]]

To Ace's excellent suggestions, let me add: the MS Press book:

"Building Enterprise Active Directory Services: Notes from the Field".

Steve Duff, MCSE
Ergodic Systems, Inc.

Thanks Steve. I hoped I covered all the basis on this one.

That MS book is a great book! Points out alot of stuff that have been
discovered in production environments since the product's release over 3
years ago.

Cheers!

Ace