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.