--- type: wiki-page area: architecture related: [] --- # 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.`. 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)