threadnet-operating/BACKLOG.md

Backlog

Offene Punkte, die bewusst nicht sofort erledigt wurden. Stand: 2026-07-30.

---

1. Zertifikatserneuerung braucht offene Ports — oder Umstellung auf DNS-01

Status: offen, zeitkritisch ab ca. 2026-09-28

Das Cert für selendis.axion1337.de wurde am 2026-07-30 ausgestellt und läuft am 2026-10-28 ab. Traefik erneuert automatisch ca. 30 Tage vorher, also ab Ende September 2026.

Traefik ist auf TLS-ALPN-01 konfiguriert (--certificatesresolvers.letsencrypt.acme.tlschallenge=true). Diese Challenge läuft ausschließlich über Port 443, erreichbar aus dem offenen Internet. Ist der Port zu diesem Zeitpunkt in der Hetzner-Cloud-Firewall gesperrt, scheitert die Erneuerung still mit:

urn:ietf:params:acme:error:connection :: Timeout during connect (likely firewall problem)

Traefik liefert dann sein Default-Self-Signed-Cert aus — Browser und curl brechen mit Zertifikatsfehler ab. Das betrifft auch Gitea (rohana.axion1337.de, Cert im selben Resolver), also die Erreichbarkeit dieses Repos per HTTPS.

Eine IP-Allowlist für die Let's-Encrypt-Server ist keine Option: LE veröffentlicht seine Validierungs-IPs nicht und prüft seit Einführung der Multi-Perspective Validation aus mehreren Regionen gleichzeitig.

IPv6 beachten (Stand 2026-07-30): rohana, www.rohana und selendis haben inzwischen AAAA-Records auf 2a01:4f8:c17:93eb::1. Damit validiert Let's Encrypt bevorzugt über IPv6. Die Hetzner-Cloud-Firewall braucht für Port 443 deshalb eine Regel mit Quelle ::/0 — 0.0.0.0/0 deckt IPv6 nicht mit ab. Fehlt sie, scheitert die Erneuerung, obwohl IPv4 offen ist. Vom Host aus lässt sich das nicht verifizieren (Verbindung auf die eigene öffentliche Adresse läuft lokal), das muss in der Hetzner-Konsole geprüft werden.

Zwei Wege:

• A — Port 443 zur Erneuerung öffnen. Nichts umbauen, aber alle ~60 Tage daran denken. Fehleranfällig, weil das Scheitern nicht auffällt, bis jemand die Seite aufruft.
• B — auf DNS-01 umstellen (empfohlen). Validierung über einen TXT-Record, kein offener Port nötig, Erneuerung läuft bei komplett dichter Firewall durch. Voraussetzung: API-Token des DNS-Providers für axion1337.de, hinterlegt als Secret für Traefik. Ermöglicht zusätzlich Wildcard-Certs (*.axion1337.de), was künftige Subdomains ohne Portöffnung abdeckt.

Nächster Schritt: Entscheidung A oder B. Bei B: DNS-Provider benennen und API-Token bereitstellen, dann Traefik-Resolver umstellen.

Nebenpunkt: www.rohana.axion1337.de löschen

Der Record (A + AAAA) wurde nach IONOS-Default-Muster angelegt. Bei einer Subdomain ist ein www.-Präfix überflüssig — das Muster gilt für Apex-Domains (axion1337.de / www.axion1337.de, dort bei IONOS sinnvoll). rohana ist bereits der Hostname des Dienstes.

Aktueller Zustand: kein Traefik-Router matcht den Namen, Traefik liefert sein TRAEFIK DEFAULT CERT aus, TLS bricht mit Zertifikatsfehler ab. Der Name funktioniert also ohnehin nicht.

Empfehlung: A- und AAAA-Record für www.rohana löschen. Es geht nichts verloren. Die Alternative — Router plus Cert-SAN für den zweiten Namen — bedeutet mehr Teile, die bei jeder Erneuerung mitvalidieren müssen, ohne Nutzen. Für selendis aus demselben Grund kein www. anlegen. Siehe Punkt 3 für die vollständige DNS-Bereinigung.

---

3. DNS-Bereinigung bei IONOS

Status: rohana und selendis werden vom User direkt umgesetzt (2026-07-30), game / matrix / ftp / Apex noch offen

Die Zone liegt bei IONOS (ns10xx.ui-dns.*), Zonentransfer ist verweigert — die Records unten stammen aus gezielten Abfragen und der IONOS-Oberfläche, die Liste ist daher nicht garantiert vollständig. Für eine vollständige Prüfung entweder die ungefilterte IONOS-Liste durchgehen oder die Certificate-Transparency-Logs abfragen.

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. Bei selendis und matrix ist das passiert, bei rohana und game nur das www.-Paar.

Warum nicht einfach löschen

