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 clients.uw.edu DNS zone:
- By design, the clients.uw.edu 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 http://technet.microsoft.com/en-us/library/cc961412.aspx (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 ‘clients.uw.edu’ 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
|__Network
|__DNS Client
Dynamic Update: Enabled
Register PTR Records: Disabled
Register DNS records with connection-specific DNS suffix: Enabled
Connections Specific DNS Suffix: clients.uw.edu
Primary DNS suffix: clients.uw.edu
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 help@uw.edu.
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 http://support.microsoft.com/kb/929852.
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 clients.uw.edu 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.
Support
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 help@uw.edu for assistance or questions.