Thore CimbalandClaude Opus 5
8e98a39447
Bisher lag der Backlog als BACKLOG.md in threadnet-operating und damit in einem Repo, das nur einen Stack auf einem Host beschreibt. Da die Arbeit inzwischen mehrere Hosts umfasst, hier ein File pro Host plus shared/ fuer Themen, die sich nicht pro Host trennen lassen. Uebernommen und auf die Hosts verteilt: - CFGMON: Cert-Erneuerung inkl. IPv6-Firewall, nicht versionierter Portainer-Stack (traefik/gitea/cadvisor), offener Remote-Write- Receiver, Grafana-API-Credentials; dazu drei erledigte Punkte von heute als Historie - game: Host von CFGMON aus nicht erreichbar, 2 Targets down - matrix: Mailversand klaeren, bevor die Zone gehaertet wird - k3s: pusht auf den offenen Receiver, liegt aber schon im privaten Netz - shared/zone-axion1337: DNS-Bereinigung und Apex-DMARC-Policy Konventionen in README.md, Vorlage in TEMPLATE.md. IDs sind pro File fortlaufend und werden nicht wiederverwendet. Praefix fuer DNS-Themen ist ZONE-, nicht DNS-, weil DNS-01 der Name eines ACME-Challenge-Typs ist und hier laufend als Fachbegriff vorkommt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
7.4 KiB
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-07-30 |
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.
ZONE-01 — IONOS-Default-Records bereinigen
Status: rohana und selendis in Arbeit (User setzt direkt um, 2026-07-30);
game, matrix, ftp offen
IONOS legt beim Anlegen einer Subdomain automatisch einen kompletten Mail-Satz mit an
— MX, SPF, DKIM-CNAMEs, autodiscover — und ein www.-Paar. Auch für Hosts, auf
denen nie Mail läuft.
Warum www. bei einer Subdomain überflüssig ist
Das Muster stammt aus der Zeit, als der Webserver einer Domain der Host www war,
und hält sich für Apex-Domains: axion1337.de und www.axion1337.de sollen
dasselbe liefern, weil Leute beides tippen. Beim Apex ist das also richtig und bleibt.
Auf eine Subdomain überträgt es sich nicht. rohana.axion1337.de ist schon der
Hostname des Dienstes; www.rohana.axion1337.de heißt wörtlich „der Webserver des
Webservers". Das tippt und verlinkt niemand.
Verifiziert für www.rohana und www.selendis: kein Traefik-Router matcht die Namen,
Traefik liefert sein TRAEFIK DEFAULT CERT aus, TLS bricht mit Zertifikatsfehler ab.
Die Namen funktionieren also ohnehin nicht — wer dort landet, sieht etwas Kaputtes.
Sie zum Funktionieren zu bringen hieße Router plus Cert-SAN, also mehr Teile, die bei
jeder Erneuerung mitvalidieren müssen, für null Nutzen.
Warum die Mail-Records nicht ersatzlos gelöscht werden
Zwei Fallstricke, die Löschen zur schlechteren Variante machen:
- Ohne SPF existiert keine Aussage darüber, wer als dieser Name senden darf. Das
bestehende
~allist nur Softfail und wird von vielen Empfängern akzeptiert — eine ungenutzte Subdomain mit gültigen MX und Softfail-SPF ist ein brauchbarer Spoofing-Vektor. - Fehlt ein MX-Record, weichen Absender per RFC 5321 auf A/AAAA aus. Mail an
@rohana.axion1337.dewürde also Port 25 auf188.245.193.243ansprechen.
Richtig ist, „hier gibt es keine Mail" explizit zu erklären: Null-MX (RFC 7505), SPF
-all, DMARC p=reject.
rohana.axion1337.de
Löschen: A www.rohana, AAAA www.rohana
Anlegen:
| Typ | Name | Wert |
|---|---|---|
| MX | rohana |
. (Priorität 0) |
| TXT | rohana |
v=spf1 -all |
| TXT | _dmarc.rohana |
v=DMARC1; p=reject; |
Nicht anfassen: A rohana, AAAA rohana — daran hängen Gitea und das Zertifikat.
selendis.axion1337.de
Löschen: MX mx00.ionos.de, MX mx01.ionos.de,
CNAME s1-ionos._domainkey.selendis, CNAME s2-ionos._domainkey.selendis,
CNAME s42582890._domainkey.selendis, CNAME autodiscover.selendis,
A www.selendis, AAAA www.selendis
Ändern — den bestehenden TXT editieren, nicht einen zweiten anlegen: zwei SPF-Records auf einem Namen ergeben einen PermError, die Prüfung fällt dann komplett aus.
| Typ | Name | von | auf |
|---|---|---|---|
| TXT | selendis |
v=spf1 include:_spf-eu.ionos.com ~all |
v=spf1 -all |
Anlegen: MX selendis = . (Priorität 0), TXT _dmarc.selendis =
v=DMARC1; p=reject;
Nicht anfassen: A selendis, AAAA selendis.
Vorab prüfen: ob im IONOS-Mail-Bereich ein Postfach oder eine Weiterleitung für
selendis.axion1337.de existiert. Wenn ja, entfallen die MX-Änderungen.
Falls IONOS . als MX-Ziel ablehnt — kommt vor: MX löschen und nur die
TXT-Records setzen. -all und p=reject; greifen trotzdem, es fehlt nur die
explizite „nimmt keine Mail an"-Aussage.
Noch offen
gameundmatrix:www.-Records, siehe GAME-02 und MATRIX-03.- Mail-Records auf
matrix: erst MATRIX-01 klären. Wenn der Homeserver Mail als@matrix.axion1337.deverschickt, sind SPF und DKIM dort funktional nötig. ftp.axion1337.de→217.160.233.227: IONOS-Default aus dem Hosting-Paket, zeigt auf IONOS und nicht auf eigene Infrastruktur — also keine zusätzliche Angriffsfläche, aber Ballast. Löschen, falls dort kein FTP genutzt wird.
Nach der Umsetzung von hier aus verifizieren: dass www.rohana und
www.selendis nicht mehr auflösen; dass MX, SPF und DMARC greifen und nur ein
SPF-Record pro Name existiert; und dass A/AAAA von rohana und selendis
unverändert sind und Gitea sowie Grafana weiter über HTTPS antworten. Der letzte
Punkt ist der, bei dem ein Verklicker in der IONOS-Oberfläche wehtun würde.
ZONE-02 — Apex-DMARC ist p=none und schützt nichts
Status: offen — blockiert durch MATRIX-01
_dmarc.axion1337.de enthält v=DMARC1; p=none; (via dmarc.ionos.de). Das ist
reines Monitoring: Empfänger melden Verstöße, verwerfen aber nichts. Für gefälschte
Mail in deinem Namen ist das kein Hindernis.
Zusätzlich fehlt eine sp=-Angabe. Ohne sie erben alle Subdomains dieses
p=none — auch solche, die nie Mail senden, und auch künftige.
sp=reject am Apex wäre daher der effiziente Hebel: deckt alle Subdomains auf einmal
ab, inklusive der noch nicht angelegten, und macht die einzelnen _dmarc-Records aus
ZONE-01 auf Dauer entbehrlich.
Reihenfolge ist hier wichtig. Zuerst MATRIX-01 klären, dann
für jeden Namen, der tatsächlich Mail versendet, SPF und DKIM korrekt setzen — erst
danach sp=reject. Umgekehrt zerlegt es den Mailversand der betroffenen Dienste, und
zwar unbemerkt, weil verworfene Mail beim Absender keinen Fehler produziert.
Für den Apex selbst (dort läuft echte Mail über IONOS) wäre der übliche Weg, p=none
erst auf p=quarantine zu ziehen, die DMARC-Reports eine Weile zu beobachten und dann
auf p=reject zu gehen. Auffällig: unter s1._domainkey.axion1337.de war kein
DKIM-Record auffindbar, obwohl die Subdomains DKIM-CNAMEs von IONOS haben — das wäre
beim Härten mitzuprüfen.