T

rzeciego grudnia 2009 roku firma Google oddała własne serwery DNS do publicznego użytku. Jest to projekt bardzo zbliżony do OpenDNS. Ma on zapewnić jego użytkownikom szybkość odpowiedzi resolwerów DNS, ich bezpieczeństwo oraz niezawodność w działaniu. Szybkość i niezawodność osiągnięto dzięki zapewnieniu odpowiedniej obsługi klastrów złożonych z serwerów DNS; równoważeniu obciążenia (ang. load-balancing) zapytań do resolwerów DNS jak i zastosowaniu mechanizmu aktywnego prefetchingu.

Szybkość odpowiedzi:

Pod pojęciem odpowiedniej obsługi klastrów Google DNS, tak na prawdę kryje się odpowiednia konfiguracja maszyn składających się na klaster: serwery buforujące zapytania DNS (ang. caching dns) muszą wykonywać znacznie droższe w eksploatacji operacje niż serwery autorytatywne, gdyż wiele odpowiedzi DNS nie może być podawanych z pamięci; zamiast tego wymagają komunikacji z innymi serwerami nazw, a ten sposób pracy wymaga wiele ruchu sieciowego. Jeśli resolwery nie są odpowiednio przygotowane do pracy sieciowej – ich obciążenie ma negatywny wpływ na wydajność oraz szybkość obsługi klientów. Wiele pakietów jest traconych, wiele musi być retransmitowanych, zapytania są kolejkowane itd. Wszystkie te czynniki prowadzą do opóźnień obsługi. Ponadto publiczne / otwarte serwery DNS są bardziej narażone na ataki typu dns spoofing, cache poisoning oraz DDoS. Dlatego ważnym czynnikiem dla serwerów DNS jest umieszczenie ich w wysoko wydajnej infrastrukturze sieciowej. Umożliwia to obsługę ataków DDoS, dla których jednym ze skutecznych rozwiązań jest rozproszenie ich na wiele maszyn. Jednocześnie istotnym zabiegiem jest nie zmniejszanie prawdopodobieństwa trafienia pamięci podręcznej wraz z dodawaniem kolejnych serwerów DNS – wymaga to wdrożenia skutecznej polityki równoważenia obciążenia, którą Google rozwiązało następująco:

– skalowanie infrastruktury resolwerów poprzez dodawanie kolejnych maszyn może rzeczywiście odbić się rykoszetem i zmniejszyć prawdopodobieństwo trafień pamięci podręcznej serwerów DNS, jeśli nie zostanie zastosowana odpowiednia polityka równoważenia obciążenia. W typowych środowiskach produkcyjnych wiele maszyn umieszczonych jest za mechanizmem rozkładania obciążenia, który po równo rozdziela ruch do każdej maszyny używając prostego algorytmu karuzelowego (ang. round robin). Rezultatem takiego działania jest to, że każda maszyna ma swoją, własną niezależnie zbuforowaną pamięć, która jest niedostępna dla reszty serwerów DNS. Jeśli każde przychodzące zapytanie jest rozprowadzane do losowo wybranej maszyny – w zależności od rodzaju ruchu sieciowego – efektywna liczba nietrafień pamięci podręcznej może zostać proporcjonalnie zwiększona. Dla przykładu: domeny z długim TTL (ang. Time To Live – czasem ważności rekordów w domenie wyrażonym w sekundach), o które często występują zapytania posiadają zwiększone prawdopodobieństwo nietrafień pamięci podręcznej poprzez liczbę maszyn w klastrze. Analogicznie – dla domen z bardzo krótkim TTL, o które zapytania występują bardzo rzadko lub wyniki pochodzą z niezbuforowanych odpowiedzi (0 TTL lub błędów) – prawdopodobieństwo nietrafień pamięci podręcznej nie jest na prawdę uzależnione od ilości maszyn DNS w klastrze.

By zwiększyć procent trafień dla bardzo popularnych domen ważne jest by poddać równoważeniu obciążenia serwery, których pamięć podręczna jest nie pofragmentowana (oddzielona od innych). Istnieją dwa sposoby, aby tego dokonać:

