2026-08-18 12:00:00 +00:00
|
|
|
---
|
|
|
|
|
type: issue
|
|
|
|
|
id: "0102"
|
|
|
|
|
status: open
|
|
|
|
|
created: 2026-08-18
|
|
|
|
|
milestone: M1
|
|
|
|
|
priority: medium
|
|
|
|
|
area: security
|
|
|
|
|
related:
|
|
|
|
|
- "docs/issues/0006-zone-02-apex-dmarc-ist-p-none-und-schuetzt.md"
|
|
|
|
|
- "docs/aar/2026-08-16-mrtc-dns-record.md"
|
2026-08-18 12:00:00 +00:00
|
|
|
gitlab_iid: "40"
|
2026-08-18 12:00:00 +00:00
|
|
|
---
|
|
|
|
|
# DMARC der Plattform-Zone `axion1337.chat` steht auf p=none — und gehört IONOS, nicht uns
|
|
|
|
|
|
|
|
|
|
> Nebenbefund der `mrtc`-Diagnose vom 2026-08-16 (siehe AAR); von sorb am
|
|
|
|
|
> 2026-08-18 zum Issue erhoben.
|
|
|
|
|
|
|
|
|
|
## Befund
|
|
|
|
|
|
|
|
|
|
**#0006 hat die falsche Zone gehärtet — nicht aus Fehler, sondern weil es die
|
|
|
|
|
andere war.** Dort ging es um `axion1337.de` (die Zone mit den echten
|
|
|
|
|
Postfächern), und die steht heute korrekt:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
_dmarc.axion1337.de TXT "v=DMARC1; p=reject;" ← eigener Record, scharf
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Die **Plattform-Zone** `axion1337.chat` ist davon unberührt geblieben und steht
|
|
|
|
|
noch so da (gemessen 2026-08-18 gegen 1.1.1.1):
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
_dmarc.axion1337.chat CNAME dmarc.ionos.de. → "v=DMARC1; p=none;"
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Zwei getrennte Probleme in dieser einen Zeile:
|
|
|
|
|
|
|
|
|
|
1. **`p=none` schützt nichts.** Gefälschte Mail „von" `axion1337.chat` wird beim
|
|
|
|
|
Empfänger nicht abgewiesen. Das ist die Domain, unter der die Nutzer ihre
|
|
|
|
|
Einladungen und Konto-Mails bekommen — der Phishing-Weg zeigt also genau auf
|
|
|
|
|
die eigene Nutzerschaft.
|
|
|
|
|
2. **Der Record gehört uns gar nicht.** Es ist ein CNAME auf IONOS' geteilten
|
|
|
|
|
Record. Die Richtlinie unserer Domain wird damit von IONOS gesetzt und kann
|
|
|
|
|
sich ohne unser Zutun ändern. Ein eigener TXT-Record ist Voraussetzung für
|
|
|
|
|
jede Härtung.
|
|
|
|
|
|
|
|
|
|
Ohne `sp=`-Tag gilt `p=` laut RFC 7489 auch für alle Subdomains — die sieben
|
|
|
|
|
Service-Namen erben also ebenfalls `none`. Und alle sieben tragen, als
|
|
|
|
|
IONOS-Voreinstellung, MX- und SPF-Records, obwohl unter ihnen nie Mail läuft:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
matrix|account|auth|admin|wiki|turn|mrtc . axion1337.chat
|
|
|
|
|
MX 10 mx00/mx01.ionos.de.
|
|
|
|
|
TXT "v=spf1 include:_spf-eu.ionos.com ~all" ← Softfail
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
## Wer wirklich sendet (vor jeder Änderung zu bestätigen)
|
|
|
|
|
|
|
|
|
|
Zwei belegte Absender, **beide am Apex**, keiner unter einem Service-Namen:
|
|
|
|
|
|
|
|
|
|
| Absender | Adresse | Weg | Fundstelle |
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
| Authentik (Enrollment, Passwort) | `gamemaster@axion1337.chat` | `smtp.ionos.de:587` | `gitops:apps/authentik/authentik.yaml` |
|
|
|
|
|
| Wartungsmeldungen der Hosts | `wartung@axion1337.chat` | msmtp, Provider laut Template offen | `gitops:host-config/maintenance-notify/` |
|
|
|
|
|
|
|
|
|
|
DKIM ist am Apex vorhanden: `s1-ionos`, `s2-ionos` und `s42582890` zeigen als
|
|
|
|
|
CNAME auf `*.dkim.ionos.com`. Für Authentik über IONOS-SMTP ist die Signatur
|
|
|
|
|
damit gedeckt. **Ungeklärt ist der Weg von `maintenance-notify`** — die
|
|
|
|
|
`msmtprc.template` trägt Platzhalter und verweist auf „your own
|
|
|
|
|
transactional-mail provider". Läuft der nicht über IONOS, bricht `p=reject`
|
|
|
|
|
genau diese Meldungen, und zwar still.
|
|
|
|
|
|
|
|
|
|
## Vorschlag
|
|
|
|
|
|
|
|
|
|
Die Reihenfolge aus #0006 gilt unverändert: **erst Absender klären, dann
|
|
|
|
|
Richtlinie verschärfen** — umgekehrt zerlegt es den Versand unbemerkt.
|
|
|
|
|
|
|
|
|
|
1. **Klären**, worüber `maintenance-notify` tatsächlich versendet, und ob es
|
|
|
|
|
weitere Absender auf `@axion1337.chat` gibt (Synapse verschickt derzeit
|
|
|
|
|
nichts — im Zweifel gegenprüfen).
|
|
|
|
|
2. **Service-Namen stilllegen**, die nachweislich weder senden noch empfangen
|
|
|
|
|
(`matrix`, `account`, `auth`, `admin`, `wiki`, `turn`, `mrtc`): Null-MX
|
|
|
|
|
`MX 0 .` und `TXT "v=spf1 -all"`. Risikoarm, weil dort nie Mail lief.
|
|
|
|
|
3. **Eigenen `_dmarc`-Record** für `axion1337.chat` anlegen (CNAME ersetzen),
|
|
|
|
|
zunächst `p=quarantine; rua=…`, Reports beobachten, dann `p=reject`.
|
|
|
|
|
4. **Apex-SPF bleibt `~all`.** Dieselbe Abwägung wie in #0006: neben scharfem
|
|
|
|
|
DMARC ist der Gewinn von `-all` gering, das Risiko eines vergessenen
|
|
|
|
|
legitimen Absenders real.
|
|
|
|
|
|
|
|
|
|
## Abnahme
|
|
|
|
|
|
|
|
|
|
- `_dmarc.axion1337.chat` ist ein **eigener** TXT-Record, nicht mehr der
|
|
|
|
|
IONOS-CNAME, und trägt mindestens `p=quarantine`.
|
|
|
|
|
- Die sieben Service-Namen liefern `MX 0 .` und `v=spf1 -all`.
|
|
|
|
|
- Eine Testmail von Authentik (Passwort-Zurücksetzen) und eine
|
|
|
|
|
Wartungsmeldung kommen nachweislich weiterhin an — **verifiziert, nicht
|
|
|
|
|
angenommen**.
|
|
|
|
|
- `notfallhandbuch:dns-soll.md` und `pruefe-dns.sh` tragen den neuen Soll-Stand;
|
|
|
|
|
der bisherige Satz „Härtung vorgeschlagen, aber nicht entschieden" wird
|
|
|
|
|
ersetzt.
|
