Die erste Fassung entstand vor der Caddy-Abnahme. Live erhoben, dagegen:
- adguard_bf1 (.20.16) ist ein Archiv, keine Vorlage: 24 Rewrites, davon 8
ins tote VLAN1, 9 auf den heute zerstoerten nginx-proxy-manager (LXC 128)
und 2 FritzBox-Reste. Uebernommen werden Upstreams/Filter, die Rewrites
entstehen neu aus caddy/Caddyfile.
- .20.17 ist nicht "bf2", sondern adguard_fm2 (FM-Standort) und antwortet
fuer gitea mit 10.40.41.123. BF hat heute EINEN AGH.
- Die TP5-Vorratsregeln erlauben LAN->DNS hart auf .20.16. Nach dem
DHCP-Flip wird DNS ein forward-Fluss ueber VLAN-Grenzen; ohne erweiterte
Regeln verlieren IOT/MEDIA/UNTRUSTED/GUEST/MGMT die Aufloesung, waehrend
VLAN20 weiterlaeuft und den Fehler tarnt.
Dazu neu: lease-time=1d macht Flip und Rollback traege (erst zur
Erneuerung wirksam), expliziter Rollback-Abschnitt, .36/.37 als frei
geprueft, und der Core bleibt bewusst Rueckfallebene.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Split-Horizon-Entscheid (AdGuard statt Core) macht aus 'ein paar
Eintraegen' eine Verschiebung der DNS-Aufloesung des ganzen Standorts in
einen Container -- heute liefert der DHCP in allen sieben VLANs den Core.
Das gehoert nicht ans Ende einer langen Sitzung (Lehre aus TP28).
Handoff enthaelt: Ausgangslage (Caddy produktiv, 16 Sites/17 Zertifikate),
den Auftrag in fuenf Schritten inkl. der IP-Kollision .30 (Nautobot) und
der Vorgabe, AGH als Paar 110/111 zu bauen statt als DNS-SPOF, sowie die
Staffelung VLAN fuer VLAN mit VLAN30 zuletzt.
Vier Fallen mitgegeben, alle in dieser Session bezahlt: Statuscode vom
oeffentlichen FQDN beweist nichts (grafana), pvesm free scheitert an
geschuetzten Snapshots stillschweigend, Startreihenfolge haengt nicht an
der VMID, und Core-Config braucht Golden Config.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
