Thore CimbalandClaude Fable 5
d019bfedda
Die Rezepte in ZONE-01 nannten Werte (Null-MX, v=spf1 -all, p=reject), ohne zu sagen, wogegen sie schuetzen. Wer sie umsetzt, ohne das zu wissen, kann nicht erkennen, wann ein Halbfertig-Zustand schlechter ist als der Ausgangszustand - und genau das ist eingetreten. Ergaenzt: die vier Mechanismen einzeln (SPF, DKIM, DMARC, Null-MX), was jeder beantwortet und warum keiner allein reicht. Zwei Punkte, die man kennen muss: - SPF darf nur EINMAL je Name existieren; ein zweiter Record erzeugt PermError, und dann pruefen viele Empfaenger gar nicht mehr. Die Haertung schlaegt ins Gegenteil um. - DMARC wird vererbt. Fehlt _dmarc.<name>, gilt die Policy des Apex - und die steht auf p=none. Damit erben ALLE Subdomains 'kein Schutz', egal wie sauber ihr SPF ist. Der Apex ist damit der groesste Hebel der Zone (ZONE-02), nicht die Einzelnamen (ZONE-01). Dazu der gemessene Ist-Stand (DoH, um den Lab-Resolver zu umgehen): Bei rohana sind MX und SPF geloescht, die Ersatz-Records fehlen. Vorher gab es wenigstens ein Softfail-SPF, jetzt gar keine Aussage - keine Aussage ist schwaecher als eine schlechte. Bei selendis ist nur das www weg, der Mail-Satz steht unveraendert. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
6.6 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-08-06 (Mail-Records gemessen) |
Ist-Stand der Mail-Härtung (gemessen 2026-08-06 über DoH, um den Lab-Resolver zu umgehen):
| Name | www |
MX | SPF | _dmarc |
Bewertung |
|---|---|---|---|---|---|
rohana |
löst auf ❌ | gelöscht | gelöscht ⚠️ | fehlt | ⚠️ schwächer als vorher |
selendis |
weg ✅ | IONOS ❌ | ~all ❌ |
fehlt | unangetastet |
matrix |
löst auf ❌ | IONOS ❌ | ~all ❌ |
fehlt | offen |
game |
löst auf ❌ | — | — | fehlt | teilweise |
| Apex | legitim ✅ | IONOS (genutzt) | ~all |
p=none ⚠️ |
siehe ZONE-02 |
Kein einziger Name trägt bisher _dmarc, alle erben damit p=none vom Apex.
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.
Was die Mail-Records eigentlich tun
Damit die Rezepte in ZONE-01 nicht als Zahlensalat dastehen: Vier Mechanismen, die zusammenspielen. Keiner schützt allein.
Das Grundproblem
Der Absender einer Mail (From:) ist frei wählbar — SMTP prüft ihn nicht. Jeder
kann rechnung@rohana.axion1337.de in den Umschlag schreiben. Die folgenden
Records sind die Möglichkeit, dem widersprechen, bevor jemand darauf hereinfällt.
SPF — „diese Server dürfen für mich senden"
TXT-Record am Namen selbst. Listet die berechtigten Absender-IPs.
Entscheidend ist das Ende des Eintrags:
| Endung | Bedeutung | Wirkung beim Empfänger |
|---|---|---|
~all |
Softfail | „war nicht auf der Liste" → wird meist trotzdem zugestellt, evtl. markiert |
-all |
Hardfail | „war nicht auf der Liste" → ablehnen |
v=spf1 -all ohne jeden Server davor heißt: Für diesen Namen sendet niemand.
Genau die richtige Aussage für rohana, selendis, matrix — die verschicken keine
Mail (für matrix verifiziert in MATRIX-01: weder Synapse noch MAS senden).
⚠️ Es darf nur EIN SPF-Record je Name existieren. Ein zweiter erzeugt
PermError, und dann prüfen viele Empfänger gar nicht mehr — die Härtung
schlägt ins Gegenteil um. Deshalb: bestehenden TXT editieren, nie einen zweiten
anlegen.
DKIM — „diese Mail wurde unterwegs nicht verändert"
Signatur mit einem privaten Schlüssel, öffentlicher Teil als CNAME/TXT im DNS
(s1-ionos._domainkey…). Beweist Unversehrtheit und Herkunft.
Für Namen, die nicht senden, sind die DKIM-Einträge schlicht Ballast — sie signieren nichts. Sie können weg.
DMARC — „und das tust du, wenn SPF oder DKIM nicht passen"
TXT unter _dmarc.<name>. SPF und DKIM stellen nur fest; DMARC sagt, welche
Konsequenz das hat:
| Policy | Wirkung |
|---|---|
p=none |
nur beobachten — kein Schutz, Mail wird zugestellt |
p=quarantine |
in den Spam-Ordner |
p=reject |
ablehnen |
⚠️ DMARC wird vererbt. Fehlt _dmarc.rohana, gilt die Policy des
organisatorischen Namens axion1337.de. Die steht heute auf p=none
(ZONE-02) — damit erben
alle Subdomains „kein Schutz", egal wie sauber ihr SPF ist.
Das ist der wichtigste Hebel der ganzen Zone: Der Apex wirkt auf alle Namen
gleichzeitig. Mit sp= lässt sich für Subdomains sogar eine strengere Policy
setzen als für den Apex selbst.
Null-MX — „hier nimmt niemand Mail an" (RFC 7505)
Ein MX-Record mit dem Ziel . (Punkt) und Priorität 0.
Der Grund, warum Löschen nicht reicht: Findet ein Absender keinen MX, weicht er per RFC 5321 auf den A/AAAA-Record aus und versucht, direkt an den Webserver zuzustellen. Der Name sieht dann nach „nimmt vielleicht Mail an" aus. Null-MX sagt stattdessen ausdrücklich nein — Absender brechen sofort ab.
Warum die Kombination
| Record | Beantwortet die Frage |
|---|---|
| Null-MX | Nimmt dieser Name Mail an? → nein |
SPF -all |
Darf jemand für diesen Namen senden? → niemand |
DMARC p=reject |
Was tun, wenn doch jemand behauptet, es zu dürfen? → ablehnen |
Erst zusammen ergeben sie eine Aussage, auf die sich ein Empfänger verlassen kann. Einzeln bleibt jeweils eine Lücke — und ersatzloses Löschen hinterlässt die größte: keine Aussage ist schwächer als eine schlechte Aussage.
Real eingetreten: Bei rohana sind MX und SPF gelöscht, die Ersatz-Records
fehlen (gemessen 2026-08-06). Vorher gab es wenigstens ein Softfail-SPF, jetzt gar
keine Aussage mehr — dazu die geerbte p=none vom Apex. Der Halbfertig-Zustand ist
schwächer als der Ausgangszustand.
Offene Punkte → git.lab-Issues
Seit dem Framework-Umbau (2026-08-01) leben offene Punkte als Issues im management-Projekt; die IDs bleiben in den Issue-Titeln erhalten. Dieses File hält nur noch Bestand und Historie.