Test serwerów DNS – edycja 2025

DNS (Domain Name System) jest jedną z podstawowych usług sieciowych, która odpowiada za rozwiązywanie nazw domenowych na adresy IP powiązane z daną domeną. Dzięki DNS system operacyjny uzyskuje informację, jaki adres obsługuje wybraną domenę i gdzie powinna być kierowana komunikacja. Oczywiście sam proces jest znacznie bardziej skomplikowany, szczególnie w sieci Internet. Praktyczne zastosowanie DNS najlepiej więc poznawać w przypadku sieci lokalnej, gdzie także z powodzeniem można uruchomić własny serwer DNS, aby przykładowo wszystkie urządzenia mogły uzyskiwać z użyciem domen dostęp do usług uruchomionych na serwerze NAS itp.

Usługa DNS działa na porcie 53 UDP. „Baza” DNS składa się z kilku typów rekordów, z czego te najczęściej używane to:

• A – adres IPv4
• AAAA – adres IPv6
• CNAME – nazwa kanoniczna (w rekordzie tym podawana jest domena, na którą powinna kierować inna domena – przykładowo przy zmianie adresu IP serwera obsługującego wiele domen nie trzeba wtedy modyfikować każdego rekordu A)
• MX – nazwa hosta (nie adres IP) obsługującego pocztę e-mail
• TXT – dowolny ciąg znaków tekstowych, używany m.in. dla konfiguracji SPF, DKIM czy DMARC, jak również do weryfikacji własności domeny w różnych usługach (takich jak Search Console)
• NS – nazwa serwera DNS, który „zarządza” wybraną domeną
  
  

Zapytania do DNS, co do zasady, nie są szyfrowane i z tego powodu dość istotne jest wsparcie dla DNS over HTTPS, zapewniane przed niektórych dostawców (wskazanych w sekcji Testowane serwery DNS).

Zarówno domeny, jak i sam DNS, są kluczowymi elementami działania sieci komputerowych, a przede wszystkim Internetu. Bez dostępu do DNS, w celu nawiązania połączenia z dowolną domeną, w pierwszej kolejności należałoby w pliku hosts podać adekwatny adres IP. Warto tutaj wspomnieć, iż zupełnie standardowym podejściem jest fakt, iż jeden serwer z reguły obsługuje wiele domen – może to być load balancer (gdzie z zewnątrz możliwy jest wyłącznie ruch HTTP/HTTPS), który przekierowuje wszelkie zapytania do innych serwerów w sieci wewnętrznej.

Z kolei plik hosts może być użyty w celu przetestowania działania aplikacji, która została wdrożona, ale z różnych powodów nie zamierzamy jej jeszcze udostępniać publicznie. To także jest powszechnie używaną praktyką. Można z tego wyciągnąć wniosek, iż plik hosts jest sprawdzany jako pierwszy, a dopiero potem system odpytuje serwer DNS ustawiony w systemie, a jeżeli takowy nie jest podany (nie jest statyczny) – bo konfiguracja sieci jest dostarczana z serwera DHCP – to odpytywany jest serwer podany na poziomie serwera DHCP (zwykle routera).

Zmiana serwera DNS w systemie bądź edycja pliku hosts wymaga uprawnień administratora. Ustawienie adresu DNS w systemie obejmuje wyłącznie to konkretne urządzenie. Korzystają z tego na przykład klienty różnych rozwiązań VPN – po zestawieniu tunelu system otrzymuje adresy serwerów DNS kontrolowanych przez dostawcę VPN. Z kolei zmiana w konfiguracji routera obejmuje wszystkie podłączone urządzenia – chyba iż zostały ustawione statyczne adresy dla DNS. Powinny zostać ustawione dwa różne adresy (od różnych dostawców), aby w razie niedostępności pierwszego z serwerów wykorzystywane były odpowiedzi z zapasowego.

Ustawienie sprawdzonego operatora DNS pomoże w pewnym stopniu zwiększyć bezpieczeństwo naszej sieci, zadbać o kontrolę treści czy choćby częściowo wpłynąć na „szybkość” korzystania z zasobów internetowych. Jednak pod kątem bezpieczeństwa poleganie wyłącznie na DNS jest błędne, ponieważ ewentualna ochrona dotyczy wyłącznie domen – nietrudno wyobrazić sobie, iż ktoś pobiera i uruchamia złośliwy załącznik z wiadomości widocznej w przeglądarkowym kliencie poczty elektronicznej. Ochrona na poziomie DNS nie może więc zostać uznana za alternatywę, a raczej powinna być traktowana jako dodatkowy element zwiększający bezpieczeństwo.

Zmiana adresu serwera DNS

