{"id":449,"date":"2026-09-07T17:35:00","date_gmt":"2026-09-07T15:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?p=449"},"modified":"2026-10-24T00:58:26","modified_gmt":"2026-10-23T22:58:26","slug":"infrastruktura-zero-trust-dns-unbound-i-pi-hole-z-doh-oraz-dnssec","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/it-networks-pl\/tutorials-pl-it-networks-pl\/infrastruktura-zero-trust-dns-unbound-i-pi-hole-z-doh-oraz-dnssec\/","title":{"rendered":"Infrastruktura Zero-Trust DNS: Unbound i Pi-hole z DoH oraz DNSSEC"},"content":{"rendered":"
Pi-hole i Unbound pe\u0142ni\u0105 r\u00f3\u017cne funkcje: Pi-hole filtruje nazwy DNS wed\u0142ug regu\u0142, a Unbound rozwi\u0105zuje dozwolone zapytania i sprawdza DNSSEC. Centralny publiczny resolwer przestaje by\u0107 punktem zbieraj\u0105cym przekazywane zapytania. Nadal potrzebne s\u0105 serwery root, TLD i autorytatywne. Samo po\u0142\u0105czenie tych narz\u0119dzi nie tworzy kompletnej architektury zero trust.<\/p>\n
1. Filtrowanie, rekursja i DNSSEC<\/h2>\n
DNS przyporz\u0105dkowuje nazwy, np. example.com<\/code>, do adres\u00f3w. Publiczny resolwer mo\u017ce zapisywa\u0107 otrzymane nazwy, ale zwyk\u0142e zapytanie DNS nie zawiera pe\u0142nej \u015bcie\u017cki URL, tre\u015bci strony ani wszystkich metadanych ruchu sieciowego.<\/p>\n
\n
Pi-hole:<\/strong> obs\u0142uguje zapytania urz\u0105dze\u0144 faktycznie korzystaj\u0105cych z Pi-hole jako serwera DNS. Listy domen nie zapewniaj\u0105 pe\u0142nego wykrywania reklam ani z\u0142o\u015bliwego oprogramowania. Przegl\u0105darka z osobn\u0105 us\u0142ug\u0105 DoH mo\u017ce omin\u0105\u0107 lokalny filtr.<\/li>\n
Unbound:<\/strong> rozwi\u0105zuje dozwolone zapytania bez dost\u0119pnej odpowiedzi w pami\u0119ci podr\u0119cznej. Odes\u0142ania prowadz\u0105 od serwer\u00f3w root przez TLD do serwer\u00f3w autorytatywnych; zapisane wcze\u015bniej dane mog\u0105 skr\u00f3ci\u0107 t\u0119 drog\u0119.<\/li>\n
DNSSEC:<\/strong> sprawdza podpisane dane DNS na podstawie \u0142a\u0144cucha zaufania. B\u0142\u0119dne podpisy powoduj\u0105 odrzucenie odpowiedzi. Strefy poprawnie rozpoznane jako niepodpisane nadal dzia\u0142aj\u0105, lecz bez kryptograficznego potwierdzenia autentyczno\u015bci odpowiedzi. DNSSEC nie szyfruje zapyta\u0144.<\/li>\n<\/ul>\nPi-hole filtruje skonfigurowanych klient\u00f3w; Unbound rozwi\u0105zuje nazwy i sprawdza podpisane dane DNS. Bezpo\u015brednia rekursja zwykle korzysta z nieszyfrowanego transportu.<\/figcaption><\/figure>\n
2. Przyk\u0142ad dla Debiana lub Raspberry Pi OS<\/h2>\n
Przyk\u0142ad zak\u0142ada Pi-hole i Unbound na wsp\u00f3lnym ho\u015bcie i we wsp\u00f3lnej przestrzeni sieciowej, bez oddzielnych sieci kontener\u00f3w. Zmiany dzia\u0142aj\u0105cego DNS mog\u0105 przerwa\u0107 rozwi\u0105zywanie nazw. Przygotowanie obejmuje kopi\u0119 dotychczasowej konfiguracji i dost\u0119pny kana\u0142 administracyjny. Rekursja wymaga wychodz\u0105cego ruchu UDP oraz TCP na port 53.<\/p>\n
Instalacja z utrzymywanych pakiet\u00f3w dystrybucji:<\/p>\n
Przed dodaniem ustawie\u0144 konieczna jest kontrola konfiguracji pakietu w \/etc\/unbound\/<\/code>. Pakiety Debiana zwykle zapewniaj\u0105 root hints i kotwic\u0119 zaufania DNSSEC. Istniej\u0105cego wpisu auto-trust-anchor-file<\/code> dla tej samej \u015bcie\u017cki nie nale\u017cy powiela\u0107. Us\u0142uga Unbound potrzebuje prawa zapisu do automatycznie aktualizowanej kotwicy. Przy braku takiej konfiguracji punktem odniesienia jest instrukcja pakietu dystrybucji.<\/p>\n
Poni\u017cszy fragment pliku \/etc\/unbound\/unbound.conf.d\/pi-hole.conf<\/code> uzupe\u0142nia konfiguracj\u0119 pakietu:<\/p>\n
do-ip6: no<\/code> wybiera tutaj transport IPv4; rekordy AAAA pozostaj\u0105 dost\u0119pne. Przy dzia\u0142aj\u0105cym natywnym IPv6 uzasadniona mo\u017ce by\u0107 warto\u015b\u0107 yes<\/code>. Fragment celowo nie deklaruje drugiej kotwicy zaufania i nie stanowi pe\u0142nej samodzielnej konfiguracji.<\/p>\n
Restart nast\u0119puje dopiero po poprawnej kontroli konfiguracji. Poni\u017csze polecenia stanowi\u0105 oddzielne kroki; b\u0142\u0105d pierwszej kontroli oznacza konieczno\u015b\u0107 wstrzymania restartu:<\/p>\n
Pierwszy test DNS powinien zwr\u00f3ci\u0107 SERVFAIL<\/code>, a drugi NOERROR<\/code> z flag\u0105 ad<\/code>. Pojedynczy wynik SERVFAIL<\/code> nie dowodzi sprawnej walidacji: podobny rezultat powoduj\u0105 problemy z \u0142\u0105czno\u015bci\u0105. DNSSEC wymaga prawid\u0142owego czasu systemowego. Polecenie restart<\/code> nie w\u0142\u0105cza startu us\u0142ugi przy uruchamianiu systemu; is-enabled<\/code> sprawdza istniej\u0105ce ustawienie.<\/p>\n
3. Po\u0142\u0105czenie z Pi-hole i kontrola rzeczywistej trasy<\/h2>\n
W Settings > DNS<\/code> niestandardowym serwerem nadrz\u0119dnym zostaje 127.0.0.1#5335<\/code>. Dla wy\u0142\u0105cznie lokalnej rekursji pozosta\u0142e serwery nadrz\u0119dne wymagaj\u0105 usuni\u0119cia. Po zapisaniu zmian testowe zapytanie do Pi-hole powinno wskaza\u0107 Unbound jako cel przekazania w dzienniku zapyta\u0144. W oddzielnych kontenerach adres 127.0.0.1<\/code> oznacza wn\u0119trze danego kontenera i nie nadaje si\u0119 do takiego po\u0142\u0105czenia.<\/p>\n
Opcja Use DNSSEC<\/code> uruchamia dodatkow\u0105 walidacj\u0119 w Pi-hole, a nie samo przekazywanie flag. Unbound sprawdza DNSSEC niezale\u017cnie. Po w\u0142\u0105czeniu dodatkowej kontroli oba testy DNSSEC wymagaj\u0105 powt\u00f3rzenia przez Pi-hole. Kontroli wymaga r\u00f3wnie\u017c integracja z openresolv<\/code> lub unbound-resolvconf<\/code>: wpis dotycz\u0105cy portu 53 nie mo\u017ce tworzy\u0107 p\u0119tli do lokalnej us\u0142ugi.<\/p>\n
4. DoH jako inny tryb dzia\u0142ania<\/h2>\n
Zwyk\u0142a bezpo\u015brednia rekursja wysy\u0142a poza sie\u0107 nieszyfrowane zapytania DNS. Minimalizacja QNAME ogranicza cz\u0119\u015bci nazwy ujawniane poszczeg\u00f3lnym serwerom, lecz obserwator na \u0142\u0105czu internetowym nadal mo\u017ce odczytywa\u0107 zapytania.<\/p>\n
Celowo skonfigurowany serwer nadrz\u0119dny DoH szyfruje po\u0142\u0105czenie z wybranym resolwerem. Ten resolwer otrzymuje przekazywane nazwy. Jest to inna architektura, a nie automatyczny tryb awaryjny. Dodanie kolejnego serwera nadrz\u0119dnego w Pi-hole nie zapewnia ustalonej kolejno\u015bci prze\u0142\u0105czania po awarii. Weryfikacja certyfikatu, pocz\u0105tkowe rozwi\u0105zanie adresu us\u0142ugi i zachowanie podczas niedost\u0119pno\u015bci wymagaj\u0105 osobnej konfiguracji.<\/p>\n
Funkcja cloudflared proxy-dns<\/code> zosta\u0142a usuni\u0119ta od wersji 2026.2.0 i nie jest aktualn\u0105 opcj\u0105 instalacji. Udokumentowana obs\u0142uga DoH w Unbound dla przychodz\u0105cych zapyta\u0144 klient\u00f3w r\u00f3wnie\u017c wymaga odr\u00f3\u017cnienia od wychodz\u0105cego przekazywania przez DoH.<\/p>\n
\n
Pytania i odpowiedzi<\/h2>\n
Czy ta konfiguracja zapobiega obserwacji przez dostawc\u0119 Internetu?<\/h3>\n
Sama bezpo\u015brednia rekursja nie zapewnia takiej ochrony. DoH chroni tre\u015b\u0107 danego po\u0142\u0105czenia DNS; docelowe adresy IP p\u00f3\u017aniejszych po\u0142\u0105cze\u0144 zasadniczo pozostaj\u0105 widoczne. DNSSEC chroni podpisane dane przed niewykryt\u0105 zmian\u0105, ale nie zapobiega blokadom ani atakom na niepodpisane dane DNS. Szyfrowane po\u0142\u0105czenie klienta z w\u0142asnym resolwerem rekursywnym jest mo\u017cliwe; nie oznacza automatycznego szyfrowania drogi od resolwera do serwer\u00f3w autorytatywnych.<\/p>\n
Dlaczego znikaj\u0105 odpowiedzi z prywatnymi adresami IP?<\/h3>\n
private-address<\/code> zapobiega wprowadzaniu wymienionych prywatnych adres\u00f3w przez odpowiedzi publicznego DNS. Celowo wewn\u0119trzna nazwa mo\u017ce wymaga\u0107 w\u0105skiego wyj\u0105tku, np. private-domain: \"internal.example.com\"<\/code>. Wyj\u0105tek dla ca\u0142ej domeny obejmuje r\u00f3wnie\u017c subdomeny i os\u0142abia ochron\u0119 przed rebindingiem w tym zakresie. Lokalne rekordy obs\u0142ugiwane bezpo\u015brednio przez Pi-hole nie przechodz\u0105 przez Unbound.<\/p>\n<\/div>\n
![\"Pi-hole](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/quality-449-20261024.png\")