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>

docs/aar/2026-08-16-mrtc-dns-record.md

@@ -0,0 +1,62 @@
+---
+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.