2

I've read a few article on AD-integrated dns zones, including an excellent DNS Stub Zones in Windows Server 2003, but I am still uncertain on grasping the whole picture:

1)

Why didn't AD (Active Directory)-integration provide possibility of secondary zones AD-integration in order to be replicated through AD (vs. why were stub zones were provided with AD-integration possibility)?

2)

Why did not MS provide synchroization for delegated zone records?

I.e there is no granularity and configurability in stub zones (stub zone contain all the NS records for a specified zone)

Added later: Stub zones are similar in functionality to delegation, but stub zones include necessarily references to all dns servers in the referenced domain while delegation not. Is delegation more granular or it unnecessarily requires more administration efforts?

3)

Why do we possibly need secondary zones at all?

if redundancy is provided by multi-master AD-integrated primary zones?

4)

Does multiple AD-integrated master domain controllers provide redundancy against failure of a computer with one of AD-integrated DCs? In other words, does each of domain controllers contain a replica of AD (and AD-integrated dns) databse?

5)

Can't a secondary zone (in case of primary zone computer failure) be copied and one of copy be promoted to primary zone?

6)

  • "Also, while most DNS servers can be configured to prevent zone transfers to secondary zones from occurring, stub zones request only SOA, NS, and A records for name servers, all of which are provided without restriction by any name server since these records are essential for name resolution to function properly"
    • -

Does it mean that DNS servers cannot be configured to prevent transfers to stub zones?

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
Gennady Vanin Геннадий Ванин
  • 677
  • 3
  • 12
  • 28

1 Answers1

4
  1. The way Active Directory's multiple-master replication works is quite different from the DNS protocol's primary/secondary replication model. So a secondary copy of the records is truly "secondary", in that it is always refreshed from the master.
  2. Not quite sure what you mean... Can you clarify?
  3. We need secondary zones because that's the way every other DNS server in the world works, including the industry standard one, BIND. Many companies have their BIND services running on large UNIX servers, and the Windows AD/DNS servers just have a secondary copy.
  4. Yes, each domain controller keeps a full copy of all the AD & DNS data (with some minor exceptions--read up on Global Catalogs and FSMO roles).
  5. Sort of... there's no built-in command to do this, but you can use BIND tools and a copy of the data from the secondary to fill out a new primary zone. It's not advisable, though.
  6. No, you still have full control over zone transfer security. The quoted line is saying that the SOA, NS and A-records which point to the zone's primary & secondary name servers are always available for all clients to read, which means that they could use the info to create their own stub zone if they wanted to.
ewall
  • 1,054
  • 3
  • 13
  • 23
  • Tanks for answers. I expanded my question 2) Concerning your answer to my 1): "So a secondary copy of the records is truly "secondary", in that it is always refreshed from the master" - to which of the masters? – Gennady Vanin Геннадий Ванин Jul 09 '10 at 18:36
  • 1
    Ah, yes... In the original DNS protocol, there is only *one* master/primary server. Microsoft's implementation of DNS with Active Directory makes any domain controller act like a primary DNS, so you could create a secondary from whichever is the closest/fastest/whatever domain controller. – ewall Jul 09 '10 at 21:58
  • 1
    @ewall, it's not just Microsoft's implementation, ISC-BIND servers can be backed by LDAP too; then LDAP's replication takes care of the replication process. Also, to #4, there's also RODCs now too. – Chris S Aug 23 '10 at 17:37