Thore CimbalandClaude Sonnet 5
15396d53e8
MATRIX-01 (Mail-Absender-Frage): per Config verifiziert, dass weder Synapse noch MAS Mail versenden - kein Konfigurationsblock in den deployten Werten. MATRIX-02: Korrektur einer falschen Annahme - "k3s-Host (10.0.0.2)" und "matrix" sind dieselbe Maschine, nicht zwei getrennte. Remote-Write nutzt bereits die private IP. MATRIX-04 neu: Host-Level Pre-Update-Benachrichtigung (Issue #24). Cross-Referenzen in zone-axion1337.md (ZONE-02 entblockt) und cfgmon.md (CFGMON-03-Update, neues CFGMON-08 fuer die Gitea-Runner-Standortfrage) aktualisiert. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
171 lines
8.1 KiB
Markdown
171 lines
8.1 KiB
Markdown
# DNS-Zone `axion1337.de` und Mail-Policy
|
||
|
||
Übergreifend, weil die Zone alle Hosts abdeckt und die Mail-Policy sich nicht pro
|
||
Host trennen lässt.
|
||
|
||
| | |
|
||
|---|---|
|
||
| **Registrar / DNS** | IONOS (`ns1098.ui-dns.biz`, `ns1022.ui-dns.com`, `ns1070.ui-dns.org`, `ns1059.ui-dns.de`) |
|
||
| **Apex** | `217.160.0.140` / `2001:8d8:100f:f000::2e9` — IONOS-Hosting, nicht eigene Infrastruktur |
|
||
| **Mail** | IONOS (`mx00.ionos.de`, `mx01.ionos.de`) |
|
||
| **Stand** | 2026-07-30 |
|
||
|
||
> **Die Aufstellung ist nicht garantiert vollständig.** Zonentransfer ist verweigert,
|
||
> DNS erlaubt kein Enumerieren. Die Records unten stammen aus gezielten Abfragen und
|
||
> der IONOS-Oberfläche. Für eine vollständige Prüfung entweder die ungefilterte
|
||
> IONOS-Liste durchgehen oder die Certificate-Transparency-Logs abfragen (zeigt alle
|
||
> Namen, für die je ein Cert ausgestellt wurde).
|
||
|
||
## Bekannter Bestand
|
||
|
||
| Name | A | AAAA | Ziel |
|
||
|---|---|---|---|
|
||
| `axion1337.de` | `217.160.0.140` | `2001:8d8:100f:f000::2e9` | IONOS-Hosting |
|
||
| `www` | `217.160.0.140` | dito | IONOS-Hosting — hier ist `www` **legitim** |
|
||
| `rohana` | `188.245.193.243` | `2a01:4f8:c17:93eb::1` | CFGMON, Gitea |
|
||
| `selendis` | `188.245.193.243` | `2a01:4f8:c17:93eb::1` | CFGMON, Grafana |
|
||
| `game` | `157.90.155.206` | — | Pterodactyl |
|
||
| `matrix` | `49.13.132.245` | — | Matrix-Homeserver |
|
||
| `ftp` | `217.160.233.227` | `2001:8d8:1000:30f5:…` | IONOS-Default |
|
||
| `www.rohana`, `www.selendis`, `www.game`, `www.matrix` | wie ohne `www` | teils | überflüssig, siehe ZONE-01 |
|
||
|
||
Mail-Records existieren auf `selendis` und `matrix` (MX ×2, SPF, DKIM-CNAMEs,
|
||
`autodiscover`), auf `rohana` und `game` nicht.
|
||
|
||
---
|
||
|
||
## ZONE-01 — IONOS-Default-Records bereinigen
|
||
|
||
**Status:** `rohana` und `selendis` in Arbeit (User setzt direkt um, 2026-07-30);
|
||
`game`, `matrix`, `ftp` offen
|
||
|
||
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.
|