Files

T

Thore CimbalandClaude Opus 4.8 5ec4aa702e docs(aar): mrtc DNS outage AAR; #0053 takes the real-timestamp commits too

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>

2026-08-17 12:00:00 +00:00

3.3 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 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.

3.3 KiB Raw Blame History

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