• ‘wszym jest wykorzystanie globalnej pamięci podręcznej, która jest współdzielona przez wszystkie maszyny.
• ‘gim jest podział ogólnej pamięci podręcznej na domeny – tak by zapytania dla wybranej domeny zawsze trafiały do tej samej maszyny.

W przypadku publicznych serwerów Google DNS wykorzystywane są obydwa podejścia. Jedna pula maszyn współdzieli pewną małą część globalnej pamięci podręcznej dla najbardziej popularnych domen. Jeśli odpowiedź na zapytanie nie może zostać dostarczona z współdzielonej pamięci podręcznej tych maszyn – zapytanie jest wysyłane do innego zespołu maszyn, które dzielą pamięć podręczną mniej popularnych domen. Wszystkie zapytania dla tej samej domeny są wysyłane do tej samej maszyny, gdzie została już / lub nie zbuforowana.

Prefetching, czyli wcześniejsze wczytanie z dysku plików potrzebnych do działania programu pozwala skrócić czas uruchomienia programu, jak również czas uruchomienia całego systemu. W systemach operacyjnych taki mechanizm jest obecny od dawna. W przypadku serwerów DNS prefetching polega na na ciągłym, asynchronicznym odświeżaniu rekordów w pamięci podręcznej. Dzięki takiemu rozwiązaniu nie powinno być sytuacji, w której klient odpytuje o rekord domeny, który już wygasł i nie ma go w pamięci podręcznej. Wówczas konieczne jest odświeżenie rekordu przez odpytywane serwery DNS, a to wprowadza dodatkowe opóźnienia. Google nastawiło się również na geolokalizację tj. w zależności z jakiego kraju korzystamy z jego serwerów DNS będziemy kierowani do geograficznie najbliższego data center utrzymującego Google DNS. Ma to wpłynąć głównie na zlikwidowanie opóźnień przy kierowaniu ruchu przez niepotrzebne węzły sieciowe. W tym przypadku należy mieć na uwadze fakt, iż mimo zastosowaniu tylu technik optymalizacji publiczne serwery Google nadal mogą być wolniejsze od serwerów, które dostarcza nam nasz ISP (ang. Internet Service Provider – Dostawca Internetu) – właśnie ze względu na odległość geograficzną, która głównie wiąże się z ilością routerów do pokonania. Z badań przeprowadzonych przez serwis Heise Online wynika, że pakiety (zapytania) polskich użytkowników wędrujące do serwerów DNS Google’a muszą pokonać trasę zawierającą około 12 węzłów i składającą się z około 8 podsieci należących do czterech różnych operatorów – przyjmując za punkt początkowy sieć Telekomunikacji Polskiej.

Bezpieczeństwo:

Ze względu na otwarty i rozproszony projekt jakim jest usługa DNS oraz fakt, iż korzysta on z protokołu UDP (ang. User Datagram Protocol) powoduje, że jest podatny na różne formy ataków. Publiczne resolwery DNS pozwalające na rekursywne pytania, tym bardziej. W dodatku nie ograniczają one przychodzących pakietów do dopuszczalnego zakresu adresów IP np. sieci lokalnej. Dlatego Google postawiło nacisk głównie na ochronę przed dwoma rodzajami ataków:

• Ataki podszywania się (ang. dns spoofing) prowadzące do zatruwania pamięci podręcznej DNS (wcześniej wspomniane dns cache poisoning) oraz inne rodzaje fałszowania odpowiedzi, których celem jest kierowanie użytkowników z legalnych witryn do stron zawierających szkodliwe i złośliwe oprogramowanie (ang. malware), w tym te odkryte przez Dana Kaminsky’ego, w których agresor przejmuje autorytatywną kontrolę nad całą strefą DNS.
• Ataki Denial of Service (DoS) lub Distributed Denial of Service (DDoS), które wymierzone są prosto w serwery DNS jak również do przeprowadzania dalszych ataków na innych systemach. Ataki, które wykorzystują serwery DNS do przeprowadzenia ataków DDoS na innych systemach poprzez wywołanie bardzo dużej ilości odpowiedzi na zapytania są znane jako “wzmocnienia ataku” (ang. amplification attacks).

