I think Hunter is on the right track. I seem to recall having to run through a similar process for a similar issue.
- Sean On Thu, Aug 5, 2010 at 1:53 PM, Brian Desmond <br...@briandesmond.com>wrote: > So is the record on all your DCs or just one? Are you sure the reverse zone > is replicating in the ForestDnsZones NDNC? > > What I would suggest doing is turning on auditing for this subtree in AD > and enabling DS Access auditing and then you can figure out what's causing > it to get created. > > Thanks, > Brian Desmond > br...@briandesmond.com > > c - 312.731.3132 > > > -----Original Message----- > From: mb [mailto:midphan12...@gmail.com] > Sent: Thursday, August 05, 2010 4:25 PM > To: NT System Admin Issues > Subject: Re: Cannot delete a PTR record, AD integrated DNS > > There is no corresponding A record for this PTR record. There is however a > different machine at that IP with A & PTR records, and this ghost PTR record > is causing a little bit of grief to the folks that manage this other system. > The A record that originally existed for this ghost PTR record, that's been > gone a couple of years at least. > > Was looking for zone files just on a hunch. I do understand that being AD > integrated, this is stored in AD, but in my original note I mentioned that I > used ADSIEdit to look in ForestDNSZones, and this ghost PTR record does not > exist there. So it's somehow local to any domain controller (because it > reappears faster than it could be replicating back), and it's not where it > should be within the AD database. > > I'm missing something. > > > -------------------------------------------------- > From: "Brian Desmond" <br...@briandesmond.com> > Sent: Thursday, August 05, 2010 4:09 PM > To: "NT System Admin Issues" <ntsysadmin@lyris.sunbelt-software.com> > Subject: RE: Cannot delete a PTR record, AD integrated DNS > > > There are no zone files there because your zones are stored in AD. > > > > What's the corresponding A record for this represent? > > > > Thanks, > > Brian Desmond > > br...@briandesmond.com > > > > c - 312.731.3132 > > > > > > -----Original Message----- > > From: mb [mailto:midphan12...@gmail.com] > > Sent: Thursday, August 05, 2010 4:07 PM > > To: NT System Admin Issues > > Subject: Re: Cannot delete a PTR record, AD integrated DNS > > > > This is interesting. > > > > Checked \system32\dns on a few of our domain controllers, I'm not > > finding any zone files with any data in them. I haven't checked all > > the domain controllers. One thing though - on any DC, if I delete > > this record and then immediately refresh the zone, that record is > > right there again, like it's coming from something local or I didn't > > actually delete the record (though I'm not seeing any kind of error > dialogue). > > > > Checked properties on this record. There's no timestamp, it's a > > static record. I suppose that means it could never become stale - > > thought about trying the "Delete this record when it becomes stale" > > checkbox. Just because I've tried everything I know that makes sense. > > > > I could interrupt DHCP if I do it late on a weekend night. And it's > > worth a try. But I just keep going back to the fact that this record > > reappears instantly, as fast as I can delete/refresh, that record is > > there, on any domain controller (all our DC's are running DNS). So > > I'm thinking this isn't replicating from another DC or being > > dynamically created from a DHCP server. > > > > > > -------------------------------------------------- > > From: "Ben Scott" <mailvor...@gmail.com> > > Sent: Thursday, August 05, 2010 2:00 PM > > To: "NT System Admin Issues" <ntsysadmin@lyris.sunbelt-software.com> > > Subject: Re: Cannot delete a PTR record, AD integrated DNS > > > >> On Thu, Aug 5, 2010 at 2:38 PM, mb <midphan12...@gmail.com> wrote: > >>> I've tried through ADSIEdit, > >>> and interestingly, this record does not exist there. It does show > >>> up in the DNS console as a 'static' record, but I'm at a loss where > >>> it's coming from. > >> > >> Check %SystemRoot%\system32\dns\ for any files which might contain > >> the offending record. Some vague notion deep in the dusty reaches of > >> the back of my mind says there's a thing where MS-DNS will > >> automatically load/merge records from (some of?) those files even if > >> it's AD integrated. > >> > >> Open the MS DNS MMC GUI. Enable "Advanced" features (under "View" > >> menu). Select the offending record and bring up properties. What's > >> the time stamp? Is it something recent or wicked old? Check the > >> "Security" tab. See if there are any funky permissions that might be > >> restricting things. > >> > >> If you can, try stopping your DHCP server service(s) and then > >> deleting the record, to see if it comes back without DHCP running. > >> It's the DHCP service which actually issues the DDNS UPDATE command > >> for AD clients. > >> > >> -- Ben > >> > >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > >> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > >> > >> > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ < > http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
