DNS (Domain Name System) to usługa odpowiedzialna za przypisywanie adresów IP nazwom internetowym (domenom), czytelnym dla człowieka. Każda strona WWW posiada swój „identyfikator”, czyli wspomniany adres IP. Adresy te można poznać poprzez wyszukanie strony np. w bazie GWhois lub za pomocą polecenia PING. Jest to o tyle dobrze przemyślane, że dzięki usługom DNS nie musimy pamiętać adresu IP każdej strony, z którą zamierzamy się połączyć.
Tak naprawdę trudno wyobrazić sobie świat bez tych serwerów. Adresami IP serwerów DNS zajmuje się IANA i ICANN. W Polsce ich odpowiednikiem jest Naukowa i Akademicka Sieć Komputerowa, czyli NASK. Sam DNS podczas przesyłania zapytań działa na podstawie protokołu UDP w warstwie aplikacji w modelu OSI, na domyślnym porcie 53. Zwykle mamy skonfigurowane dwa adresy IP różnych dostawców DNS-ów, co jest zabezpieczeniem w przypadku awarii któregoś z nich. Natomiast wykupienie domeny nie zawsze jest równoznaczne z natychmiastowym dodaniem do bazy DNS adresu internetowego. Zwykle trwa to kilka godzin. Po więcej informacji odsyłam na stronę dns.pl.
„Szkielet Internetu” stanowią tzw. root servers. Ich lista dostępna jest na stronie https://root-servers.org/.
Często bywa tak, że dostawca usług internetowych konfiguruje router, aby łączył się z ustalonymi DNS-ami i zazwyczaj są to serwery DNS operatora internetu. Nie jest to zawsze bezpieczne i nie jest to idealne rozwiązanie, co wyjaśniam w dalszej części artykułu.
Dlaczego warto zmienić domyślny adres DNS?
Domyślne adresy DNS, które są ustawione przez mojego dostawcę w routerze, zostały przeze mnie zmienione na te oferowane przez Quad9. Ta zmiana jest podyktowana chęcią skonfigurowania routera według moich potrzeb oraz zasadą „Security First”. Wątpię, że mój ISP oferuje najwyższe zabezpieczenia. Dzięki analizie logów dostawca będzie wiedział, jakie strony odwiedziłem. Zmiana DNS co prawda niewiele pomoże w tym przypadku, gdyż każdy ISP jest zobowiązany do monitorowania aktywności i przechowywania zapisów przez 5 lat. Jeśli chcemy ukryć tę aktywność, to zachęcam do zapoznania się z poprzednim artykułem, w którym opisałem zasadę działania sieci Tor i VPN.
Natomiast operator prawdopodobnie nie stosuje filtracji domen, z którymi użytkownicy łączą się poprzez jego infrastrukturę. Czyli, jeśli odwiedzimy porządnie wykonaną stronę phishingową (SSL budzący zaufanie, wygląd i adres), to zazwyczaj (ale nie zawsze) serwer DNS nie informuje o zagrożeniu.
Idąc dalej, zauważamy, że mój ISP ma siedzibę w Polsce. A więc wciąż nie zapominamy o pomyśle cenzury polskiego Internetu przez rząd. Z założenia „filtrowanie szkodliwych treści” byłoby realizowane przez DNS-y. Czyli wystarczyłaby zmiana adresu serwera DNS i moglibyśmy cieszyć się „niekontrolowanym” dostępem do blokowanych domen. Taka sama sytuacja jest z ministerialną listą zakazanych stron hazardowych. Jeśli rząd wpadnie w przyszłości na pomysł cenzurowania Internetu, to chcąc zwiększyć jej skuteczność, powinien posłuchać tego podcastu Niebezpiecznika.
Porównanie serwerów DNS
| Nazwa usługi serwerów DNS | Adresy IP | Kraj operatora (jurysdykcja) | Filtrowanie kategorii np. pornografia i reklamy | Ochrona przed malware i phishingiem | Wsparcie dla DNS over HTTPS (DoH) |
|---|---|---|---|---|---|
| Cloudflare | 1.1.1.1 oraz 1.1.1.2, 1.0.0.2 (ochrona przed malware), 1.1.1.3, 1.0.0.3 (ochrona przed malware i filtr treści) | USA | NIE | TAK | TAK |
| Google Public DNS | 8.8.8.8 i 8.8.4.4 | USA | NIE | NIE | TAK |
| Cisco OpenDNS | 208.67.222.222 i 208.67.220.220 | USA | TAK | TAK | TAK |
| Quad9 | 9.9.9.9 | USA | NIE | TAK | TAK |
| DNS.Watch | 84.200.69.80 i 84.200.70.40 | Niemcy | NIE | NIE | NIE |
| OpenNIC | 192.71.245.208, 195.10.195.195, 176.126.70.119 i 91.217.137.37 | USA | NIE | NIE | NIE |
| Comodo Secure DNS | 8.26.56.26 i 8.20.247.20 | USA | NIE | TAK | NIE |
| VeriSign Public DNS | 64.6.64.6 i 64.6.65.6 | USA | NIE | NIE | NIE |
| CleanBrowsing | 185.228.168.168 i 185.228.169.168 | USA | TAK | NIE | TAK |
| Alternate DNS | 23.253.163.53 i 198.101.242.72 | USA | TAK | NIE | NIE |
| AdGuard DNS | 176.103.130.130 i 176.103.130.131 | USA | TAK | TAK | TAK |
Komentarz do tabeli:
Praktycznie wszystkie serwery DNS znajdują się z jurysdykcją w USA. Jedynie dwóch dostawców zapewnia jednocześnie filtrowanie kategorii i ochronę przed złośliwymi (w ogólnym znaczeniu) stronami. Cieszy fakt, że sporo serwerów wspiera DNS over HTTPS (DoH), czyli szyfrowanie zapytań. Warto zauważyć, że serwery bez wsparcia tej technologii nie mają wiele do zaoferowania.
Konfiguracja adresów DNS
Zmianę adresów DNS dokonujemy na pojedynczym urządzeniu lub na wszystkich (w ustawieniach routera). Ma do duże znaczenie. W przypadku modyfikacji adresów np. na laptopie, sprawimy, że tylko to pojedyncze urządzenie będzie komunikowało się ze światem za pośrednictwem ustawionych serwerów. Pozostałe urządzenia w sieci będą rozwiązywały domeny na adresy IP za pośrednictwem serwerów DNS ustawionych w routerze. Należy pamiętać, że systemowe DNS mają „pierwszeństwo” przed tymi w konfiguracji routera.
W przypadku zmiany adresów DNS w konfiguracji routera sprawa wygląda paradoksalnie łatwiej. Należy jednak pamiętać, że pozostałych ustawień lepiej nie modyfikować, jeśli się nie wie do czego służą. W przeglądarce wchodzimy pod adres (najczęściej) 192.168.0.1 lub 192.168.1.1, czy też inny, w zależności od struktury sieci i producenta routera.
Zazwyczaj ustawienia DNS są połączone z ustawieniami DHCP (Dynamic Host Configuration Protocol), co odpowiada za automatyczne przydzielanie urządzeniom w sieci informacji o niej, m.in. adres IP, maska czy adres bramy domyślnej i DNS.
W jaki sposób poznać adres routera?
Metod jest kilka, a te zależą w głównej mierze od systemu:
- Windows: Uruchamiamy wiersz polecenia (z poziomu Menu Start, wyszukując “cmd”, lub skrótem Win+R i wpisując “cmd”. Następnie wpisujemy „ipconfig” i szukamy pozycji Default Gateway. Widoczny adres to adres routera. To zdecydowanie najszybszy sposób, bo w domowej sieci raczej DHCP przydziela konfigurację, a niewiele osób ustawia ją statycznie (co ma uzasadnienie w przypadku serwerów i drukarek w sieci). Jeśli posiadamy sprzęt od MikroTik, to polecam wykorzystać WinBox, który w zakładce Neighbours wyświetla urządzenia tej firmy w naszej sieci.
- Linux: W terminalu wystarczy wpisać “route” i pod Gateway widoczny jest szukany adres.
- Android: Adres routera jest widoczny w ustawieniach konkretnej sieci WiFi. Nie zalecam jednak zmieniać konfiguracji z poziomu mobilnych przeglądarek z powodu małego komfortu. Lepiej pobrać aplikację (Tether w przypadku TP-Link i MikroTik dla łotewskiego producenta) z oficjalnego sklepu i z niej korzystać, bo umożliwia szybki dostęp do najważniejszych ustawień (w tym blokadę danego urządzenia jednym kliknięciem).
Test szybkości serwerów DNS
Do przetestowania szybkości serwerów DNS użyłem skryptu, który pobierał z serwera WWW zainstalowanego na VPS plik tekstowy z listą 10 tysięcy domen. Następnie automatycznie, wykorzystując polecenie dig (narzędzie do administrowania siecią), odpytywał po kolei serwery z adresami z tej listy.
Wykonanie się skryptu zajmowało około kilku godzin za każdym razem w ciągu dnia, dlatego zastosowałem tzw. wirtualną konsolę (polecenie screen). W ten sposób mogłem bez obaw o przerwanie się skryptu zakończyć sesję SSH (w przeciwieństwie do RDP, czyli zdalnego pulpitu, przerwanie połączenia SSH skutkuje zatrzymaniem wykonywania polecenia). Okresowo kontrolowałem poprawność działania skryptu, wyświetlając aktualne procesy (polecenie w terminalu ps -A).
Tabelka zawiera wyniki (w milisekundach) średniego czasu odpowiedzi od 10 tysięcy domen zapisanych w pliku konfiguracyjnym. Im mniejsza wartość, tym odpowiedź serwera jest szybsza.
| Nazwa usługi serwerów DNS | Test o 5 rano | Test o 13 po południu | Test o 20 wieczorem | Test kolejnego dnia o 9 rano |
|---|---|---|---|---|
| Cloudflare | 106.56 | 90.43 | 91.92 | 88.11 |
| Google Public DNS | 66.05 | 70.49 | 66.50 | 66.99 |
| Cisco OpenDNS | 91.37 | 87.68 | 87.98 | 88.41 |
| Quad9 | 89.28 | 90.97 | 87.19 | 105.78 |
| DNS.Watch | 104.09 | 116.65 | 109.28 | 111.42 |
| OpenNIC | 93.45 | 95.59 | 93.17 | 98.46 |
| Comodo Secure DNS | 84.75 | 83.90 | 76.47 | 84.71 |
| VeriSign Public DNS | 89.08 | 91.93 | 82.12 | 91.23 |
| CleanBrowsing | 92.29 | 105.35 | 85.49 | 99.38 |
| Alternate DNS | 189.41 | 186.54 | 185.70 | 185.91 |
| AdGuard DNS | 118.33 | 115.16 | 105.64 | 109.47 |
Komentarz do tabeli:
Rzecz jasna im mniejszy czas odpowiedzi, tym lepiej. Od razu można zauważyć zdecydowaną przewagę DNS Google pod względem wydajności. W tym przypadku podobne wyniki utrzymywały się praktycznie przez cały dzień, z wyjątkiem pory popołudniowej. Niektóre serwery również potrafią szybko obsłużyć ruch (OpenDNS, Quad9, OpenNIC, Comodo), chociaż uzyskane czasy znacznie się różną z wynikami lidera testu.
Test ochrony przed phishingiem (100 adresów dziennie)
Poniższe dwa testy nie były aż tak zautomatyzowane. Zdecydowałem się na wykorzystanie polecenia wget, które pobierało z pliku tekstowego dokładnie 100 „świeżych” i unikalnych adresów każdego dnia.
Adresy zebrałem z zagranicznych list. Za każdym razem zmieniałem serwer DNS w /etc/resolv.conf, po czym uruchamiałem polecenie wget i czekałem na pobranie plików (w przypadku malware) lub zwykłych plików HTML (w przypadku phishingu). Od liczby 100 odejmowałem ilość pobranych plików i w ten sposób uzyskiwałem ilość zablokowanych zapytań.
| Zablokowane adresy (NXDOMAIN [*]) | Cloudflare | Cisco OpenDNS | Quad9 | Comodo Secure DNS | AdGuard DNS |
|---|---|---|---|---|---|
| Dzień 1 | 53 | 98 | 99 | 35 | 46 |
| Dzień 2 | 54 | 96 | 97 | 36 | 40 |
| Dzień 3 | 36 | 93 | 97 | 24 | 43 |
Przed każdym testem system był restartowany, aby wyczyścić cache DNS.
[*] Tak zwany błąd NXDOMAIN oznacza, że w bazie DNS konkretnego operatora domena nie jest powiązana z adresem IP, czyli użytkownik końcowy nie widzi odwiedzi od danej strony.
Test ochrony przed malware (100 adresów dziennie)
| Zablokowane adresy (NXDOMAIN [*]) | Cloudflare | Cisco OpenDNS | Quad9 | Comodo Secure DNS | AdGuard DNS |
|---|---|---|---|---|---|
| Dzień 1 | 48 | 47 | 88 | 47 | 50 |
| Dzień 2 | 43 | 42 | 50 | 41 | 39 |
| Dzień 3 | 24 | 23 | 29 | 23 | 25 |
Przed każdym testem system był restartowany, aby wyczyścić cache DNS.
[*] Tak zwany błąd NXDOMAIN oznacza, że w bazie DNS konkretnego operatora domena nie jest powiązana z adresem IP, czyli użytkownik końcowy nie widzi odwiedzi od danej strony.
Wnioski z testu serwerów DNS
Przeprowadzone testy były bardzo interesujące od strony technicznej. Pozwoliły na pogłębienie wiedzy oraz zobaczenie „na żywo” różnych metod blokowania zawartości. Opisując to na dwóch przykładach:
- OpenDNS od Cisco podstawia własny certyfikat, który z oczywistych przyczyn nie jest zaufany w systemie operacyjnym (w przeglądarce też, pomimo niezależności od systemu). Dzięki temu użytkownik końcowy (zwłaszcza nietechniczny) po prostu nie odwiedzi danej strony, czyli nie pobierze malware lub nie spotka się z phishingiem. W konsekwencji zostanie ochroniony.
- Quad9 (dawniej należący do F-Secure) zakłada nieco prostsze działanie. Po prostu złośliwa domena nie znajduje się w bazie operatora. W ten sposób serwer zwraca błąd NXDOMAIN,, który oznacza, że wyszukanie DNS zakończyło się niepowodzeniem, ponieważ wskazana domena nie istnieje.
Należy pamiętać, że nawet najskuteczniejszy serwer DNS nie będzie alternatywą dla programu antywirusowego. Jego przewaga polega na tym, że wystarczy ustawić raz adres w routerze i cała lokalna sieć będzie chroniona.
Serwer DNS to ważny aspekt naszego bezpieczeństwa!
Wszystkie urządzenia wysyłają i odbierają jakieś dane. Użytkownik odwiedza daną stronę w przeglądarce, zainstalowana aplikacja odpytuje swoje serwery o aktualizacje itp. Serwer DNS może ochronić przed różnymi złośliwymi działaniami. Należy jednak pamiętać, że malware nie znajduje się jedynie w Internecie, bo równie dobrze możemy zainfekować system, uruchamiając złośliwe makra, nieznany program. Zagrożeniem jest też podłączenie nieznanego pendrive.
DNS nie chroni przed popularnymi atakami występującymi w sieci (MITM, podsłuchanie komunikacji, ARP spoofing). Nie możemy też liczyć na ochronę kamery internetowej czy pliku hosts. Swoją drogą mało osób o tym wspomina, ale ten prosty plik ma ogromny wpływ na bezpieczeństwo. Podmiana pliku HOSTS przez malware może mieć tragiczne konsekwencje:
[adres_IP_atakujacego] mbank.pl
Od teraz zamiast na stronie mBanku, będziemy na stronie atakującego! Jeśli jest dobrze przygotowana, to raczej nie mamy szans na zauważenie ataku. W pasku adresu widoczny jest mbank.pl, a w praktyce jesteśmy połączeni z serwerem przestępcy!
Serwery DNS to bardzo ważny element naszego bezpieczeństwa. O tym niech poświadczy fakt szkodliwego oprogramowania DNSChanger, które podmieniało adresy DNS. Pisał o tym także CERT Polska. Na tej stronie internetowej znajdują się aktualne listy serwerów DNS w Polsce.
