# Overview

> What DNSServer.DebugLogParser does, what a Windows DNS debug log looks like, and when converting it to CSV is worth the effort.

---

LLMS index: [llms.txt](/llms.txt)

---

Windows DNS Server can write a debug log. It is a plain text file, it is meant to be read by a human, and it grows by hundreds of megabytes a day on a busy domain controller. That combination makes it nearly useless the moment you want to answer a question like *"which client asked for this domain 40.000 times last night?"*

**DNSServer.DebugLogParser** turns that text file into a CSV table. One log line becomes one row with named columns, so you can open it in Excel, load it into Power BI, bulk-insert it into SQL Server, or ship it to your SIEM.

The module contains a single command:

```powershell
Convert-DNSDebugLogFile -InputFile "C:\Windows\System32\dns\dns.log"
```

That is the whole entry point. Everything else on this site is about doing it at scale, on a schedule, and across several servers.

## What a DNS debug log looks like

A raw entry is a single line with positional fields, some of them in brackets:

```text
2026-01-20 23:00:16 0FE0 PACKET 000002C53117D990 UDP Rcv 10.0.0.2 c049 Q [0001 D NOERROR] A (3)odc(9)officeapps(4)live(3)com(0)
```

After conversion, the same event is a CSV row you can filter and sort:

```text
DateTime;ThreadId;Context;PacketId;Protocol;Direction;ClientIP;Xid;Type;Opcode;FlagsHex;FlagsChar;ResponseCode;QuestionType;QuestionName;Information;Details;ComputerName
2026-01-20 23:00:16;0FE0;Packet;000002C53117D990;UDP;Rcv;10.0.0.2;c049;Query;Standard;0001;RecursionDesired;NOERROR;A;"odc.officeapps.live.com";"";"";dc01
```

Note two things that the raw format makes hard and the parser handles for you:

- The queried name is stored in DNS wire notation, `(3)odc(9)officeapps(4)live(3)com(0)`, and becomes a normal FQDN.
- A single event is not always a single line. `PACKET` detail blocks and event messages continue on indented follow-up lines. The parser keeps those attached to the record they belong to instead of dropping them or creating orphan rows.

Every entry carries up to 16 native fields — timestamp, protocol, direction, client IP, query type, queried name, response code, flags, and more. The full column list is described in [Output Formats](../02-output-formats/).

## Why bother converting

### Troubleshooting

- Find out why a name does not resolve, and whether the query even reached the server
- Identify misconfigured clients or applications that hammer the server
- Trace where a problematic query actually comes from
- Verify zone transfers and general DNS behaviour

### Performance and capacity

- Rank clients by query volume and find the noisy ones
- See which record types dominate your traffic
- Spot configuration mistakes that cause avoidable lookups
- Track server load over time instead of guessing

### Security analysis

- Detect DNS tunneling and data exfiltration (typically visible as excessive `TXT` traffic — see the [SQL Server analysis example](../examples/security-analysis-sql/))
- Find lookups against malware and command-and-control domains
- Recognize query patterns of a compromised host
- Watch for DNS amplification abuse
- Reconstruct what happened during an incident

### Compliance and auditing

- Satisfy logging and retention obligations
- Keep an audit trail of network activity
- Produce reports for management or auditors

## How the module works

`Convert-DNSDebugLogFile` reads the log as a stream and writes the CSV as a stream. The file is never loaded into memory as a whole, so a 100 MB log costs roughly the same amount of RAM as a 10 MB one. Details are in [Performance](../04-performance/).

What it gives you:

| Capability | Detail |
|---|---|
| Consistent CSV layout | 18 columns, same order every time, regardless of which contexts appear in the log |
| Multi-line records | `PACKET` detail blocks and event text stay attached to their record |
| DNS Server versions | 2012 R2 through 2025 log formats |
| PowerShell editions | Windows PowerShell 5.1+ and PowerShell 7.x |
| File size | Tested with 100 MB+ logs; single-pass streaming |
| Header validation | Rejects files that are not DNS debug logs (can be switched off) |
| Statistics | Optional daily rollups, per context and per client/protocol/type |
| Pipeline support | `Get-ChildItem *.log \| Convert-DNSDebugLogFile` |
| Compression | Optional ZIP output, typically 90 %+ smaller |
| Source cleanup | Optional deletion of the log after a successful run |
| International logs | Parses and writes dates per culture, so a `de-DE` log can be read on an `en-US` workstation |
| Network paths | Reads sources from SMB/UNC paths |
| Locked files | Reads logs that DNS Server (or anything else) currently has open |

## Active log vs. rotated log

<div class="alert alert-warning" role="alert"><div class="h4 alert-heading" role="heading">Read active logs with care</div>


The module can read the log file that DNS Server is writing to right now. That is convenient for a quick look, but the file keeps changing while the conversion runs. The result may miss the newest entries or end with a truncated record.

For anything scheduled or production-relevant, convert **rotated, closed** log files instead, and never combine an active log with `-RemoveSourceFile`.
</div>


The practical pattern is to enable log rollover on the DNS server and let the scheduled conversion skip the newest file:

```powershell
Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -Skip 1 |
    Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME
```

A complete Group Policy based implementation of this is documented in the [GPO-driven collection example](../examples/gpo-driven-collection/).

## Where to go next

- [Output Formats](../02-output-formats/) — what the columns mean, with real sample files
- [Parameters and Options](../03-parameters-and-options/) — the knobs, explained in plain language
- [Performance](../04-performance/) — why it is fast and how to keep it fast
- [Integration](../05-integration/) — Excel, Power BI, SQL, SIEM, Python
- [Operational Best Practices](../06-operational-best-practices/) — running it in production
- [Usage Examples](../examples/) — scheduled tasks, GPO rollout, SQL analytics
- [Command Reference](../commands/convert-dnsdebuglogfile/) — the authoritative parameter list

## Licensing and support

MIT License. Community support runs through GitHub Issues; bug reports and feature requests are welcome.

- GitHub repository: [AndiBellstedt/DNSServer.DebugLogParser](https://github.com/AndiBellstedt/DNSServer.DebugLogParser)
- PowerShell Gallery: [DNSServer.DebugLogParser](https://www.powershellgallery.com/packages/DNSServer.DebugLogParser)