Procedura ustawienia adresów DNS dla routerów zależy od konkretnego producenta i nie można przedstawić jednej instrukcji. W większości typowych routerów domowych najlepiej szukać odpowiednich opcji w ustawieniach DHCP. W tych bardziej zaawansowanych z reguły powinny być dedykowane ustawienia DNS (chyba iż w konfiguracji DHCP nie jest podany adres routera jako adres serwera DNS).

Dla systemów Windows cała procedura wymaga wejścia w Panel sterowania -> Sieć i Internet -> Centrum sieci i udostępniania -> Zmień ustawienia karty sieciowej. Następnie wybieramy lokalną kartę sieciową (można ją rozpoznać po faktycznej nazwie fizycznego urządzenia) i dalej adekwatności. W Protokół internetowy w wersji 4 (TCP/IPv4) znajdziemy adekwatne ustawienia.

W przypadku systemów z rodziny Linux metoda jest zależna od dystrybucji i wykorzystywanego środowiska graficznego. Dla Debiana ustawienia znajdują się w pliku /etc/network/interfaces, dla aktualnych wersji Ubuntu wymagana jest zmiana konfiguracji Netplan (pliki YAML w /etc/netplan), a dla systemów RHEL można skorzystać z polecenia nmtui lub edytować adekwatny plik z katalogu /etc/NetworkManager (jeśli katalog jest pusty, to pozostaje użyć narzędzia nmtui).

Z kolei dla Androida nie wydaje się, aby istniała inna możliwość niż ustawienie statycznej adresacji IP dla wykorzystywanych sieci Wi-Fi.

Metodologia testu ochrony przed malware i phishingiem

W tym roku przygotowana została specjalna aplikacja, która automatyzuje niemal cały proces testów DNS. Generuje listy domen zawierające malware i te stanowiące próby phishingu na podstawie publicznie dostępnych zbiorów. Dla obu testów przyjęliśmy 100 domen każdego dnia, co w sumie dało 300 unikalnych domen. Wykluczamy ewentualne false positive – pliki będące rzekomym złośliwym oprogramowaniem były w pierwszej kolejności skanowane przez dwa silniki antywirusowe, a ponadto zastosowaliśmy wykluczanie domen popularnych usług chmurowych czy repozytoriów Git (mogą zawierać malware, ale prawdopodobnie żaden dostawca DNS nie zablokuje ruchu np. do dropbox.com). Domeny były także sprawdzane pod kątem dostępności (przez serwer DNS niezapewniający żadnej ochrony), aby wykluczyć możliwość, iż w listach testowych znalazłyby się np. wygasłe adresy. Dodatkowo po każdym wygenerowaniu wykonywaliśmy weryfikację poprawności i rzetelności list przygotowanych przez skrypt.

Same testy DNS polegały na ustawieniu w systemie odpowiedniego adresu (jeśli dany dostawca zapewnia różne funkcjonalności, to sprawdzany był wyłącznie serwer DNS oferujący ochronę przed malware – było tak w przypadku Cloudflare, dns0.eu i Mullvad) oraz wykonaniu restartu maszyny, aby uniknąć możliwego wpływu cache. Mullvad wymagał nieco innego podejścia, ponieważ wszystkie serwery DNS dostarczane przez tego operatora są skonfigurowane do działania z dodatkowymi zabezpieczeniami – DNS over HTTPS i DNS over TLS – jest to szyfrowanie zapytań DNS (standardowo komunikacja z tą usługą nie jest szyfrowana). Zastosowane zostało lokalne proxy DNS do podanego niżej adresu serwera. Był to najprostszy sposób konfiguracji systemu AlmaLinux do korzystania z DNS over HTTPS.

Aplikacja po uruchomieniu danego testu próbowała nawiązać połączenie z każdą z domen zawartych na liście. Zapytania i ich wyniki były logowane. Dalej w pliku CSV zapisywana była pełna statystyka: domena, czas połączenia, rezultat (CONNECTED bądź BLOCKED) oraz ostateczny wynik procentowy zablokowanych połączeń – widoczny w tabelach poniżej.

A. Generowanie domen malware – krok po kroku

1. Upewnij się, iż w systemie operacyjnym ustawiony jest serwer DNS niezapewniający żadnego filtrowania domen.
2. Pobierz zawartość zdalnego pliku zawierającego rzekome adresy złośliwego oprogramowania.
3. Usuń wystąpienia popularnych domen (np. usług chmurowych czy repozytoriów Git).
4. Usuń duplikaty domen.
5. Zapisz przygotowaną zawartość do pliku przeznaczonego do generowania ostatecznych adresów z malware.
6. Pobierz zawartość pliku z adresami malware.
7. Wykonaj próbę pobrania każdego z adresów:
   1. próba się nie powiodła – adres jest odrzucany
   2. próba się powiodła – uruchom lokalne skanowanie antywirusowe
   3. plik zawiera malware – adres pozostaje
   4. plik nie zawiera malware – adres jest odrzucany