Jak również postawiło nacisk na kontrolę upływu ważności oraz odrzucanie podejrzanych odpowiedzi innych serwerów nazw, w tym:

• nie parsowalne lub zniekształcone odpowiedzi,
• odpowiedzi, których ID, źródłowe IP, źródłowy port lub nazwa zgłoszenia są niezgodne z parametrami oryginalnego żądania,
• rekordy, które nie są powiązane z żądaniem,
• rekordy odpowiedzi, dla których Google nie jest w stanie zrekonstruować łańcuch CNAME,
• rekordy, dla których odpowiadający serwer nazw nie jest wiarogodny (określenie wiarygodności serwera odbywa się poprzez sprawdzenie jego pozycji w delegacji dla wybranej domeny, zapamiętanie jej w pamięci podręcznej serwerów Google, a następnie porównywanie jej z każdym serwerem nadsyłającym odpowiedź).

Jeśli chodzi o ochronę przed atakami “podszywania się” – zastosowano następujące mechanizmy zwiększające entropię, utrudniającą atakującemu odgadnięcie ID zapytania, numer portu UDP, adresu IP (z którego pochodzi odpowiedź) oraz nazwy zapytania:

• Google DNS nie używa standardowego numeru portu odpowiedzi 53 (UDP), lecz dla każdego zapytania losuje inny numer portu (używając 15 bitów, które pozwalają na wykorzystanie około 32.000 losowych numerów portów),
• w sytuacji, gdy do odpowiedzi na dane zapytanie zgłasza się większa liczba serwerów DNS z wybranej strefy, usługa Google określa losowo tylko jeden z nich,
• wprowadzenie losowej zmiany wielkości liter w zapytaniach – technika znana jako “0x20”, ponieważ właśnie ten bit służy do określania wielkości liter w US-ASCII (przy czym podczas tłumaczenia nazw różnice te nie mają żadnego znaczenia),
• dodawanie etykiet do zapytań kierowanych do głównych serwerów nazw np. zapytanie o entriih-f10r3.www.google.com powinno zwrócić identyczną odpowiedź, co zapytanie o www.google.com,
• usuwanie zduplikowanych zapytań, w celu uniknięcia ataku urodzinowego, czyli Google DNS nigdy nie pozwoli na więcej niż jedno żądanie dla tej samej nazwy, typie oraz docelowym adresie IP.

W przypadku ochrony przed atakami DoS, Google DNS wprowadziło mechanizm ograniczający lub “dławiący” ilość i szybkość odpowiedzi. Ma on na celu ochronę zarówno innych serwerów DNS jak i samych klientów przed atakami DoS oraz DDoS (również w wersji z wzmocnieniem) poprzez wykorzystanie serwerów Google. Jeśli zapytania z określonego adresu IP konsekwentnie będą przekraczać maksymalną wartość QPS (ang. Queries Per Second – zapytań na sekundę) lub przydzieloną, średnią przepustowość (sporadyczna, większa liczba odpowiedzi będzie przepuszczana) usługa Google DNS będzie zwracała błędne odpowiedzi lub nawet żadnych.

Opisana usługa Google DNS jest osiągalna pod następującymi adresami IP:

DNS1: 8.8.8.8
DNS2: 8.8.4.4

Nawiązując do wcześniej wspomnianej usługi OpenDNS – Google nie umożliwia żadnych przekierowań, blokowania stron czy nakładania filtrów. Wszystkie strony są w pełni dostępne. Ponadto Gigant z Mountain View uspokaja swoich sceptyków, jeśli chodzi o ochronę prywatności – gwarantując zapisywanie jedynie danych niezbędnych do rozwiązywania problemów natury technicznej – żadne dane pozwalające na zidentyfikowanie użytkownika nie są gromadzone.

Więcej informacji: Google Public DNS, Domain Name System, Round Robin