[✨ Triage] dotnet/runtime#124751 by rzikm - DNS localhost subdomain tests with AddressFamily fail on Android

[MihuBot]

Triage for dotnet/runtime#124751.
Repo filter: All networking issues.
MihuBot version: a74eff.
Ping MihaZupan for any issues.

This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.

Tool logs

dotnet/runtime#124751: DNS localhost subdomain tests with AddressFamily fail on Android by rzikm
Extracted 5 search queries: Dns.GetHostEntry('test.localhost', AddressFamily) tests failing on Android, getaddrinfo localhost AF_INET/AF_INET6 returns EAI_NONAME on Android, RFC 6761 localhost subdomain fallback: resolve localhost with AddressFamily.Unspecified vs specific, Dns.GetHostAddresses/GetHostEntry family-specific resolution fails on Android emulator, Android resolver behavior for family-specific getaddrinfo vs AF_UNSPEC when resolving localhost
Found 23 candidate issues

• Pull Request #123076 (Jan 2026, merged Feb 19 2026) - Handle RFC 6761 special-use domain names in Dns resolution
  Summary: Implements the RFC 6761 handling that your tests rely on: try the OS resolver for *.localhost first, and if it fails/returns empty, fall back to resolving plain "localhost" so subdomains return loopback addresses. The PR moved fallback logic out of try/catch, guarded async fallbacks, added tests (including address-family variants), and adjusted assertions to avoid IPv6 CI flakiness. Crucially, the implementation performs the fallback by calling the platform resolver for "localhost" with the same AddressFamily hint; that matches your analysis and is likely why Android's getaddrinfo(AF_INET/AF_INET6) can return EAI_NONAME and make the tests fail. The PR discussion also introduced defensive changes for malformed names and ordering of returned loopbacks.

• Issue #118569 (Aug 2025) - Domain name resolution does not handle RFC6761 special names correctly
  Summary: The original feature request and discussion that led to the PR above. Contains design tradeoffs discussed in the follow-ups: preserve OS resolver behavior for plain "localhost" (to respect /etc/hosts), handle subdomains in managed code, and be careful around IPv4/IPv6 support on the host. Useful context for why the code falls back to resolving "localhost" via the OS instead of synthesizing loopbacks.

• Pull Request #120376 (Draft, Oct 2025) - Draft RFC 6761 handling for invalid and *.localhost
  Summary: Earlier draft implementing the same RFC 6761 behavior. Discussion in the draft covers filtering loopback addresses by AddressFamily, checking whether IPv6 is actually supported on the machine (and whether to consult network interfaces), and rejecting malformed hostnames. The draft shows the alternative approach space and concerns about relying on OS/host IPv6/IPv4 configuration—relevant to deciding how to implement a robust fallback on Android.

• Issue #56549 (Jul 2021) - Inconsistent behavior with new GetHostAddress overloads that take AddressFamily?
  Summary: Important design discussion about passing an AddressFamily "hint" to the OS vs. not passing it and filtering results in managed code. The consensus / recommendation in the thread was to prefer NOT passing the AddressFamily hint to the OS and instead query with AF_UNSPEC and then filter results, because passing the hint can cause the OS to return confusing errors (e.g., "no data of requested type") for valid domains that simply lack the requested record type. This directly maps to your suggested fix [✨ Triage] dotnet/runtime#121199 by hlinkaintenscz - mTLS intermediate certificate handling for application that is ... #1 (resolve with Unspecified then filter) and supports it as a pragmatic cross-platform solution.

• Pull Request #112642 (Feb 2025) - Narrow AddressFamily passed to getaddrinfo when IPv6 is unsupported
  Summary: This change goes the opposite way: when IPv6 is disabled, it narrows queries to AF_INET to avoid unnecessary AAAA queries that can surface user-facing failures. It shows prior work in the repo adjusting when to pass AF_UNSPEC vs. a specific family. Takeaway: platform/feature flags elsewhere can influence whether AF_UNSPEC or a narrowed family should be used; any change to fallback behavior should consider the existing logic that narrows queries when IPv6 is globally disabled.

• Issue #106969 (Aug 2024) - MAUI Dns.GetHostEntry(hostNameOrAddress) on Android returns "hostname nor servname provided, or not known"
  Summary: A field report where Dns.GetHostEntry fails on Android (same error text as your failing stack trace) in real devices and depends on router/device/mobile data state. The report highlights that Android/device/emulator network configuration can cause getaddrinfo to behave differently (and sometimes fail) — supporting the hypothesis that Android getaddrinfo with a family hint can fail while AF_UNSPEC would succeed. This indicates the problem may be platform/environment-specific (emulator or device network setup) rather than purely a regression in the RFC 6761 change.

• Issue #119851 (Sep 2025, closed Nov 2025) - [Android][arm64] TryGetAddrInfo_ExternalHost fails with HostNotFound
  Summary: Another Android-specific name-resolution failure (arm64) that manifested regularly in CI at one point. It was tracked and then closed when it did not reproduce for weeks. Shows precedent that Android name-resolution tests are flaky and sometimes tied to specific images/queues or environment; useful to consider when triaging intermittent CI failures.

• Issue #47591 / PR #47594 (Jan 2021) - TryGetAddrInfo_ExternalHost failing on Android / Disable test on Android
  Summary: Historical example of Android name-resolve test failures that were tied to particular devices/machines and led to temporarily disabling tests. Reinforces that Android test environment/setup (emulator/device, DNS configuration) can cause resolution failures unrelated to library logic.

Conclusion / actionable pointers for triage

• The most relevant prior discussion is the address-family hint vs. AF_UNSPEC tradeoff (#56549). The recommended pragmatic fix is exactly your option 1: perform the fallback resolution for "localhost" with AF_UNSPEC (no family hint) and then filter the returned addresses by the requested AddressFamily. That avoids getaddrinfo returning EAI_NONAME for family-specific queries on Android while still respecting AddressFamily filtering at managed layer.
• PR #123076 intentionally relied on calling the OS resolver for "localhost" (with the same family). That design explains why Android runs fail; updating the fallback to query AF_UNSPEC and filter should be a small, targeted change with precedent in the repo discussion.
• As an alternative or companion step, investigate the Android emulator/device setup for the windows.11.amd64.android.open helix queue (similar to prior flaky Android issues) to see if a platform/environment issue causes family-specific getaddrinfo to fail; but the AF_UNSPEC+filter approach is likely the least invasive and most cross-platform robust fix.