I would think in a typical AD domain that was built using reasonably good practices (maybe even the default settings) in the last 5 (maybe even 10) years, DNS c

I would think in a typical AD domain that was built using reasonably good practices (maybe even the default settings) in the last 5 (maybe even 10) years, DNS changes alone wouldn't be able to directly result in the compromise of any Microsoft products, or third-party products that authenticate against AD. One or more cryptographic mechanisms (TLS certificate verification, SMB signing, etc.) should prevent other devices from trusting the system with the spoofed name. That having been said, if the domain has relaxed security to support legacy systems, or was built 20 years ago and incrementally upgraded to newer Windows versions ever since, this technique seems like it could be used to compromise the domain. For example, if NTLM auth is enabled, but signing is not required, it seems like this would allow a network-wide version of NTLM relaying attacks. Those are usually done using subnet-specific name spoofing, so it would be a big increase in scope. Additionally, in most large enterprise environments, there will be at least a few third-party products that are set up (deliberately or by default) to operate in a way that could be exploited using this technique. Web applications that authenticate using cleartext HTTP, network appliances with telnet or other unencrypted sevices, email that's exchanged over cleartext SMTP, etc., on the assumption that an attacker would have to already have privileged access to something to capture the information sent over that channel. I suspect there would usually be a way to exploit one of those things in a way that would eventually lead to compromise of the AD domain. e.g. the organization uses Cisco network hardware configured to back up their configurations to a TFTP server every night. The attacker exploits the DHCP DNS vulnerability to pretend to be the TFTP server and captures the device configurations. They decrypt reversibly-encrypted network appliance administrator passwords, or crack the hashes if they're stored in a non-reversible format. Then they use those credentials to alter the TACACS configuration on one or more network devices to send credentials to their own system when someone tries to log on. TACACS is set up to authenticate to AD, so now the attacker has a bunch of AD credentials that belong to network administrators.