atenet/egress: resolve upstream names on both address families - #1060
Open
Yuan Gao (ygao-g) wants to merge 1 commit into
Open
atenet/egress: resolve upstream names on both address families#1060Yuan Gao (ygao-g) wants to merge 1 commit into
Yuan Gao (ygao-g) wants to merge 1 commit into
Conversation
Yuan Gao (ygao-g)
marked this pull request as draft
August 19, 2026 16:12
Yuan Gao (ygao-g)
force-pushed
the
atenet-egress-dns-lookup-family
branch
from
August 19, 2026 22:34
1898a7f to
de81578
Compare
Yuan Gao (ygao-g)
force-pushed
the
atenet-egress-dns-lookup-family
branch
3 times, most recently
from
August 20, 2026 15:16
e1c077a to
0772d77
Compare
Yuan Gao (ygao-g)
marked this pull request as ready for review
August 20, 2026 16:07
Yuan Gao (ygao-g)
force-pushed
the
atenet-egress-dns-lookup-family
branch
3 times, most recently
from
August 20, 2026 19:34
3a9ea53 to
778b9d7
Compare
Yuan Gao (ygao-g)
force-pushed
the
atenet-egress-dns-lookup-family
branch
2 times, most recently
from
August 20, 2026 21:05
88d823c to
2285bd1
Compare
The egress gateway's dynamic forward proxy pinned dns_lookup_family to V4_ONLY at all seven sites, so Envoy only ever resolved the A record. On an IPv6-only cluster there is no A record to find, and the gateway cannot resolve upstream names at all. All seven now use ALL, which returns both families and lets Envoy Happy-Eyeballs between them. AUTO will not do: it returns AAAA whenever the name has one, leaving no A address to retry when that AAAA is unroutable. A test walks the shipped manifests and requires ALL on every dns_cache_config, so a new egress variant cannot reintroduce the pin -- the seventh site arrived with the sdsmint MITM leg while this change was in review, and the test caught it.
Yuan Gao (ygao-g)
force-pushed
the
atenet-egress-dns-lookup-family
branch
from
August 20, 2026 21:36
2285bd1 to
7d533ae
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #246
The egress Envoy pinned
dns_lookup_familytoV4_ONLYin both the dynamicforward proxy filter and the dynamic forward proxy cluster. On an IPv6-only
cluster every upstream connection failed: Envoy reported a DNS resolution
failure and the actor got a 503. Seven sites across the two egress manifests,
including the sdsmint variant, now use
ALL, which returns both families andenables Happy Eyeballs.
This is a prerequisite for IPv6 egress, not the fix on its own. An actor's
connection is redirected by nftables and atunnel recovers the original
destination with
getsockopt(SOL_IP, SO_ORIGINAL_DST), which returns ENOENTfor a v6-redirected connection — so egress fails before Envoy is ever asked to
resolve anything.
Testing
make verifyis clean. A new test walks the shipped manifests and requiresALLon everydns_cache_config, so a new egress variant cannot reintroducethe pin. It has already paid for itself: the seventh site arrived with the
sdsmint MITM leg while this was in review, still pinned to
V4_ONLY, and thetest caught it on rebase.
Measured on an IPv6-only kind cluster with #911, #958, #979 and #753 applied.
Each value was deployed, Envoy restarted, and the live
/config_dumpcheckedbefore running the suites:
dns_lookup_familyTestActorEgress/TestActorEgressHTTPSALL(shipped)code=200to[2606:4700:10::ac42:93f3]:80V4_ONLY(before)code=503 flags=DFAUTOAUTOis not distinguishable fromALLon this path: the dynamic forwardproxy is handed the IP literal that atunnel recovered, never a hostname, so
dns_lookup_familyonly decides which literal families it accepts.ALLischosen as the value that strands neither family.
The IPv4 lane is unaffected:
TestActorEgressandTestActorEgressHTTPSpasswith the change in place, across two runs of the standard e2e job.
🤖 Generated with Claude Code