I'm having a problem where our Windows Server 2003 domain controller assigns my Windows 7 computer one IP address (x.x.x.75) via DHCP, but reports another (x.x.x.84) via DNS. This causes some interesting behavior on the network. If I change my adapter settings to get IP and DNS addresses from DHCP, I can access the internet, but no one on our network can access my computer. If I change my IP manually to what DNS says it is, I lose my internet access, but everyone can get to my computer again.

I know that we have some old, invalid reverse DNS pointers hanging around (a reverse lookup on an IP address often gives more than one result, usually not including the one that is correct), so that could be contributing, but my problem is recent, and the invalid reverse pointers have been around a long time.

What's going on, and how do I fix it?


Do you have DNS aging and/or DNS scavenging properly configured? As you said yourself, it sounds like you have too many old DNS records hanging around on your domain controller. My suggestion is to look into setting up DNS scavenging or at the very least, delete the old A record (x.x.x.84) and then renew your workstation's DHCP lease for testing purposes.

DNS scavenging will periodically remove the old DNS records that were dynamically generated when a client received a DHCP lease. This is a Good Thing (TM). DNS records are only good (and useful) if they are actually fresh. Having a bunch of records that point to clients that are no longer there isn't useful.

You might also want to look at your DHCP lease TTL to make sure that it appropriately matches your DNS TTL and "aging" policy. A contrived example: if your TTL for DHCP leases is 12 hours and your DNS aging policy is to keep records for three weeks, you're just setting yourself up for trouble.

The earlier mentioned technet blog post is a good place to start.

| improve this answer | |
  • I don't think we have either of those really set up, but I'll look into it; it would probably be beneficial. I deleted both DNS records for my workstation (forward and reverse), then released and renewed my IP. DNS and DHCP now match, and everything appears to be working. – Mr. Jefferson Jun 21 '11 at 21:38

Your problem, as stated, is that the name→address DNS lookup for your computer results in a different IP address to the one that the computer actually has. This has nothing to do with PTR resource records, which are not involved in name→address DNS lookups. (They are used for address→name lookups.) Cleaning up your PTR records won't do a thing for your stated problem.

What will fix your problem is finding out why the name→address DNS lookups aren't correct. Since you are using DHCP, your DNS database should be being dynamically updated with the name→address maps as the DHCP server hands out leases. For best results, one configures one's DHCP server to talk to the DNS server directly, the former sending the updates to the latter as leases are granted and renewed. Only the DHCP server needs to security permissions to modify the DNS data through dynamic update.

But some people have their DHCP clients do this. In which case one can run into various permissions problems, such as DHCP clients not having appropriate update permissions, or not being able to update records in the database that they don't have the access rights to, or being able to hijack special-use domain names that they shouldn't be able to claim. There are also various problems with domain name suffixes that can raise their heads.

So find out whether your DHCP server or your DHCP clients are sending the updates to the (content) DNS server. Ensure that the access controls let whichever is performing the updates do so, ensure that the server is recieving the update traffic, ensure that the appropriate parts of the namespace are updatable, ensure that all of your advertized content DNS servers can actually update the DNS database, and ensure that the updates are ending up with the correct domain names.

| improve this answer | |
  • The poster specifically mentioned issues with reverse DNS lookups as well, but you are correct in that the 1st part of the question has nothing to do with PTR records. I've update my answer to try and be more correct. – user62491 Jun 22 '11 at 16:23
  • I know what the questioner mentioned. I addressed it in the first paragraph. Xe didn't mention PTR resource records as a problem. Xe suggested it as a potential cause of the actual problem, which of course it isn't. The questioner even supposed as much xyrself. – JdeBP Jun 22 '11 at 16:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.