"DNSSEC Validated" icon near DNSSEC incorrect domain

[DavidOsipov]

System Details:

• Version of AdGuard Home server:
  • Adguard Home v0.106.0-b.4
• How did you install AdGuard Home:
  • Snap package
• How did you setup DNS configuration:
  • Ubuntu VPS
• CPU architecture:
  • x86_64
• Operating system and version:
  • Ubuntu 20.04.2 LTS
• Unbound is present:
  • Unbound 1.13.0 (with DNSSEC features and hardenings on)

Describe the bug

I use Unbound + Adguard Home
I turned on "Enable DNSSEC" feature in Adguard home
I use www.servfail.sidnlabs.nl and www.dnssec-failed.org domains to check if DNSSEC checks are really working

When DNSSEC checks are turned on in Unbound and Adguard Home:

Expected behavior:
No "DNSSEC Validated" icon near www.servfail.sidnlabs.nl and www.dnssec-failed.org domains in Adguard Home, because Unbound has restricted us from entering these domains with SERVFAIL

Actual behavior:

When DNSSEC checks are turned off in Unbound and turned on in Adguard Home:

Expected behavior:
Domains www.servfail.sidnlabs.nl and www.dnssec-failed.org are inaccessible (SERVFAIL) and no "DNSSEC Validated" icon near them

Actual behavior:

P.S.
If it's correct behavior of Adguard Home, than "DNSSEC Validated" icon is quite misleading.

[ameshkov]

Yeah, the icon is indeed misleading and we'd better improve it. And not just it, DNSSEC check should be implemented fully and not as it is now: AGH does not perform the validation by itself, it just asks the upstream resolver to do it. The icon indicates the fact that it asked to validate but does not indicate the fact that the validation failed.

[ainar-g]

Additional suggestions from #4258:

Please add a tool-tip for the DNSSEC Icon in the Query Log when DNSSEC is not used (grey icon).

• Has the it been resolved from local cache?
• Has it been affected by "optimistic caching"?
• Has it incorrectly not used DNSSEC when it should have?

In any case, those indicators could probably be more informative.

[DavidOsipov]

I have found out, that the optimistic cache is serving outdated DNSSEC signed responses, which are considered bogus by other DNSSEC validating software like Mozilla Thunderbird DKIM Verifier add-on. Not really a big deal, but can cause troubles for other users.

Proposal: add an option to opt DNSSEC-signed domains out from the optimistic cache.

[ameshkov]

Proposal: add an option to opt DNSSEC-signed domains out from the optimistic cache.

Probably we should simply automatically exclude signed responses (i.e. that have an RRSIG record) from the optimistic cache?

[Sil3ntVip3r]

I reproduced the current DNSSEC query-log state and prepared the dependency-side fix in dnsproxy #519.

The original SERVFAIL false-positive path is no longer present: a locally generated/upstream-failure SERVFAIL reports no authenticated data. A related current false-negative remains, however. When DNSSEC is enabled and a validating upstream returns AD=true for a valid answer, dnsproxy must clear AD from the wire response if the client did not send AD or DO. AdGuard Home currently records pctx.Res.AuthenticatedData after that client-specific filtering, so the query log loses a valid upstream DNSSEC result for ordinary clients.

PR #519 exposes the pre-filter response AD state through DNSContext.ResponseAD for fresh upstreams and cache hits, resets it on context reuse, and preserves it across pending-request coalescing. The eventual AdGuard Home follow-up is then a one-line metadata change in processUpstream:

dctx.responseAD = pctx.ResponseAD()

Validation completed:

• valid upstream AD with no client AD/DO: wire AD remains false, metadata AD is true;
• cached response keeps the same metadata with one upstream exchange;
• generated SERVFAIL and reused contexts remain false;
• pending-request leader and waiters agree;
• focused regressions pass 20 times under race;
• full dnsproxy proxy package, lint/vulnerability scan, and all supported-OS vet checks pass;
• full AdGuard Home internal/dnsforward package passes under race with the local dependency and one-line consumer change;
• independent adversarial review is clean after two edge-case corrections.

This keeps protocol behavior unchanged while making the Query Log indicator reflect the resolver validation result rather than the client-specific wire filtering. I will keep the AdGuard Home consumer change isolated until the dependency API can be consumed normally.