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>
8.1 KiB
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 |
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
~allist 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.dewürde also Port 25 auf188.245.193.243ansprechen.
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
gameundmatrix:www.-Records, siehe GAME-02 und MATRIX-03.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
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 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 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.