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 manipulacją ze strony dostawcy Internetu; przed podsłuchem na łączu samo to nie chroni.

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 zewnętrznym dostawcom DNS 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.