Stąd do internetu – 1.1.1.1, 8.8.8.8 a może 9.9.9.9?

Na nasze sprawne poruszanie się po internecie ma wpływ wiele czynników. Oczywiście, że przydaje się do tego celu działająca myszka. Monitor o cywilizowanej rozdzielczości. Ważne są również takie aspekty jak prędkość naszego połączenia internetowego. Ale czasami nawet koneser zoptymalizowanych ustawień sieciowych wpada w pułapkę gorzkich spostrzeżeń. Dlaczego te strony się tak „ślimaczą” na moim super szybkim łączu 100Mb/s?

Otóż czas spojrzeć prawdzie w oczy. Te wszystkie gigabajty i gigaherce poupychane w naszym sprzęcie to nie wszystko. Szczęścia nie da też nawet łącze 1Gbit w połączeniu z promocyjną ceną, w ramach której otrzymujemy również pakiet damskich rajstop co miesiąc. A wszystko za sprawą tego, że na przestrzeni lat rozwoju zapomnieliśmy o podstawach. Czyli o tym, że każdy wpisywany przez nas adres internetowy musi zostać przetłumaczony na odpowiadający mu adres IP. Tak, to właśnie ustawienia serwer DNS są nieraz języczkiem u wagi nasze zadowolenia.

Jak jest

Ustawienia DNS? W czasach gdy wszystko się samo ustawia i konfiguruje? Otóż tak. Utyskując na miernego operatora internetu często utyskujemy na jego DNSy, które chociaż może i są tuż pod ręką, to nie mogą stawać w konkury z „wielkimi” półświatka DNSowego. Jednak, pytaniem zasadniczym pozostaje – czy zmieniać te ustawienia DNS, czy nie.

Łatwo się o tym przekonać wykonując prosty test sprawności serwera DNS. Może to być ordynarna pętla w BASHu:

for i in {1..100}; do time dig 404.g-net.pl @$(grep -m1 ^nameserver /etc/resolv.conf|cut -d' ' -f 2); done 2>&1 | grep ^real | sed -e s/.*m0,/0./ | awk '{sum += $1} END {print sum / NR}'

Zwolennicy bezwolnego przeklejania komend do terminala zapewne zastanawiają się teraz co właśnie zrobili. Otóż odpytaliśmy 100 razy lokalną pamięć podręczną DNS (grep nameserver /etc/resolv.conf) o host 404.g-net.pl. Czas odpowiedzi zsumowaliśmy, podzieliśmy, wyszła jakąś uśredniona wartość. Za $(grep nameserver /etc/resolv.conf|cut -d’ ‘ -f 2) możemy podstawić dowolny adres IP dowolnego serwera DNS.

Skąd wiemy, że 127.0.0.53 (w większości przypadków) to pamięć podręczna? Pamiętacie ambicje systemd, aby być wszystkim w Linuksie? No właśnie.

#$ systemd-resolve --statistics

DNSSEC supported by current servers: no

Transactions
Current Transactions: 0
  Total Transactions: 7475

Cache
  Current Cache Size: 157
          Cache Hits: 1498
        Cache Misses: 1309

DNSSEC Verdicts
              Secure: 0
            Insecure: 0
               Bogus: 0
       Indeterminate: 0

O, czyli mamy jakąś pamięć podręczną. Wyśmienicie. Odpytywanie pamięci podręcznej o adresy DNS powinno być bardziej optymalne niż wysłanie za każdym razem zapytań gdzieś w świat. No chyba, że akurat jakiś IP nie został wcześniej zbuforowany lokalnie. Co robi wtedy systemd-resolve? Ano musi odpytać serwery zewnętrzne. A jakie?

#$ systemd-resolve --status

(...)

Link 3 (wlp5s0b1)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.1.1
          DNS Domain: 
(...)