8. Z listy adresów po weryfikacji wyodrębnij domeny.
9. Sprawdź, czy domena występowała w listach testowych z poprzednich dni:
   1. domena już się pojawiła – zostaje odrzucona
   2. domena jest unikalna – pozostaje
10. Wykonaj usuwanie duplikatów z listy ostatecznych domen testowych.
11. Zapisz 100 domen do ostatecznego pliku przeznaczonego do testu.

B. Generowanie domen phishing – krok po kroku

1. Upewnij się, iż w systemie operacyjnym ustawiony jest serwer DNS niezapewniający żadnego filtrowania domen.
2. Pobierz zawartość zdalnego pliku zawierającego rzekome adresy phishingowe.
3. Wyodrębnij adresy dodane dziś i wczoraj (prosta optymalizacja czasu potrzebnego na weryfikację dostępności).
4. Zapisz przygotowaną zawartość do pliku przeznaczonego do generowania ostatecznych adresów phishingowych.
5. Pobierz zawartość pliku z adresami phisingowymi.
6. Wyodrębnij domeny z adresów.
7. Dla każdej domeny sprawdź jej dostępność:
   1. domena nie odpowiada – zostaje odrzucona
   2. domena odpowiada – pozostaje do weryfikacji unikalności
8. Sprawdź, czy domena występowała w listach testowych z poprzednich dni:
   1. domena już się pojawiła – zostaje odrzucona
   2. domena jest unikalna – pozostaje
9. Wykonaj usuwanie duplikatów z listy ostatecznych domen testowych.
10. Zapisz 100 domen do ostatecznego pliku przeznaczonego do testu.

C. Test ochrony przed malware – krok po kroku

1. Ustaw w systemie operacyjnym dany serwer DNS i wykonaj restart.
2. Wykonaj próbę nawiązania połączenia z każdą z domen zapisanych w liście testowej:
   1. połączenie pomyślne – pobierz wynik skanowania antywirusowego i czas połączenia
   2. połączenie zablokowane – odnotuj fakt i czas połączenia
3. Zapisz wyniki w pliku CSV (dostawca_malware_data.csv) – domena, czas połączenia, (ewentualny) wynik skanowania i podsumowanie na końcu listy.

D. Test ochrony przed phishingiem – krok po kroku

1. Ustaw w systemie operacyjnym dany serwer DNS i wykonaj restart.
2. Wykonaj próbę nawiązania połączenia z każdą z domen zapisanych w liście testowej:
   1. połączenie pomyślne – odnotuj fakt i czas połączenia
   2. połączenie zablokowane – odnotuj fakt i czas połączenia
3. Zapisz wyniki w pliku CSV (dostawca_phishing_data.csv) – domena, czas połączenia i podsumowanie na końcu listy.

Metodologia testu szybkości czasu odpowiedzi

W tym teście wykorzystano znane od lat narzędzie dnsperf. Przez trzy dni sprawdzano średnie czasy odpowiedzi dla najbardziej popularnych domen. Scenariusz generowania list z tymi domenami był analogiczny do testów ochrony przed malware i phishingiem – aplikacja weryfikowała dostępność domen, po czym 100 unikalnych domen zapisywano w plikach stanowiących listy testowe. Ten test został zautomatyzowany tylko częściowo, bo dnsperf był uruchamiany manualnie dla wszystkich z serwerów (tych samych, co w przypadku pozostałych testów). Nie stanowiło to żadnego problemu, ponieważ wspomniane narzędzie nie wymaga, aby testowany serwer DNS był ustawiony w systemie – jest podawany jako parametr -s.

A. Generowanie domen do testu szybkości czasu odpowiedzi – krok po kroku

1. Upewnij się, iż w systemie operacyjnym ustawiony jest serwer DNS niezapewniający żadnego filtrowania domen.
2. Pobierz zawartość lokalnego pliku z 1000 najpopularniejszymi domenami (codzienne aktualizowanie tej listy nie było zasadne).
3. Dla każdej domeny sprawdź jej dostępność:
   1. domena nie odpowiada – zostaje odrzucona
   2. domena odpowiada – pozostaje do weryfikacji unikalności
4. Sprawdź, czy domena występowała w listach testowych z poprzednich dni:
   1. domena już się pojawiła – zostaje odrzucona
   2. domena jest unikalna – pozostaje
5. Wykonaj usuwanie duplikatów z listy ostatecznych domen testowych.
6. Zapisz 100 domen do ostatecznego pliku przeznaczonego do testu.

B. Test szybkości czasu odpowiedzi – krok po kroku

1. Uruchom dnsperf dla wszystkich testowanego serwera DNS i ze wskazaniem listy domen z danego dnia.
2. Zapisz wynik podany w Average Latency (s) – pomnożony 1000 razy, ponieważ wartość w milisekundach jest czytelniejsza.

