problem with registering cluster's records in DNS

Due to a lot of stale records in my DNS servers, I recently decided to turn
on aging/scavenging on my DNS servers (with refresh interval 2 days, and non
refresh interval 13 days, DHCP lease is 15 days). Several hours after turning
on aging on my forward/reverse lookup zones in my cluster servers' logs I
started getting warnings that their A record cannot be registered in DNS
(The system failed to register host (A) resource records (RRs) for network
adapter with settings: ... (event 11116)), followed by the sequence of
warnings: "The registration of DNS name FQDN for resource 'SQL Network
Name(****)' over adapter 'Public Team' failed for the following reason: DNS
signature failed to verify " - event 1119, every 10 minutes. After 2 days my
cluster group failed (with the error message Cluster resource 'Cluster Name'
in Resource Group 'Cluster Group' failed - event 1069).
Does this mean that turning on aging on my DNS zones has caused all this mess?
Is there anything special to be reconsidered regarding cluster servers' DNS
settings before implementing aging/scavenging in my DNS zones?
Before turning on aging on DNS servers, cluster's A and PTR were statically
created in both DNS zones, and they haven't been deleted all the time. After
we turned off aging and brought online Cluster group resource, we noticed
that for some cluster records time stamps appeared (for several A and PTR
records), and even if I try to uncheck the option "delete this record when it
becomes stale" after some time it becomes checked (this happenes only on one
of our 4 DNS servers).
So what shoud I do regarding DNS settings in the cluster servers in order to
have DNS aging/scavenging implemented without consequences?

Hi Niokola,

Try http://technet.microsoft.com/en-us/l.../cc773512.aspx .

Perhaps that helps?.

Cheers!
Jens

"NikolaRS" wrote:

> Due to a lot of stale records in my DNS servers, I recently decided to turn
> on aging/scavenging on my DNS servers (with refresh interval 2 days, and non
> refresh interval 13 days, DHCP lease is 15 days). Several hours after turning
> on aging on my forward/reverse lookup zones in my cluster servers' logs I
> started getting warnings that their A record cannot be registered in DNS
> (The system failed to register host (A) resource records (RRs) for network
> adapter with settings: ... (event 11116)), followed by the sequence of
> warnings: "The registration of DNS name FQDN for resource 'SQL Network
> Name(****)' over adapter 'Public Team' failed for the following reason: DNS
> signature failed to verify " - event 1119, every 10 minutes. After 2 days my
> cluster group failed (with the error message Cluster resource 'Cluster Name'
> in Resource Group 'Cluster Group' failed - event 1069).
> Does this mean that turning on aging on my DNS zones has caused all this mess?
> Is there anything special to be reconsidered regarding cluster servers' DNS
> settings before implementing aging/scavenging in my DNS zones?
> Before turning on aging on DNS servers, cluster's A and PTR were statically
> created in both DNS zones, and they haven't been deleted all the time. After
> we turned off aging and brought online Cluster group resource, we noticed
> that for some cluster records time stamps appeared (for several A and PTR
> records), and even if I try to uncheck the option "delete this record when it
> becomes stale" after some time it becomes checked (this happenes only on one
> of our 4 DNS servers).
> So what shoud I do regarding DNS settings in the cluster servers in order to
> have DNS aging/scavenging implemented without consequences?

Dear Jens, thank you very much for your reply. I've just read the article,
but what is strange is that my cluster records have never been deleted, it
seems that after turning on DNS aging there was a problem with registering
(refreshing) cluster's A records in DNS, which eventually led to cluster
group failure. Does that mean that DNS aging/scavenging shouldn't be
implemented in my environment or should I do something special in cluster DNS
TCP/IP settings before I implement DNS (server)aging/scavenging?

"Jens Imsan" wrote:

> Hi Niokola,
>
> Try http://technet.microsoft.com/en-us/l.../cc773512.aspx .
>
> Perhaps that helps?.
>
> Cheers!
> Jens
>
> "NikolaRS" wrote:
>
> > Due to a lot of stale records in my DNS servers, I recently decided to turn
> > on aging/scavenging on my DNS servers (with refresh interval 2 days, and non
> > refresh interval 13 days, DHCP lease is 15 days). Several hours after turning
> > on aging on my forward/reverse lookup zones in my cluster servers' logs I
> > started getting warnings that their A record cannot be registered in DNS
> > (The system failed to register host (A) resource records (RRs) for network
> > adapter with settings: ... (event 11116)), followed by the sequence of
> > warnings: "The registration of DNS name FQDN for resource 'SQL Network
> > Name(****)' over adapter 'Public Team' failed for the following reason: DNS
> > signature failed to verify " - event 1119, every 10 minutes. After 2 days my
> > cluster group failed (with the error message Cluster resource 'Cluster Name'
> > in Resource Group 'Cluster Group' failed - event 1069).
> > Does this mean that turning on aging on my DNS zones has caused all this mess?
> > Is there anything special to be reconsidered regarding cluster servers' DNS
> > settings before implementing aging/scavenging in my DNS zones?
> > Before turning on aging on DNS servers, cluster's A and PTR were statically
> > created in both DNS zones, and they haven't been deleted all the time. After
> > we turned off aging and brought online Cluster group resource, we noticed
> > that for some cluster records time stamps appeared (for several A and PTR
> > records), and even if I try to uncheck the option "delete this record when it
> > becomes stale" after some time it becomes checked (this happenes only on one
> > of our 4 DNS servers).
> > So what shoud I do regarding DNS settings in the cluster servers in order to
> > have DNS aging/scavenging implemented without consequences?