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-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 `~all` ist 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.de` würde also Port 25 auf `188.245.193.243` ansprechen.

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

- **`game`** und **`matrix`**: `www.`-Records, siehe
  [GAME-02](../hosts/game.md#game-02--wwwgameaxion1337de-ist-überflüssig) und
  [MATRIX-03](../hosts/matrix.md#matrix-03--wwwmatrixaxion1337de-ist-überflüssig).
- **Mail-Records auf `matrix`**: **erst** [MATRIX-01](../hosts/matrix.md) klären. Wenn
  der Homeserver Mail als `@matrix.axion1337.de` verschickt, sind SPF und DKIM dort
  funktional nötig.
- **`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.

**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 — **blockiert durch [MATRIX-01](../hosts/matrix.md)**

`_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](../hosts/matrix.md) 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.