Filter AAAA app always sets `AA=0` on its synthesized NODATA response, even when the original response was authoritative

[IReclaimer]

Version: DNS Server 2.6.2 (DnsServerApp.dll fileVersion 2.6.2.46322)

Summary

When the Filter AAAA app (Apps/FilterAaaaApp/App.cs) rewrites an AAAA response into a synthetic NODATA answer, it hardcodes the authoritativeAnswer flag to false unconditionally, rather than preserving whatever the original response's flag actually was. This is correct for the common case (filtering AAAA on a recursively-resolved/forwarded answer for a domain this server doesn't host, where AA=0 is the right behavior anyway), but wrong when the server is authoritative for the zone being filtered: e.g. a locally-hosted internal domain with an A record and no AAAA record. In that case the real, correct answer is a confirmed authoritative NODATA, but the app always downgrades it to non-authoritative.

A resolver forwarding to this server (e.g. Unbound with a forward-zone) treats a non-authoritative NODATA as inconclusive rather than a confirmed negative answer, and falls back to normal recursive resolution instead of trusting it, silently defeating the filter for anyone running Technitium behind a forwarding resolver for their own authoritative zones.

Where

PostProcessAsync in App.cs, the response construction at the end of the filtering branch:

return new DnsDatagram(response.Identifier, true, response.OPCODE, false, false,
    response.RecursionDesired, response.RecursionAvailable, false, false,
    DnsResponseCode.NoError, response.Question, answer, authority) { Tag = response.Tag };

The 4th positional argument (authoritativeAnswer) is a literal false. RecursionDesired/RecursionAvailable a few arguments later are correctly carried over from response. AuthoritativeAnswer should be too.

Reproduction

1. Host an authoritative zone in Technitium (e.g. example.com) with an A record but no AAAA record for some name.
2. Enable Filter AAAA with that domain in filterDomains.
3. Query the A record directly: response has aa set (correct, this server is authoritative).
4. Query the AAAA record: response is a clean NOERROR/NODATA (correct data), but aa is missing, despite this server being authoritative for the zone.
5. Point an Unbound forward-zone at this server for the domain. A queries resolve correctly. AAAA queries, given the non-authoritative NODATA, get treated as inconclusive and fall through to real recursive resolution, returning the domain's real public AAAA records instead of confirming none exist internally.

Expected fix

Replace the literal false with response.AuthoritativeAnswer, so the synthesized response inherits the same authority status the original response already correctly had; false when relaying a recursive/forwarded answer (as now), true when the server is genuinely authoritative for the zone (currently broken).

Workaround

bypassLocalZones: true avoids this for locally-hosted zones by skipping the rewrite entirely when the original response is already authoritative, but that also disables filtering for those zones going forward, including any future host that gets a genuine AAAA record.

[ShreyasZare]

Thanks for the post. The app is responding correctly since the response it generates is not authoritative, i.e. its not what the actual authoritative zone answered. Thus the AA flag for NODATA response form the app will always have AA=0.

Point an Unbound forward-zone at this server for the domain. A queries resolve correctly. AAAA queries, given the non-authoritative NODATA, get treated as inconclusive and fall through to real recursive resolution, returning the domain's real public AAAA records instead of confirming none exist internally.

From the Unbound documentation, it does not seem to expect the response to come from an authoritative name server. The documentation explicitly says that the upstream servers "are not authority servers, but are (just like Unbound is) recursive servers too; Unbound does not perform recursion itself for the forward zone, it lets the remote server do it. ". The AA flag should not matter at all in this case since all recursive resolvers always answer with AA=0.

The fallback feature of Unbound works only if its explicitly enabled and if the upstream responds with a Server Failure response so not sure how you see it doing a fallback.

[IReclaimer]

Thanks for taking a look, and for the detail on how the Unbound docs describe forward-zone in the general case.

I think there is a distinction worth drawing out about the deployment this report is based on. Unbound's forward-zone here is not pointed at a generic public recursive resolver like 1.1.1.1. It is pointed specifically at this Technitium instance because Technitium hosts the domain in question as a locally authoritative zone. That is a standard split-horizon DNS pattern: point a forward-zone (or stub-zone) at your own authoritative server for an internal-only domain, rather than at another recursive resolver.

Live evidence that this Technitium instance really does answer this zone authoritatively: a direct dig for the A record returns flags: qr aa rd ra, AA set. A dig for AAAA on the same name, same zone, same server returns flags: qr rd ra, AA missing, purely because FilterAaaaApp's PostProcessAsync rewrites it to a hardcoded false rather than passing through response.AuthoritativeAnswer. So the same authoritative zone, queried on the same server, gives inconsistent AA signaling purely depending on whether the app touched the response.

