Small scope nit on logBridgeBuild / bridgeBuildID: nice debugging aid, but it's unrelated to the allow_net fix and the hand-bumped "...allownet-dns-resilience-2026-06" constant will go stale (nobody will remember to bump it). Consider either splitting it into its own PR, or dropping the constant and logging just the auto-derived vcs.revision/vcs.modified/vcs.time fields so it never lies. The retry + fail-closed + longest-suffix-sort changes all look great. 👍

Also better to add tests to confirm the difference between pre and post fix

Have you meet DNS timeout I/O reported by mistake in this situation?

Sure, here are two snippets that demo before/after — easier to grok than test code:

Pre-fix (map-iteration order, what gvisor saw):

// gvisor matches first-suffix-wins, no most-specific preference.
// services/dns/dns.go:51 — strings.HasSuffix(q.Name, "."+zone.Name)
 
zones := []Zone{
  {Name: "com.",       DefaultIP: net.IPv4(0,0,0,0),
  Records: []Record{{Name: "github", IP: net.IPv4(20,205,243,166)}}},
  {Name: "sample.com.", DefaultIP: net.IPv4(0,0,0,0),
  Records: []Record{{Name: "iapi",   IP: net.IPv4(100,64,1,1)}}},
}
// query "iapi.sample.com." → matches com. first → no record "iapi.sample"
//                        → returns DefaultIP 0.0.0.0 

Post-fix (longest-name-first, what we now emit):

zones := []Zone{
  {Name: "sample.com.", DefaultIP: net.IPv4(0,0,0,0),
  Records: []Record{{Name: "iapi",   IP: net.IPv4(100,64,1,1)}}},
  {Name: "com.",       DefaultIP: net.IPv4(0,0,0,0),
  Records: []Record{{Name: "github", IP: net.IPv4(20,205,243,166)}}},
}
// query "iapi.sample.com." → matches sample.com. first → record "iapi"
//                        → returns 100.64.1.1 

I'd rather not encode this as a unit test — it would have to copy gvisor's matcher into our tests and would mislead future contributors. TestBuildAllowNetDNSZones_LongestSuffixWinsBeforeRoot already pins the contract on our side.

On DNS timeouts: doesn't happen as misreported — it just happens, on corporate networks with TLS scanners and proxy chains. Slow but legitimate resolution. The original code's context.Background() lookup didn't handle that error path at all; the new retry/fail-closed code does.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

All committers have signed the CLA.

Small scope nit on logBridgeBuild / bridgeBuildID: nice debugging aid, but it's unrelated to the allow_net fix and the hand-bumped "...allownet-dns-resilience-2026-06" constant will go stale (nobody will remember to bump it). Consider either splitting it into its own PR, or dropping the constant and logging just the auto-derived vcs.revision/vcs.modified/vcs.time fields so it never lies. The retry + fail-closed + longest-suffix-sort changes all look great. 👍

agreed, constant removed

solid fix — retry, fail-closed, and longest-suffix ordering each map cleanly onto the three root causes, and the injected-resolver tests are the right shape. two things i'd want resolved before merge, plus some cleanups.

signal handler inside the FFI export (main.go:985)

signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM) runs inside gvproxy_create, which is a //exported symbol called from the rust runtime embedded in the python/node/go/c SDKs — a host process that owns its own signal disposition. in c-shared mode every box.create transiently diverts the host's SIGINT/SIGTERM into go's signal machinery. a host app with its own SIGTERM handler (graceful shutdown, supervisor) could see different behavior during any create. the cancellation goal is right; a library grabbing process signals to achieve it is the part i'd push back on. can the cancellation be driven by a context the rust caller already controls across the FFI boundary instead? and was this exercised with an embedding process that installs its own handlers?

fail-closed doesn't cover ipv6-only hosts (dns_filter.go:299-329)

lookupWithRetry treats len(ips) > 0 as success, but resolveAndAddRecords then drops every non-v4 address (if ip.IP.To4() == nil { continue }). an allow-listed host that resolves AAAA-only gets a zone with zero A records, falls through to that zone's DefaultIP=0.0.0.0, and silently sinkholes — the exact symptom this PR sets out to kill. it's logged (v4_count=0) but not failed. meanwhile docs/reference/README.md:83-90 states create "fails — by design, so a half-baked sinkhole never silently sinkholes an allow-listed host to 0.0.0.0", which is only true for resolution errors, not v4-less results. the code and the doc guarantee disagree; one of them needs to move.

minor

• config_build comment above const dnsLookupAttempts says "exposed as var (not const) so tests can override timing" — it's describing the var (...) block below it but sits on the const. move it so the const isn't covered by an "exposed as var" sentence.
• dns_filter_test.go hand-rolls contains/indexOf instead of importing strings and calling strings.Contains — more code, more to get wrong, just import it.
• flakyResolver.successIPs and attemptHook are read but never set by any test — dead scaffolding, drop until something needs them.
• the zone sort uses sort.Slice (unstable) but the comment claims "deterministic" ordering — equal-length zone names get an unspecified order. doesn't affect correctness (equal length can't shadow), and the test only uses distinct-length names so it wouldn't catch a regression; use SliceStable or a lexical tiebreak if you want the comment to hold literally.
• dnsLookupInitialBackoffVar/dnsLookupAttemptTimeoutVar carry a Var suffix that dnsLookupBackoffFactor (also a var) doesn't — inconsistent, and it leaks "is a variable" into the name with no const counterpart to disambiguate from.

worth a note, not a blocker

• worst-case create latency on the failure path is sequential per host: ~4×2s timeouts + ~4s backoff ≈ 12s per unreachable host, so a 10-entry allow_net of dead hosts is ~2min before create fails (interruptible, modulo the signal issue above). a line in docs/reference would save someone the surprise.
• the longest-suffix test asserts slice order as a proxy for gvisor-tap-vsock's first-suffix-wins matching — reasonable since you can't easily drive the real matcher, but the whole fix rests on that upstream contract. a link to the gvisor-tap-vsock matcher code would harden it against an upstream behavior change the test can't see.