Thore CimbalandClaude Fable 5
92b448fe30
Gate 4, slice 3: verfahren/, hosts/, vision/ and shared/ moved via git mv - six AARs to docs/aar/ (four harvested by the 2026-08-09 retro, two open), procedures and host knowledge to docs/wiki/ (admin, deployment, architecture, new area vision), the retro protocol and the commit mapping table to docs/sources/ (protokolle/, migration/). New: the wiki index linking every page, and the mirror-topology page carrying the why-two-places reasoning verbatim from the old CLAUDE.md (F-013 preserved). All moved-path references retargeted; the link checker drove the sweep to zero. pruefe_prosa.py added (pattern C+D): SHA citations resolve via repo, mapping table, optional component clones or a curated exemption list (documented dead Gitea-force-push commits, a vendor-repo tag, an Authentik uid that is hex but no git SHA, the external neckbeard reference); wiki task prose without an issue reference errors, with a visible pragma for deliberate checklists; the dead-tracker denylist now covers every mirrored repo's retired Gitea tracker (F-005) - two links re-verified against live GitLab titles and retargeted, five defused into honest historical citations. Verified: validate 0/0, gen_status --check current, drift 0. Demo on the pre-migration state fires 6 findings (3 orphaned SHAs, 3 task blocks); on the current tree exactly the 3 F-004 task blocks remain - they turn green in slice 4 when the issues exist, which is why pruefe_prosa joins CI only then. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
6.6 KiB
type, area, related
| type | area | related |
|---|---|---|
| wiki-page | architecture |
DNS-Zone axion1337.de und Mail-Policy
Übergreifend, weil die Zone alle Hosts abdeckt und die Mail-Policy sich nicht pro Host trennen lässt.
| Registrar / DNS | IONOS (ns1098.ui-dns.biz, ns1022.ui-dns.com, ns1070.ui-dns.org, ns1059.ui-dns.de) |
| Apex | 217.160.0.140 / 2001:8d8:100f:f000::2e9 — IONOS-Hosting, nicht eigene Infrastruktur |
IONOS (mx00.ionos.de, mx01.ionos.de) |
|
| Stand | 2026-08-06 (Mail-Records gemessen) |
Ist-Stand der Mail-Härtung (gemessen 2026-08-06 über DoH, um den Lab-Resolver zu umgehen):
| Name | www |
MX | SPF | _dmarc |
Bewertung |
|---|---|---|---|---|---|
rohana |
löst auf ❌ | gelöscht | gelöscht ⚠️ | fehlt | ⚠️ schwächer als vorher |
selendis |
weg ✅ | IONOS ❌ | ~all ❌ |
fehlt | unangetastet |
matrix |
löst auf ❌ | IONOS ❌ | ~all ❌ |
fehlt | offen |
game |
löst auf ❌ | — | — | fehlt | teilweise |
| Apex | legitim ✅ | IONOS (genutzt) | ~all |
p=none ⚠️ |
siehe ZONE-02 |
Kein einziger Name trägt bisher _dmarc, alle erben damit p=none vom Apex.
Die Aufstellung ist nicht garantiert vollständig. Zonentransfer ist verweigert, DNS erlaubt kein Enumerieren. Die Records unten stammen aus gezielten Abfragen und der IONOS-Oberfläche. Für eine vollständige Prüfung entweder die ungefilterte IONOS-Liste durchgehen oder die Certificate-Transparency-Logs abfragen (zeigt alle Namen, für die je ein Cert ausgestellt wurde).
Bekannter Bestand
| Name | A | AAAA | Ziel |
|---|---|---|---|
axion1337.de |
217.160.0.140 |
2001:8d8:100f:f000::2e9 |
IONOS-Hosting |
www |
217.160.0.140 |
dito | IONOS-Hosting — hier ist www legitim |
rohana |
188.245.193.243 |
2a01:4f8:c17:93eb::1 |
CFGMON, Gitea |
selendis |
188.245.193.243 |
2a01:4f8:c17:93eb::1 |
CFGMON, Grafana |
game |
157.90.155.206 |
— | Pterodactyl |
matrix |
49.13.132.245 |
— | Matrix-Homeserver |
ftp |
217.160.233.227 |
2001:8d8:1000:30f5:… |
IONOS-Default |
www.rohana, www.selendis, www.game, www.matrix |
wie ohne www |
teils | überflüssig, siehe ZONE-01 |
Mail-Records existieren auf selendis und matrix (MX ×2, SPF, DKIM-CNAMEs,
autodiscover), auf rohana und game nicht.
Was die Mail-Records eigentlich tun
Damit die Rezepte in ZONE-01 nicht als Zahlensalat dastehen: Vier Mechanismen, die zusammenspielen. Keiner schützt allein.
Das Grundproblem
Der Absender einer Mail (From:) ist frei wählbar — SMTP prüft ihn nicht. Jeder
kann rechnung@rohana.axion1337.de in den Umschlag schreiben. Die folgenden
Records sind die Möglichkeit, dem widersprechen, bevor jemand darauf hereinfällt.
SPF — „diese Server dürfen für mich senden"
TXT-Record am Namen selbst. Listet die berechtigten Absender-IPs.
Entscheidend ist das Ende des Eintrags:
| Endung | Bedeutung | Wirkung beim Empfänger |
|---|---|---|
~all |
Softfail | „war nicht auf der Liste" → wird meist trotzdem zugestellt, evtl. markiert |
-all |
Hardfail | „war nicht auf der Liste" → ablehnen |
v=spf1 -all ohne jeden Server davor heißt: Für diesen Namen sendet niemand.
Genau die richtige Aussage für rohana, selendis, matrix — die verschicken keine
Mail (für matrix verifiziert in MATRIX-01: weder Synapse noch MAS senden).
⚠️ Es darf nur EIN SPF-Record je Name existieren. Ein zweiter erzeugt
PermError, und dann prüfen viele Empfänger gar nicht mehr — die Härtung
schlägt ins Gegenteil um. Deshalb: bestehenden TXT editieren, nie einen zweiten
anlegen.
DKIM — „diese Mail wurde unterwegs nicht verändert"
Signatur mit einem privaten Schlüssel, öffentlicher Teil als CNAME/TXT im DNS
(s1-ionos._domainkey…). Beweist Unversehrtheit und Herkunft.
Für Namen, die nicht senden, sind die DKIM-Einträge schlicht Ballast — sie signieren nichts. Sie können weg.
DMARC — „und das tust du, wenn SPF oder DKIM nicht passen"
TXT unter _dmarc.<name>. SPF und DKIM stellen nur fest; DMARC sagt, welche
Konsequenz das hat:
| Policy | Wirkung |
|---|---|
p=none |
nur beobachten — kein Schutz, Mail wird zugestellt |
p=quarantine |
in den Spam-Ordner |
p=reject |
ablehnen |
⚠️ DMARC wird vererbt. Fehlt _dmarc.rohana, gilt die Policy des
organisatorischen Namens axion1337.de. Die steht heute auf p=none
(ZONE-02) — damit erben
alle Subdomains „kein Schutz", egal wie sauber ihr SPF ist.
Das ist der wichtigste Hebel der ganzen Zone: Der Apex wirkt auf alle Namen
gleichzeitig. Mit sp= lässt sich für Subdomains sogar eine strengere Policy
setzen als für den Apex selbst.
Null-MX — „hier nimmt niemand Mail an" (RFC 7505)
Ein MX-Record mit dem Ziel . (Punkt) und Priorität 0.
Der Grund, warum Löschen nicht reicht: Findet ein Absender keinen MX, weicht er per RFC 5321 auf den A/AAAA-Record aus und versucht, direkt an den Webserver zuzustellen. Der Name sieht dann nach „nimmt vielleicht Mail an" aus. Null-MX sagt stattdessen ausdrücklich nein — Absender brechen sofort ab.
Warum die Kombination
| Record | Beantwortet die Frage |
|---|---|
| Null-MX | Nimmt dieser Name Mail an? → nein |
SPF -all |
Darf jemand für diesen Namen senden? → niemand |
DMARC p=reject |
Was tun, wenn doch jemand behauptet, es zu dürfen? → ablehnen |
Erst zusammen ergeben sie eine Aussage, auf die sich ein Empfänger verlassen kann. Einzeln bleibt jeweils eine Lücke — und ersatzloses Löschen hinterlässt die größte: keine Aussage ist schwächer als eine schlechte Aussage.
Real eingetreten: Bei rohana sind MX und SPF gelöscht, die Ersatz-Records
fehlen (gemessen 2026-08-06). Vorher gab es wenigstens ein Softfail-SPF, jetzt gar
keine Aussage mehr — dazu die geerbte p=none vom Apex. Der Halbfertig-Zustand ist
schwächer als der Ausgangszustand.
Offene Punkte → git.lab-Issues
Seit dem Framework-Umbau (2026-08-01) leben offene Punkte als Issues im management-Projekt; die IDs bleiben in den Issue-Titeln erhalten. Dieses File hält nur noch Bestand und Historie.