AD DNS Problem with 2 Domains

Posted on 2007-10-10
Last Modified: 2013-12-05
I have 2 Windows 2000 AD DOMAINS, and, running on the same IP subnet. The domains are setup with a functioning trust.

Both domains use AD integrated DNS that's hosted on AD servers in the domain.

Zone transfers are enabled for servers listed on the name servers tab. Secure updates are enabled. All DNS records function and replicate to DNS servers in (this includes all records for the zone.)

I'm now setting up a new subnet that will extend the domain to a new site.
IP routing is functioning between the sites, and there are no FW policies in place that block traffic between the subnets. I've also setup a new site & subnet in AD Sites & Svcs.

Only will be setup at the new site, so I've setup an additional DC for on the remote subnet, listing the IP address as the primary DNS server before running DC promo. DNS server was installed on the new DC but not configured before running DCpromo.

After running DCPromo and rebooting, all seems well (including AD replication) with the exception of DNS.

When I open the DNS snap-in I see the zones for and, but none of the records have replicated from the DNS servers. Only the name server and host records for the domain controllers are listed.

Dcdiag gives me no errors. There are no errors in the event log.
Repadmin /showreps shows successful attempts for inbound neighbors, and displays nothing under outbound neighbors.

Could this be some kind of permission problem between the DNS servers on and the domain/DNS servers in

To test, I tried setting up AD integrated DNS on one of the other servers on the existing subnet, and I get the *same* result.

When I setup an additional DC with DNS on the new subnet, DNS works perfectly. All records are displayed and replicated. This eliminates an IP routing/firewall problems.

This definitely has something to do with the fact that the primary AD DNS for is hosted on the DCs.

Are there permissions that I can set on the DC to make this work or is this setup just wrong?

Should I setup a standard secondary DNS in the new subnet instead of AD integrated? was originally setup to use's DNS server because all machines are on the same subnet and share DHCP configuration.
Is there a way to migrate's DNS to a AD server while still sharing the same subnet/DHCP configuration?

Thanks for any help!
Question by:tdelia
    LVL 70

    Expert Comment

    by:Chris Dent

    Your new DC on will only replicate AD Data from other DCs within

    Do the servers for have the full set of records on the primary network?

    If so, how? Zone Transfers?

    LVL 1

    Author Comment

    Thanks so much for responding.

    I think this is the crux of the problem, but don't know how to work my way around or out of it:
    "Your new DC on will only replicate AD Data from other DCs within"

    The servers still point to the DNS server. I did this because DCHP on this network directs clients in both domains to the same primary/secondary DNS servers.

    None of the DCs are running DNS servers -- I believe that's why I'm not seeing the full set of records when I start a DNS server on the servers. I only see the and zones and server records.

    Everything has worked well up to this point... I assumed that because the original AD setup of allowed me to use "AD integrated" on the server that I was OK.

    So how do I work my way around/out of this given that all machines on this subnet use the same DNS settings? Can I transfer the zone to DNS servers on the domain, and still have all clients point to the DNS server?

    Thanks again!
    LVL 70

    Accepted Solution


    That makes sense.

    AD Integrated is just a storage and replication mechanism for DNS. It means the zone data is stored in the directory. You can see that under AD Users and Computers if you turn on Advanced Features and look under System then MicrosoftDNS.

    You should, hopefully, see that the DNS Data held in is fairly limited as it only exists in the AD Domain

    So you have a few choices:

    1. Have all Servers and Clients in the remote site use the Main Site's DNS Servers for name resolution.

    This is perhaps the easiest solution, but gives no independence to the remote site. If that's a requirement we should move on.

    2. This option is more complex, we have to go back to a more traditional approach to the DNS configuration. This has it's own pitfalls which we can cover in a moment, the main one being that Secondary zones are Read Only.

    Main Site:

     - Install the DNS Service onto's DCs
     - Add a Primary AD Integrated Zone for to's DCs
     - Change's DCs to refer to themselves for DNS Resolution
     - Add a Secondary Zone to each of's DCs for
     - Remove from the DCs for
     - Add a Secondary Zone to each of's DCs for

    Remote Site:

     - AD Replication will take care of the addition of the zone for
     - Add a Secondary Zone to each of the DCs for
     - Change's DCs to refer to themselves for DNS Resolution

    While this configuration is technically correct it does leave client updates a little dead. As clients in the main site will still be referring to the DCs for they won't be able to add records for themselves into

    Probably best if I pass this back to you so you can read through and see what you think at this stage.

    LVL 1

    Author Comment

    I definitely need to make sure that the remote site can function if there's a connectivity problem. That's kind of where this all began.

    Client updates might also be a problem.

    Would it be possible to setup a DC/DNS server at the remote site, but with a secondary zone to and from the server? Not sure if this is possible because of a conflict with the namespace...

    If the DNS server would allow it, I could also setup a secondary zone for (from the remote site) on the server. All users at the primary site could still point to and make client updates to the DNS server. Users at the second site would point to the site 2 server and update it. Each site could read the other site's records. In that scenario, would DNS check the secondary zone if it didn't find a record in the primary AD integrated zone with the same name?

    LVL 70

    Expert Comment

    by:Chris Dent

    >Would it be possible to setup a DC/DNS server at
    > the remote site, but with a secondary zone to
    > and from the server?

    Yes. But you would have to delete the zone from that server (and out of's AD entirely).

    Remember that using Secondary zones means they would be Read Only. Clients and Servers on that site would be unable to perform updates against the Read Only zones.

    Updates are never referred, so anything on the remote site would simply fail to update DNS. That includes the Domain Controller itself which gets in the way if you use Aging / Scavenging in DNS at all.

    If using Secondary Zones in that fashion you should ensure that the Expire interval in the SOA (Start of Authority) Record for the zone is sufficiently high that the Secondary zone won't disappear should the connection drop.

    LVL 1

    Author Comment

    Thanks, Chris. You've been incredibly helpful.

    Now that I know the setup was functioning as it should, I think I may just expand upon what's already in place.

    It will cost me a machine, but if I setup a DC/DNS server at the remote site, I can point the DNS clients (and AD servers) to them (as we do at the primary site.)  
    This would provide AD replication, client updates, and fault tolerance should I lose the connection between sites.

    LVL 70

    Expert Comment

    by:Chris Dent

    That would work very well indeed :)


    Featured Post

    What Security Threats Are You Missing?

    Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

    Join & Write a Comment

    Have you considered what group policies are backwards and forwards compatible? Windows Active Directory servers and clients use group policy templates to deploy sets of policies within your domain. But, there is a catch to deploying policies. The…
    This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…
    This tutorial will walk an individual through the process of configuring their Windows Server 2012 domain controller to synchronize its time with a trusted, external resource. Use Google, Bing, or other preferred search engine to locate trusted NTP …

    730 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    17 Experts available now in Live!

    Get 1:1 Help Now