dhcp not matching DNS

Discussion in 'DNS Server' started by p vanhorn, Jul 29, 2009.

  1. p vanhorn

    p vanhorn Guest

    we have multiple locations and several dns and dhcp servers setup through out
    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, Jul 29, 2009
    1. Advertisements

  2. p vanhorn

    p vanhorn Guest

    It looks like it is only in the revese lookup zones that are not being
    updated and still have issues with IP addresses being handed out that are
    already being used.
    p vanhorn, Jul 29, 2009
    1. Advertisements

  3. Hello p,

    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:

    Best regards

    Meinolf Weber
    Meinolf Weber [MVP-DS], Jul 30, 2009

  4. 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
    Properties sheet click the Credentials button, and provide this account
    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

    Once you implement scavenging, you will need to wait at least a week for it
    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,
    the most part, it is not advised to use it as it weakens security INCLUDING
    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
    (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
    the client machine is not joined to the domain and has a missing or
    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
    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
    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
    with the records in DNS, as well as issues with WINS trying to keep up with
    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
    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,
    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
    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

    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
    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.

    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.

    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.

    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 ...

    And from Kevin Goodnecht:
    Setting up DHCP for DNS registrations

    317590 - HOW TO Configure DNS Dynamic Update in Windows 2000 and
    DNSUpdateProxy Group:

    816592 - How to configure DNS dynamic updates in Windows Server 2003:

    Follow up discussion on the DNSUpdateProxy-Group:


    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


    For urgent issues, you may want to contact Microsoft PSS directly. Please
    check http://support.microsoft.com for regional support phone numbers.
    Ace Fekay [MCT], Jul 30, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.