Files

T

Thore CimbalandClaude Opus 5 f092e60dfb docs(issues): #0102 — DMARC of the platform zone is p=none and belongs to IONOS

Decision sorb: the mail hardening carried over from the mrtc diagnosis becomes an
issue. Writing it up corrected the premise the AAR and dns-soll.md carried:
#0006 hardened axion1337.DE, the zone with the real mailboxes, and it stands at
p=reject. The platform zone .chat was never its subject and still resolves its
_dmarc as a CNAME into IONOS' shared p=none - so the policy for our own domain is
set by IONOS, and RFC 7489 passes that none down to all seven service names.

Two senders are documented rather than assumed: Authentik as gamemaster@ via
IONOS SMTP (DKIM-covered), and maintenance-notify as wartung@ over an msmtp
config whose provider the template leaves open. That second path is why the issue
puts "clarify the senders" ahead of any policy change - p=reject before that
question is answered breaks maintenance mail silently.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-18 12:00:00 +00:00

3.4 KiB

Raw Blame History

type, status, date, related

type

status

date

aar

open

2026-08-16

docs/issues/0005-zone-01-ionos-default-records-bereinigen-www.md

AAR — Gruppen-Calls fünf Tage tot: `mrtc`-A-Record bei der Zonen-Bereinigung gelöscht

Datum des Vorfalls: 2026-08-11 bis 2026-08-16 · Beteiligt: sorb + Mac-Session · Stack: MatrixRTC (LiveKit-SFU + Authorisation-Service), IONOS-DNS, cert-manager Auftrag am 16.08.: „zwischen frank und sorb kommt in raum test kein call zustande, OPEN_ID_Error" — Grundursache finden.

1. Ergebnis

Behoben: mrtc.axion1337.chat A 49.13.132.245 von sorb bei IONOS neu gesetzt; danach Token-Tausch am Authorisation-Service nachweislich wieder angekommen, Calls liefen im Test.

Grundursache: Der A-Record wurde bei der IONOS-Zonen-Bereinigung (#0005, 11.08.) mit gelöscht — auf Empfehlung der Session, die keine Soll-Liste hatte, gegen die sie hätte prüfen können. Letzter erfolgreicher Call-Beitritt 11.08. 21:48; erster Fehlversuch danach erst am 16.08. — fünf Tage unbemerkt, weil niemand telefonierte.

2. Warum nichts Alarm schlug

Zertifikat blieb grün: DNS-01-Renewal braucht keinen A-Record.
Cluster blieb grün: Ingress, SFU-Pod, Authorisation-Service — alles gesund; der Dienst bekam schlicht keine Anfragen mehr (nur Health-Checks).
Der Client-Fehler führte in die Irre: „OPEN_ID_Error" — dabei war das OpenID-Stück das Einzige, was funktionierte (Synapse gab Tokens mit 200 aus). Der Bruch lag eine Stufe später: https://mrtc…/sfu/get war nicht auflösbar.

3. Diagnose-Weg (was künftig Zeit spart)

Synapse-Log: openid/request_token 200 für beide Nutzer → OpenID entlastet.
Authorisation-Service-Log: nur Health-Checks, keine echte Anfrage → Bruch davor.
curl https://mrtc…/healthz → HTTP 000 → dig → kein Record, autoritativ bestätigt.
DB-Abgleich Versuche↔Beitritte (open_id_tokens vs. call.member-Events) datierte den Bruch exakt: 11.08. 76/61, 16.08. 3/0.

4. Lehren und Maßnahmen

Es gab keine DNS-Soll-Liste. Die einzige Nennung von mrtc als Pflicht-Record steckte in einem alten Fehlerbericht (gitops:docs/oldwiki/fix report mrtc.md). → Umgesetzt: notfallhandbuch:dns-soll.md (Soll-Liste mit „Wenn er fehlt"-Spalte und dem, was es bewusst NICHT gibt) plus pruefe-dns.sh (prüft öffentlich UND autoritativ; Positiv- und Negativlauf verifiziert). Vor jeder Zonen-Änderung laufen lassen.
Aufschreiben allein hätte nicht gereicht (Wiederholung der Bindmount-Lehre): wirksam ist das ausführbare Skript, nicht die Tabelle daneben.
„Meldet Erfolg, ist aber blind", DNS-Ausgabe: Grüne Zertifikate und grüne Pods sagen nichts über die Erreichbarkeit von außen. Der Fehlertext des Clients benennt die Stufe, auf der er scheitert — nicht die Ursache.
Bereinigungen brauchen eine Soll-Liste vorab. Die Session hat beim Aufräumen Einträge freigegeben, deren Zweck sie nicht kannte. Erst prüfen, wogegen — dann löschen.

5. Offen

DMARC-/Mail-Härtung der Zone axion1337.chat: bei der Diagnose als Nebenbefund erhoben, seit 2026-08-18 als #0102 geführt. Beim Anlegen präzisiert: #0006 hat axion1337.**de** gehärtet (dort heute p=reject); die Plattform-Zone .chat hängt weiterhin als CNAME an IONOS' geteiltem p=none — sie war nie Gegenstand von #0006.

3.4 KiB Raw Blame History

AAR — Gruppen-Calls fünf Tage tot: mrtc-A-Record bei der Zonen-Bereinigung gelöscht