Question : AD DNS Reverse Lookup Zone Name (wrong subdomain)

I run a Windows Server 2008 Active Directory network comprised of numerous geographical offices organized in AD as seperate sites.  Each office has one or more subnets, and as such these subnets have been added into AD under the corresponding sites.  There are 10 subnets in all, with most sites having more than one subnet each.

Recently I began to notice that some PCs at my site were returning 'Can't find server name for address [address]: Non-existent domain' errors when I ran NSLOOKUP commands on them.  For some reason other systems appear unaffected.

I researched the problem and determined that this can be caused by a missing or inaccessible PTR record in DNS.  Upon RDP'ing into my local DNS server (each site typically has one DC/DNS/WINS server that replicates with all others) I discovered what I think to be the problem, but I'm a little leery of making any changes to try and fix it for fear of making things worse.

Under the Reverse Lookup Zones section I see all the subnets of my organization, but the subnet for my site is wrong.  My site uses the subnet 172.31.88.0/23.  Therefore my site's reverse lookup zone should be 88.31.172.in-addr.arpa.  However, it instead shows 88.231.172.in-addr.arpa.  Notice that extra '2' in the second octet.

I'm thinking that this reverse zone being mis-labeled in DNS is the culprit.  However, I don't think I can simply rename an existing zone, and even if I could, I have no idea what the ramifications of such an act would be.  I could create a new zone, but I'm not sure what entries to put into it (so far all the reverse zones have populated on their own...I've never had to enter objects into any of them directly).

So I guess my questions break down to the following:

1. Does it sound like I'm on the right track here in terms of the reverse lookup zone being the cause of my NSLOOKUP problems?

2. Is there a way to simply rename an existing reverse lookup zone, or does the zone have to be completely deleted and recreated?

3. How are reverse lookup zones created in the first place?  I didn't create the one for my site (I inherited this AD environment), but I HAVE created sites under ADSAS.  Does the reverse lookup zone appear when the new sites appear, or is it completely unrelated?

Any help anyone can offer is GREATLY appreciated.

Thanks!

-Bob

Answer : AD DNS Reverse Lookup Zone Name (wrong subdomain)

> Hmmm...interesting (and a bit annoying that the zones work that way, but I'm sure there's a good reason).

There is :) In part it's because DNS was first thought up before we shifted to classless IP ranges, late 70s or early 80s, I forget which. However, at the time no one got anything but /8, /16 or /24. It took CIDR (Classless Inter-Domain Routing in 1993) to make usage of smaller classless ranges common.

Then you have the zone name format. There's no 4or3.2.1.in-add.arpa, it's one or the other. I should have mentioned that there was another way to move to a single zone for yours, you would take the 16-bit zone, that is 31.172.in-addr.arpa, then you can have both 88 and 89 in the same zone. Of course, with this approach you're responsible for everything under 172.31 (1, 2, 3, 200, 201, etc) because you can't be partially responsible for a zone.

In short, DNS just isn't capable of thinking outside of the classful blocks. Classless delegation is a technique to work-around the limitation (using fairly obscure zone naming), but it's very clearly a work-around.

> but I wonder if it will cause problems to create a new host record that is identical to an existing record...

You shouldn't need to. If the server is dynamically registering it will add its own PTR record once a zone exists for it to live in. You can force it to attempt registration by running "ipconfig /registerdns".

Otherwise you could create a PTR record in the zone directly, no need to touch the record in the forward lookup zone. The tick box in the GUI about the PTR record is an administrative convenience, there's no real link in DNS between the Host (A) record and the Domain Pointer (PTR) record.

Chris