Feature Request: Include SOA in NXDOMAIN responses to enable proper negative caching

[Cebeerre]

Feature Request: Include SOA in NXDOMAIN responses to enable proper negative caching

Description

Currently, Blocky returns bare NXDOMAIN responses (no SOA in the authority section) when blocking is set to nxDomain.
This causes stub resolvers (Linux glibc, Windows DNS Client, macOS mDNSResponder, Android, etc.) to ignore the configured blockTTL and re-query the blocked domains repeatedly.

Per RFC 2308 – Negative Caching of DNS Queries, stub resolvers may only cache negative responses if the NXDOMAIN reply contains an SOA record in the authority section, which provides the negative TTL.
Without that, the default behavior for many systems is to not cache and keep retrying, which leads to:

• Log floods (same blocked domain queried every few seconds or minutes)
• Unnecessary CPU and network load
• User confusion, since blockTTL is documented as applying to NXDOMAIN but in practice doesn’t have any effect without SOA

Documentation mismatch

The Blocky documentation states that blockTTL applies to both nxDomain and zeroIp modes.
In practice, only zeroIp (and customIP) are honored by stub resolvers, because they cache the returned A/AAAA records.
With nxDomain, the absence of an SOA prevents caching, so the behavior is inconsistent with the docs.

Proposed solution

• When returning NXDOMAIN for a blocked domain, Blocky should include a minimal SOA in the authority section.
• The SOA’s minimum TTL should be set from blocking.blockTTL.
• This would align Blocky with RFC 2308 and allow negative caching to work correctly across stub resolvers.

Benefits

• Greatly reduced log noise and repeated queries for blocked domains
• Consistency between nxDomain mode and Blocky’s documented behavior
• Better interoperability with standard DNS client behavior

References

• RFC 2308 – Negative Caching of DNS Queries
• Blocky documentation: blocking.blockTTL