hack: fix DNS on IPv6-only kind clusters

[Yuan Gao (ygao-g)]

Part of #246.

• Tests pass
• Appropriate changes to documentation are included in the PR (none needed — the new IPV6_DNS_UPSTREAM knob is documented in the scripts' --help)

---

On a fresh IP_FAMILY=ipv6 cluster nothing resolves from inside a pod and no actor boots: CoreDNS runs dnsPolicy: Default and inherits the node's IPv4 resolver, which a v6-only pod cannot reach. Two Corefile clauses fix it — a forward to an IPv6 upstream, overridable with IPV6_DNS_UPSTREAM, and a hosts entry for kind-registry, which step 3 wires into containerd on the node but atelet pulls from its own pod netns. IPv4 and dual-stack pods get both names from Docker's embedded resolver, so this is gated on ipv6 and those families are untouched.

hack/verify-ipv6-dns.sh proves it and runs last in create-kind-cluster.sh, but stays separate so a live cluster can be re-checked: the hosts entry records an address the registry can move off, and the script names that case instead of blaming a registry that is down (#1049). CI has no IPv6 job (#939 is signal-only), so it runs by hand; results in a comment below. atenet-egress still crashloops on v6-only, for an unrelated Envoy bind bug.

🤖 Generated with Claude Code

[Yuan Gao (ygao-g)]

Testing

Each check is paired with a control that must fail — the failure mode this guards against is a probe that passes without proving anything.

• IPv6-only. IP_FAMILY=ipv6 hack/create-kind-cluster.sh → --deploy-ate-system → --deploy-demo-counter: atelet pulls the gVisor tarball from storage.googleapis.com over IPv6 from its own pod netns, the actor image pulls through kind-registry, and a golden actor runs and checkpoints. 11 of 11 fresh clusters exit 0 on a single probe pod. hack/run-e2e-kind.sh: demo 19/0/5 with a skip set identical to the IPv4 control, networking 7/2 — both failures are atenet-egress crashlooping on v6-only for an unrelated Envoy bind.
• Controls. IPV6_DNS_UPSTREAM=2001:db8::1 exits 1 in ~28s, naming each replica that did not answer. Pointing the hosts entry at an address the registry is not on exits 1 with the Corefile says [...] but the registry is at [...] — the hack: IPv6-only kind clusters resolve a stale registry address #1049 case, told apart from a registry that is down. The stock Corefile fails the probe; dropping only the hosts block leaves external names working and the registry fetch failing.
• IPv4 regression. Step 4.5 and the verifier do not run, the Corefile keeps forward . /etc/resolv.conf, and the demo stays green. dual takes the same path.

CI has no IPv6 job and this PR does not add one — #939 is a signal-only draft that produces that coverage on demand.

[Yuan Gao (ygao-g)]

Ping — this one is a two-file hack/ change, and it unblocks the IPv6-only CI job in #939, which carries it verbatim and can't merge first.

Worth knowing that the branch has moved since it was last looked at. Two commits went on, both fixes for defects I hit while trying to run it rather than responses to review: the DNS gate was reporting green with one of kind's two CoreDNS replicas unable to resolve, and the IPv6-only kubeconfig repoint was replacing a working apiserver address with a refused one on a native-Linux Docker host, which killed every kubectl after it.