Domain controller unable to dynamically add/update PTR record
Smith, William E. (Bill), Jr.
Bill.Smith at jhuapl.edu
Wed Jan 26 14:03:06 UTC 2005
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
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
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 188.8.131.52#2772:
>updating zone '
>dom1.jhuapl.edu/IN': update failed: 'RRset exists (value dependent)'
>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
More information about the bind-users