We are in the midst of a BYOD rollout, and one of the challenges we’ve faced is how to best provide DHCP services and DNS resolution to BYOD clients. On the surface these are not difficult items, but with BYOD you are inherently dealing with a variety of devices that are outside of your control, plus you obviously want them isolated from your production (secure) network. This implies a few things:
- If you want BYOD devices registered in DNS, your DHCP server(s) will need to handle the registration and maintenance of DNS records.
- A BYOD device that is behind your firewall yet physically isolated from production resources may need different DNS resolution than a domain-joined device. An example of this is a federation (ADFS) server; domain-joined devices connect to an “internal” ADFS server that does SSO, while non-domain devices need to connect to an ADFS proxy that accepts a manual login.
There are many posts about DHCP and/or DNS configuration, including how to handle DHCP registering DNS records. Rather than repeat anything, I’ll link to a few that I found helpful:
TechNet: Windows Server: Integration between DNS and DHCP
Ace Fekay: Dynamic DNS Updates…
Where things get a bit trickier (or perhaps less obvious) is when you want DHCP to register a client on a DNS server that is different from the DNS server assigned to that client. In our case, we want our BYOD devices registered on our Windows DNS servers, but the BYOD devices themselves need to query a DNS proxy rather than our Windows DNS servers.
We already had DHCP configured to register clients in DNS, but which DNS server? I could not find any reference for this, but based on packet captures and empirical evidence, this is what happens:
- DHCP queries the DNS server that is being assigned to the client for the address(es) associated with the DNS domain name in DHCP option 015
- DHCP then attempts to register the client on the address(es) returned by the prior query
Put another way…when DHCP offers a DNS server to a client via option 006, DHCP will query that same option 006 DNS server for the DNS Domain Name in option 015, in order to determine what DNS server the client should be registered on.
Long story short: the option 006 DNS server must have an entry that matches the option 015 DNS Domain Name, and resolves to the IP address of the DNS server where you actually want the clients registered.
Thank you for this post. I have a similar problem where I want to register guest devices DNS names but they are firewalled away from my non-guest vlans. I have my Windows DHCP server configured to register these devices DNS names on behalf of the device.
I have configured DHCP option 006 with the IP of my internal (non-accessible) DNS server at index 0. Followed by accessible ISP DNS and (of course) 126.96.36.199.
In general this works. However some devices fail all DNS lookups because they cannot access my internal DNS server. Bad device, bad. The only way for them to work is to remove my internal DNS IP from the 006 list. Doing that, of course, fails to register the DNS at all.
So, I am confused. Since my DHCP server is performing the actual DNS registration instead of the device…. why do I need to add my internal DNS address to 006?
Is there any way to tell the DHCP server which DNS IP to use directly? If not, why not???
There are three pieces to this:
* DHCP Option 15 should reflect the domain name you want used for guest devices.
* DHCP Option 6 should reflect the DNS server you want clients to use for name resolution.
* The DNS server in option 6 must have a host entry that matches the domain name from option 15, and resolves to the DNS server you want the devices registered on.
The long and short of this is that your option 6 DNS server must be a server you manage, because without being able to add an entry yourself, you cannot meet the third requirement above.
Does that clarify things?
Thanks for the response. Yes, I understand the mechanics and they work as you describe. However:
1) Option 006 is an array of DNS servers, not just one. The first one in the array is what must be your internal DNS server to register with.
2) In my case, the first DNS in the the 006 array is unaccessible (via firewall rule) to the device. But it *IS* available to the DHCP server.
So, my question is why does the DHCP server need to use the first item in the 006 array? Instead, why not do what DHCP clients are supposed to do and query for the DNS SOA to connect to (based on 015)?
I am hoping for some way to configure the DHCP server to use an alternate DNS server (other than the first one in 006) or have the DHCP server perform the SOA lookup for 015. Otherwise it seems massively short sighted.
“The first one in the array is what must be your internal DNS server to register with.”
What makes you say this? That is not the behavior I see, and I absolutely do NOT have the server we are registering hostnames to listed in option 6.
I stumbled upon the “first IP in 006” point here (3rd reply):
My experimentation confirms this (if my DNS IP is 2nd or later in the list it fails).
So, back to my original problem: some devices do not skip a failed DNS entry. Therefore if my internal DNS IP is first in the 006 array the DNS is properly updated (DHCP server successfully registers on behalf of the device) but the device fails all DNS lookups.
So…. certainly there must be a way to override which DNS server to register. Maybe a reg key to set on the DHCP server? Or somehow override option 081?
From what you’re describing, you are experiencing different behavior than I am. What Windows version is DHCP running on?
…furthermore referencing MSFT’s own docs:
This outlines that normal DNS registration occurs by the DHCP client on the device looks up the DNS SOA for its 015 domain name to determine which DNS IP use for registration.
In my scenario, the device’s DHCP client is not performing these steps, instead the DHCP server is. So, why is it not doing what the device’s DHCP client normally would? Why not have the DHCP server perform the 015 DNS SOA lookup instead of assuming the 1st DNS IP in 006 is where you register.
This is why I have to assume there is some way to override this. Or maybe I am just overtly hopeful. 🙂
Is it possible the DHCP server updates are failing for some reason and falling back to the client? Not sure what else to suggest, other than whatever debug logging you can enable on the server, and running WIreshark on the DHCP exchange.
Thanks James (the web site doesn’t allow me to reply to our last reply so this may seem out of order).
None of the devices in this scope have access to the DNS server but the DHCP server is successfully registering their DNS names properly as long as they have the DNS server IP as item 0 in the 006 array.
It is only if I remove the DNS IP from item 0 in 006 that I see the problem. Unfortunately some devices have problems if their first DNS server is unavailable. This is why I am looking for a workaround.
I think I’ll just have to create static IPs for these devices and create static DNS entries.
Thanks for your help.