The KB he linked should be rolled in to 2003 SP1 based on the date. Thanks, Brian Desmond br...@briandesmond.com
c - 312.731.3132 From: Sean Martin [mailto:seanmarti...@gmail.com] Sent: Thursday, August 05, 2010 6:05 PM To: NT System Admin Issues Subject: Re: Cannot delete a PTR record, AD integrated DNS 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<mailto: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<mailto:br...@briandesmond.com> c - 312.731.3132 -----Original Message----- From: mb [mailto:midphan12...@gmail.com<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<mailto:br...@briandesmond.com>> Sent: Thursday, August 05, 2010 4:09 PM To: "NT System Admin Issues" <ntsysadmin@lyris.sunbelt-software.com<mailto: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<mailto:br...@briandesmond.com> > > c - 312.731.3132 > > > -----Original Message----- > From: mb [mailto:midphan12...@gmail.com<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<mailto:mailvor...@gmail.com>> > Sent: Thursday, August 05, 2010 2:00 PM > To: "NT System Admin Issues" > <ntsysadmin@lyris.sunbelt-software.com<mailto: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<mailto: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/> ~
