Tag: dns

Opublikowane w

Jaki serwer DNS wybrać?

Wybór serwera DNS z którego korzystamy na urządzeniu końcowym jest ważny z kilku powodów:

  • Szybkość serwera DNS. Czas oczekiwania na odpowiedzi z serwerów DNS może być istotną częścią czasu ładowania stron Jest to szczególnie widoczne na stronach z dużą ilością wklejek z różnych domen. W przypadku szybkości serwera DNS nie chodzi jedynie o opóźnienie sieci (to można sprawdzić przy pomocy ping), ale o czas udzielenia odpowiedzi. Zależy on już od większej liczby czynników: opóźnienie sieci, posiadanie bądź nie odpowiedniego spisu w cache (oczywiście lepiej, jeśli odpowiada z cache), wydajność sprzętu i oprogramowania na którym działa DNS.
  • Poprawność odpowiedzi. Nic po szybkiej odpowiedzi z serwera DNS, jeśli będzie ona błędna. W skrajnym przypadku możemy paść ofiarą spoofingu DNS i trafić na podstawioną stronę.
  • Neutralność, czyli brak cenzury. Trochę wiąże się z poprzednim zagadnieniem, ale w tym przypadku chodzi o to, że do pewnych stron w ogóle nie będzie można się dostać. O ile działanie takie ma sens przy ograniczaniu zasięgu szkodliwego oprogramowania, to może być także służyć jako ograniczenie dostępu do treści.

 

Co warto zrobić w kwestii DNS?

Jeśli posiadamy sieć lokalną z kilkoma (i więcej) komputerami, to prawie na pewno warto postawić lokalny cache DNS – dzięki temu powtarzające się nazwy będą rozwiązywane lokalnie. Dobrym i prostym rozwiązaniem dla małej sieci jest dnsmasq, dostępny także dla OpenWrt.

Poza tym, warto wybrać te serwery DNS, które odpowiadają najszybciej. Zwykle nie popełnimy dużego błędu, jeśli wybierzemy serwery zalecane przez naszego dostawcę sieci lub wskazane automatycznie.

Czy zawsze lokalny serwer DNS lub oferowany przez naszego dostawcę Internetu jest najlepszy? Niestety nie. Prawie zawsze będzie on najszybszy pod względem opóźnienia sieci, ale już zawartość cache bywa różna. Szczególnie w przypadku lokalnego serwera może się okazać, że jego cache jest pusty dla większości zapytań. Na szczęście zwykle narzut lokalnego serwera nie jest duży.

Jeśli nasz komputer łączy się z internetem za pośrednictwem wielu sieci (wifi, połączenia GSM), można pomyśleć o postawieniu lokalnego cache DNS bezpośrednio na nim.

Jak najprościej znaleźć najlepsze serwery DNS?

Istnieje do tego darmowy i wolny program o nazwie namebench, służący do benchmarku serwerów DNS. Działa na wszystkich systemach, wersję dla Windows i Mac OS X można pobrać ze strony, w przypadku Linuksa zapewne jest w dystrybucyjnym repozytorium. Domyślnie działa z GUI, ale nie jest ono niezbędne – program daje się również uruchomić w konsoli. Ważne jest, żeby nie uruchamiać testu od razu, tylko najpierw przeczytać jak program działa i zastanowić się, co chcemy zrobić. Dlaczego? Ano dlatego, że pierwsze uruchomienie jest najbardziej zbliżone do rzeczywistych warunków ze względu na oryginalną, niezakłóconą poprzednimi testami zawartość cache testowanych serwerów DNS, czyli najbardziej miarodajne.

Jak korzystać z namebench?

W polu nameservers warto podać, oddzielone spacjami przynajmniej: DNS lokalny w sieci (jeśli posiadamy), serwery DNS naszego ISP. W przypadku Polski dodatkowo warto podać serwery DNS Orange (najpopularniejsze to 194.204.159.1 i 194.204.152.34) – kiedyś były dostępne tylko dla klientów TPSA, ale obecnie wyglądają na otwarte – działają z każdej sieci, z której testowałem – i osiągają dobre wyniki. W moim przypadku były szybsze, niż serwery DNS mojego ISP.

Namebench - ekran startowy
Ekran startowy namebench. Źródło: strona domowa programu namebench.

