dhcp not matching DNS
vanhorn@discussions.microsoft.com p vanhorn
our domain. dhcp and dns are set up correctly and we do get clients to
update. What we are finding is the client will get a lease and you check dns
and it does not match what was given by dhcp. we have also been having issues
with clients getting addresses that are already being used and IP phones
getting addresses already being used which bring the phone down. It seems
that dhcp is not updating the DNS servers correctly or in a timely fashion.
p vanhorn
updated and still have issues with IP addresses being handed out that are
already being used.
Meinolf Weber [MVP-DS]
You have to configure the DNS zones for scavenging not under 24 hours to
cleanup the zones from old entries. Not under 24 hours, because machines
with fixed ip addresses like servers register once in 24 hours there records.
Or you use DNSupdateproxy group:
http://technet.microsoft.com/en-us/library/cc787034(WS.10).aspx
Best regards
Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
Ace Fekay [MCT]
news:4CEA7EFF-3E4A-4C3C...@microsoft.com...
I agree with Meinolf. You will need to configure scavenging and forcing DHCP
to own the records. As for the phone system IP addresses, I would definitely
create an exclusion, for it seems that if they are fixed IPs, there is an
overlap in their IPs and the DHCP scope, unless they are also getting DHCP
configurations, which I would suggest creating a reservation for them so
they get their own IPs.
To elaborate on scavenging and DnsUpdateProxy group that Meinolf mentioned,
please read the following to gain a better understanding of how the whole
thing works.
==================================================================
DHCP, Dynamic DNS Updates , Scavenging, static entries & timestamps, and the
DnsProxyUpdate Group:
--------------------------------------------
The entity that registers it owns the record. The nice thing about DHCP
owning the record is it will update it if DHCP gives the machine a new IP.
Otherwise you'll see multiples of the same in DNS whether scavenging is
enabled or not. I would force DHCP to own the record as well as enable
scavenging to keep it clean. To force DHCP to own the record, you will need
to do the following:
1. Add the DHCP server to the DnsUpdateProxy Group.
2. Force DHCP to register all records, Forward and PTR, (whether a client
machine can do it or not) in the Option 081 tab (DHCP properties, DNS tab).
3. Set Option 015 to the AD domain name (such as example.com).
4. Set Option 006 to only the internal DNS servers.
5. If the zone is set for Secure Updates Only, then DHCP cannot update
non-Microsoft clients and Microsoft clients that are not joined to the
domain. In this case, you will need to create and configure a user account
for use as credentials for DHCP to register such clients.
If your DHCP servers are Windows 2003 or WIndows 2008, Configure a
dedicated the user account you created as credentials in DHCP by going into
DHCP COnsole, DHCP server properties, and on the Advanced tab of the DHCP
Server
Properties sheet click the Credentials button, and provide this account
info.
The user account does not need any elevated rights, a normal user account
is fine, however I recommend using a Strong non-expiring password on the
account.
Once you implement scavenging, you will need to wait at least a week for it
to
take effect. You can quicken it up by manually deleting the incorrect
records to
get started.
But more importantly, if DHCP is on a DC, it will not overwrite the
original host record for a machine getting a new lease with an IP
formerly belonging to another. To overcome this, add the DHCP server
(the DC) to the DnsProxyUpdate group. This will force DHCP to own
all records it will create moving forward and will update an IP with
a new name in DNS.
With regards to the DnsProxyUpdate Group, this is one method, but normally,
for
the most part, it is not advised to use it as it weakens security INCLUDING
the
DC records if DHCP is on a DC. Preferably configure DHCP with an account.
This can be done in w2k and w2k3 and up.
For w2k you need to use NETSH
For w2k3 and up can use NETSH or the GUI
If you set this, but when a record shows up in the DHCP Lease list with a
pen
(which means that a write is pending), it m ay mean it is trying to register
into a zone that does not exist on the DNS servers. This happens in cases
where
the client machine is not joined to the domain and has a missing or
different
suffix than the zone in DNS. It can only register into a zone that exists on
DNS and that zone updates have been configured to allow updates.
If this is the case, go into the client machine's IP properties, and
on the DNS tab in TCP/IP properties, clear the "Register this connection's
addresses in DNS" as well as the "Use this connection's DNS suffix in DNS
registration"
check boxes, the DHCP Server will fill these in for you and register using
the domain name in Option 015.
Concerning records and timestamps, and lack of timestamps:
If the record was manually created, it won't show a time stamp, however, if
the record was dynamically registered, it will show a time stamp. My guess
is the records you are referring to were manually created. If you manually
create a record, the checkbox will not be checked to scavenge, however if it
was dynamically registered, it will be checked. I just tested this
withWindows 2003 DNS. When I had built a few servers for a customer and let
them auto register, they had a timestamp and the scavenge checkbox was
checked. For the records I manually created, such as internal www records,
and others, they did not have a time stamp and were not checked to scavenge.
Even if you allow auto registration, which I do by default, and it gets
scavenged, it gets re-registered anyway by the OS. Unless you are seeing
something going on that is affecting your environment, the default settings
work fine, at least they do for me for all of my customers and installations
I've worked in that I've set scavenging and forced DHCP to own the records
so it can update the records it had registered at lease refresh time.
==========
Now if you reduce the DHCP lease to say, 8 hours instead of the default 8
days,
a number of things can occur, such as increased Tombstoning of DNS entries,
which will increase the AD NTDS.dit file size, as well as possibly an
inconsistency
with the records in DNS, as well as issues with WINS trying to keep up with
the
changes, which will be evident with WINS Event log error entries.
Regarding the WINS issue, I've seen this once at a customer site years ago.
It's always stuck to the back of my mind to keep this in mind when such as
short
lease is desired. I found a default lease works fine, as long as scavenging
is enabled (default as well), including if the DHCP server is on a DC,
adding
the DHCP server to the DnsUpdateProxy group, or to alleviate the security
issues with such as move, to rather supplying credentials for DHCP, so it
owns all records it registers into DNS, in order so it can update the
records
as they change. Otherwise, expect issues to occur.
Read the following for more info, which was compiled by Chris Dent.
===
A high rate of change in DNS will lead to a large number of tombstoned
DNS entries.
It would seem reasonable to reconsider the DHCP Lease duration, 8 hours
is, after all, extremely short.
Essentially you have:
* The amount of Tombstoned Data is increasing because of Stale DNS records
* The number of Stale DNS Records is high because of the (potential)
rate of change of records in both Forward and Reverse Lookup
* The rate of change must be somewhat proportional to changing leases in
DHCP
The DNS Record lifecycle is this:
1. Record Created (as dnsNode)
2. When Timestamp is no longer updated and Aging Intervals pass Record
becomes Stale
3. Stale Record is removed from the active DNS system and dnsTombstoned
is set to TRUE
4. Tombstoned record exists for value of DsTombstoneInterval (7 days by
default)
5. DnsNode object is moved to Deleted Objects for value of
tombstoneLifetime (120 days by default for domains built with 2003 SP1;
60 days prior to that)
Therefore, you either reduce the rate of change by increasing the lease
duration, or put up with inaccuracy in DNS (by limiting Aging /
Scavenging), or put up with increasing directory size.
The directory size should level out eventually, when you reach the point
where the number of tombstoned records being flushed is equal to the
number being created.
==========
The following links provide additional information on how it all works.
How to configure DNS dynamic updates in Windows Server 2003.
http://support.microsoft.com/kb/816592
Using DNS Aging and ScavengingAging and scavenging of stale resource records
are features of Domain Name System (DNS) that are available when you deploy
your server with primary zones.
http://technet.microsoft.com/en-us/library/cc757041.aspx
Microsoft Enterprise Networking Team : Don't be afraid of DNS ...Mar 19,
2008 ... DNS Scavenging is a great answer to a problem that has been nagging
everyone since RFC 2136 came out way back in 1997.
http://blogs.technet.com/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx
DHCP, DNS and the DNSUpdateProxy-Group - Directory Services/Active ...I had
a discussion in the Newsgroups lately about DHCP and the
DNSUpdateProxy-Group which is used to write unsecured DNS-Entries to a
DNS-Zone which only ...
http://msmvps.com/ulfbsimonweidner/archive/2004/11/15/19325.aspx
And from Kevin Goodnecht:
Setting up DHCP for DNS registrations
http://support.wftx.us/setting_up_dhcp_for_dns_registra.htm
317590 - HOW TO Configure DNS Dynamic Update in Windows 2000 and
DNSUpdateProxy Group:
http://support.microsoft.com/?id=317590
816592 - How to configure DNS dynamic updates in Windows Server 2003:
http://support.microsoft.com/kb/816592/
Follow up discussion on the DNSUpdateProxy-Group:
http://msmvps.com/ulfbsimonweidner/archive/2005/03/26/39841.aspx
==================================================================
--
Ace
This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.
Please reply back to the newsgroup or forum to benefit from collaboration
among responding engineers, and to help others benefit from your resolution.
Ace Fekay, MCT, MCTS Exchange, MCSE, MCSA 2003 & 2000, MCSA Messaging
Microsoft Certified Trainer
ace...@mvps.RemoveThisPart.org
http://twitter.com/acefekay
For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.