Lokalne rozwiązywanie i filtrowanie zapytań DNS: konfiguracja Pi-hole z Unbound

Pi-hole i Unbound pełnią różne funkcje: Pi-hole filtruje nazwy DNS według reguł, a Unbound rozwiązuje dozwolone zapytania i sprawdza DNSSEC. Centralny publiczny resolwer przestaje być punktem zbierającym przekazywane zapytania. Nadal potrzebne są serwery root, TLD i autorytatywne. Samo połączenie tych narzędzi nie tworzy kompletnej architektury zero trust.

1. Filtrowanie, rekursja i DNSSEC

Droga do odpowiedzi DNS: Resolwer znajduje odpowiedź na pytanie DNS. Przy rekursji podąża za odesłaniami między serwerami zamiast przekazywać całe zadanie jednemu publicznemu resolwerowi. Serwery root wskazują serwery końcówek takich jak .com, czyli domen najwyższego poziomu (TLD). Serwery autorytatywne przechowują rekordy DNS właściwej strefy. Pamięć podręczna zachowuje wcześniejsze odpowiedzi przez pewien czas i ogranicza ponowne zapytania.

DNS przyporządkowuje nazwy, np. example.com, do adresów. Publiczny resolwer może zapisywać otrzymane nazwy, ale zwykłe zapytanie DNS nie zawiera pełnej ścieżki URL, treści strony ani wszystkich metadanych ruchu sieciowego.

• Pi-hole: obsługuje zapytania urządzeń faktycznie korzystających z Pi-hole jako serwera DNS. Listy domen nie zapewniają pełnego wykrywania reklam ani złośliwego oprogramowania. Przeglądarka z osobną usługą DoH może ominąć lokalny filtr.
• Unbound: rozwiązuje dozwolone zapytania bez dostępnej odpowiedzi w pamięci podręcznej. Odesłania prowadzą od serwerów root przez TLD do serwerów autorytatywnych; zapisane wcześniej dane mogą skrócić tę drogę.
• DNSSEC: sprawdza podpisane dane DNS na podstawie łańcucha zaufania. Błędne podpisy powodują odrzucenie odpowiedzi. Strefy poprawnie rozpoznane jako niepodpisane nadal działają, lecz bez kryptograficznego potwierdzenia autentyczności odpowiedzi. DNSSEC nie szyfruje zapytań.

2. Przykład dla Debiana lub Raspberry Pi OS

Przykład zakłada Pi-hole i Unbound na wspólnym hoście i we wspólnej przestrzeni sieciowej, bez oddzielnych sieci kontenerów. Zmiany działającego DNS mogą przerwać rozwiązywanie nazw. Przygotowanie obejmuje kopię dotychczasowej konfiguracji i dostępny kanał administracyjny. Rekursja wymaga wychodzącego ruchu UDP oraz TCP na port 53.

Instalacja z utrzymywanych pakietów dystrybucji:

sudo apt update
sudo apt install unbound dnsutils

Przed dodaniem ustawień konieczna jest kontrola konfiguracji pakietu w /etc/unbound/. Root hints to początkowe adresy serwerów root. Kotwica zaufania DNSSEC jest zaufanym kluczem lub rekordem początkowym służącym do sprawdzenia łańcucha podpisów. Pakiety Debiana zwykle zapewniają oba elementy. Istniejącego wpisu auto-trust-anchor-file dla tej samej ścieżki nie należy powielać. Usługa Unbound potrzebuje prawa zapisu do automatycznie aktualizowanej kotwicy. Przy braku takiej konfiguracji punktem odniesienia jest instrukcja pakietu dystrybucji.

Poniższy fragment pliku /etc/unbound/unbound.conf.d/pi-hole.conf uzupełnia konfigurację pakietu:

server:
    interface: 127.0.0.1
    port: 5335
    verbosity: 0
    do-ip4: yes
    do-ip6: no
    do-udp: yes
    do-tcp: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: no
    edns-buffer-size: 1232
    prefetch: yes
    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
    private-address: 169.254.0.0/16
    private-address: fc00::/7
    private-address: fe80::/10

do-ip6: no wybiera tutaj transport IPv4; rekordy AAAA zawierające adresy IPv6 pozostają dostępne. Przy działającym natywnym IPv6 uzasadniona może być wartość yes. Fragment celowo nie deklaruje drugiej kotwicy zaufania i nie stanowi pełnej samodzielnej konfiguracji.

Restart następuje dopiero po poprawnej kontroli konfiguracji. Poniższe polecenia stanowią oddzielne kroki; błąd pierwszej kontroli oznacza konieczność wstrzymania restartu:

sudo unbound-checkconf
sudo systemctl restart unbound
systemctl is-enabled unbound
dig @127.0.0.1 -p 5335 fail01.dnssec.works
dig @127.0.0.1 -p 5335 dnssec.works +ad

Pierwszy test DNS powinien zwrócić SERVFAIL, a drugi NOERROR z flagą ad. Pojedynczy wynik SERVFAIL nie dowodzi sprawnej walidacji: podobny rezultat powodują problemy z łącznością. DNSSEC wymaga prawidłowego czasu systemowego. Polecenie restart nie włącza startu usługi przy uruchamianiu systemu; is-enabled sprawdza istniejące ustawienie.

3. Połączenie z Pi-hole i kontrola rzeczywistej trasy

W Settings > DNS niestandardowym serwerem nadrzędnym zostaje 127.0.0.1#5335. Dla wyłącznie lokalnej rekursji pozostałe serwery nadrzędne wymagają usunięcia. Po zapisaniu zmian testowe zapytanie do Pi-hole powinno wskazać Unbound jako cel przekazania w dzienniku zapytań. W oddzielnych kontenerach adres 127.0.0.1 oznacza wnętrze danego kontenera i nie nadaje się do takiego połączenia.

Opcja Use DNSSEC uruchamia dodatkową walidację w Pi-hole, a nie samo przekazywanie flag. Unbound sprawdza DNSSEC niezależnie. Po włączeniu dodatkowej kontroli oba testy DNSSEC wymagają powtórzenia przez Pi-hole. Kontroli wymaga również integracja z openresolv lub unbound-resolvconf: wpis dotyczący portu 53 nie może tworzyć pętli do lokalnej usługi.

4. DoH jako inny tryb działania

Zwykła bezpośrednia rekursja wysyła poza sieć nieszyfrowane zapytania DNS. Minimalizacja QNAME ogranicza części nazwy ujawniane poszczególnym serwerom, lecz obserwator na łączu internetowym nadal może odczytywać zapytania.

Serwer nadrzędny to kolejny serwer DNS, do którego przekazywane jest zapytanie. DoH oznacza DNS przez HTTPS. Celowo skonfigurowany serwer nadrzędny DoH szyfruje połączenie z wybranym resolwerem. Ten resolwer otrzymuje przekazywane nazwy. Jest to inna architektura, a nie automatyczny tryb awaryjny. Dodanie kolejnego serwera nadrzędnego w Pi-hole nie zapewnia ustalonej kolejności przełączania po awarii. Weryfikacja certyfikatu, początkowe rozwiązanie adresu usługi i zachowanie podczas niedostępności wymagają osobnej konfiguracji. Początkowe rozwiązanie dostarcza adres potrzebny do pierwszego połączenia z szyfrowaną usługą DNS.

Funkcja cloudflared proxy-dns została usunięta od wersji 2026.2.0 i nie jest aktualną opcją instalacji. Udokumentowana obsługa DoH w Unbound dla przychodzących zapytań klientów również wymaga odróżnienia od wychodzącego przekazywania przez DoH.