---
type: aar
status: open
date: 2026-08-16
related:
  - "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)

1. Synapse-Log: `openid/request_token` **200** für beide Nutzer → OpenID entlastet.
2. Authorisation-Service-Log: **nur Health-Checks**, keine echte Anfrage → Bruch davor.
3. `curl https://mrtc…/healthz` → HTTP 000 → `dig` → **kein Record, autoritativ bestätigt**.
4. 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 Service-Namen (`sp=` am Apex, Null-MX + `-all` je Service-Name):
  bei der Diagnose als Nebenbefund erhoben, **Entscheidung sorb steht aus** — #0006 (Apex-
  DMARC) ist geschlossen und deckt die Subdomain-Frage nicht ab.