Re: Pointer not updated in Root DNS

"travelfreak" <> wrote in message
news:...
>
> ok, some more infos:
>
> on the DNS Server in the subdomain i have 2 Reverse Lookup Zones:
> - 172.10.120.x Subnet
> this is the local Reverse Zone with all the Pointers set (note, there
> are no DHCP Clients, only Servers with static IPs in it). The zone is
> set to: Replicate to all the DCs in the Domain
>
> - 172.x.x.x Subnet with folders for the subnet 10-120/121, 12-120/121
> (and some more subnets)
> this zone was replicated from the Root domain. Here in the 120 Subnet
> Folder the Reverse Pointers are missing. This zone is set to replicate
> all over the forest. For some reasons this zone is called
> 172.in-addr.arpa on the root DNS.
>
> I hope its clearer now. So iam not even sure, if those pointers really
> set automaticly in the root dns zone, or have to set manually for static
> IPs.
>
> cheers,
> Marco


It appears there's an overlap or conflicting zone going on, that is if I
read your post correctly.

Just to make sure I understand, you stated there is a zone called
172.10.120.x
Replication scope = DomainDnsZones application partition.

Then you said there is a zone for:
172.x.x.x Subnet, which includes numerous subnets under 172.x.x.x.
replication scope = ForestDnsZones application partition.

If this info is correct, then the first zone you have, 172.10.120.x, is
actually a subset of 172.x.x.x. Therefore, this causes two things: 1) A
Duplicate Zone in the AD database, and 2) Conflicting zone in the AD
database.

My suggestion is to delete the 172.10.120.x zone, and allow the 172.x.x.x
zone to take care of the forest needs for the reverse zone. All machines in
the 172.10.120.x subnet will register into 172.x.x.x automatically.

However, once you delete it in the console, it doesn't mean it's deleted in
the AD database. This is due to replication as well as possibly that the
zone itself may have been removed, but you may see zones inthe AD database
that start with "CNF...." which means it's a conflicting entry.

To read more on how to determine if there are dupe or conflicts, and how to
clean up the AD database from this data, please read my blog in the
following link.

Using ADSI Edit to Resolve Conflicting or Duplicate AD Integrated DNS zones
http://msmvps.com/blogs/acefekay/arc...dns-zones.aspx

Keep in mind, and this should be obvious, is that there is only one
ForestDnsZones partition, however there are one DomainDnzZones partition for
each domain that exists, including the forest root domain. Therefore when
checking the domainDnsZones partition, you must check EACH domain's
partition,including the forest root domains's partition to make sure all are
clean

Ace

"travelfreak" <> wrote in message
news:...
>
> Ace, youre right
>
> In some dns servers it seems, that the Reverse Lookup Zone was created
> manually in addition to the forest wide AD integrated Reverse Lookup
> Zone.
> So the scope of the manually created zone was only domain wide. I just
> checked some other DNS Server without the zone and there the pointers
> are set in the Forest wide Reverse Lookup Zone. So i have to delete the
> Domain Reverse Lookup zone. The Pointers should register itself at next
> reboot?
>
> Just tested it in a demo lab by deleteing the domain wide reverse
> lookup zone, forcing replication. The forest wide Reverse Lookup Zone
> from the root domain was replicated to the subdomain DNS Server then.
>
> cheers,
> Marco


Good to hea! Replication scopes and overlapping, as you've seen, have to be
taken into account.

Did you double check with ADSI Edit to make sure there's nothing else that
needs to be cleaned up?

Ace