Poza tym, zaznaczamy globalne publicznie dostępne serwery cache’ujące oraz serwery regionalne. Można zaznaczyć sprawdzanie pod kątem cenzury i podzielenie się uzyskanymi wynikami. Lokalizacja to oczywiście Polska, query data source – możemy skorzystać z historii stron którejś z naszych przeglądarek, wyniki będą wówczas bardziej zbliżone do realnych.

Następnie uruchamiamy test i na kilka-kilkanaście minut zostawiamy komputer w spokoju. Po tym czasie otrzymamy wyniki: propozycję trzech najlepszych dla nas – zdaniem programu – serwerów DNS (kolejność ma znaczenie) oraz szczegółowe dane i wykresy. Kluczowy dla szybkości działania sieci jest oczywiście średni czas odpowiedzi z serwera DNS.

Na koniec uwaga: jeśli najszybsze serwery nie należą do naszego ISP ani nie są otwartymi, publicznymi serwerami, może się zdarzyć, że ich właściciel ograniczy za jakiś czas do nich dostęp.

 

Opublikowane w

Benchmark DNS cache – problemy.

Jakiś czas temu zainteresowałem się, głównie za sprawą prezentacji Infoblox na 9 PLNOG nt. DNS, tematem DNS cache i jego wydajności. Nie jest to zupełnie nowa sprawa, bo kiedyś otarłem się o problem wydajności DNS cache (albo raczej sprzętu, na którym działało to jako jedna z wielu usług…). Skończyło się tak, że mały i lekki dnsmasq jest za mały dla większej osiedlówki, choć nadal fajny w rozwiązaniach domowych.

Pierwsze skojarzenie z DNS to oczywiście bind, którego „wszyscy znają, wszyscy używają i nadaje się do wszystkiego”. Autorzy unbound przekonują, że to niekoniecznie dobre podejście, więc – zachęcony tym, co znalazłem w sieci – postanowiłem przetestować wydajność bind vs. unbound.

