Introduction
Moving workloads to the cloud leads to collateral effects that have seasoned IT Pros nodding in recognition that the world is not precisely how marketing and sales like to present it. On the other hand, management often stares at it in disbelief.
That is how I found myself working on a solution for a dozen heavy-duty workstations with a truckload of CPU cores, memory, and lots of high-capacity flash storage. Not to mention that these systems run 24/7 and have 3D screens. It’s not precisely a workload you can run realistically, let alone cost-effectively, in the cloud. Welcome to the world of satellite and aerial image processing!
No Active Directory
So, we had to devise a way to give these workstations connectivity to the internet and their Azure tenant, which provides some services that are not publicly exposed. That is not a technical challenge, but it requires some dealing with corporate bureaucracy and institutional inertia.
A real challenge is finding people who can creatively build decent solutions with a server operating system physically or in a virtual machine. Many people have been raised and educated with everything as a service. Knowledge and skills of DIY solutions end for them when something starts working without seeking a deeper understanding of the technologies.
Now, Active Directory is still in their on-premises environments. However, we cannot use it as the service provider won’t support anything not covered by the corporate-issued client devices and where the workloads in play are something other than the lowest common denominator. Using another Active Directory environment, setting one up, for example, is not allowed as that is legacy. No, not even in a separate, isolated network segment. Hence, I needed to provide secure DHCP services and automatic DNS registration for name resolution for those workstations. So that is the story of how I ended up with workstations in a workgroup registered in Entra ID, requiring secure DHCP and dynamic DNS registration and updates in a workgroup.
DNS and DHCP work together
We need DNS for name resolution, and since the clients are not in Active Directory, we have to handle some details ourselves. First, workgroup clients do not get a primary DNS suffix assigned as they would when Active Directory joined. That’s because they get that configured based on the domain name, which matches the DNS zone name required by Active Directory. Dynamic DNS registration and updates won’t work without a primary DNS suffix.
There are several ways to configure the primary DNS suffix, such as scripting or policies or automatically via DHCP. I guess I have been enough summers to know this. As a side effect, we can also make this work for non-Windows clients if needed. This might come in handy, as those engineers tend to have some equipment that is not Windows-based.
There is no DHCP service from a firewall/routing device. All that happens at the corporate level, which provides a network segment and (protected) internet access. We will use the Windows Server DHCP service to register all clients’ DHCP leases in the desired DNS zone. We will use a Windows 2025 Server, Standard Edition, on a virtual machine on Hyper-V. Remember that the DHCP and DNS servers are not Active Directory members. The Hyper-V host is a two-unit Windows Server with 200TB of storage on which an image processing service runs. It can handle that extra load perfectly.
To make this work, we must configure the DHCP service with:
- The desired DNS name in DHCP 015
- Force DHCP to register/update all DCHP leases in that zone regardless of whether the client requests it.
The question was whether we needed DHCP credentials configured or not. The idea is that since the DHCP credentials will own the DNS record, the DHCP service can also update that record when the DCHP lease renews and assigns a new IP address. Note that we use a mix of MAC address reservations and an “Allow” policy filter in this environment to secure the segment more. So, in our cases, the IP addresses will typically not change. But, the DHCP service can update the existing host records in DNS with a new IP address. As such, it prevents duplicate entries for a host with different IP addresses, which we want to avoid by design. The thing is, there are no ACLs on DNS records in a text file, which is what we have with non-Active Directory-integrated DNS. In my opinion, we do not need it.
Configuration
Preparations
Install a Windows Server 2025 Stand Edition and configure it with a fixed IP address and settings in your subnet, as shown below.
Create a local user with no administrative rights—that is unnecessary! Please give it a very long and complex passphrase.
Note that this account and the password never expire, and the user cannot change the password. We want to avoid service interruptions. We need this account to prove a point later in this article—one on DHCP secure automatic updates of DNS records in a non-Active Directory DNS environment.
Configure the server’s primary DNS suffix to the desired DNS suffix, which will also be the DNS zone name. To do so, go to Windows Explorer, right-click “This PC,” and choose properties.
In “System, > About,” choose Domain or Workgroup. Click the “Change” button on the Computer Name tab to navigate to the Computer Name/ Domain changes form, where you click the “More” button to get to the place where you can specify the primary DNS suffix.
You can do this via the CLI, PowerShell, or scripting the relevant registry settings. Use whatever you like best and is available to you. Configuring this setting requires a computer reboot.
The system can now register the server records in DNS due to the default DNS settings shown in the screenshot below: “Register this connection’s address in DNS.”
Install the DNS role
Install the DNS role and create the following zones
Forward lookup zone: image.analysis
Reverse lookup zone: 3.168.192.in-addr.arpa.dns
You must ensure that Dynamic Updates is set to “Nonsecure and secure” for both the forward and reverse lookup zones. Nonsecure updates are risky, but “secure only” updates are only an option in Active Directory-based environments. As this is a risk factor, we will show you how to mitigate it later via an allow filter in DHCP.
Leave the “Aging” settings at their defaults. That works well with the DHCP default lease time of eight days. If you want them to be “tighter,” just ensure that the sum of the no-refresh interval and refresh interval equals or exceeds the DHCP lease. That means the no-refresh and refresh intervals must be at least four days each.
In your DNS server properties, configure some Forwarders so you are not dependent on the Root Hints servers for name resolution for which the DNS server is not authoritative or has no conditional forwarders set.
If you have any specific domains for which you need to forward queries to specific DNS servers, don’t forget to configure the conditional forwarders.
Now reboot the server or, if you have console access, run Restart-NetAdapter -Name “Ethernet” in an elevated PowerShell console. After that, check the DNS entries for both zones. You should see that the DNS server has registered its records in both the forward and reverse lookup zones. That is because you configured the primary DNS suffix earlier and the default setting on the NIC to register the suffix in DNS.
Also, note that the Start of Authority and the name server record point to your server must be present for DNS to work correctly.
DHCP configuration
Install the DHCP server role and create a scope for your network segment. I size the pool for the expected number of clients, plus some extra for growth. I leave out the first 10 IPs, so I have private IPs for the gateway/router (9192.168.3.1) while knowing that IPs 192.168.3.2-9 should not be handed out to clients.
I also exclude a small range, so I have some IP addresses to use as static IPs. These are also useful if we ever encounter a device with no DHCP client capabilities to do so or a bad one that does not function properly.
The DNS settings on the DHCP scope make DHCP update the DNS records dynamically regardless of whether the client is able and willing to request this.
I create a reservation based on the MAC addresses of all clients so I can get predictable, known IP addresses.
The scope options we need for a functional network address and dynamic DNS registration to work are
- 003 Router> This provides the default gateway for routing purposes.
- 006 DNS Servers. The client needs their DNS servers configured.
- 015 DNS Domain Name. This one provides the client with the primary DNS suffix.
I also implemented a DHCP server Allow filter that only allows clients with known MAC addresses. That is important as allowing nonsecure and secure dynamic DNS updates comes with some risks. But we have to use that setting because the DNS server, the DHCP server, and these workstations are members of an Active Directory domain, and secure updates are not an option. While adding an extra step in DHCP per client, the allow filter mitigates that risk.
Important Note
Remember that we are working in a workgroup environment, and the DNS server is not Active Directory domain joined. While we can use the credentials of a local user in DHCP for dynamic DNS updates, this is only valuable in an Active Directory joined and Active Directory Integrated DNS scenario. In that case, the user can and will own the DNS records on the various DNS servers as those exist in Active Directory and have ACLs. As the DHCP user does all the registrations and updates for the client, the owner of those records must have the right to do so. That is what this does. Using that same user on various (replicated) DHCP servers is very important so that it owns all records.
If you set such a user, you must restart the DHCP service. I have tested this for you, and setting this or not in a workgroup scenario makes no difference. Notice that since we have no domain, I use the server name. I even tested with the wrong name or an empty one without any difference.
Testing
We log in to our test client, for which we have created an allow filter and a DHCP reservation on its MAC address. We also renew the IP address by running ipconfig /renew. You should see the DHCP lease and the forward and reverse lookup zone records.
Bonus
You can find a PowerShell code sample for automatically configuring DHCP filters with allow and Deny lists and Reservations. It is a code demo for inspiration.
Conclusion
Some creative use of DHCP server options and configurations combined with DNS server dynamic update settings can get you DHCP with unsecured dynamic updates in a reasonably secured manner. If that last sentence made sense, you understand what we discussed in this article. Thanks for reading!
