Thursday, May 28, 2009

AD-Integrated DNS Reverse Zones

I recently had reason to try to identify manual PTR records in DNS because of conflicts with new, dynamic registrations. While I try to discourage folks from manually "helping" (i.e. tinkering) DNS, they often do it anyway, and it can cause problems. If you enter manual records, they are just that: manual. The system won't overwrite or scavenge them, so you are signing up to manage DNS, at least for those records, instead of letting DNS manage itself.

Anyway, when I started poking around, I realized the data was stored a little differently than I expected.

So let's take one example. I noticed we had four records for the same IP, Three of the records were manual and 1 was dynamic. The dynamic one was the only "accurate" one. The rest were human-generated mistakes.

Note: For folks wondering about this, we had some inexperienced (?incompetant?) DNS admins who instantiated DNS zones without the proper delegations. I had to come back later and find all the duplicate DNS zones, ram them together because folks couldn't identify "good" records they needed to keep, create the proper delegations, and then shove the existing records back in. Unfortunately, this process creates a bunch of manual records. Sigh. But it was either that or lose all the records and no one would allow me to do that.

So, how do DNS zones look?

In DNS MMC, I see 4 records for, see below (sorry about the fuzziness).
If I use DNSCMD and /zoneexport I get the one record as show below, with four values. Only one of them is dynamic (the one marked [AGE:]). The dynamic record is the only good one:
51.20 900 PTR
[AGE:3579987] 900 PTR
900 PTR test3.
900 PTR test4.

In ADSIEDIT.MSC, it stores the records similar to what you see in the zone export, where there is one record for DC=51.20 in, where the 4 records are the values for the dnsRecord attribute:

The octal data stored in the dnsRecord attribute is the “name” you see on the DNS PTR “record”, but it is stored as a multi-valued attribute. The creation date is the date the *first* record was stored/created. So it depends on if the dynamic was first, or one of the manual records was first.
This information is more in the form of "interesting trivia", but it does help to understand what is going on.

No comments: