app: catch a search domain that swallows DNS queries

A tablet on a healthy network could not resolve anything. The DNS server
answered the bare name correctly — NOERROR, two records, A and AAAA, with
and without EDNS0 — so the earlier finding blamed the device's resolver.
It was wrong. The network advertised hudelist.local as a search domain and
the server silently dropped every query under it: not NXDOMAIN, nothing at
all. Resolvers append search domains, so they waited for a reply that was
never coming.

Silence is the part that makes this vicious. A negative answer moves a
resolver on; no answer looks like packet loss, so it retries, and some
give up on the lookup entirely. It also explains how two devices on one
network can disagree about whether DNS works — the phone tried the plain
name first and never noticed.

The probe now asks about a nonce name under each advertised search domain,
where the wanted answer is NXDOMAIN and only silence is a fault. The
finding is ordered ahead of dns.system_resolver_broken so the two cannot
both fire: without that, this exact network gets told its device is
broken.

Severity follows the harm rather than the shape. HIGH when resolution is
actually failing, MEDIUM when the domain is a black hole but this resolver
happens to try the plain name first — calling that HIGH would be crying
wolf on a network that works. The message names the fix and notes that
.local is reserved for mDNS by RFC 6762 and widely dropped by design,
while home.arpa (RFC 8375) is the name reserved for this.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

echolot-app/core-probe/src/main/kotlin/app/echo_lot/probe/DnsResolverProbe.kt

@@ -74,6 +74,31 @@ class DnsResolverProbe(
                 directDetail = "$s did not answer"
             }
 
+            // The search domains the network handed out, asked about separately.
+            //
+            // A resolver appends these to a lookup, so a search domain the server will not answer
+            // for stalls every name a client asks about — and it fails as silence, which is
+            // indistinguishable from packet loss, so clients retry rather than moving on. Asking
+            // about a name that cannot exist is deliberate: the answer wanted here is NXDOMAIN,
+            // and what matters is only whether anything comes back at all.
+            val searchDomains = e.model.link.dns?.searchDomains.orEmpty()
+            var searchAnswered: Boolean? = null
+            var searchDetail = ""
+            for (d in searchDomains) {
+                val nonce = "echolot-probe-" + java.util.UUID.randomUUID().toString().take(8)
+                val answered = servers.any { srv ->
+                    runCatching { queryDirect(srv, "$nonce.$d") != null }
+                        .getOrElse { it is DnsRefused } // a refusal is still an answer
+                }
+                if (!answered) {
+                    searchAnswered = false
+                    searchDetail = "$d is not answered at all — queries under it vanish"
+                    break
+                }
+                searchAnswered = true
+                searchDetail = "$d answers"
+            }
+
             // Through the platform: what an app actually gets.
             val viaSystem = runCatching {
                 e.handle.getAllByName(probeName).isNotEmpty()
@@ -84,12 +109,21 @@ class DnsResolverProbe(
                 put("servers", servers.joinToString(","))
                 direct?.let { put("direct_answer", it) }
                 put("direct_detail", directDetail)
+                if (searchDomains.isNotEmpty()) {
+                    put("search_domains", searchDomains.joinToString(","))
+                    searchAnswered?.let { put("search_answered", it) }
+                    put("search_detail", searchDetail)
+                }
                 put("system_resolves", viaSystem)
                 // Named here rather than left for a finding to infer, because the pairing is the
                 // whole observation and splitting it across two places invites reading one alone.
                 put(
                     "verdict",
                     when {
+                        // Ordered by which component is at fault, most specific first. A search
+                        // domain that swallows queries explains a failure that would otherwise be
+                        // blamed on the device, so it has to be tested before that conclusion.
+                        searchAnswered == false -> "search domain swallows queries"
                         viaSystem -> "resolver working"
                         direct == true -> "server answers, device resolver does not"
                         direct == false -> "server does not answer"