This morning I noticed that some of our network elements are using IPs that have more than one PTR associated with them. This isn’t a huge problem, but it was exposed to us because the DNS record in our monitoring system would just randomly pick a PTR when the element was rediscovered. Because these other PTRs were often just out of date cruft, having the old names show up in monitoring was confusing. I took this as a quick project to run through the IPs and resolve the duplicates. The fact that I’m now writing a blog post about it is a pretty good spoiler that it wasn’t as simple as I thought it was going to be.
\n
\nI went through all the IPs in question (and then also all IPs in the same \/24s as those IPs) and came up with a list of about 15 IPs that I changed. I deleted the PTRs with no matching A records, typed up a summary for my group, and was just about to hit send when I did one more check of my work and found that some of the PTRs I had deleted were back. OK. I deleted them again, and they came back again. I reloaded. I refreshed. I manually incremented zone serials. Nothing.<\/p>\n
A quick Google<\/a> showed that it is\/was a known problem that the DNS snap-in cannot delete PTR records with upper-case characters in them (this page<\/a>, leading to this Microsoft KB article<\/a>, were the key hits). This seemed like a likely culprit. All of the records I was still having problems with did contain mixed case characters, and all the ones I had successfully deleted were all lower case. The only thing that confused me was that the KB item was specifically for Windows Server 2003. I was using the snap-in locally from Windows7, and I also had tried it directly from one of the DNS servers running Windows Server 2008, and they all had the same problem.<\/p>\n At this point I tried renaming the PTR to be lower case and then deleting it, but that was a spectacular failure. It renamed in the snap-in, but querying the server then showed three records instead of two, with the one I renamed showing up twice, both with the same upper case characters, even though I had renamed it with lower case. Eesh. I counted myself lucky that when I deleted the lower case version in the snap-in it put me back to where I was when I started (two PTRs, one good, one bad but undeleteable due to upper case characters).<\/p>\n Back to the Goog<\/a>! This time I came across this interesting post<\/a> about programmatically lower-casing all PTRs. It wasn’t directly what I needed (though I’m saving it for later review), but it did introduce the idea of using Since I was already logged directly into one of the DNS servers with my admin credentials, I decided to just run the command there. A little bit of experimentation and I ran the following (yes, 10.1.1.1 really was the IP):<\/p>\n Well crap. I relaunched CMD as an even-more-admin-ish account and got the same response. I tried deleting a PTR that didn’t have upper case characters and got the same response, so it wasn’t the same problem. I tried the following, which suggested that I was using the right syntax and it really was a permission issue:<\/p>\n One final trip to Google<\/a> and I turned up this post<\/a> describing the same “what do you mean access denied, I’m an admin” experience I was having. Following the suggestion to always use an FQDN for the server, I still had the same problem. I then tried it with the IP of the server and it worked:<\/p>\n Here’s the kicker though: When I picked an IP I accidentally picked the IP from a different DNS server (oops). After a bit of experimentation I found that I could use nodename, FQDN, or IP of a different<\/strong> server and it would work, but if I tried to use “.”, nodename, FQDN, or IP of the local server, it would always fail with the ERROR_ACCESS_DENIED error. Fun!<\/p>\n So now I can delete the offending PTRs which is good, but that command also deletes the good PTR, which is not so good. Fortunately I can use After running this I saw what I expected in the DNS snap-in (just one record for 10.1.1.5, pix-515-2.example.com). This would be pretty easily scriptable but it’s 13 more PTRs. Maybe next time.<\/p>\n","protected":false},"excerpt":{"rendered":" This morning I noticed that some of our network elements are using IPs that have more than one PTR associated with them. This isn’t a huge problem, but it was exposed to us because the DNS record in our monitoring … Continue reading The Solution! (almost)<\/h1>\n
dnscmd.exe<\/code> to delete the PTRs that the snap-in won’t touch.<\/p>\n\r\nC:\\>dnscmd . \/RecordDelete 1.1.10.in-addr.arpa. 1 PTR\r\nAre you sure you want to delete record? (y\/n)y\r\n\r\nCommand failed: ERROR_ACCESS_DENIED 5 0x5\r\n<\/pre>\n
\r\nC:\\>dnscmd . \/RecordDelete 10.in-addr.arpa. 1.1.1 PTR\r\nAre you sure you want to delete record? (y\/n)y\r\n\r\nCommand failed: DNS_ERROR_ZONE_DOES_NOT_EXIST 9601 0x2581\r\n<\/pre>\n
The Solution For Reals!<\/h1>\n
\r\nC:\\>dnscmd 10.5.20.5 \/RecordDelete 1.1.10.in-addr.arpa. 1 PTR\r\nAre you sure you want to delete record? (y\/n)y\r\n\r\nDeleted PTR record(s) at 1.1.10.in-addr.arpa.\r\nCommand completed successfully.\r\n<\/pre>\n
Command<\/h1>\n
dnscmd.exe<\/code> to put the good PTR right back. Here’s a full before\/delete\/during\/recreate\/after example:<\/p>\n\r\nC:\\>dnscmd 10.5.20.5 \/EnumRecords 1.1.10.in-addr.arpa. 5\r\nReturned records:\r\n@ 3600 PTR PIX-515.example.com.\r\n 3600 PTR pix-515-2.example.com.\r\n\r\nCommand completed successfully.\r\n\r\n\r\nC:\\>dnscmd 10.5.20.5 \/RecordDelete 1.1.10.in-addr.arpa. 5 PTR\r\nAre you sure you want to delete record? (y\/n)y\r\n\r\n\r\nDeleted PTR record(s) at 1.1.10.in-addr.arpa.\r\nCommand completed successfully.\r\n\r\n\r\nC:\\>dnscmd 10.5.20.5 \/EnumRecords 1.1.10.in-addr.arpa. 5\r\nReturned records:\r\n\r\nCommand completed successfully.\r\n\r\n\r\nC:\\>dnscmd 10.5.20.5 \/RecordAdd 1.1.10.in-addr.arpa. 5 PTR pix-515-2.example.com.\r\n\r\nAdd PTR Record for 5.1.1.10.in-addr.arpa. at 1.1.10.in-addr.arpa.\r\nCommand completed successfully.\r\n\r\n\r\nC:\\>dnscmd 10.5.20.5 \/EnumRecords 1.1.10.in-addr.arpa. 5\r\nReturned records:\r\n@ 3600 PTR pix-515-2.example.com.\r\n\r\nCommand completed successfully.\r\n<\/pre>\n