Framework-Umbau: Backlogs wird management-Repo (ADR-0005, Kanban + Scrum-Elemente)

- decisions/: ADR-Verzeichnis mit Template + 0001-0005 (git.lab-Kanonik, Lab-Cutover, CVE-Meldeweg, Site-to-Site-VPN-Design, Framework-Wahl) - vision/: je eine Vision fuer Community/Tool/Plattform (Entwuerfe) - roadmap.md: Linien, Meilenstein-Kandidaten, Kadenz - hosts/+shared/: offene Punkte -> Issues #1-#12 im management-Projekt (IDs bleiben in den Titeln), Dateien halten Bestand + Historie - README: Framework, Board/status-Labels (WIP-Limit 2), Topologie Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
2026-08-01 12:00:00 +00:00
parent 0f3f155bc5
commit fdf30d42e1
18 changed files with 429 additions and 523 deletions
@@ -26,8 +26,7 @@ Damit ist die Cutover-Voraussetzung für gitops#48 erfüllt.
   fremde Hosts funktionierten) → Fix: **VPN-Subnetz auf 10.58.74.0/24** (Docker
   fasst 10.x nie an).

-**Restarbeiten:** MacBook-WG-Profil auf neue Adresse (10.58.74.2/32) und Endpunkt
-`178.25.213.70:51840` nachziehen (sorb, 2 min). ⚠️ Latente Wiederholungsgefahr
+**Restarbeiten:** MacBook-WG-Profil → [Issue #11](https://git.lab/axion1337.chat/management/-/issues/11). ⚠️ Latente Wiederholungsgefahr
 notiert: Overminds Docker-Pool deckt auch `192.168.176.0/20` ab = kollidiert mit
 dem Fritzbox-Netz 192.168.178.x — aktuell folgenlos, aber bei künftigen Subnetz-
 Entscheidungen 192.168.x auf Overmind grundsätzlich meiden (oder Docker
@@ -72,3 +71,13 @@ für das VLAN.

 **Verwandt:** gitops#48 (Cutover erst nach Lösung), perspektivisch ersetzt ein
 funktionierender Roadwarrior auch Ad-hoc-Wünsche wie „GitLab exponieren".
+
+## Offene Punkte → git.lab-Issues
+
+Seit dem Framework-Umbau (2026-08-01) leben offene Punkte als Issues im
+[management-Projekt](https://git.lab/axion1337.chat/management/-/issues); die IDs bleiben in den Issue-Titeln erhalten.
+Dieses File hält nur noch Bestand und Historie.
+
+- [LABNET-01-Rest — MacBook-WireGuard-Profil nachziehen](https://git.lab/axion1337.chat/management/-/issues/11)
+- [LABNET-02 — Site-to-Site-VPN Hetzner-Projektnetz ↔ Lab (Design: ADR-0004)](https://git.lab/axion1337.chat/management/-/issues/12)
+
@@ -32,139 +32,12 @@ Host trennen lässt.
 Mail-Records existieren auf `selendis` und `matrix` (MX ×2, SPF, DKIM-CNAMEs,
 `autodiscover`), auf `rohana` und `game` nicht.

---
+## Offene Punkte → git.lab-Issues

-## ZONE-01 — IONOS-Default-Records bereinigen
+Seit dem Framework-Umbau (2026-08-01) leben offene Punkte als Issues im
+[management-Projekt](https://git.lab/axion1337.chat/management/-/issues); die IDs bleiben in den Issue-Titeln erhalten.
+Dieses File hält nur noch Bestand und Historie.

-**Status:** `rohana` und `selendis` in Arbeit (User setzt direkt um, 2026-07-30);
-`game`, `matrix`, `ftp` offen
+- [ZONE-01 — IONOS-Default-Records bereinigen (Rezepte im Issue; rohana/selendis in Arbeit)](https://git.lab/axion1337.chat/management/-/issues/5)
+- [ZONE-02 — Apex-DMARC ist `p=none` und schützt nichts](https://git.lab/axion1337.chat/management/-/issues/6)

-IONOS legt beim Anlegen einer Subdomain automatisch einen kompletten Mail-Satz mit an
-— MX, SPF, DKIM-CNAMEs, `autodiscover` — und ein `www.`-Paar. Auch für Hosts, auf
-denen nie Mail läuft.
-
-### Warum `www.` bei einer Subdomain überflüssig ist
-
-Das Muster stammt aus der Zeit, als der Webserver einer Domain der Host `www` war,
-und hält sich für **Apex-Domains**: `axion1337.de` und `www.axion1337.de` sollen
-dasselbe liefern, weil Leute beides tippen. Beim Apex ist das also richtig und bleibt.
-
-Auf eine Subdomain überträgt es sich nicht. `rohana.axion1337.de` **ist** schon der
-Hostname des Dienstes; `www.rohana.axion1337.de` heißt wörtlich „der Webserver des
-Webservers". Das tippt und verlinkt niemand.
-
-Verifiziert für `www.rohana` und `www.selendis`: kein Traefik-Router matcht die Namen,
-Traefik liefert sein `TRAEFIK DEFAULT CERT` aus, TLS bricht mit Zertifikatsfehler ab.
-Die Namen funktionieren also ohnehin nicht — wer dort landet, sieht etwas Kaputtes.
-Sie zum Funktionieren zu bringen hieße Router plus Cert-SAN, also mehr Teile, die bei
-jeder Erneuerung mitvalidieren müssen, für null Nutzen.
-
-### Warum die Mail-Records nicht ersatzlos gelöscht werden
-
-Zwei Fallstricke, die Löschen zur schlechteren Variante machen:
-
- Ohne SPF existiert **keine Aussage** darüber, wer als dieser Name senden darf. Das
-  bestehende `~all` ist nur Softfail und wird von vielen Empfängern akzeptiert — eine
-  ungenutzte Subdomain mit gültigen MX und Softfail-SPF ist ein brauchbarer
-  Spoofing-Vektor.
- **Fehlt ein MX-Record, weichen Absender per RFC 5321 auf A/AAAA aus.** Mail an
-  `@rohana.axion1337.de` würde also Port 25 auf `188.245.193.243` ansprechen.
-
-Richtig ist, „hier gibt es keine Mail" explizit zu erklären: Null-MX (RFC 7505), SPF
-`-all`, DMARC `p=reject`.
-
-### rohana.axion1337.de
-
-**Löschen:** `A www.rohana`, `AAAA www.rohana`
-
-**Anlegen:**
-
-| Typ | Name | Wert |
-|---|---|---|
-| MX | `rohana` | `.` (Priorität 0) |
-| TXT | `rohana` | `v=spf1 -all` |
-| TXT | `_dmarc.rohana` | `v=DMARC1; p=reject;` |
-
-**Nicht anfassen:** `A rohana`, `AAAA rohana` — daran hängen Gitea und das Zertifikat.
-
-### selendis.axion1337.de
-
-**Löschen:** `MX mx00.ionos.de`, `MX mx01.ionos.de`,
-`CNAME s1-ionos._domainkey.selendis`, `CNAME s2-ionos._domainkey.selendis`,
-`CNAME s42582890._domainkey.selendis`, `CNAME autodiscover.selendis`,
-`A www.selendis`, `AAAA www.selendis`
-
-**Ändern** — den bestehenden TXT editieren, **nicht** einen zweiten anlegen: zwei
-SPF-Records auf einem Namen ergeben einen PermError, die Prüfung fällt dann komplett
-aus.
-
-| Typ | Name | von | auf |
-|---|---|---|---|
-| TXT | `selendis` | `v=spf1 include:_spf-eu.ionos.com ~all` | `v=spf1 -all` |
-
-**Anlegen:** `MX selendis` = `.` (Priorität 0), `TXT _dmarc.selendis` =
-`v=DMARC1; p=reject;`
-
-**Nicht anfassen:** `A selendis`, `AAAA selendis`.
-
-**Vorab prüfen:** ob im IONOS-Mail-Bereich ein Postfach oder eine Weiterleitung für
-`selendis.axion1337.de` existiert. Wenn ja, entfallen die MX-Änderungen.
-
-**Falls IONOS `.` als MX-Ziel ablehnt** — kommt vor: MX löschen und nur die
-TXT-Records setzen. `-all` und `p=reject;` greifen trotzdem, es fehlt nur die
-explizite „nimmt keine Mail an"-Aussage.
-
-### Noch offen
-
- **`game`** und **`matrix`**: `www.`-Records, siehe
-  [GAME-02](../hosts/game.md#game-02--wwwgameaxion1337de-ist-überflüssig) und
-  [MATRIX-03](../hosts/matrix.md#matrix-03--wwwmatrixaxion1337de-ist-überflüssig).
- **`ftp.axion1337.de`** → `217.160.233.227`: IONOS-Default aus dem Hosting-Paket,
-  zeigt auf IONOS und nicht auf eigene Infrastruktur — also keine zusätzliche
-  Angriffsfläche, aber Ballast. Löschen, falls dort kein FTP genutzt wird.
-
-### Geklärt: Mail-Records auf `matrix`
-
-[MATRIX-01](../hosts/matrix.md#matrix-01--klären-ob-der-server-mail-als-matrixaxion1337de-verschickt--erledigt-2026-07-30)
-ist erledigt (2026-07-30): weder Synapse noch MAS versenden Mail (per Config verifiziert,
-nicht nur vermutet — Registrierung/Reset laufen über Authentik). Der komplette Mail-Satz
-auf `matrix.axion1337.de` kann damit genauso gehärtet werden wie bei `selendis`
-(Null-MX, `v=spf1 -all`, `_dmarc p=reject`), siehe ZONE-01 oben. Separat davon läuft seit
-2026-07-30 echter, unabhängiger Mailversand über das **Apex**-Postfach
-`wartung@axion1337.de` (Host-Wartungsbenachrichtigungen) - betrifft die
-`matrix.`-Subdomain-Records nicht, bestätigt aber, dass am Apex weiterhin reale
-IONOS-Mail-Infrastruktur aktiv genutzt wird.
-
-**Nach der Umsetzung von hier aus verifizieren:** dass `www.rohana` und
-`www.selendis` nicht mehr auflösen; dass MX, SPF und DMARC greifen und **nur ein**
-SPF-Record pro Name existiert; und dass `A`/`AAAA` von `rohana` und `selendis`
-unverändert sind und Gitea sowie Grafana weiter über HTTPS antworten. Der letzte
-Punkt ist der, bei dem ein Verklicker in der IONOS-Oberfläche wehtun würde.
-
---
-
-## ZONE-02 — Apex-DMARC ist `p=none` und schützt nichts
-
-**Status:** offen — nicht mehr blockiert, [MATRIX-01](../hosts/matrix.md#matrix-01--klären-ob-der-server-mail-als-matrixaxion1337de-verschickt--erledigt-2026-07-30) ist seit 2026-07-30 erledigt
-
-`_dmarc.axion1337.de` enthält `v=DMARC1; p=none;` (via `dmarc.ionos.de`). Das ist
-reines Monitoring: Empfänger melden Verstöße, verwerfen aber nichts. Für gefälschte
-Mail in deinem Namen ist das kein Hindernis.
-
-Zusätzlich fehlt eine `sp=`-Angabe. Ohne sie **erben alle Subdomains dieses
-`p=none`** — auch solche, die nie Mail senden, und auch künftige.
-
-`sp=reject` am Apex wäre daher der effiziente Hebel: deckt alle Subdomains auf einmal
-ab, inklusive der noch nicht angelegten, und macht die einzelnen `_dmarc`-Records aus
-ZONE-01 auf Dauer entbehrlich.
-
-**Reihenfolge ist hier wichtig.** Zuerst [MATRIX-01](../hosts/matrix.md) klären, dann
-für jeden Namen, der tatsächlich Mail versendet, SPF und DKIM korrekt setzen — erst
-danach `sp=reject`. Umgekehrt zerlegt es den Mailversand der betroffenen Dienste, und
-zwar unbemerkt, weil verworfene Mail beim Absender keinen Fehler produziert.
-
-Für den Apex selbst (dort läuft echte Mail über IONOS) wäre der übliche Weg, `p=none`
-erst auf `p=quarantine` zu ziehen, die DMARC-Reports eine Weile zu beobachten und dann
-auf `p=reject` zu gehen. Auffällig: unter `s1._domainkey.axion1337.de` war kein
-DKIM-Record auffindbar, obwohl die Subdomains DKIM-CNAMEs von IONOS haben — das wäre
-beim Härten mitzuprüfen.