Using Dynamic DNS for Workstations

Last updated: January 30, 2023
Audience: IT Staff / Technical

This document provides an overview of the Delegated OU Dynamic DNS for Workstations service feature and instructions for OU Admins on how to enable it for their workstations.

Important notes about the DNS zone:

  • By design, the DNS zone will not fulfill manual requests–it is entirely dynamic.
  • This zone is inappropriate for computers which are servers because there is no “reverse DNS” record (PTR).
  • This zone is only appropriate for delegated OU computers, and at the time of this writing, DDNS registration is best achieved only via Windows computers.
  • Note that authorization services that key on DNS are not supported with this zone, e.g. you can not get a certificate for a hostname in this zone, except via the AD-CS CA we provide.

Quick introduction to Dynamic DNS

Dynamic DNS (DDNS) is a network service that allows a system to notify its DNS server, in real time, of changes to its DNS configuration, such as IP address, hostname, or other information.  DDNS is documented in RFC 2136 and in this Technet article (note: not much has changed in the implementation since Windows 2000 Server).

What the Dynamic DNS Service for Workstation Provides

The MI service provides the ability to securely register user workstations with a hostname in the ‘’ domain.  This provides users with a consistent name to use for access services on their workstation such as RDP, and provides systems administrators with a similar short and consistent name for managing systems.

The NETID domain DNS Servers are running in AD-Integrated mode, which allows us to enable secure updates. Because secure updates are enabled, the workstation must be joined to the NETID domain, and running a Windows OS or have a DNS client capable of providing GSS-TSIG updates. We are only able to provide support for Windows-based systems. Non-Windows systems use the service on a self-support basis.

Using the Dynamic DNS Service

To use the Dynamic DNS Service, OU Admins or GP Editors need to configure the following Group Policy settings.

Computer Configuration
|__Administrative Templates
|__DNS Client
Dynamic Update: Enabled
                        Register PTR Records: Disabled
Register DNS records with connection-specific DNS suffix: Enabled
                        Connections Specific DNS Suffix:
                        Primary DNS suffix:

It doesn’t necessarily matter which DNS servers your clients use as their primary servers, as the updates will find their way to the NETID domain DNS servers in all supported scenarios.  It’s best to continue to use the server addresses provided through the DHCP service used by your workstations.

Common Issues

Issue: On Logon, Users receive the notice ““The security database on the server does not have a computer account for this workstation trust relationship”.

Solution: This often means that the primary SPN for the workstation is missing, often due to confusion with DDNS between the connection-specific and primary DNS suffix of the machine.  The fastest solution is to add the missing SPN.  If the problem persists or exists on multiple solutions, verify that your systems have the expected values for their domain name, DNS hostname, and connection-specific DNS suffixes.  You may need to request assistance from the Microsoft Infrastructure service via

Issue: Workstations have registered, but they aren’t resolving from off campus

Solution: It will take approximately 10 minutes for changes to propagate through the DNS infrastructure, including the initial registration.

Issue: My Vista or Windows 7 workstation doesn’t appear to be registering in DDNS, even though I’m using the suggested GP settings.

Solution: It may be registering an IPv6 address in DDNS. If you haven’t disabled IPv6 on your workstation, then it is registering an IPv6 address. For more details on disabling IPv6, see

Issue: On the reboot after I configure DDNS for my Windows 7 workstation, I can’t login to my workstation! I get the error: “The security database on the server does not have a computer account for this workstation trust relationship.”

Solution: You missed configuring DDNS to be connection-specific. In that case, the servicePrincipalNames (SPNs) associated with your computer  are incorrect, not allowing the computer to setup a secure-channel connection to the NETID domain via Kerberos.

Issue: I’ve rebuilt a workstation (or built a new workstation with the same name as a workstation that used to around), but I can’t seem to get DDNS to register the correct IP address for this new workstation.

Solution: The DDNS zone probably has a stale record from the old workstation with the re-used name. Because of the security inherent in Microsoft DDNS, that (stale) record can only be updated by the original computer. DNS scavenging will remove this record after 14 days. If you need this stale record manually removed prior to 14 days, you’ll need to submit a request for that.


UW-IT will provide support for this Dynamic DNS service feature on a business hours only, best effort basis only.  We generally turn all requests around within two business days.  The service is not intended for use by mission critical, patient care, or life-safety systems.

Contact for assistance or questions.