Force update of reverse lookups on AD DNS?

  • Thread starter Thread starter geek
  • Start date Start date
G

geek

Active Directory, 2003 interim.

We've got a number of sites and subnets.

Our main domain and reverse lookup zones are all AD integrated,
allowing both secure and unsecure updates. DHCP is *not* running on
Windows, but on our legacy UNIX servers.

We're in the process of migrating to new subnets as we were purchased
and need to integrate our new networks.

All of the PCs (all XP boxes) updated their forward lookups fine.
However, most of them do not have reverse lookups, even though the zone
is there. Many of them may have migrated before the reverse lookup
zones were there.

However, an ipconfig /updatedns on the client doesn't seem to do
anything to update the reverse lookups! I guess since the IP isn't
changing, it doesn't really do anything?

Is there any way to force AD, or the client box, to populate the
reverse lookup zone?

thanks!
 
Hi,



would you provide us with a basic info about the IP subnet(s) on your
network(s) and name(s) of you reverse look-up zone(s), where you face the
problems?



There are several ways you can register PTR records: One of them is "Group
Policy" described in this article http://support.microsoft.com/kb/294785/
or here http://support.microsoft.com/kb/300684/ . Another one is usage of
Windows based DHCP server with option "... register PTR records ... "
enabled. But, at first, I'd check the names of the reverse look-up zones,
cose if the PCs successfully register the A record, it should based on own
IP address automatically attempt to register PTR record in the corresponding
zone .



Regards

Dominik Zurek
 
Dominik - thank you for your reply.
would you provide us with a basic info about the IP subnet(s) on your
network(s) and name(s) of you reverse look-up zone(s), where you face the
problems?
Click to expand...

We have a forward lookup zone (unfortunately I need to obfuscate, I
apologize):

domain.com

There are quite a few subnets on which we have XP boxes. One of them is
10.206.80.0/22 (so 10.206.80.0 - 10.206.83.255). I couldn't find a way
to do supersets of reverse lookups without including all of 10.206.X.X,
so I have seperate reverse lookups for each /24.

One of the DHCP ranges assigned IPs in 10.206.82.X.

There is, for example, a PC named eng-chrisk-hp at 10.206.82.185 (an XP
SP2 box).

There is a reverse lookup zone 82.206.10.in-addr.arpa.

Both forward and reverse zones are configured to be AD integrated and
to allow both secure and nonsecure updates.

The box registered fine in the forward lookup as
eng-chrisk-hp.domain.com.

However, there is no entry in the reverse lookup for this PC. I have
run ipconfig /registerdns on the PC itself and the reverse lookup is
not created.

*Some* reverse lookups in that zone were created properly... about a
dozen. Otherwise it is empty.
There are several ways you can register PTR records: One of them is "Group
Policy" described in this article http://support.microsoft.com/kb/294785/
or here http://support.microsoft.com/kb/300684/
Click to expand...

Thanks for the pointer.

I did create a GPO and applied it to all workstations with the
following settings:

Computer Configuration ->
Administrative Templates->
Network/DNS Client->
- Dynamic Update = Enabled
- Register PTR Records = Enabled
-- Register PTR Records = Register
- Registration Refresh Interval = Enabled
-- Seconds = 1800

Group policy modeling indicates that these settings should be set for
his PC, eng-chrisk-hp. However, in the few days these settings have
been active, his PC still has not registered the PTR record.
. Another one is usage of
Windows based DHCP server with option "... register PTR records ... "
enabled. But, at first, I'd check the names of the reverse look-up zones,
cose if the PCs successfully register the A record, it should based on own
IP address automatically attempt to register PTR record in the corresponding
zone .
Click to expand...

Well, we currently use a UNIX DHCP server. I'm hoping that can
continue, but if DNS won't work without it, then maybe we'll have to
migrate.

Any other suggestions?

thanks
 
Back
Top