This is not a proper research yet. I just happened to stumble upon an interesting artifact which is a file:

C:\Windows\System32\dns\RFC5011.csv

that dns.exe service process tries to read.

This csv file appears to be related to DNSSEC, but I don’t know enough about it, plus have not spent enough time analyzing the actual dns.exe binary to determine the csv file’s purpose and layout yet.

BUT

The code reading this CSV file refers to TrustAnchor and TrustPoint strings so it’s possible the program is using the content of the file to import a set of trusted public keys utilized by DNSSEC. Which of course could be abused.

After poking around a bit more, I have created a list of file system-based artifacts that the DNS-related executables and libraries (c:\Windows\System32\dns.exe, c:\Windows\System32\dnscmd.exe, c:\Windows\System32\dnsmgr.dll) touch:

• C:\Windows\System32\dns\backup\boot
• C:\Windows\System32\dns\backup\boot.first
• C:\Windows\System32\dns\backup\dns.log
• C:\Windows\System32\dns\boot
• C:\Windows\System32\dns\boot.txt
• C:\Windows\System32\dns\boot.write.error
• C:\Windows\System32\dns\dns.log
• C:\Windows\System32\dns\RFC5011.csv
• C:\Windows\System32\dns\TrustAnchors.dns

This is really not very useful yet, but it is a good starting point to dig deeper.

I asked myself what tangible artifacts present on a file system can immediately tell us that the server system in place is a Domain Controller and/or DNS server.

I decided to run a simple experiment.

I installed a test version of Windows Server 2022, took a snapshot of the file system, then added DC and DNS capabilities, then took a snapshot of a file system again.

The (slightly edited) diff of these 2 can be found here.