From 9399df0f8aaeaf3d3fdf50c7e07559376fb096c0 Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Sat, 15 Aug 2026 12:00:00 +0000 Subject: [PATCH] =?UTF-8?q?docs(issues):=20#0027=20W1=20measured=20?= =?UTF-8?q?=E2=80=94=20no=20divergence,=20and=20correct=20my=20overstateme?= =?UTF-8?q?nt?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Queried the lab resolver directly from inside the lab VLAN and compared every record type against the public view: A, MX, TXT, CNAME, subdomains that exist only publicly, plus records created and deleted yesterday. Not a single divergence — the UDM holds no zone of its own and forwards live; the aa flag it sets is a UniFi quirk and was what made the hypothesis look plausible. That disproves the risk I asserted earlier in this issue, where I called the pinned ACME resolvers 'load-bearing'. They are good practice, not a safety net against W1, and the claim stood as fact for an hour. Corrected in place. W1 is therefore documentation-only. What remains is that the purpose of the three extra zones is recorded nowhere, which is why a blind rollback is the worse option. Co-Authored-By: Claude Opus 4.8 --- ...01-acht-widersprueche-aus-dem-labnet-02.md | 46 +++++++++++++++++-- 1 file changed, 41 insertions(+), 5 deletions(-) diff --git a/docs/issues/0027-audit-01-acht-widersprueche-aus-dem-labnet-02.md b/docs/issues/0027-audit-01-acht-widersprueche-aus-dem-labnet-02.md index c8e147e..4deb906 100644 --- a/docs/issues/0027-audit-01-acht-widersprueche-aus-dem-labnet-02.md +++ b/docs/issues/0027-audit-01-acht-widersprueche-aus-dem-labnet-02.md @@ -158,11 +158,16 @@ autoritativ (im Lab wurde genau das beobachtet: lokale Antworten mit gesetztem ` sähe Traefik den frisch gesetzten TXT **nie** — die Erneuerung liefe in den Timeout, und zwar **still**, bis die Zertifikate ablaufen. -Das passiert aktuell **nicht**, weil die Konfiguration die Prüf-Resolver explizit festnagelt: -`--certificatesresolvers.letsencrypt.acme.dnschallenge.resolvers=1.1.1.1:53,8.8.8.8:53` -(`thread-net-git`, Commit `8d089e2`). Diese Zeile ist damit **tragend**, nicht kosmetisch — -sie umgeht genau die Zone aus W1. Wer sie beim nächsten Aufräumen für überflüssig hält, -bricht die Zertifikatserneuerung, ohne es zu merken. +Die Konfiguration nagelt die Prüf-Resolver ohnehin fest +(`--certificatesresolvers.letsencrypt.acme.dnschallenge.resolvers=1.1.1.1:53,8.8.8.8:53`, +`thread-net-git` `8d089e2`), womit die Frage für den ACME-Pfad praktisch nicht auftritt. + +⚠️ **Korrektur (gleicher Tag, nach der Messung unten):** Ich hatte diese Zeile hier zunächst +als **tragend** bezeichnet — also behauptet, ohne sie bräche die Zertifikatserneuerung. Das +war **überzogen**: die Messung zeigt, dass der Lab-Resolver die Zone live nach oben +weiterreicht und den TXT damit sehr wahrscheinlich sähe. Die Festnagelung bleibt gute Praxis +(deterministisch, umgeht Negativ-Caching), ist aber **kein Sicherheitsnetz gegen W1**. Die +Hypothese war plausibel und ist widerlegt — sie stand hier eine Stunde lang als Tatsache. **Was weiterhin ungeprüft ist:** was die UDM für `axion1337.de` tatsächlich zurückgibt. Prüfbefehle (auf CFGMON): @@ -183,3 +188,34 @@ Zonen, mit Begründung warum `~axion1337.de` überhaupt ins Lab zeigt) **oder** `~lab`. Für den Rückbau spricht, dass der Zweck der übrigen drei Zonen nirgends festgehalten ist; für das Nachführen spricht, dass sie auf sorbs Ansage entstanden sind — es gab also einen Grund, er steht nur nicht im ADR. + +### W1 — gemessen 2026-08-15: keine Abweichung, reines Doku-Problem + +Der Lab-Resolver wurde direkt abgefragt (vom Mac aus dem Lab-VLAN `10.58.73.26`, UDM +`10.58.73.1:53` erreichbar) und Record für Record gegen die öffentliche Sicht (DoH) gestellt: + +| Abfrage | UDM | öffentlich | +|---|---|---| +| `rohana` A | `188.245.193.243` | identisch | +| `selendis` A | `188.245.193.243` | identisch | +| `axion1337.de` MX / TXT (SPF) | `10 mx00/mx01.ionos.de` / `v=spf1 …~all` | identisch | +| `_dmarc` TXT, `s1-ionos._domainkey` CNAME | vorhanden | identisch | +| `status`, `crypt` A (nur öffentlich existent) | korrekt | identisch | +| **gestern angelegt:** `rohana` MX `0 .`, `_dmarc.rohana`, `rohana` SPF `-all` | **vorhanden** | identisch | +| **gestern gelöscht:** `www.rohana`, `ftp` | **leer** | leer | + +**Ergebnis: keine einzige Abweichung** — auch nicht bei Records, die erst gestern entstanden +bzw. gelöscht wurden. Die UDM hält **keine eigene Zone**, sondern reicht live nach oben durch; +das gesetzte `aa`-Flag ist eine Eigenheit des UniFi-Resolvers und war der irreführende Teil, +der die Hypothese überhaupt nahegelegt hat. + +**Damit ist die im Audit befürchtete Brisanz ausgeräumt:** Der Pfad zum Gitea-Mirror ändert +sich nicht unbemerkt, weil der Lab-Resolver dieselben Daten liefert. **W1 ist ein reines +Dokumentationsproblem**, kein Betriebsrisiko. + +**Was bleibt:** ADR-0004 beschreibt eine Zone, real sind es vier — und der **Zweck der drei +Zusatzzonen ist nirgends festgehalten**. Das ist die eigentliche Lücke: Ohne diesen Grund kann +niemand entscheiden, ob ein Rückbau auf `~lab` etwas kaputtmacht. Empfehlung daher: +**ablösender ADR mit dem As-built-Stand** samt Begründung (sorb kennt sie), statt eines +Rückbaus ins Blinde. Die Messung oben gehört als Beleg hinein — sie zeigt, dass die Zonen +heute schadlos sind.