Infrastruktura Zero-Trust DNS: Unbound i Pi-hole z DoH oraz DNSSEC

Poleganie na zewnętrznych, publicznych serwerach DNS (takich jak 8.8.8.8 czy 1.1.1.1) wiąże się z koniecznością przekazywania pełnych metadanych o aktywności sieciowej podmiotom trzecim. Nawet w przypadku stosowania szyfrowania transportowego, centralni dostawcy DNS mają możliwość rejestrowania zapytań i profilowania ruchu. Wdrożenie architektury Zero-Trust DNS poprzez połączenie systemu Pi-hole z lokalnym, rekursywnym serwerem weryfikującym Unbound całkowicie eliminuje zależność od operatorów zewnętrznych. Samodzielne odpytywanie serwerów pierwiastkowych (Root Servers) z jednoczesną walidacją DNSSEC gwarantuje integralność kryptograficzną, chroniąc sieć przed fałszowaniem pamięci podręcznej (cache poisoning) oraz podsłuchem i manipulacją ze strony dostawcy Internetu.

1. Założenia architektoniczne: Zero-Trust DNS i rekursja

W standardowej konfiguracji sieciowej zapytania DNS są przesyłane dalej do operatora ISP lub publicznego resolwera. Lokalna architektura Zero-Trust rozdziela to zadanie na dwa odrębne etapy:

• Pi-hole (DNS Sinkhole i moduł filtrujący): Przechwytuje zapytania z urządzeń lokalnych, blokując ruch telemetryczny, reklamy i domeny złośliwe na podstawie czarnych list.
• Unbound (Serwer rekursywny i walidator): Otrzymuje prawidłowe zapytania od Pi-hole i samodzielnie przechodzi przez hierarchię DNS (Root Servers → TLD Servers → Serwery autorytatywne). Każda odpowiedź jest sprawdzana pod kątem kryptograficznych podpisów DNSSEC przed zapisaniem w lokalnej pamięci podręcznej.

2. Instalacja i utwardzanie serwera Unbound krok po kroku

W celu skonfigurowania serwera Unbound jako wysoko zabezpieczonego resolwera rekursywnego na systemie Linux (np. Debian lub Raspberry Pi OS), należy zrealizować poniższą procedurę:

1. Instalacja pakietów: Instalacja serwera DNS i narzędzi kryptograficznych:
   sudo apt update && sudo apt install unbound unbound-anchor -y
2. Konfiguracja kotwicy zaufania DNSSEC: Pobranie oficjalnego klucza głównego (Root Key) do weryfikacji podpisów:
   sudo unbound-anchor -a /var/lib/unbound/root.key
3. Tworzenie pliku konfiguracyjnego: Utworzenie pliku /etc/unbound/unbound.conf.d/pi-hole.conf ze zoptymalizowanymi parametrami bezpieczeństwa i prywatności:

   server:
       verbosity: 1
       interface: 127.0.0.1
       port: 5335
       do-ip4: yes
       do-udp: yes
       do-tcp: yes
   
       # Bezpieczeństwo i walidacja DNSSEC
       auto-trust-anchor-file: "/var/lib/unbound/root.key"
       harden-glue: yes
       harden-dnssec-stripped: yes
       use-caps-for-id: no
       edns-buffer-size: 1232
       prefetch: yes
       num-threads: 1
   
       # Ochrona prywatności (Minimalizacja ujawnianych danych)
       qname-minimisation: yes
       hide-identity: yes
       hide-version: yes
       private-address: 10.0.0.0/8
       private-address: 172.16.0.0/12
       private-address: 192.168.0.0/16

4. Restart usługi i weryfikacja działania: Uruchomienie daemona Unbound i przetestowanie walidacji DNSSEC na zdefiniowanym porcie lokalnym:
   sudo systemctl restart unbound
dig @127.0.0.1 -p 5335 dnssec-failed.org +dnssec (Zapytanie musi zwrócić status SERVFAIL w wyniku błędnego podpisu DNSSEC).

3. Integracja z Pi-hole i opcjonalny tunel DoH krok po kroku

Po poprawnym uruchomieniu rekursji lokalnej, system Pi-hole musi zostać przekierowany wyłącznie na serwer Unbound:

1. Konfiguracja serwera nadrzędnego w Pi-hole: Otwarcie panelu administracyjnego Pi-hole i przejście do zakładki Settings > DNS.
2. Wyłączenie zewnętrznych dostawców: Odznaczenie wszystkich domyślnych zewnętrznych serwerów DNS (np. Google, Cloudflare, Quad9).
3. Wskazanie lokalnego serwera Upstream: W polu Custom 1 (IPv4) należy wpisać lokalne gniazdo Unbound: 127.0.0.1#5335.
4. Włączenie obsługi DNSSEC: Zaznaczenie opcji Use DNSSEC, aby Pi-hole prawidłowo przekazywał flagi walidacji kryptograficznej do klientów w sieci lokalnej.
5. Opcjonalne szyfrowanie DNS-over-HTTPS (DoH): W środowiskach sieciowych narażonych na inspekcję pakietów na porcie 53 przez ISP, serwer Unbound da się skonfigurować do kierowania ruchu przez lokalny proxy DoH (np. cloudflared lub dnscrypt-proxy), co zapewnia pełne szyfrowanie TLS w sieciach tranzytowych.

4. Podsumowanie i wartość architektoniczna

Co da się osiągnąć dzięki temu poradnikowi: Wdrożenie niezależnej architektury Zero-Trust DNS, łączącej filtrowanie reklam i zagrożeń w Pi-hole z bezpośrednią rekursją, minimalizacją zapytań i walidacją kryptograficzną DNSSEC w serwerze Unbound.

Wynikająca z tego wartość: Uzyskana zostaje pełna niezależność od komercyjnych dostawców DNS, co uniemożliwia podmiotom trzecim profilowanie oraz monetyzację historii przeglądania sieci lokalnej. Walidacja DNSSEC skutecznie zabezpiecza urządzenia przed atakami typu cache poisoning, spoofing i Man-in-the-Middle, a mechanizm QNAME minimisation sprawia, że do serwerów nadrzędnych wysyłane jest wyłącznie absolutne minimum informacji niezbędnych do ustalenia adresu docelowego.