Can a laptop's hostname be associated with both of its interfaces?

Question

I administer the network in my (very small, ~110 students) school. We have a Windows Server 2008 R2 Standard server, and we use Windows 7 Professional. We have ~10 workstations and 5 laptops, the latter of which connect sometimes over Ethernet, and sometimes over Wi-Fi. I've noticed that this creates duplicate DHCP leases, and then only one of those can get registered in DNS -- the second simply fails. Is there any way to fix this, so that when I, for example, ping laptop-1, it'll get to the laptop no matter which interface is currently in use?

Answer 1

This post reiterates some of what we've already discussed in the comments under your original post for the benefit of others, but goes further to (hopefully) address your issue.

A DHCP server leases IP addresses to clients based on the clients reported MAC address. So, if a computer has two network interfaces, LAN & WLAN (Wireless LAN), each with its own MAC address, you can end up with two DHCP leases. Both leases will report the same computer name, but if you examine the MAC address (or Unique ID), you’ll note they are actually different records.

In short, the answer to your question is yes – a laptop’s hostname can be associated with both of its interfaces? However, there are a few caveats.

Once the client receives a leased IP address from DHCP, one of several things can happen in regard to DNS registration:

• The Windows client will attempt to register its IP address with DNS using the DNS suffix supplied by the DHCP server.
• Depending on how it’s configured, the DHCP server might attempt to register the leased IP address with the local DNS service on behalf of the client.
• The client and DHCP server might both try to register the leased IP address with the local DNS server.

If the DNS server is configured to allow only secure dynamic updates, the first system to update the record becomes the owner and all other attempts to access the DNS record will result in access violations. For example, if the client registers its DNS record first, the DHCP service might encounter something like the errors Micha has described.

When the DHCP service registers a connection on behalf of a client, it will register the most recently leased or renewed IP address using the name supplied by the client. Consider the following:

1. If the WLAN receives an IP lease from DHCP, the DHCP service will register that IP & the computers FQDN with DNS, overwriting any previously registered entry.
2. If the LAN is later connected in addition to the WLAN, receiving another lease from DHCP, the DHCP service will overwrite the previously registered IP address (the one that belongs to the WLAN) with the new LAN IP address – note that only one entry exists in DNS, even though both network interfaces are connected.
3. If the LAN interface is subsequently disconnected, no DNS update will be made since DHCP doesn’t know (or care) that the LAN has been disconnected. Since the LAN’s IP address was the last to be registered with DNS, queries to DNS will not return a valid result.

Unless you have some compelling reason why the DHCP server should be registering IP addresses on behalf of its clients, you should leave DNS registrations to the individual clients. Unlike the DHCP server, the client will register multiple DNS entries – one for each network adapter with an IP address. Consider the following:

1. If the WLAN receives an IP lease from DHCP, the client will register that IP with DNS.
2. If the LAN is later connected in addition to the WLAN, receiving its own lease from DHCP, the client will register a second DNS entry. DNS queries for the client’s FQDN will now return two results, one for each registered IP address.
3. If the LAN interface is subsequently disconnected, no DNS update is made and two DNS entries will continue to exist, one of them now invalid. By default, Windows clients only update DNS when a DHCP lease is granted or renewed (DNS registrations for static IP addresses are refreshed every 24 hours). Fortunately, you can change the default refresh rate using group policy. Once refreshed, the invalid DNS record will be removed. Unfortunately, 30 minutes is the smallest refresh interval Windows will allow.

To summarize, this is what you want:

• DNS configured to allow only secure dynamic updates (for security)
• DHCP configured to only register DNS addresses on behalf of clients that request it, or clients incapable of registering their own IP addresses
• Computers configured to refresh their DNS records every 30 minutes

How to configure DNS for secure dynamic updates:

1. Open the DNS management console
2. Find the lookup zone (yourdomain.local or similar) you want to configure, right click it, select properties
3. Under the general tab, look for the dynamic updates section and select “Secure only”
4. Apply your settings

How to configure DHCP to NOT update DNS for all clients:

1. Open the DHCP management console
2. Find the IPv4 node, right click it, select properties
3. Under the DNS tab, select the following options:
   1. Select, “Enable DNS dynamic updates according to the settings below:”
   2. Select, “Dynamically update DNS A and PTR records only if requested by the DHCP clients”
   3. Optionally select, “Discard A and PTR records when lease is deleted”
   4. Optionally select, “Dynamically update DNS A and PTR records for DHCP clients that do not request updates”
4. Apply your settings

Configure windows to refresh dynamic DNS registrations at fixed intervals:

Apply the following group policy setting to all of your computers (or just the laptops):

1. Edit an appropriate group policy object
2. Expand Computer Configuration, Policies, Administrative Templates, Network, DNS Client
3. Find the “Registration refresh interval” setting and double click it
4. Configure the refresh interval for 1800 seconds (30 minutes)
5. Apply your settings and wait for the group policy changes to propagate

Note: If you need a shorter refresh interval you could try creating a scheduled task using group policy to run “ipconfig /registerdns”. The command requires elevated privileges, so this option might introduce unwanted security risks.

Hope this helps!