Thore CimbalandClaude Opus 4.8
5ec4aa702e
The five-day group-call outage from the deleted mrtc A record had no management record at all - the fix, the diagnosis path, and the lesson lived only in the session. The AAR records why nothing alarmed (DNS-01 certs and pods stay green without an A record), the exact dating via token-vs-join counts, and the countermeasure that already shipped (notfallhandbuch dns-soll.md + pruefe-dns.sh). gruppenpruefung's nine real-timestamp findings join #0053's history pass - same class, same decision, recorded so the next session repairs nothing unilaterally. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
63 lines
3.3 KiB
Markdown
63 lines
3.3 KiB
Markdown
---
|
|
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.
|