Testowane serwery DNS

Pogrubieniem wyróżniono adres serwera DNS używany w trakcie testów.

Test ochrony przed malware (zablokowane domeny / 100 adresów dziennie)

W tym teście można zdecydowanie wyróżnić cztery rozwiązania: CleanBrowsing, Alternate, dns0.eu i Mullvad. Wszystkie z nich po raz pierwszy były sprawdzane w naszym teście serwerów DNS.

Zastanawiający jest rezultat uzyskany przez Cloudflare, bo wydawał się wiarygodnym rozwiązaniem w kwestii bezpieczeństwa, ale jak widać, poziom oferowanej ochrony jest nieporównywalnie niższy do wskazanych innych operatorów DNS.

Podobnie Control D, również po raz pierwszy w naszym teście, to najgorszy wynik w teście ochrony przed malware (i to z ustawionym adresem serwera, który rzekomo zapewnia tę funkcjonalność). Wynik jest zaskakujący.

Ciekawa będzie też informacja o OpenDNS. Okazało się, iż niezależnie od tego, czy nasza sieć została „zarejestrowana” w panelu, czy też zwyczajnie ustawiliśmy adres DNS w systemie operacyjnym, poziom ochrony pozostaje bez zmian.

Trzeba przyznać, iż również Quad9 osiągnął dobry stopień blokowania zagrożeń, natomiast mimo wszystko niższy niż wyróżnione serwery DNS.

Test ochrony przed phishingiem (zablokowane domeny / 100 adresów dziennie)

Widać podobieństwa skuteczności do testu ochrony przed malware, chociaż w tym przypadku najlepsze okazały się trzy rozwiązania: CleanBrowsing, Alternate i dns0.eu. Mullvad wykazał nieco mniejszą skuteczność, ale nie jest to absolutnie zły wynik – porównywalny do Quad9. Ponownie słaby wynik osiąga Cloudflare i AdGuard.

Test szybkości czasu odpowiedzi (ms)

Test różniący się metodologią, ale też serwerami DNS, które należy wyróżnić. W tym przypadku jest to Cloudflare, które w każdym dniu uzyskiwało najkrótszy czas odpowiedzi. Wynik raczej nie jest zaskoczeniem biorąc pod uwagę złożoność sieci Cloudflare, wykorzystywanej zresztą nie tylko w usłudze publicznego resolvera DNS. Najdłuższymi czasy odpowiedzi charakteryzuje się Alternate, które w drugim dniu testu z jakiegoś powodu nie odpowiadało na żadne żądania (podczas wykonanych wcześniej testów ochrony przed malware i phishingiem nie stwierdzono anomalii). Stosunkowo szybkie są odpowiedzi CleanBrowsing i dns0.eu, które okazały się najlepsze w poprzednich testach.

Podsumowanie

Biorąc pod uwagę wyniki uzyskane we wszystkich testach, w tym roku na szczególną uwagę zasługują rozwiązania CleanBrowsing i dns0.eu. Z pewnością warto rozważyć wykorzystanie, ponieważ niezbyt skomplikowaną zmianą możemy podnieść bezpieczeństwo podczas korzystania z zasobów internetowych. Jak już zostało wspomniane, DNS nie może być traktowany jako kompleksowe podejście do szeroko rozumianego bezpieczeństwa. Istotne jest podnoszenie własnej wiedzy w tej dziedzinie (chociażby w podstawowym stopniu), dbanie o aktualność oprogramowania, wykonywanie kopii zapasowych (w sposób odpowiadający naszym potrzebom, nie istnieją uniwersalne praktyczne porady) i korzystanie z systemu antywirusowego.

Zaznaczę także, iż to pierwszy test skuteczności dns0.eu, ponieważ jest jednym z najnowszych serwerów DNS. Szerszej pisałem o nim w moim artykule z początku 2023 roku. Dobrą wiadomością jest fakt, iż europejska inicjatywa – nie powiązana zresztą z administracją Unii Europejskiej – może dostarczyć rozwiązanie zapewniające wysoką jakość.

Same testy serwerów DNS prowadzone przez AVLab.pl są unikalne, nie tylko na polskim rynku. Tegoroczna edycja była wyjątkowo ciekawa, bo przyniosła wiele zaskoczeń w kwestii oferowanej przez niektórych operatorów skuteczności ochrony.

W tym roku po raz pierwszy wykorzystaliśmy naszą autorską aplikację, która automatyzuje najbardziej pracochłonne elementy testów, a przy tym przeprowadza weryfikacje adresów z malware czy dostępności domen phishingowych lub tych wykorzystywanych w testach czasów odpowiedzi. Dzięki temu nasze testy w możliwie największym stopniu odzwierciedlają praktyczne zagrożenia w sieci.