Ersatzloses Entfernen der Mail-Records ist die schlechtere Variante:

• Ohne SPF existiert keine Aussage darüber, wer als dieser Name senden darf. Das bestehende ~all ist 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.de würde also Port 25 auf 188.245.193.243 ansprechen.

Richtig ist daher, „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 komplett aus): 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 die IONOS-Oberfläche . als MX-Ziel ablehnt: MX löschen und nur die TXT- Records setzen. -all und p=reject; greifen trotzdem.

Noch offen

• www.game, www.matrix (A-Records): dasselbe überflüssige Muster, aber auf fremden Hosts — nicht verifiziert, ob dort etwas darauf hört.
• matrix.axion1337.de: gleicher Mail-Satz wie selendis, aber erst prüfen, ob der Matrix-Server Benachrichtigungsmails mit Absender …@matrix.axion1337.de verschickt. Wenn ja, müssen SPF und DKIM dort bleiben und auf den echten Absender zeigen. autodiscover.matrix kann in jedem Fall weg — Matrix-Föderation läuft über .well-known bzw. SRV.
• ftp.axion1337.de → 217.160.233.227: IONOS-Default aus dem Hosting-Paket, zeigt auf IONOS und nicht auf eigene Infrastruktur. Löschen, falls dort kein FTP genutzt wird.
• Apex-DMARC ist v=DMARC1; p=none; — reines Monitoring, kein Schutz. Ohne sp=-Angabe erben alle Subdomains dieses p=none. sp=reject am Apex wäre der effiziente Hebel für alle Subdomains inklusive künftiger, aber erst nach Klärung von matrix, sonst bricht dessen Mailversand.
• game.axion1337.de ist 157.90.155.206 — derselbe Host wie in Punkt 2, den Prometheus per roher IP scrapt. Der Name wäre die wartbarere Variante.

---

2. Pterodactyl-Host 157.90.155.206 nicht erreichbar — 2 Prometheus-Targets down

Status: offen, Ursache liegt außerhalb dieses Hosts

Zwei Scrape-Targets sind seit Längerem down — bereits vor dem Monitoring-Rework, also kein Regressionsschaden aus der Umstellung:

Job	Target	Fehler
gameserver_cadvisor	157.90.155.206:8080	context deadline exceeded
pterodactyl_host_node	157.90.155.206:9100	context deadline exceeded

Der Host antwortet von 188.245.193.243 aus nicht auf Ping (100 % packet loss) und auf keinem der beiden Ports. Das Problem ist also nicht die Prometheus-Konfiguration, sondern die Erreichbarkeit des Zielhosts. Mögliche Ursachen, von wahrscheinlich nach unwahrscheinlich:

1. Hetzner-Cloud-Firewall des Pterodactyl-Hosts lässt 188.245.193.243 nicht auf 8080/9100 — passend zum restriktiven Firewall-Setup.
2. cAdvisor und node-exporter laufen dort nicht (mehr) bzw. binden nur auf 127.0.0.1.
3. Host ist abgeschaltet oder umgezogen (IP veraltet).

Nächster Schritt: auf dem Pterodactyl-Host prüfen, ob die beiden Exporter laufen und worauf sie binden, und die Firewall dort für 188.245.193.243 auf 8080/9100 öffnen. Idealerweise nicht öffentlich, sondern über das private Netz — dieser Host hat 10.0.0.3/32 auf enp7s0; wenn der Pterodactyl-Host im selben Hetzner-vSwitch liegt, sollte über die privaten IPs gescrapt werden statt über die öffentlichen. Dann sind dafür gar keine offenen Ports im Internet nötig.

Solange offen: die beiden Targets in Grafana/Alertmanager als known down behandeln, damit sie kein Dauer-Alerting erzeugen.

---

Weitere Beobachtungen (nicht beauftragt, aber notiert)

• Prometheus Port 9090 ist öffentlich und ohne Auth erreichbar. Nötig, weil k3s-Cluster und Matrix-Server per --web.enable-remote-write-receiver dorthin pushen. Ein offener Remote-Write-Receiver erlaubt Fremden aber das Einspeisen beliebiger Metriken und das Auslesen aller Daten. Sollte per Hetzner-Cloud-Firewall auf die Absender-IPs beschränkt werden — der Hinweis steht als Kommentar in monitoring/docker-compose.yml, ist aber noch nicht umgesetzt. Gleiches gilt für Loki auf 3100.
• Grafana-Admin-Credentials aus .env greifen nicht für die HTTP-API. Der Live-Admin wurde offenbar irgendwann in der UI geändert; GF_SECURITY_ADMIN_* wirkt nur beim allerersten Start mit leerem Volume. Verifikation läuft deshalb über grafana.db statt über die API. Kein Defekt, aber bei künftigen Checks wissen.