2026-08-17 12:00:00 +00:00
|
|
|
---
|
|
|
|
|
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
|
|
|
|
|
|
2026-08-18 12:00:00 +00:00
|
|
|
- DMARC-/Mail-Härtung der Zone `axion1337.chat`: bei der Diagnose als Nebenbefund erhoben,
|
|
|
|
|
seit 2026-08-18 als [#0102](../issues/0102-dmarc-und-mail-haertung-der-zone-axion1337-chat.md)
|
|
|
|
|
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.
|
