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
143 lines
6.6 KiB
Markdown
143 lines
6.6 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-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](https://git.lab/axion1337.chat/management/-/issues/5)
|
||
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](https://git.lab/axion1337.chat/management/-/issues/6)) — **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](https://git.lab/axion1337.chat/management/-/issues); die IDs bleiben in den Issue-Titeln erhalten.
|
||
Dieses File hält nur noch Bestand und Historie.
|
||
|
||
- [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)
|
||
|