vh
32349b7653
Rewrites the in-flight section, which had gone stale in one place (speaches is stopped, not live) and did not reflect a session in which everything opened was also closed. Three detail files carry the bulk: the FortiGate's public surface reduced to nothing including the ACME listener, Scriberr's deployment and the three upstream defects it required working around, and the ESH DNS repair that also made the IPv6 naming scheme real on three hosts. The tunnel entry in the decisions log described a cipher change as proposed and pending; it has since been attempted, found impossible in the form intended, and resolved differently, so the line now points at the outcome rather than the intention. New decisions cover the cipher adoption and the finding that the per-flow ceiling belongs to the UniFi gateway's software cipher rather than the firewall, the administrative closure, the transcription deployment, the DNS repair, the retirement of an ASR service whose only consumer was abandoned, and a database VM that until now had no fleet identity and no vaulted credential at all. Three approaches are recorded as abandoned: an AEAD cipher the far end cannot express, an upstream DNS setting the gateway accepts and ignores, and a scheme to claim unused delegated prefixes that founders not on the prefixes but on having to rebuild a firewall policy to use them.
3.7 KiB
[2026-08-24] ESH DNS fixed at the IPv6 layer, and the naming scheme went live
Reported as "scriberr.ana.internal doesn't resolve on my Mac, and nslookup
shows an IPv6 DNS server." Operator's diagnosis was right; the fix took three
wrong turns worth recording.
Root cause
esh-userland has IPv6 PD with RA at pref high, and the UDM advertises
itself as the resolver via RDNSS. macOS honours RDNSS and prefers it over
the DHCPv4-supplied resolver, so queries went to the UDM — which does not know
.internal — and returned NXDOMAIN. AdGuard was never consulted.
Two adjacent gaps found while there: esh-userland's secondary v4 resolver
was 10.0.10.1 (the UDM itself), and esh-server had DNS handout disabled
entirely, so every host there got the UDM and could never resolve .internal
— esh-docker-vm was living proof.
The three wrong turns
dhcpdv6_dns_auto=falsealone does nothing. It is only honoured when an explicit server is supplied. Setting it bare looks like a no-op and invites the conclusion that the field is inert — which I drew, wrongly. Despite thedhcpdv6_prefix it does drive the RA's RDNSS option on a SLAAC network.wan_dns1is NOT used by the UDM's LAN-facing forwarder. Setting it to AdGuard persists, reads back, and changes nothing. Proven with fresh uncached ad domains — AdGuard blocklists answer0.0.0.0, the UDM returned real IPs. Reverted.force-provisionreturnsrc:okand proves nothing — consistent with the knowncmd/devmgrbehaviour.
Every failed attempt returned rc: ok. Verify by observed effect. RAs were
probed with a stdlib raw-socket Router Solicitation parsing option type 25
(rdisc6/tcpdump were both absent; nothing was installed).
What landed
RDNSS redirected rather than disabled — better than switching it off:
| VLAN | v4 | v6 RDNSS |
|---|---|---|
esh-userland |
10.0.50.45 + 10.100.50.40 | …:4411:b105:50:45 |
esh-server |
10.0.50.45 + 10.100.50.40 | …:4411:b105:50:45 |
The v4 secondary moved from the UDM to the NH3 AdGuard — reachable over
Site Magic and authoritative for the zone. ⚠ A secondary only fails over on
SILENCE, not on wrong answers: NXDOMAIN is a successful answer, the client
accepts it and never retries. A secondary that doesn't know your private zone is
a coin flip, not a spare tyre. esh-cameras deliberately untouched — routing
camera DNS through AdGuard's filtering risks their cloud features.
The naming scheme became real
The resolver address is the scheme's first live use, replacing a MAC-derived
SLAAC address that would break on a NIC change. All three esh-server Linux
hosts now carry 4411:B105 ("FOR ALL BIOS"):
esh-docker-vm …:4411:b105:50:45 esh-pve-nas …:4411:b105:50:55
esh-vm-db …:4411:b105:50:60
Applied by an if-up.d hook that derives the prefix at runtime (self-heals
on re-delegation), backgrounds itself with a retry (SLAAC may not have landed;
a blocking hook would stall bring-up on a headless box), and adds nothing to
existing config. Not an iface … inet6 static stanza — on Debian that sets
accept_ra=0 and would strand the host.
⚠ Proxmox bridges need accept_ra=2. esh-pve-nas had link-local only
despite every sysctl looking right: vmbr0.forwarding=1, and the kernel ignores
RAs on a forwarding interface unless accept_ra is explicitly 2. Fixed with
accept_ra_defrtr=0 alongside, so it takes the prefix but declines the default
route — an IPv6 identity with no change to a hypervisor's routing. Expect this
on every Proxmox node when its LAN gets v6.
Canonical: docs/pfi/ipv6-naming-scheme.md. UniFi limits:
auto-memory reference_unifi_dns_rdnss_limits.