AD-integrated DNS: secure updates, record creation rights and booby-trapped records
DNS is often seen as plain network plumbing. In an Active Directory domain, however, it sits at the heart of authentication: whoever controls how a name resolves can attract connections, and with them authentication attempts, to a machine of their choosing.
Dynamic updates: secure only
An Active Directory-integrated zone can accept three dynamic update modes: none, nonsecure and secure, or secure only. Nonsecure mode lets any machine on the network, even outside the domain, create or change records without authenticating. It must be banned on every zone, including reverse lookup zones, which are often overlooked. Secure-only mode requires Kerberos authentication and applies directory access control lists to each record.
Who can create records?
In an integrated zone, every record is a directory object. By default, Authenticated Users have the right to create child objects in the zone. In practice, any domain account can create a record for a name that does not exist yet and then owns it. This is what lets workstations register themselves, but it also lets a compromised account claim strategic names.
Two measures reduce the risk: pre-create sensitive names you do not yet use, with a controlled owner, and restrict that creation right on zones where automatic workstation registration is not needed, after assessing the impact.
Wildcard and WPAD records
A wildcard record (the * character) answers for any name that does not exist. Created by an attacker, it captures every mistyped or failed lookup. The wpad name is just as sensitive: browsers and the WinHTTP service may query it to discover a proxy automatically. Windows DNS Server includes a global query block list that contains wpad and isatap by default; check that it is still active and has not been emptied to accommodate an old proxy. If you really use WPAD, create the record yourself and protect it.
The DnsAdmins group
When the DNS service runs on domain controllers, which is the most common setup, DnsAdmins members can change the configuration of a service running with high privileges on a DC. Public research has shown that such configuration changes could lead to code execution on the controller. Microsoft has hardened some behaviours through updates, but the principle stands: DnsAdmins must be treated as a tier 0 group, empty or close to it, and monitored like Domain Admins.
The DnsUpdateProxy group. Records created by a DHCP server that is a member of DnsUpdateProxy have no secure owner and can be taken over by the first machine that updates them. Prefer a dedicated account configured in the DHCP service for dynamic updates.
Scavenging stale records
Scavenging (record aging and scavenging) removes dynamic records that have not been refreshed. Without it, the zone piles up names pointing to addresses that have since been reassigned, which causes confusion and spoofing opportunities. Enable it carefully: set refresh intervals consistently with DHCP leases, let aging run for several cycles before allowing deletion, and make sure critical static records carry no timestamp.
What an audit checks
- the dynamic update mode of every forward and reverse zone;
- wildcard,
wpadorisataprecords and the state of the global query block list; - DnsAdmins members and delegations on zones;
- aging and scavenging settings, and the use of DnsUpdateProxy.