shared/zone-axion1337.md

# 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)