Add AAAA for udm.renner.uno (fixes flapping UniFi integration in HA) #133

2026-07-08T23:45:12Z

k.renner commented

2026-07-08 23:45:12 +00:00

Problem

HA's UniFi Network integration intermittently drops to setup_error:
Cannot connect to host udm.renner.uno:443 … TLSV1_ALERT_INTERNAL_ERROR.

Root cause (verified, not the UDM)

UniFi auto-generates only the A record for its own hostname (udm → 192.168.8.1) and forwards AAAA queries upstream, where the *.renner.uno wildcard answers with proxy.renner.uno (the public reverse proxy). HA is IPv6-first, so over v6 it reaches the proxy, which rejects the unknown SNI → tlsv1 alert internal error. It only works when resolution lands on the A path — hence the flapping.

Resolution path confirmed: CoreDNS → k8s_gateway → (no ingress) → Proxmox DNS 10.2.40.53 → forwards renner.uno to the UDM 10.2.40.1 (authoritative).

Fix

Add an explicit udm AAAA → fd00::1 to the unifi_dns_record map (UniFi local DNS, the authoritative source):

fd00::1 serves the controller — cert CN=udm.renner.uno ✅
it's a ULA → doesn't rotate like the 2003:d6:* ISP GUAs ✅
reachable from the cluster — nodes have a v6 default route via the UDM ✅
matches the cert CN, so TLS verification also passes ✅

With a local AAAA present, UniFi answers it instead of forwarding upstream to the wildcard.

Verified

tofu fmt clean.
fd00::1 controller-serving + reachability checked via openssl s_client and talosctl get routes.

Watch on apply

If the UniFi provider / UDM rejects AAAA record types (UniFi's v6 record support is historically weak), the tofu apply is where it surfaces. After apply: confirm udm.renner.uno AAAA resolves to fd00::1 and the HA unifi entry stays loaded.

## Problem HA's UniFi Network integration intermittently drops to `setup_error`: `Cannot connect to host udm.renner.uno:443 … TLSV1_ALERT_INTERNAL_ERROR`. ## Root cause (verified, not the UDM) UniFi auto-generates only the **A** record for its own hostname (`udm → 192.168.8.1`) and **forwards AAAA queries upstream**, where the `*.renner.uno` wildcard answers with `proxy.renner.uno` (the public reverse proxy). HA is IPv6-first, so over v6 it reaches the **proxy**, which rejects the unknown SNI → `tlsv1 alert internal error`. It only works when resolution lands on the A path — hence the flapping. Resolution path confirmed: CoreDNS → k8s_gateway → (no ingress) → Proxmox DNS `10.2.40.53` → forwards `renner.uno` to the UDM `10.2.40.1` (authoritative). ## Fix Add an explicit `udm` **AAAA → `fd00::1`** to the `unifi_dns_record` map (UniFi local DNS, the authoritative source): - `fd00::1` **serves the controller** — cert `CN=udm.renner.uno` ✅ - it's a **ULA** → doesn't rotate like the `2003:d6:*` ISP GUAs ✅ - **reachable from the cluster** — nodes have a v6 default route via the UDM ✅ - matches the cert CN, so TLS verification also passes ✅ With a local AAAA present, UniFi answers it instead of forwarding upstream to the wildcard. ## Verified - `tofu fmt` clean. - `fd00::1` controller-serving + reachability checked via `openssl s_client` and `talosctl get routes`. ## Watch on apply If the UniFi provider / UDM rejects **AAAA** record types (UniFi's v6 record support is historically weak), the tofu apply is where it surfaces. After apply: confirm `udm.renner.uno` AAAA resolves to `fd00::1` and the HA `unifi` entry stays `loaded`.

k.renner added 1 commit 2026-07-08 23:45:12 +00:00

fix(dns): add AAAA for udm.renner.uno so HA's UniFi integration stops flapping

ci/woodpecker/push/deploy-infrastructure Pipeline was successful

Details

42be3a8f29

The UniFi Network integration in Home Assistant intermittently drops to
setup_error with:
  Cannot connect to host udm.renner.uno:443 ... TLSV1_ALERT_INTERNAL_ERROR

Root cause is IPv6, not TLS or the UDM. UniFi auto-generates only the A
record for the UDM's own hostname (udm -> 192.168.8.1) and forwards AAAA
queries to its upstream, where the *.renner.uno wildcard answers with
proxy.renner.uno (the public NetBird reverse proxy). HA is IPv6-first, so
it resolves udm.renner.uno to the proxy over v6 and gets its handshake
rejected (unknown SNI -> tlsv1 alert internal error). The integration
recovers only when resolution happens to land on the working A path.

Pin an explicit AAAA to the UDM's own management ULA fd00::1:
- verified serving the controller (cert CN=udm.renner.uno),
- a ULA, so it doesn't rotate like the ISP 2003:d6:* GUAs,
- reachable from the cluster via the node v6 default route (UDM ll gw).

With a local AAAA present, UniFi answers it itself instead of forwarding
upstream, so v6-first clients reach the controller. Because the record
matches the cert CN, TLS verification also passes.

Applied via the unifi_dns_record resource (UniFi local DNS) on tofu apply.
Watch the apply: if the UniFi provider/UDM rejects AAAA record types, this
is the point it surfaces.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

k.renner merged commit 37b7f2230e into master

2026-07-08 23:45:47 +00:00

k.renner referenced this issue from a commit

2026-07-08 23:45:48 +00:00

Merge pull request 'Add AAAA for udm.renner.uno (fixes flapping UniFi integration in HA)' (#133) from feat/udm-aaaa-record into master

k.renner referenced this pull request

2026-07-08 23:55:19 +00:00

Add AAAA for captive.renner.uno (same UniFi v6 gap as udm) #134

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#133