Serwer DNS 192.168.1.1? Ki czort? Cóż, większość użytkowników routerów zwykle pozostawia ustawienia domyślne, gdzie wraz z adresem IP, router wręcza nam również ustawienia serwera DNS, który zwykle jest adresem… Routera, starającego się być pamięcią podręczną dla zapytań DNS wysyłanych przez niego do serwera DNS, który jest zdefiniowany przez naszego operatora internetu i zaoferowanego wraz z ustawieniami połączenia WAN. Uff… Bez obaw, to już prawie koniec tej pętli zależności.

Jak by mogło być

Co bystrzejsi użytkownicy zapytają się zapewne, po co nam pamięć podręczna na komputerze, która odpytuje pamięć podręczną na ruterze, która odpytuje nie wiadomo co (chyba, że mamy wgląd w ustawienia routera)?

I w tym momencie docieramy do sedna powyższych wywodów. A gdyby tak zaoszczędzić ilość serwerów pośredniczących w zapytaniach DNS wysyłanych z naszego komputera? A może warto wykluczyć niepewne lub niewiadome serwery DNS operatora, bo inne po prostu działają lepiej? Najlepsze rozwiązanie dla nas podpowie nam programik namebench.

sudo apt-get install namebench python-tk

Zapewne większość z nas zna ten tester. Wykonuje on masowe zapytania do określonych serwerów DNS i na podstawie uśrednionego czasu odpowiedzi podpowiada nam, co możemy poprawić. Na początek sprawdźmy, jak się ma nasza pamięć podręczna w starciu z popularnymi publicznymi serwerami DNS (o nich poniżej): 1.1.1.1 (Cloudfare), 8.8.8.8 (Google), 9.9.9.9 (Quad9). Wykonamy dwie serie testów. Pierwsza ze standardowymi ustawieniami naszego menedżera sieci, druga z wybraną opcją Ustawieniach IPV4 -> Metoda -> Automatycznie (DHCP), tylko adresy i dopisanymi w polu Serwery DNS serwerami wspomnianymi powyżej (wpisujemy bez przecinków, same adresy IP).

Po uruchomieniu programu widzimy okno o estetyce słusznej narzędziom służącym jakiemuś celowi (test można też przeprowadzić w terminalu). Uzupełniamy pole Nameservers o nasz lokalny cache i inne serwery DNS (w naszym przypadku 1.1.1.1 8.8.8.8 9.9.9.9). Uruchamiamy test i po chwili…

Nasza lokalna pamięć podręczna dla zapytań DNS zawiodła nas 10 razy (10 timeouts), uzyskała też mocno przeciętny średni czas odpowiedzi (~219ms). Okazało się, że szybsze są zapytania bezpośrednie do serwera 1.1.1.1 (~69 ms). Pamiętajmy, że to przykład w którym wspieramy też pamięcią podręczną routera.

No dobrze, wyedytujmy nasze połączenie sieciowe według powyższych zaleceń. Czyli od routera chcemy otrzymać tylko adres IP dla naszego komputera, serwery DNS wpiszemy sami.

#$ systemd-resolve --status
(...)
         DNS Servers: 1.1.1.1
                      8.8.8.8
                      9.9.9.9
(...)

I tym razem wyniki testu są następujące:

W końcu nasza komputerowa pamięć podręczna DNS do czegoś się przydaje. Odpowiedzi z niej są szybsze niż bezpośrednie zapytania do pozostałych serwerów. Nie ma są gubione zapytania. Innymi słowy, sukces.

Powyższą metodę można zastosować wszędzie tam, gdzie mamy wątpliwości co do jakości serwerów DNS lub routera jako pośrednika w zapytaniach DNS. Jakie serwery możemy rozważać jako zastępcze? Wszystkie serwer publiczne o potwierdzonej renomie. Pamiętajmy, że fałszywe lub podstawione serwery DNS to najprostsza droga do ataku na użytkownika internetu – atakujący będzie mógł niemal dowolnie manipulować odpowiedziami i tym dokąd skieruje się nasza przeglądarka. Wybierajmy zatem te serwery z rozwagą.