Resolver dla Twoich urządzeń, nie otwarty wzmacniacz.

Wybierz rolę

Rekurencyjny resolver, taki jak Unbound, i interfejs filtrujący, taki jak AdGuard Home, rozwiązują powiązane, ale odrębne problemy. Zdecyduj, czy usługa sama wykonuje rekurencję, czy przekazuje zapytania do serwera nadrzędnego, i zrozum, która strona widzi wtedy zapytania.

Zachowaj prywatność

Nieograniczony publiczny resolver może być wykorzystywany do ataków odbiciowych. Powiąż go z siecią prywatną lub zezwól tylko autoryzowanym źródłom, w tym IPv6. Jeśli używasz szyfrowanego DNS, uwierzytelnij lub w inny odpowiedni sposób ogranicz dostęp, zamiast zakładać, że HTTPS czyni go prywatnym.

Ustal politykę rejestrowania

Zapytania DNS mogą ujawniać wrażliwą aktywność przeglądania i aplikacji. Wyłącz niepotrzebne przechowywanie, chroń zachowywane rekordy i wyjaśnij zakres użytkownikom. Szyfrowany transport chroni ścieżkę; nie powstrzymuje samego resolvera przed widzeniem zapytań.

Przetestuj więcej niż jedną nazwę

Zweryfikuj zachowanie DNSSEC, jeśli jest włączone, wyniki IPv4 i IPv6, wyjątki filtrowania i odzyskiwanie, gdy nadrzędny serwer zawiedzie. Zapewnij bezpieczny sposób naprawy dostępu bez polegania wyłącznie na resolverze, który naprawiasz.

Udowodnij, że obcy nie mogą jej odpytywać

Powiąż resolver z zamierzonym interfejsem, zdefiniuj dozwolone zakresy klientów i ogranicz zaporę sieciową. Zweryfikuj konfigurację przed ponownym uruchomieniem. Odpytaj go z autoryzowanego klienta, a następnie powtórz spoza zaufanej sieci: takie żądanie powinno zostać odrzucone lub przekroczyć limit czasu. Sprawdź oddzielnie IPv6. Resolver, który przyjmuje dowolne zapytania z internetu, może stać się źródłem nadużyć.

• Uruchom walidator konfiguracji przed zastosowaniem zmian
• Przetestuj dozwolonego i odrzuconego klienta
• Utrzymuj szczegółową diagnostykę zapytań tymczasowo

unbound-checkconf

Oficjalna dokumentacja: Nieograniczona konfiguracja kontroli dostępu

Zachowaj precyzję zaszyfrowanych roszczeń DNS

DNS-over-HTTPS lub DNS-over-TLS szyfruje konkretną ścieżkę transportu. Resolver nadal otrzymuje zapytanie, a resolver przekazujący może je przekazać innemu operatorowi. Przejrzyj wybór nadrzędnego resolvera i przechowywanie danych. Jeśli udostępniasz zaszyfrowany punkt końcowy resolvera, uczyń jego politykę dostępu równie świadomą jak zwykły port DNS.

Wybierz łańcuch resolvera przed otwarciem portu

Przydatny prywatny projekt to klient VPN odpytujący AdGuard Home, przy czym AdGuard przekazuje zapytania do Unbound na interfejsie loopback. Unbound wykonuje wtedy rekurencję; AdGuard dodaje filtrowanie i interfejs zarządzania. Alternatywnie użyj samego Unbound dla mniejszego stosu. Nadaj każdemu nasłuchowi odrębny adres/port i wyznacz kierunek przekazywania: wysłanie Unbound z powrotem do AdGuard tworzy pętlę. Zdecyduj, którzy prywatni klienci mogą korzystać z usługi, zanim cokolwiek opublikujesz.

• Utrzymuj publiczne przychodzące TCP i UDP 53 zamknięte, chyba że istnieje konkretna polityka autoryzowanych klientów.
• Nadaj interfejsowi filtrowania i nasłuchiwaczowi DNS osobne reguły dostępu.
• Sprawdź własność portu przed instalacją; istniejący resolver systemowy może już zajmować docelowy adres.

Oficjalna dokumentacja: Konfiguracja AdGuard Home

Punkt wyjścia dla lokalnego Unbound

W systemie z już zainstalowanym Unbound poniższy fragment ilustruje backend osiągalny tylko na hoście. Zintegruj go z konfiguracją dystrybucji, zamiast nadpisywać ustawienia pakietu lub zarządzanie trust anchor. Wysoki port pozwala innemu frontendowi DNS użyć portu 53. Zweryfikuj cały efektywny plik, a następnie przeładuj przez zainstalowany menedżer usług. Zdalny klient wymaga osobno kontrolowanego tunelu lub frontendu; ten fragment celowo nie tworzy publicznego resolvera.

server:
  interface: 127.0.0.1
  port: 5335
  access-control: 127.0.0.0/8 allow
  access-control: 0.0.0.0/0 refuse
  access-control: ::0/0 refuse

# Validate the complete installed configuration:
unbound-checkconf

Oficjalna dokumentacja: Dokumentacja konfiguracji Unbound

Przeprowadź listę kontrolną odbioru z dwóch sieci

Najpierw odpytaj backend lokalnie, potem normalną ścieżkę klienta. Sprawdź zwykłe rekordy A/AAAA, celowo nieistniejącą nazwę i walidację DNSSEC za pomocą udokumentowanej domeny testowej. Powtórz z maszyny spoza dozwolonej podsieci: nie może otrzymać rekursji. Sprawdź, czy przeglądarka używa własnego szyfrowanego resolvera i omija skonfigurowany DNS urządzenia. Utrzymuj tymczasowy niezależny resolver dostępny podczas zmiany, aby błąd DNS nie odciął Twojej trasy administracyjnej.

• Diagnostyka lokalna: dig @127.0.0.1 -p 5335 example.org A
• Sprawdź osiągalność zarówno przez UDP, jak i TCP oraz nasłuchy IPv6.
• Potwierdź wyjątki filtrowania i rejestruj tylko faktycznie potrzebne dane diagnostyczne.

Diagnozuj przekroczenia czasu, pętle i błędy walidacji

Limit czasu frontendu przy działającym lokalnym backendzie wskazuje na adres frontendu, zaporę lub cel przekierowania. Powtarzające się zapytania kierowane do siebie sugerują pętlę. Rozległe awarie DNSSEC mogą wiązać się z nieprawidłowym czasem systemowym lub utrzymaniem trust anchor; napraw przyczynę, zamiast pozostawiać walidację wyłączoną. Jeśli zawodzą tylko duże odpowiedzi, zbadaj fallback TCP i ścieżkę sieciową. Prowadź rejestrowanie zapytań tymczasowo i przetestuj restart oraz przywrócenie konfiguracji, zanim resolver stanie się zależnością dla każdego urządzenia.