Best practice for decommissioning a Domain Controller that is also a DNS server?
I'm hesitant to answer because I think this is more of a "discussion" question than a strictly Q&A question... but it's a lazy Saturday morning so I will anyway.
Is there a clear cut best practice here?
No. (Damn, maybe this was an easy answer all...)
Microsoft provides very generic, easily Googleable Bingable guidance on how to demote domain controllers, and perform migrations of AD and DNS, but I won't bother linking to them nor will I pretend that they address your specific question, because Microsoft obviously can't document every specific case for every different organization's environment.
So systems admins/engineers like us are left to fill in the gaps with our own expertise and experience where Microsoft hasn't written a special script just for us, and that's what makes us valuable.
I can give you an example of something that we've done to address this same issue, since I also work in globe-spanning environments with dozens or more domain controllers, disparate AD forests cohabitating on the same networks, non-Windows devices also consuming DNS services from the same DCs, etc.. Moving into new datacenters and moving out of old ones, needing to migrate to new hardware or new OS versions, and plain old business politics are all possible reasons we'd need to decommission domain controllers that were potentially still being used. And when you have multiple heterogeneous organizations currently using those DC/DNS servers, it's usually a grueling, drawn-out process of reconfiguring every client (many of which may not be under your control) before decommissioning the domain controller, involving project managers, tickets to various other teams that may take days or weeks to get worked, etc..
So that's why I say I don't think anyone can give you the answer to this question. There are a thousand ways you could go about it and some will be better than others depending on your organization's structure and needs.
Something we've done to get in front of this issue is make a VIP for each datacenter, and pool all the domain controllers in that datacenter behind that VIP. (This VIP is for DNS service only for obvious reasons, I'm not talking about load balancing Kerberos and LDAP.) That way, clients can be configured to use that VIP for their DNS resolver, and we are free to add and take away domain controllers behind that VIP whenever and however we please.
But you're not in front of the problem... so given the options you provided:
Add the IP address of the outgoing DC to a new DC and ensure that DNS is listening on that address.
Demote the old DC, leave the DNS role on it, and configure a global DNS forwarder to your new server.
I would choose option #1, because your goal is to decommission the old server as quickly as possible, and option #2 does not help you get rid of the old server. With option #2 the server's existence is still necessary. Nor would I go with Mathias R. Jessen's suggestion of stub zones, because again, you still have to leave the old server in place and in service, which is not conducive to your end goal.
With option #1, ugly as it may be, you can retire the old server, claim cost savings for your company, avoid having to pay another month's rent on that datacenter, and be given an award for being such a good employee.
Edit: Thinking about our chat a little more, I think I may have projected my own requirements onto you, because I do have pull-the-plug-ASAP requirements on some stuff right now, so that was fresh on my mind. It sounds like you do not have as much of an immediate requirement to shut the server off ASAP.
That said, I'm not changing my suggestion, as I would still prefer it. Tacking the extra IP onto an existing domain controller has worked well for me in the past in very similar scenarios, and I would rather that than have a weird vestigial appendage of a server sitting there for an indeterminate amount of time.
The road to Active Directory hell is paved with temporary bandages. Assigning the IP address of a decomissioned or to-be-decomissioned DNS server to your new DC and DNS server is a temporary bandage.
As @gravyface noted in the comments, in the ideal scenario you would change all DHCP scopes and static configurations to update the client DNS preference to the new IP instead of the old one, before you decomission the old DC entirely.
I understand that maing sure that all clients have been reconfigured is not necessarily possible on time, but I certainly regard option number 2 (forwarding the entire namespace) as the least objectionable option here.
In addition to letting the old server forward requests even after demoting it, I would recommend enabling Debug Logging for incoming requests on the DNS Server - this makes it a little easier to assess not only if clients are still pointing to the old DNS server but also identifying said clients.
That being said, I think you've missed the obvious third option: Stub Zones!
- Demote the DC, keep the DNS role and add all the zones it previously held as stub zones - forward everything else. This way, your enforcing the clients to actually contact the Domain Controllers they should be using, instead of doing the work for them