# Runbook 20 — domeny i DNS

Wszystkie trzy domeny są w OVH, DNS też w OVH. To upraszcza sprawę: Traefik może
używać API OVH do wyzwania **DNS-01**, więc dostajemy certyfikaty wildcard.

---

## 1. Dlaczego DNS-01, a nie HTTP-01

| | HTTP-01 | DNS-01 (nasz wybór) |
|---|---|---|
| Jak działa | Let's Encrypt puka na port 80 | Traefik wpisuje rekord TXT przez API |
| Wildcard | niemożliwy | możliwy |
| Nowa subdomena | osobny certyfikat, osobne wyzwanie | działa od razu, zero akcji |
| Usługi niepubliczne | nie da się | da się |
| Wymaga | otwartego portu 80 | kluczy API dostawcy DNS |

Przy wildcardzie `*.dfkk.cloud` dodanie `nowyprojekt.dfkk.cloud` to jeden rekord A
i restart kontenera. Certyfikatem nie zajmujesz się w ogóle.

---

## 2. Klucze API OVH — jednorazowo

1. Wejdź na stronę tworzenia tokenów API OVH dla właściwego regionu konta
   (uwaga: konto jest w regionie **CA** — patrz adres panelu w `SERVER.md`,
   to zmienia zarówno adres, pod którym generujesz token, jak i endpoint w konfiguracji)
2. Uprawnienia zawężone do stref DNS — `GET`, `POST`, `PUT`, `DELETE`
   na `/domain/zone/*`. Nie dawaj tokenowi pełnego dostępu do konta.
3. Ważność: bez limitu, ale **wpisz token do `SERVER.md`, sekcja 9**, żeby wiadomo było,
   co unieważnić przy incydencie
4. Trzy wartości — application key, application secret, consumer key —
   lądują w `/srv/infra/stacks/traefik/.env`, `chmod 600`, poza repo

---

## 3. Nowa subdomena

```
Typ: A
Nazwa: <projekt>
Cel: <IP serwera>
TTL: 300 (na czas testów; potem można podnieść)
```

Sprawdzenie propagacji:

```bash
dig +short <projekt>.dfkk.cloud
```

Dopóki `dig` nie zwraca IP serwera, nie ma sensu debugować Traefika —
problem jest w DNS, nie w kontenerze.

---

## 4. Nowa domena (druga lub trzecia)

Wildcard obejmuje **tylko** `*.dfkk.cloud`. Kolejna domena wymaga:

1. Rekordu A na IP serwera
2. Dopisania nowej domeny do konfiguracji certresolvera w Traefiku
   (osobny wpis `domains` z `main` i `sans`)
3. Sprawdzenia, że token API OVH ma uprawnienia **także do tej strefy**
4. Wpisu w `SERVER.md`, sekcja 2

---

## 5. Odpinanie domeny

Kolejność odwrotna niż przy podpinaniu:

- [ ] Usuń labele Traefika z compose i zrestartuj usługę
- [ ] Usuń rekord A w panelu OVH
- [ ] Sprawdź, że nie ma innych rekordów wskazujących na serwer (CNAME, MX)
- [ ] Wykreśl subdomenę z `SERVER.md`, sekcja 2
- [ ] Usuń monitor z Uptime Kuma

Martwy rekord A wskazujący na Twój serwer to nie tylko bałagan — jeśli kiedyś oddasz
to IP, ktoś inny odziedziczy ruch kierowany na Twoją nazwę.

---

## 6. Diagnostyka

| Objaw | Gdzie szukać |
|---|---|
| `dig` nie zwraca IP | DNS, panel OVH — nie ruszaj serwera |
| DNS ok, ale 404 z Traefika | literówka w `Host()` albo brak `traefik.enable=true` |
| DNS ok, ale połączenie odrzucone | kontener nie działa lub nie jest w sieci `edge` |
| Błąd certyfikatu | logi Traefika, klucze API OVH, uprawnienia do strefy |
| Certyfikat „fake" / staging | w konfiguracji został adres staging Let's Encrypt |

```bash
docker logs traefik --tail=100 | grep -i -E "acme|error|certificate"
```

> **Uwaga na limity Let's Encrypt.** Przy debugowaniu certyfikatów łatwo wpaść
> w limit żądań i zostać zablokowanym na tydzień. Jeśli certyfikat nie chce się
> wystawić — przełącz się na serwer **staging** Let's Encrypt, dopracuj konfigurację
> tam, i dopiero potem wróć na produkcyjny.