web_fetch fails for every dual-stack host when ipv4only.arpa does not resolve (NAT64 discovery throws ENOTFOUND)

[J-Oe-2]

Summary

web_fetch through the local HTTP provider (@deepseek-ai/dsh-web-fetch-http) fails for every URL whose host has an IPv6 address when the network's DNS does not resolve ipv4only.arpa. The RFC 7050 NAT64 discovery lookup lets the resolver's ENOTFOUND propagate, so an optional probe turns into a hard failure of the whole fetch. On such networks web fetching is effectively unusable for dual-stack sites.

Reproduction

1. Use a machine whose DNS resolver returns NXDOMAIN for ipv4only.arpa (check: getent ahosts ipv4only.arpa exits with status 2). This is common on networks without DNS64.
2. Start dsh with the default web profile and fetchProvider: http.
3. Ask the agent to web_fetch any URL on a host that has AAAA records, for example https://store.bblcdn.eu/.

The same failure reproduces without the UI by constructing HttpFetchProvider from the package and calling fetch({ url }).

Current behavior

The fetch fails with WEB_PROVIDER_ERROR ("web fetch failed: …"), with the ENOTFOUND error for ipv4only.arpa as the cause. resolvePublicAddresses calls discoverNat64Prefixes whenever the target resolves to at least one IPv6 address, and discoverNat64Prefixes does not handle a rejected lookup:

// packages/web/web-fetch-http/src/network.ts (master)
async function discoverNat64Prefixes(signal: AbortSignal, resolver: AddressResolver): Promise<Nat64Prefix[]> {
  const discovered = await raceWithSignal(
    resolver(IPV4ONLY_DISCOVERY_HOST, { all: true, order: 'verbatim' }),
    signal,
  )
  ...

Expected behavior

If ipv4only.arpa does not resolve, there is no DNS64/NAT64 prefix to discover. Discovery should return an empty list, and the fetch should continue with the normal public-address checks. Other resolver errors (timeouts, SERVFAIL, abort) can still propagate.

Suggested fix, which we run locally against the published build and which restores fetching on the affected network:

async function discoverNat64Prefixes(signal: AbortSignal, resolver: AddressResolver): Promise<Nat64Prefix[]> {
  let discovered
  try {
    discovered = await raceWithSignal(
      resolver(IPV4ONLY_DISCOVERY_HOST, { all: true, order: 'verbatim' }),
      signal,
    )
  } catch (error) {
    // NXDOMAIN / no data for ipv4only.arpa means no DNS64 on this network.
    const code = (error as NodeJS.ErrnoException | undefined)?.code
    if (code === 'ENOTFOUND' || code === 'ENODATA') return []
    throw error
  }
  ...

This only treats "the name does not exist / has no data" as "no NAT64". It does not relax the SSRF address checks.

Environment

• @deepseek-ai/dsh and @deepseek-ai/dsh-web-fetch-http 0.1.5-rc.2 (npm). The same code is on master as of 2026-09-14.
• Linux x86_64 (Ubuntu), Node.js v26.8.1.
• Web profile, fetchProvider: http, no HTTP(S) proxy configured.
• DNS: the system resolver returns NXDOMAIN for ipv4only.arpa; IPv6 is available.

[PerryLink]

Confirmed against master (c291e79) — your report matches the source line for line, and the patch direction is right:

• The NAT64 probe runs whenever the resolved set contains IPv6: resolvePublicAddresses (packages/web/web-fetch-http/src/network.ts:90-93) calls discoverNat64Prefixes with no try/catch.
• The discovery (:113-134) resolves ipv4only.arpa (:38) through raceWithSignal; with no DNS64 in the network the lookup rejects (ENOTFOUND) and the exception propagates out of resolvePublicAddresses → every dual-stack host dies. Exactly what you observed.
• The SSRF guard is a separate step (:96-106) and is unaffected by handling the probe error.
• One compatibility detail for your patch: raceWithSignal's abort error is a plain Error with no code field (:287-296), so a catch that filters by code (ENOTFOUND/ENODATA) will correctly NOT swallow cancellations. Your design is compatible.

Semantics I'd suggest: treat ENOTFOUND/ENODATA as "no DNS64 present → empty prefix set" and rethrow anything else. And please add a resolver-injected test for the no-DNS64 case — the hook already exists for tests (AddressResolver, :34).