Domain controller unable to dynamically add/update PTR record

[Smith, William E. (Bill), Jr.]

I think have resolved this problem.  Without going into many specifics
since it turns out that it wasn't a BIND issue per se, I'll just note
that it was a configuration issue within QIP that once enabled addressed
the problem. =20

- Bill=20

-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
Behalf Of Kevin Darcy
Sent: Monday, January 24, 2005 8:39 PM
To: bind-users at isc.org
Subject: Re: Domain controller unable to dynamically add/update PTR
record

Smith, William E. (Bill), Jr. wrote:

>In our environment, we have allowed Windows domain controllers to=20
>dynamically update their A & PTR records within the Windows only=20
>domains.  I'm currently troubelshooting a problem where a couple DC's=20
>register their A records fine but fail when trying to do their PTR=20
>records.  After sifting through the various server logs, I came across=20
>the following error which I believe is at the core of the problem since

>I had a Windows admin do an ipconfig /registerdns on the DC to force it

>to re-register its records and noted that this error appeared within=20
>seconds after that attempt.
>update.log:Jan 24 11:45:24.901 info: client 128.244.198.27#2772:
>updating zone '
>dom1.jhuapl.edu/IN': update failed: 'RRset exists (value dependent)'
>prerequisit
>e not satisfied (NXRRSET)
>
>While it's clear that the problem is related to a prerequisite not=20
>being met, it's not clear to me what exact prerequisite has failed to=20
>be satisifed.  Can anyone shed any light here?  I know this is a common

>problem with DHCP clients but DHCP is not involved here.  FWIW, the=20
>primary DNS server where these updates are coming into is a QIP DNS=20
>server.  I'll provide any further info as needed/requested.
>
Hmmm... That's a failure of the *forward* update, because it would have
been redundant (value-dependent NXRRSET). My guess would be that
occurred when you manually did "ipconfig /registerdns" after the
original failure, because, as you said, the forward update worked on the
original try, just not the reverse update.

As for the root cause of why the reverse-record updates are failing, I
would check the usual suspects, e.g. the appropriate allow-update
statement on the reverse zone, correct info in the SOA record of the
reverse zone, etc. What happens if you try to add a record to that zone
via nsupdate?

=20

                                       - Kevin