Krótka odpowiedź
Jak uruchomić prywatny resolver DNS z Unbound na VPS?
Aby uruchomić prywatny resolver DNS z Unbound, zainstalować pakiet unbound, wskazać adresy nasłuchu, zezwolić tylko własnej sieci przez access-control i przetestować poleceniem dig. Plan Ember Gloamport, 1 vCPU, 1 GB RAM, 20 GB NVMe, 1 TB traffic przy $3.74 miesięcznie przy 12 miesiącach, wystarcza na zapytania jednej osoby.
Które ustawienia Unbound czynią resolver prywatnym?
| Ustawienie | Wartość w tym poradniku | Co mówi podręcznik Unbound |
|---|---|---|
| interface | 127.0.0.1 i adres tunelu | Adresy, z których klienci mogą wysyłać zapytania; bez wpisów Unbound nasłuchuje na localhost |
| access-control | Zezwolenie dla sieci tunelu | Najbardziej szczegółowy blok sieci wygrywa; klient, który nie pasuje do żadnego, jest odrzucany |
| hide-identity | tak | Zapytania id.server i hostname.bind dostają REFUSED |
| hide-version | tak | Zapytania version.server i version.bind dostają REFUSED |
| qname-minimisation | tak | Wysyła upstreamowym serwerom jak najmniej informacji |
harden-dnssec-stripped | tak | Strefa z kotwicą zaufania, ale bez danych DNSSEC, staje się fałszywa (bogus) |
| prefetch | tak | Odświeża wpisy trafione w ostatnich 10% ich TTL, przy około 10% większym ruchu |
| private-address | Prywatne zakresy sieci | Takie odpowiedzi są usuwane dla publicznych nazw, co chroni przed DNS rebinding |
Ceny sprawdzone
Co zmienia prywatny resolver, a czego nie?
Prywatny resolver zmienia to, kto odpowiada na zapytania DNS i kto może je zobaczyć z sieci. Unbound rozwiązuje nazwy sam, pytając serwery root, a potem serwery każdej strefy, zamiast przekazywać zapytania do publicznego dostawcy DNS. Urządzenia wysyłają zapytania tylko do VPS, a serwery stref widzą adres VPS, a nie adres użytkownika.
Nie ukrywa to przeglądania. Odwiedzane strony nadal są osiągane przez swoje adresy, a dostawca VPS przenosi zapytania do VPS. Zwykły DNS między urządzeniem a VPS nie jest szyfrowany, dlatego najbezpieczniej nasłuchiwać wewnątrz tunelu, na przykład WireGuard na tym samym VPS. Nigdy nie zostawiać portu 53 otwartego dla całego internetu: otwarty resolver będą używać inni, a linie access-control poniżej go odrzucają.
Jak uruchomić Unbound jako prywatny resolver
Polecenia są przeznaczone dla Debiana 13 i Ubuntu 24.04. Przykłady zakładają tunel WireGuard z VPS pod adresem 10.8.0.1.
Instalacja Unbound i narzędzia do testów DNS
Uruchomić apt install unbound bind9-dnsutils. Drugi pakiet dostarcza dig do testów. Oba pakiety są dostępne zarówno w Debianie 13, jak i w Ubuntu 24.04.
Zapisanie konfiguracji
Utworzyć plik w /etc/unbound/unbound.conf.d/ z sekcją server z pierwszego bloku kodu. Zastąpić 10.8.0.1 i 10.8.0.0/24 adresem i siecią tunelu albo użyć wyłącznie 127.0.0.1, jeśli zapytania wysyła się bezpośrednio z VPS.
Sprawdzenie pliku
Uruchomić unbound-checkconf. Podręcznik mówi, że sprawdza on unbound.conf przed użyciem; wskazuje plik i wiersz każdego błędu.
Restart i sprawdzenie nasłuchu
Zrestartować usługę, a następnie uruchomić ss z opcjami -lunt i przefiltrować wynik przez grep dla :53. Powinny pojawić się tylko podane adresy, a nie 0.0.0.0.
Wysłanie zapytania
Z VPS uruchomić dig @127.0.0.1 example.org. Z urządzenia w tunelu uruchomić dig @10.8.0.1 example.org. Odpowiedź REFUSED z sieci spoza listy dozwolonych jest prawidłowym wynikiem.
Ustawienie urządzeń
W konfiguracji tunelu na urządzeniach ustawić serwer DNS na adres VPS w tunelu. Zaporę na porcie 53 zostawić zamkniętą dla interfejsu publicznego.
server:
interface: 127.0.0.1
interface: 10.8.0.1
access-control: 127.0.0.0/8 allow
access-control: 10.8.0.0/24 allow
hide-identity: yes
hide-version: yes
qname-minimisation: yes
harden-glue: yes
harden-dnssec-stripped: yes
prefetch: yes
private-address: 10.0.0.0/8
private-address: 172.16.0.0/12
private-address: 192.168.0.0/16sudo apt install unbound bind9-dnsutils
sudo unbound-checkconf
sudo systemctl restart unbound
sudo ss -lunt | grep :53
dig @127.0.0.1 example.org
dig @10.8.0.1 example.orgDlaczego Unbound trzeba ograniczyć przez access-control?
Ponieważ resolver odpowiadający każdemu zostanie znaleziony i użyty przez obcych. Podręcznik Unbound mówi, że przy access-control używa się najbardziej szczegółowego dopasowania bloku sieci, a klient, który nie pasuje do żadnego, jest odrzucany. Wpisać tylko sieci, których się jest właścicielem, a wszystko inne zostanie odrzucone domyślnie.
Dwa domyślne ustawienia pomagają. Jeśli nie podano linii interface, Unbound nasłuchuje tylko na localhost, a do-not-query-localhost ma wartość yes, więc nie wyśle własnych zapytań upstream na adresy localhost. Dodać linie private-address dla wewnętrznych zakresów, aby nazwa publiczna nie mogła wskazywać urządzeń na własnej sieci.
Który plan Gloamport wystarczy dla resolvera DNS?
Najmniejszy plan obsługuje prywatny resolver, a jego współdzielenie z VPN na tym samym serwerze to typowa konfiguracja. Ember, 1 vCPU, 1 GB RAM, 20 GB NVMe, 1 TB traffic, kosztuje $3.74 miesięcznie przy 12-miesięcznym okresie i $7.48 przy jednym miesiącu, a Gloamport wskazuje go dla VPN WireGuard dla kilku urządzeń. Resolver i WireGuard mieszczą się na nim razem. Nie testowaliśmy Unbound; jeśli obsługuje się wiele urządzeń, Dusk za $5.25 miesięcznie przy 12-miesięcznym okresie dodaje drugi GB pamięci (2 GB).
Pamięcią podręczną się dostraja. Podręcznik mówi, że cache-min-ttl, domyślnie wyłączone, może sprawiać kłopoty po ustawieniu powyżej około godziny, więc nie ruszać go bez konkretnego powodu.
Czy samodzielny resolver jest lepszy niż publiczny dostawca DNS?
Zależy od tego, komu ufa się w kwestii dziennika zapytań, a samodzielny resolver usuwa jedną stronę. Publiczny dostawca DNS widzi każdą nazwę, o którą pytają urządzenia; przy Unbound na własnym VPS zapytania gromadzi tylko serwer, który się kontroluje. Serwery autorytatywne sprawdzanych stref nadal widzą adres VPS.
Według ankiety Gloamport dotyczącej 10 listopada 2026, 28 z 49 wymienionych dostawców nie wymaga dokumentu tożsamości przy rejestracji, więc VPS, na którym działa resolver, jest dostępny bez przekazywania dokumentów. Pełne omówienie opcji tunelu znajduje się w Czy samodzielny VPN na VPS jest lepszy od usługi VPN?, a serwer należy zabezpieczyć według Jak zabezpieczyć SSH na nowym VPS?.
Podsumowanie
- Zainstalować unbound i bind9-dnsutils; konfigurować w /etc/unbound/unbound.conf.d/.
- Użyć interface i access-control, aby tylko własna sieć mogła wysyłać zapytania.
- Klient, który nie pasuje do żadnego bloku access-control, jest odrzucany.
- hide-identity i hide-version sprawiają, że zapytania o identyfikację i wersję dostają REFUSED.
- Przed każdym restartem uruchomić unbound-checkconf.
- Umieścić w tunelu WireGuard; zwykły DNS nie jest szyfrowany.
- Ember, $3.74 miesięcznie przy 12 miesiącach, go uruchamia.
Prywatny resolver Unbound: najczęstsze pytania
Czy Unbound weryfikuje DNSSEC?
Unbound jest resolverem walidującym, a jego podręcznik opisuje opcje trust-anchor i harden-dnssec-stripped. Instalację sprawdzić poleceniem dig +dnssec i poszukać flagi ad w odpowiedzi.
Czy zamiast tego można przekazywać zapytania do innego dostawcy DNS?
Tak, Unbound obsługuje przekazywanie, ale wtedy ten dostawca widzi zapytania. Ten poradnik rozwiązuje nazwy rekurencyjnie, więc żaden pojedynczy dostawca tego nie widzi.
Dlaczego unbound-checkconf zgłosił błąd?
Narzędzie wskazuje plik i wiersz pierwszego błędu. Typowe przyczyny to literówka w słowie kluczowym albo brakujący dwukropek. Poprawić go i uruchomić polecenie ponownie przed restartem usługi.
Czy trzeba otwierać port 53 w zaporze?
Tylko na interfejsie tunelu. Na interfejsie publicznym zostawić go zamknięty i ograniczyć listę access-control do własnej sieci.
Co robi prefetch?
Przy prefetch ustawionym na yes trafienie w pamięci podręcznej w ostatnich 10 procentach czasu życia wpisu uruchamia odświeżenie w tle. Podręcznik mówi, że powoduje to około 10 procent więcej ruchu i obciążenia.
Źródła (1)
- Podręcznik unbound.conf(5): opcje serwera — NLnet Labs (checked 2026-11-10)