Fałszywe rekordy DNSSEC – cichy zabójca Twojego DNS. Jak poprawnie zabezpieczyć Unbound i trust anchor?

DNSSEC miał być gwarantem bezpieczeństwa. Miał uniemożliwić podmianę rekordów DNS przez atakujących.
A jednak coraz częściej administratorzy obserwują dziwne błędy:

• nagle przestaje się rozwiązywać google.com,
• apt update kończy się błędem SERVFAIL,
• a logi Unbounda wyglądają jakby coś “padło” w trust anchorze.

W praktyce, winowajcą nie jest DNSSEC jako idea, tylko sposób, w jaki systemy odnawiają trust anchor (klucz zaufania do strefy root).
Jeden restart w złym momencie — i Twój resolver zaczyna wierzyć fałszywym danym.
Brzmi poważnie? Bo jest.

Co to jest trust anchor i czemu ma znaczenie?

Trust anchor to klucz publiczny strefy głównej DNS (.), który jest źródłem całego łańcucha zaufania DNSSEC. Bez niego resolver (np. Unbound) nie jest w stanie zweryfikować żadnej podpisanej strefy.
W Unboundzie znajduje się on w pliku:

/var/lib/unbound/root.key

Ten plik jest automatycznie aktualizowany przy pomocy narzędzia:

unbound-anchor

⚠️ Objawy problemu

Typowe logi w /var/log/unbound/unbound.log lub journalctl -u unbound:

error: validation failure <example.com. A IN>: no valid signature
info: validation failure <debian.org. DS IN>: no valid signature

lub:

error: trust anchor . has expired

Czasem problem maskuje się częściowo – niektóre domeny działają (bez DNSSEC), inne przestają.
Objaw: losowe błędy SERVFAIL, których nie da się powtórzyć.

🧩 Szybka diagnoza

Sprawdź status trust anchor:

sudo unbound-anchor -l

Jeśli widzisz stare daty lub brak aktualizacji – to pierwszy sygnał.

Sprawdź poprawność łańcucha DNSSEC:

dig +dnssec linuxadmin.online

Jeśli w sekcji AD (Authenticated Data) nie ma flagi ad, oznacza to brak walidacji.

🔧 Naprawa i aktualizacja trust anchor

1. Zatrzymaj Unbounda: sudo systemctl stop unbound
2. Usuń stary klucz: sudo rm -f /var/lib/unbound/root.key
3. Wygeneruj nowy: sudo unbound-anchor -a /var/lib/unbound/root.key
4. Sprawdź aktualność: sudo unbound-anchor -l
5. Uruchom ponownie resolver: sudo systemctl start unbound
6. Zweryfikuj: dig +dnssec +multi google.com | grep ad Jeśli widzisz ad — walidacja działa poprawnie.

🧱 Dobre praktyki

🔁 Ustaw cron na automatyczne odświeżanie:

0 3 * * 0 /usr/sbin/unbound-anchor -a /var/lib/unbound/root.key >/dev/null 2>&1

⏰ Zadbaj o synchronizację czasu:

timedatectl status

DNSSEC wymaga poprawnego zegara.

🔒 Nie mieszaj trust anchor między VM-ami – każdy resolver powinien mieć własny plik root.key.

📜 Włącz pełne logowanie walidacji:
W /etc/unbound/unbound.conf:

verbosity: 2
val-log-level: 2

🧠 Bonus: test poprawności z dnssec-trigger

Jeśli chcesz być pewny, że Twój resolver nie ufa fałszywym danym, możesz użyć narzędzia:

sudo apt install dnssec-trigger
sudo dnssec-trigger-control status

Narzędzie przeprowadzi testy walidacji i powie, czy Twój Unbound ufa poprawnym kluczom.

💬 Podsumowanie

DNSSEC to potężne narzędzie, ale jego siła jest równa najsłabszemu ogniwu — a tym jest trust anchor.
Jeden nieaktualny klucz potrafi położyć cały DNS resolver, nawet jeśli reszta systemu działa bezbłędnie.
Zadbaj o regularną aktualizację, monitoring logów i poprawny czas — a Twój Unbound będzie naprawdę nie do ruszenia.