fix(dnssec): only validate public-upstream answers (#2126) - #2128

What

Exempt conditional-upstream answers (ResponseTypeCONDITIONAL) from DNSSEC validation, clearing the AD flag instead of validating them.

Fixes #2126.

Why

Since v0.32.0 (the GHSA-x845-2f78-7v36 hardening, #2119), a response carrying no RRSIGs is no longer automatically treated as Insecure — classifyUnsignedResponse now checks the zone's security status, and because the whole namespace sits under the default IANA root trust anchor, the fail-closed logic classifies any unsigned answer without an authenticated insecure-delegation proof as Bogus → SERVFAIL.

Conditional-upstream answers serve private/split-horizon zones from an operator-trusted resolver. They are inherently unsigned and have no chain of trust in the public DNS hierarchy, so with dnssec.validate: true every private lookup routed through a conditional mapping now returns SERVFAIL:

No RRSIG for myhost. but zone is secure - treating unsigned answer as bogus
DNSSEC validation failed for myhost. - returning SERVFAIL

This worked before 0.32.0, where an unsigned answer resolved to Insecure (AD cleared) and passed through.

How

In DNSSECResolver.Resolve, skip validation for ResponseTypeCONDITIONAL and clear the AD flag — mirroring RebindingProtectionResolver, which already exempts trusted-local answers by response type. The DNSSEC resolver sits above the conditional resolver in the chain, so it observes these answers on the way back up.

Security

The GHSA-x845 findings concern answers from the public DNS hierarchy — RESOLVED and CACHED — which remain fully validated. ResponseTypeCONDITIONAL is assigned only by blocky's own conditional resolver for operator-configured mappings and can never be attacker-assigned, so the carve-out does not reopen the unsigned-answer bypass. The change is deliberately scoped to this single response type to stay as close as possible to the hardened 0.32 behaviour; SPECIAL (SUDN) and SYNTHESIZED (DNS64) remain validated.

Tests

• Regression test: an unsigned CONDITIONAL answer passes through (no SERVFAIL, AD cleared) under the default root anchor.
• Companion test: an equivalent unsigned RESOLVED answer still SERVFAILs — proving validation remains active and the carve-out is strictly response-type scoped.
• go test ./resolver/... green; gofmt/go vet clean.

Update — generalized to a response-type whitelist (89185b0)

Follow-up review found the CONDITIONAL-only carve-out above left two siblings of the same SERVFAIL class open, since both also reach the DNSSEC resolver from below in the chain and are inherently unsigned under the default root anchor:

• SPECIAL (SUDN) — e.g. localhost A → 127.0.0.1 SERVFAILs under the default config (SUDN is on by default + dnssec.validate: true) — the same precondition as DNSSEC blocks trusted conditional resolvers #2126 itself.
• SYNTHESIZED (DNS64) — synthesized AAAA for signed zones SERVFAILs when DNS64 is enabled.

The carve-out is now the rebinding resolver's exact response-type whitelist: validate only RESOLVED and CACHED (the public chain of trust / GHSA-x845 attack surface) and skip + clear AD for every other trusted-local or synthesized type. This supersedes the "deliberately scoped to this single response type" note above — SPECIAL and SYNTHESIZED are now exempted too. The security argument is unchanged: RType is assigned by blocky's own resolvers and is never attacker-controlled, and CACHED stays validated so re-validation on every cache hit (a GHSA finding) is preserved.

Tests are now table-driven: the skip table {CONDITIONAL, SPECIAL, SYNTHESIZED} asserts pass-through + AD cleared + no DS/DNSKEY sub-queries issued; the validate table {RESOLVED, CACHED} asserts unsigned answers still SERVFAIL.

Known residual: a DNS64-synthesized answer is cacheable and re-served as CACHED, so it is re-validated and SERVFAILs on cache hits — inherent to DNS64 + server-side DNSSEC validation (RFC 6147 §5.5), left for a separate change.