Query Logs (PostgreSQL) app crashes on DNS queries containing null bytes (0x00)

[daedaevibin]

Problem

The Query Logs (PostgreSQL) app throws Npgsql.PostgresException (22021) when attempting to bulk-insert DNS query logs that contain null bytes (0x00) in string fields. PostgreSQL's text type rejects embedded null bytes, causing the entire batch insert to fail.

Error Log

[2026-07-17 16:57:47 Local] DNS App [Query Logs (PostgreSQL)]: 
Npgsql.PostgresException (0x80004005): 22021: invalid byte sequence for encoding "UTF8": 0x00
   at QueryLogsPostgreSql.App.BulkInsertLogsAsync(List`1 logs, StringBuilder sb) in ...\App.cs:line 333
  Exception data:
    Severity: ERROR
    SqlState: 22021
    MessageText: invalid byte sequence for encoding "UTF8": 0x00
    Where: unnamed portal parameter $8

The error repeats for different parameter positions ($8, $30, etc.), indicating multiple fields are affected.

Environment

• Technitium DNS Server: v15.4
• App: Query Logs (PostgreSQL)
• PostgreSQL: Any version (text type behavior is standard)

Root Cause

DNS query data (QNAME, client hostnames, answer data, etc.) can legitimately contain or be poisoned with null bytes. The app passes these strings directly to Npgsql/PostgreSQL without sanitization.

Suggested Fix

Sanitize string fields before insertion by stripping or replacing null bytes.

This should be applied to all user-controlled string fields in the log batch (QNAME, client identifier, answer RDATA, etc.).

Impact

• Query logs are lost for the affected batch
• Log gaps make troubleshooting and auditing unreliable
• Repeated failures may indicate active exploitation or malformed client traffic

[ShreyasZare]

Thanks for the feedback. Do you have any domain name which can be used to reproduce this issue?

Of all fields, only answer field may have issue with char encoding since it may contain data from TXT records. QNAME will never have a null char, its simply not possible.

The suggested fix to strip off \0 char would cause different issues. Thus reproducing this issue would be required before a suitable fix can be thought of.

[daedaevibin]

Thanks for the feedback. Do you have any domain name which can be used to reproduce this issue?

Of all fields, only answer field may have issue with char encoding since it may contain data from TXT records. QNAME will never have a null char, its simply not possible.

The suggested fix to strip off \0 char would cause different issues. Thus reproducing this issue would be required before a suitable fix can be thought of.

I don't have the exact domain — the failed insert means the log never made it to the DB. The parameter positions ($8, $30) were different across two failures 10 seconds apart, so it's probably in the answer data, not the QNAME.
I think this is a TXT record with a null byte in the RDATA. I haven't been able to trigger it intentionally, let me know if you want me to dig deeper.

Also, would it make sense to sanitize answer RDATA before insert regardless, or do you want to wait for a confirmed repro?

---

Update:

Repro confirmed, check PR.

[ShreyasZare]

Thanks for the details. Will test it out and let you know.