I cant speak to the openBSD DHCP...but I can speak from a MS DHCP perspective....
Lets hit on the basics for DHCP scope configuration:
1. Is the DNS domain option set, and is it set to your AD domain name? (domain.com for example)
2. Are you specifying a DNS suffix search list (I never recommend this unless absolutely necessary)? If so, is the top listed domain your AD domain name, and if there is a parent domain, is it second, before all other dns suffixes?
3. Are clients pointing to the DC for DNS (I assume yes but playing it safe)?
4. What other options are you setting?
let's go over DNS basic config questions:
1. Are secure and insecure dynamic updates enabled?
2. Are your client systems NATed in any way?
3. Is the zone set to allow everyone group to update the records on the zone?
My DNS forward and reverse zones not only do not match, but there are hardly any entries that are even accurate.
Q: What do you mean by "not only do not match"? Are you speaking of different IPs appearing for the host records?
There are two entries for almost everyone about 10 percent of them are right.
Q: Do they have different IP addresses? Is this what you mean by 10 percent are right?
Q: How many network segments are the clients residing in?
It seems to me by looking at it that DNS is not being dynamically updated when a computer joins the domain.
A: DNS records *should* be updated at computer startup (or reboot), and every 1.5 hrs or so, give or take. They should also be registered when the DHCP client service is restarted, or when running ipconfig /registerdns
Basics of how MS DHCP works with client DNS registration:
1. DHCP server registers on behalf of client, therefore, it owns the record (this can be disabled via the reg)
2. DHCP maintains ownership of records, and performs periodic updates of DNS records (the client never registers itself, despite pointing to the DC for DNS)
3. DHCP removes the DHCP records when a lease for a system expires
Its late, but thats pretty much the nuts n bolts off top of head.
What I think is happening (theoretical right now of course):
You are running secure and insecure dynamic updates on the zone. openBSD is unable to "own" the DNS records due to not being a domain member/AD authorized DHCP server. It can however do the initial update of the client systems as they boot up. Since it does not take ownership, about 1.5 hrs after bootup, the client recognizes it needs to register a record under its ownership as it does not recognize the original registering entity, or the IP address is incorrect. Now there are two records for the same system (which is a major problem for kerberos auth to work properly).
Here's what I'd like to see tested:
1. Choose a client system you have seen the dup DNS records for
2. Check its assigned IP and IP info (sm, gw, etc.), then set this info statically OR choose an IP that has not been assigned by the DHCP server (I suggest reserving the IP for testing-skip step 3 if doing this)
3. If possible, terminate the lease of the IP of that client in the DHCP scope, then reserve that IP for the client for testing
4. Once client system is set statically, power it off completely OR disable and stop the DHCP client service temporarily
5. Delete all DNS records for the client system from the DNS zone; also ensure no duplicate IPs exist in the zone for the IP you are using for testing.
6. Power on the system, or reset the dhcp client service back to automatic and start it
7. Look at the DNS management console at your zone FROM THE DC ITSELF and refresh repeatedly until you see the record appear (depending on the client OS, this could take 5-10 minutes)-ensure the record is accurate
8. Delete the DNS record once more
9. Restart the DHCP client service on the client system
10. Repeat step 7
If your record is correct after steps 7 and 10, then your problem is likely not with the zone itself at all, but rather, the use of a 3rd party DHCP server.
-Brandon Wilson
MCSE00/03, MCSA:Messaging00, MCSA03, A+
Manager - Global AD Operations
ACS, Inc.
