BACKLOG.md: DNS-Bereinigung bei IONOS aufnehmen

IONOS legt pro Subdomain automatisch einen Mail-Satz (MX, SPF,
DKIM-CNAMEs, autodiscover) und ein www.-Paar an, auch fuer Hosts ohne
Mail. Betrifft selendis und matrix vollstaendig, rohana und game nur
beim www.-Paar.

Ersatzloses Loeschen waere schlechter: ohne SPF gibt es keine Aussage
mehr, und ohne MX weichen Absender per RFC 5321 auf A/AAAA aus -- Mail
an @rohana.axion1337.de landete dann auf Port 25 des Hosts. Richtig ist
Null-MX (RFC 7505) plus SPF -all plus DMARC p=reject.

Konkrete Record-Listen fuer rohana und selendis dokumentiert; der User
setzt diese beiden direkt um. game, matrix, ftp und die Apex-DMARC-
Policy bleiben offen -- bei matrix erst klaeren, ob der Server Mail mit
Absender @matrix.axion1337.de verschickt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

BACKLOG.md

@@ -66,7 +66,95 @@ funktioniert also ohnehin nicht.
 **Empfehlung:** A- und AAAA-Record für `www.rohana` löschen. Es geht nichts
 verloren. Die Alternative — Router plus Cert-SAN für den zweiten Namen — bedeutet
 mehr Teile, die bei jeder Erneuerung mitvalidieren müssen, ohne Nutzen. Für
-`selendis` aus demselben Grund kein `www.` anlegen.
+`selendis` aus demselben Grund kein `www.` anlegen. Siehe Punkt 3 für die
+vollständige DNS-Bereinigung.
+
+---
+
+## 3. DNS-Bereinigung bei IONOS
+
+**Status:** `rohana` und `selendis` werden vom User direkt umgesetzt (2026-07-30),
+`game` / `matrix` / `ftp` / Apex noch offen
+
+Die Zone liegt bei IONOS (`ns10xx.ui-dns.*`), Zonentransfer ist verweigert — die
+Records unten stammen aus gezielten Abfragen und der IONOS-Oberfläche, die Liste
+ist daher **nicht garantiert vollständig**. Für eine vollständige Prüfung entweder
+die ungefilterte IONOS-Liste durchgehen oder die Certificate-Transparency-Logs
+abfragen.
+
+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. Bei `selendis` und `matrix` ist das passiert, bei `rohana` und
+`game` nur das `www.`-Paar.
+
+### Warum nicht einfach löschen
+
+Ersatzloses Entfernen der Mail-Records ist die schlechtere Variante:
+
+- 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 daher, „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 komplett
+aus): `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 die IONOS-Oberfläche `.` als MX-Ziel ablehnt: MX löschen und nur die TXT-
+Records setzen. `-all` und `p=reject;` greifen trotzdem.
+
+### Noch offen
+
+- **`www.game`, `www.matrix`** (A-Records): dasselbe überflüssige Muster, aber auf
+  fremden Hosts — nicht verifiziert, ob dort etwas darauf hört.
+- **`matrix.axion1337.de`**: gleicher Mail-Satz wie `selendis`, aber **erst prüfen**,
+  ob der Matrix-Server Benachrichtigungsmails mit Absender
+  `…@matrix.axion1337.de` verschickt. Wenn ja, müssen SPF und DKIM dort bleiben und
+  auf den echten Absender zeigen. `autodiscover.matrix` kann in jedem Fall weg —
+  Matrix-Föderation läuft über `.well-known` bzw. SRV.
+- **`ftp.axion1337.de`** → `217.160.233.227`: IONOS-Default aus dem Hosting-Paket,
+  zeigt auf IONOS und nicht auf eigene Infrastruktur. Löschen, falls dort kein FTP
+  genutzt wird.
+- **Apex-DMARC ist `v=DMARC1; p=none;`** — reines Monitoring, kein Schutz. Ohne
+  `sp=`-Angabe erben alle Subdomains dieses `p=none`. `sp=reject` am Apex wäre der
+  effiziente Hebel für alle Subdomains inklusive künftiger, **aber erst nach**
+  Klärung von `matrix`, sonst bricht dessen Mailversand.
+- **`game.axion1337.de` ist `157.90.155.206`** — derselbe Host wie in Punkt 2, den
+  Prometheus per roher IP scrapt. Der Name wäre die wartbarere Variante.
 
 ---