Nie ma lekko. W Debianie nie znajdziemy gotowego pakietu z narzędziem do testowania wydajności serwera DNS. W ogóle nie ma (nie znalazłem) wydajnego narzędzia do tego. Jest queryperf, dostępny w źródłach bind (do samodzielnej kompilacji), ale do wydajności mu daleko – często obciąża maszynę porównywalnie, jeśli nie bardziej, niż sam testowany program. W prezentacji (http://www.infoblox.nl/content/dam/infoblox/documents/solution-notes/infoblox-note-ib-2000-performance-test.pdf – dead link) znalazłem skrypt:

#!/b in/sh
SECS=5
INPUT=qp.forward.master.cached
SERVER=10.34.31.2
# SECS is number of seconds to run test
# INPUT is input file
# SERVER is server IP
queryperf -s $SERVER -d $INPUT -l $SECS > out1 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out2 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out3 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out4 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out5 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out6 2>&1 &
wait
grep ‘Queries per’ out? | awk ‘BEGIN { sum=0;}{ sum += $5;}
END {printf(“Total: %.1f qps\n”, sum);}’


Szybkie zapytanie na kanale IRC i… jedna osoba zgłasza, że przesiadła się na unbound i jest zadowolona; sugestii co do oprogramowania testującego brak, za to pojawia się koncert życzeń: jak już to jeszcze przetestować pnds_recursor, djbdns… i może bind10, bo podobno poprawiona wydajność. Robi się tego sporo, bo i lab z paroma maszynami wysyłającymi zapytania by się przydał, i testowanych demonów większa ilość. A miało być szybkie i proste zagadnienie na 1-2h.

Do tego problem danych testowych – każdy ma u siebie nieco inną charakterystykę ruchu, wyniki mogą się różnić dość znacznie, więc skąd wziąć dane? Jasne, można benchmarkować na podstawie własnych, rzeczywistych danych i będzie to najbliższe optymalizacji w danym przypadku, ale czy wartościowe dla innych? No i na pewno nie opublikuję takiego testowego zestawu danych. Jest też problem dostosowania konfiguracji do konkretnej platformy, na której uruchamiane będzie oprogramowanie (np. ilość wątków). Domyślny konfig jest różny dla różnych demonów, przy czym domyślny debianowy dla unbound ma się nijak do maszyny wieloprocesorowej. No i przydał by się tuning samego systemu pod kątem wydajności sieci, bo default w Linuksie jest raczej słaby.

Więcej pytań, niż odpowiedzi. Stanęło na tym, że pełnego testu nie zrobiłem. Za to puściłem szybki test na jakimś małym zestawie danych (kilkanaście wpisów). W ww. skrypcie zmieniłem liczbę procesów na 4, czas na 60 sekund i testowałem na laptopie (Intel Core i5). Nie do końca optymalnie, ale cóż, lepiej, niż pojedynczy proces. Poprzestałem więc na tym pseudobenchmarku na domyślnym konfigu – zabawa w optymalizację to grubsza sprawa, jeśli ma być zrobiona porządnie. Unbound wypadł bardzo dobrze. Mimo, że działał tylko na pojedynczym rdzeniu, wypadł dwukrotnie lepiej, niż bind.

Nie ukrywam, że chętnie poznam sugestie dot. danych testowych (takich, które można opublikować) i ew. doświadczeń z benchmarkowaniem DNS (cache). Jeśli się zbiorę i zrobię benchmark, to dane i wyniki będą opublikowane. Na razie stanęło na tym, że na moich dekstopach zmieniłem bind na unbound (tak, mam lokalne cache na desktopach od jakiegoś czasu, raczej eksperyment, kiedyś napiszę na ten temat).

Opublikowane w

Jak zdobyć certyfikat IPv6 i fajną koszulkę za darmo.

No i udało się. Szczerze mówiąc myślałem, że będzie trudniej i nie przypuszczałem, że cel jest tak blisko. Blokada IRC przez HE o której pisałem niedawno okazała się świetnym motywatorem do skończenia testu, czyli osiągnięcia poziomu Sage, który pozwala na odblokowanie dostępu do IRC. No i okazuje się, że prawdą jest to, co chciałem sprawdzić, czyli że certyfkiat IPv6 od HE da się zrobić, nie wydając ani złotówki i korzystając wyłącznie z zasobów (domeny, serwery DNS), dostępnych zupełnie za darmo w Internecie.

Nie zamierzam robić tutoriala krok po kroku – sam proces certyfikacji jest prosty i w sumie daje sporo frajdy (pod warunkiem, że nie trzeba powtarzać kroków kilka razy jak w moim przypadku…), poza tym samo HE daje tutoriale video, ale parę wskazówek się przyda, żeby się nie frustrować niepotrzebnie.

Adresację (tunel) IPv6 za darmo dostaniemy na przykład od samego HE. Z kolei domeny (dobra, subdomeny) za darmo daje na przykład afraid.org w ramach usługi FreeDNS. Niestety, ich NSy nie posiadają adresów IPv6 (żaden!). Można to jednak obejść delegując subdomenę na takie NSy, które posiadają obsługę IPv6. Na przykład te od HE.

Żeby nie było za prosto – wygląda, że jest jakiś problem z cache’owaniem(?) wpisów DNS po stronie HE – w pewnym momencie panel żadną miarą nie chciał przyjąć obsługi domeny, mimo, że powinien (support też tak twierdził). Rozwiązaniem jest dodanie delegacji na wszystkie ns1 do ns5 na he.net. Potem, przy którymś teście co prawda trzeba usunąć ns1, bo test wymaga (IMHO błędnie, powinien sprawdzać czy minimum 1 ma), żeby wszystkie NSy miały adresy IPv6, ale to insza inszość.

I tyle. Warto dodać, że ukończenie certyfikatu IPv6 od HE daje nie tylko możliwość odblokowania dostępu do IRC. Dodatkowo (a może przede wszystkim?) każdy, kto uzyska poziom Sage może otrzymać fajną, geekową, unikatową koszulkę za darmo (wysyłka też) – wystarczy podać rozmiar w panelu HE i potwierdzić adres do wysyłki. Taki – podobno bardzo udany – pomysł HE na popularyzację IPv6.

Zachęcam do zabawy. Mi pozostało wymaksowanie punktów. Osobną kategorią zabawy jest znalezienie błędów (implementacyjnych, nie rzeczowych) w samym teście (można udawać, że się zrobiło pewne rzeczy, nie robiąc ich, ale nie o to oczywiście chodzi). 😉

UPDATE: Szczerze mówiąc, myślałem, że Sage jest więcej, szczególnie, że sporo spotkałem na IRCu. Tymczasem na PLNOG dowiedziałem się, że jest raptem 87 osób w Polsce i ok. 4600 na całym świecie. Więcej statystyk.