On whether AA matters here: RFC 2308 section 2.1.1 documents almost exactly this failure mode, for NXDOMAIN rather than NODATA. It notes that some downstream resolvers keep retrying when AA is unset on a negative response from a server being used as a forwarder, and that the standard fix (default in BIND since 4.9.3) is to force AA on for those responses, not off. I have not found an equivalent explicit statement for NODATA in the RFC, but it is the closest documented precedent I could find for a downstream resolver caring about AA on a negative answer from a forward-zone target specifically.

On the point that fallback only happens with explicit config plus a SERVFAIL: could you point me at where that is implemented, or is that Unbound's own behavior rather than something in DnsServer? What we saw live was Unbound treating the AAAA NODATA as inconclusive and returning the real public AAAA record instead, which does not look like a SERVFAIL path from where I am sitting, so I would like to reconcile that if possible.

Either way, the minimal fix stands regardless of the exact downstream mechanism: response.AuthoritativeAnswer instead of a hardcoded false preserves correctness in both directions. For a pure recursive/forwarding deployment, response.AuthoritativeAnswer is already false, so behavior is unchanged. For a deployment where DnsServer is itself authoritative for the zone, it correctly reflects that. Happy to test a patched build against this exact setup if that would help confirm it either way.

[ShreyasZare]

Thanks for taking a look, and for the detail on how the Unbound docs describe forward-zone in the general case.

You're welcome and thanks for the response.

I think there is a distinction worth drawing out about the deployment this report is based on. Unbound's forward-zone here is not pointed at a generic public recursive resolver like 1.1.1.1. It is pointed specifically at this Technitium instance because Technitium hosts the domain in question as a locally authoritative zone. That is a standard split-horizon DNS pattern: point a forward-zone (or stub-zone) at your own authoritative server for an internal-only domain, rather than at another recursive resolver.

The Unbound's forward-zone feature is something that expects the upstream to be a resolver that returns a full answer back i.e. does not return a referral response. It should not matter if the upstream is a recursive resolver or a name server for the forwarded zone as long as Unbound gets back an answer.

Live evidence that this Technitium instance really does answer this zone authoritatively: a direct dig for the A record returns flags: qr aa rd ra, AA set. A dig for AAAA on the same name, same zone, same server returns flags: qr rd ra, AA missing, purely because FilterAaaaApp's PostProcessAsync rewrites it to a hardcoded false rather than passing through response.AuthoritativeAnswer. So the same authoritative zone, queried on the same server, gives inconsistent AA signaling purely depending on whether the app touched the response.

Yes, that app is modifying the response and thus the response is not authoritative. It is not something that the authoritative zone generated.

On whether AA matters here: RFC 2308 section 2.1.1 documents almost exactly this failure mode, for NXDOMAIN rather than NODATA. It notes that some downstream resolvers keep retrying when AA is unset on a negative response from a server being used as a forwarder, and that the standard fix (default in BIND since 4.9.3) is to force AA on for those responses, not off. I have not found an equivalent explicit statement for NODATA in the RFC, but it is the closest documented precedent I could find for a downstream resolver caring about AA on a negative answer from a forward-zone target specifically.

The RFC section talks only about NXDOMAIN. The next section talks about NODATA and does not mention anything about AA flag. Also, this RFC is 28 years old and it is safe to assume that no such resolvers exist that it talks about.

On the point that fallback only happens with explicit config plus a SERVFAIL: could you point me at where that is implemented, or is that Unbound's own behavior rather than something in DnsServer? What we saw live was Unbound treating the AAAA NODATA as inconclusive and returning the real public AAAA record instead, which does not look like a SERVFAIL path from where I am sitting, so I would like to reconcile that if possible.

The fallback thing with Unbound is mentioned in the same documentation link I shared earlier. Its actually strange if Unbound is rejecting a valid answer just because AA flag is not set especially when the forward-zone feature is designed to forward queries to recursive resolvers which are always going to respond without AA flag set. I would say that if such thing is observed then it may be a issue with the implementation.

Either way, the minimal fix stands regardless of the exact downstream mechanism: response.AuthoritativeAnswer instead of a hardcoded false preserves correctness in both directions. For a pure recursive/forwarding deployment, response.AuthoritativeAnswer is already false, so behavior is unchanged. For a deployment where DnsServer is itself authoritative for the zone, it correctly reflects that. Happy to test a patched build against this exact setup if that would help confirm it either way.

Does the fix you suggest cause Unbound to work differently? Have you tested with and without this fix? If this is confirmed then I guess you should reach out to Unbound team too to confirm if this is how they expect it to work. From my understanding, the AA flag is something that is not to be used to make any kind of resolution decisions and it exist only for humans to help debug issues.

My concern with this fix is that later someone will create another issue saying that the AA flag is incorrect since its not what the authoritative zone says which is true since the zone has AAAA record.