1 (Pobrane z slow7.pl) Zarządzanie przestrzenią nazw domenowych ma ogromne znaczenie w sieci Internet oraz w sieciach korporacyjnych (w sieciach domowych raczej nikt serwera tego typu nie posiada, gdyż jest to zbędne lecz nie oznacza to że z usługi tej nie korzystamy). W sieciach firmowych działanie mechanizmu DNS ma szczególne znaczenie gdyż zapewnia on: stabilność komunikacji pomiędzy hostami a serwerami, odszukanie kontrolera domeny i wykonanie procesu logowania, dostęp aplikacją biznesowym do przydzielonych im zasobów, poprawne funkcjonowanie otoczenia sieciowego i widoczność krytycznych zasobów, użytkownikom sieci VPN na dostęp do świadczonych usług czy możliwość połączenia z siecią Intranet. Używając ścieżek bezpośrednich w oparciu o adres IP problem nie występuje. Pewnie nie jest to dla Ciebie Czytelniku tajemnicą, że do komunikowania się między sobą komputery w sieci wykorzystują adresy IP. Ich format oraz wartości dla nas ludzi stanowią pewien problem gdyż są po prostu trudne do zapamiętania. Znacznie lepiej zamiast przykładowego adresu 213.180.141.140 pamiętać www.onet.pl. Jest to tzw. nazwa kanoniczna. Użyty format odzwierciedla hierarchię systemu nazw domen używanych w sieci Internet, czyli DNS (ang. Domain Name Service). Aby tradycyjne adresy IP mogły współistnieć z nazwami komputerów, należało wymyślić i opracować mechanizm, który wykonywałby odwzorowywanie adresów z jednej postaci w drugą. I tym właśnie zajmuje się DNS. Sposób działania DNS-u został opracowany przez organizację IETF (ang. Internet Engineering Task Force) a jego opis znajdziemy w dokumentach RFC 1034 i 1035. System DNS jest standardem usługi nazw. Usługa DNS pozwala komputerom znajdującym się w sieci komputerowej rejestrować i rozwiązywać nazwy domen DNS. Za pomocą tych nazw można
2 (Pobrane z slow7.pl) zidentyfikować i uzyskać dostęp do zasobów oferowanych przez inne komputery w sieci lub innych sieciach, takich jak Internet. Aby nazwa komputera mogła być odwzorowana na adres IP musi przyjmować zdefiniowany format zgodny z zasadami przyjętymi w modelu systemu DNS. Na samym początku istnienia sieci komputerowych powiązanie nazwy komputera z jego adresem IP odbywało się poprzez zapisanie tych informacji w jednym pliku tekstowym. W miarę jak sieci komputerowe rozwijały się i rosła ich liczba rozwiązanie te przysparzało coraz więcej problemów. Dlatego też jak mówi stare przysłowie Potrzeba jest matką wynalazków: zdecydowano się na wprowadzenie systemu opartego o hierarchiczny, rozproszony model definiowania nazw. Najwyższy poziom w hierarchii jest reprezentowany przez znak. nazywany również korzeniem drzewa bądź domeną główną (w obiegu używana jest również nazwa root). Sposób definiowania nazw kolejnych poddomen nie został określony lecz przyjęto pewne zasady nazewnictwa i na następnym poziomie określono nazwy domen oraz zdefiniowano ich przeznaczenie. I tak pojawiły się poddomeny typu: com - organizacje komercyjne, int - organizacje międzynarodowe, edu - instytucje edukacyjne, net - internetowe, biz - biznesowe, info - serwisy o charakterze informacyjnym, gov - administracja rządowa, mil - wojsko, org - inne organizacje, name nazewnicze indywidualne, pro zawodowe, arpa - specjalna domena do wiązania adresów IP z nazwami. Ponieważ na samym początku sieć Internet swym zasięgiem obejmowała tylko USA, przyjęty system nadawania nazw nie odzwierciedlał podziałów terytorialnych państw. Dlatego też gdy Internet stał się na tyle popularny i na tyle dostępny dla reszty świata rozszerzono nazewnictwo domen o dwuliterowe kody krajów (większość z nich odpowiada kodom krajów ze standardu ISO 3166-1). Kody te łączy się z wymienionymi powyżej nazwami domen (np..com.pl) ale oprócz tego można je używać bezpośrednio po znaku. (np. samo.pl). Tak więc jak już wspomniano w systemie DNS przyjęto hierarchiczny układ domen co oznacza, że przykładowe domeny org czy net są poddomenami domeny głównej, zaś domena firma.com jest poddomeną domeny com. Hierarchię tę najczęściej odnosi się do drzewa w którym to gałęzie są kolejnymi poziomami hierarchii zaś liście to nazwy konkretnych maszyn. Taki sposób podejścia do sprawy ma swoje konsekwencję gdyż, przyjęty system nadawania nazw najczęściej odzwierciedla strukturę podmiotów (firmy komercyjne, uczelnie, jednostki administracji rządowej) i chyba co najważniejsze zapewnia autonomię w zarządzaniu i administrowaniu nazwami dostępnymi w ramach
3 (Pobrane z slow7.pl) pojedynczej domeny. Nazwę domeny (czytamy od lewej do prawej strony) tworzą nazwy kolejnych domen, które są wyżej w hierarchii. Wracając do naszej analogii z drzewem idziemy od liścia poprzez kolejne gałęzie aż do korzenia. Nazwy poszczególnych domen są od siebie oddzielone kropką. Pełna nazwa komputera posiada zaś dodatkowo na początku identyfikator komputera. Na przykład, komputer o identyfikatorze komp02 w domenie abc.com ma nazwę komp02.abc.com. Każda domena posiada swój serwer, który odpowiada za rozwiązywanie nazw w zdefiniowanej przestrzeni nazw przy czym kilka domen może być obsługiwanych przez jeden serwer (oczywiście możliwy jest również scenariusz w którym za obsługę klientów w danej strefie odpowiada kilka serwerów DNS). Każdy serwer DNS jest obsługiwany przez administratora, który najczęściej jest właścicielem danej domeny. Tak więc utworzenie własnej domeny (a mówiąc szczegółowo poddomeny) sprowadza się do zarejestrowania jej u właściciela domeny stojącego w hierarchii wyżej (rejestracja najczęściej wiąże się z uiszczeniem pewnej kwoty). Administrując daną domeną mamy swobodę w tworzeniu domen potomnych czyli subdomen. Serwer obsługujący domenę musi znać adresy serwerów DNS odpowiedzialnych za funkcjonowanie wszystkich jej poddomen. Przykładowo, chcąc utworzyć nową domenę abc w domenie com, fakt ten należy zgłosić do administratora domeny com. Po rejestracji domeny abc.com adres IP serwera DNS odpowiedzialny za rozwiązywanie nazw w tej strefie zostaje zapisany na serwerze domeny com. W systemie DNS możemy wyróżnić trzy podstawowe składniki, które odpowiadają za funkcjonowanie całego mechanizmu: zdefiniowana przestrzeń nazw domen i związane z nią typy rekordów zasobów rozproszona baza nazw i skojarzonych z nią adresów IP, strefy nazw DNS - serwery, które odpowiadają za funkcjonowanie domeny a których zadaniem jest kontrolowanie domeny (przechowywanie rekordów i zasobów związanych z obsługiwaną strefą) oraz udzielania odpowiedzi na kwerendy (zapytania) pochodzące od klientów DNS. W systemie DNS wyróżnić możemy dwa główne typy serwerów: serwery domeny głównej (ang. root servers) - są to serwery obsługujące domeny najwyższego poziomu (TLD top level domains) - znajdują się one na samym szczycie hierarchii modelu. Aktualnie na świecie funkcjonuje 13 serwerów domeny głównej. Serwery te określane są również jako root-servers, nazwy ich zostały zdefiniowane od a.rootservers.net do m.root-servers.net.
4 (Pobrane z slow7.pl) Nazwa hosta Adres IPv4/IPv6 Zarządca a.root-servers.net 198.41.0.4, 2001:503:ba3e::2:30 VeriSign, Inc. b.root-servers.net 192.228.79.201, 2001:500:84::b University of Southern California (ISI) c.root-servers.net 192.33.4.12, 2001:500:2::c Cogent Communications d.root-servers.net 199.7.91.13, 2001:500:2d::d University of Maryland e.root-servers.net 192.203.230.10, 2001:500:a8::e NASA (Ames Research Center) f.root-servers.net 192.5.5.241, 2001:500:2f::f Internet Systems Consortium, Inc. g.root-servers.net 192.112.36.4, 2001:500:12::d0d US Department of Defense (NIC) h.root-servers.net 198.97.190.53, 2001:500:1::53 US Army (Research Lab) i.root-servers.net 192.36.148.17, 2001:7fe::53 Netnod j.root-servers.net 192.58.128.30, 2001:503:c27::2:30 VeriSign, Inc. k.root-servers.net 193.0.14.129, 2001:7fd::1 RIPE NCC l.root-servers.net 199.7.83.42, 2001:500:9f::42 ICANN m.root-servers.net 202.12.27.33, 2001:dc3::35 WIDE Project Ponieważ główne serwery DNS są podstawą działania Internetu i obsługują ogromną ilość zapytań pochodzących od klientów tak więc aby przyspieszyć działanie całego systemu zostały one skopiowane. Kopie głównych serwerów zostały rozmieszczone po całym świecie (posiadają te same adresy IP co serwery główne). Użytkownicy z reguły łączą się z najbliższym im serwerem. Aktualne rozmieszczenie serwerów DNS poznasz odwiedzając tą stronę: http://www.root-servers.org/ serwery autorytatywne (ang. authoritative servers) - są to serwery obsługujące daną domenę/strefę to one przechowują informację na temat rekordów znajdujących się w zarządzanej przez siebie strefie. Ponieważ usługa DNS jest usługą kluczową bez której dostęp do sieci jest znacznie utrudniony (ale nie niemożliwy) dobrą praktyką jest aby za obsługę każdej domeny odpowiadały dwa serwery DNS (zabezpieczenie w przypadku awarii jednego z serwerów). klienci - aplikacje, które łączą się z serwerem DNS celem uzyskania informacji o przechowywanych zasobach serwera DNS. Odpytanie serwera DNS ma na celu uzyskanie informacji na temat adresu IP poszukiwanego hosta (w przykładach przedstawionych poniżej szukamy adresu IP komputera komp02.abc.pl). Serwer DNS aby wykonać odwzorowanie nazwa domenowa = adres IP może do tego celu wykorzystać dwa rodzaje zapytań DNS iteracyjne oraz rekurencyjne. Zasadę działania zapytania iteracyjnego ilustruje poniższy rysunek:
5 (Pobrane z slow7.pl) 1. Jeśli dany klient nie posiada odwzorowania buduje zapytanie, które następnie wysyła do serwera DNS (w jednym komunikacie do serwera może być wiele zapytań) - Jaki jest adres IP komputera o nazwie komp02.abc.com? 2. Lokalny serwer DNS również nie potrafi odpowiedzieć na pytanie hosta komp01.opole.firma.pl dlatego zapytanie o adres poszukiwanego hosta wysyła w kierunku serwera root - Jaki jest adres IP komputera o nazwie komp02.abc.com? 3. Serwer root odpowiada - Nie wiem, ale zapytaj serwer DNS odpowiedzialny za obsługę domeny com. 4. Zapytanie zostaje wysłane w kierunku serwera DNS com - Jaki jest adres IP komputera o nazwie komp02.abc.com? 5. Serwer com odpowiada - Nie wiem, ale zapytaj serwer domeny abc.com. 6. Zapytanie zostaje wysłane w kierunku serwera DNS abc.com - Jaki jest adres IP komputera o nazwie komp02.abc.com? 7. Serwer abc.com odsyła odpowiedź - Adres IP komputera komp02.abc.com to 1.2.3.4 8. Serwer DNS odsyła odpowiedź klientowi - Adres IP komputera komp02.abc.com to 1.2.3.4 W tym modelu lokalny serwer DNS w imieniu klienta odpytuje wszystkie serwery DNS wysyłając zapytania do innych serwerów DNS tak długo aż uzyska odpowiedź na poszukiwane pytanie. Uzyskana odpowiedź zostaje odesłana klientowi, który pytanie zadał. Zasada działania zapytania rekurencyjnego została przedstawiona poniżej:
6 (Pobrane z slow7.pl) 1. Host chcąc poznać adres komputera komp02.abc.com wysyła zapytanie do lokalnego serwera DNS - Jaki jest adres IP komputera o nazwie komp02.abc.com? 2. Serwer DNS na tak postawione pytanie nie może udzielić odpowiedzi dlatego zapytanie zostaje powielone i wysłane do kolejnego serwera DNS będącego wyżej w hierarchii. 3. Serwer DNS do którego trafia zapytanie również nie jest w stanie udzielić odpowiedzi. Komunikat zostaje przesłany do kolejnego serwera DNS. 4. Powielony komunikat zostaje przekazany do serwera root. 5. Serwer root nie może udzielić odpowiedzi. Ponieważ poszukiwany adres IP znajduje się w domenie com - w kroku następnym zapytanie zostaje skierowane do niego. 6. Główny serwer DNS obsługujący przestrzeń nazw domen com nie zna odpowiedzi - pytanie zostaje wysłane w kierunku serwera DNS abc.com 7. Ponieważ poszukiwany host należy do domeny abc.com serwer DNS obsługujący tę strefę w swojej bazie odnajduje adres IP poszukiwanego hosta. Adres IP komputera komp02.abc.com to 1.2.3.4 8. Odpowiedź zostaje przekazana do serwera DNS strefy com. - Adres IP komputera komp02.abc.com to 1.2.3.4 9. Serwer DNS informację przekazuje dalej - Adres IP komputera komp02.abc.com to 1.2.3.4 10. Serwer DNS informację przekazuje dalej - Adres IP komputera komp02.abc.com to 1.2.3.4 11. Serwer DNS informację przekazuje dalej - Adres IP komputera komp02.abc.com to 1.2.3.4 12. Lokalny serwer DNS odsyła odpowiedź do hosta, który wysłał zapytanie - Adres IP komputera komp02.abc.com to 1.2.3.4 Host poznaje adres IP komputera komp02.abc.com - rozpoczyna się wymiana danych pomiędzy nimi. Przedstawione schematy ukazują jedynie koncepcję zapytań prowadzonych przez serwery DNS, gdyż w rzeczywistości serwery DNS potrafią w celu wykonania odwzorowywania łączyć obydwa rodzaje zapytań. System DNS oprócz odpytania serwera pod kątem dopasowania nazwy komputera z jego adresem IP umożliwia wykonywanie zapytań odwrotnych, znajdujących nazwę komputera o znanym adresie IP.
7 (Pobrane z slow7.pl) Komunikaty DNS używane podczas wymiany informacji (zapytania, odpowiedzi, transfer strefy) mają ściśle ustalony format. Przykład takiego komunikatu został pokazany na rysunku poniżej. W pakiecie DNS można wyróżnić następujące pola: Identyfikator DNS - dane zawarte w tym polu są określone przez klienta i zwracane do niego w niezmienionej formie. Pole te umożliwia powiązanie zapytania DNS z odpowiedzią na nie. Żądanie/odpowiedź (QR) - pole określa rodzaj pakietu: żądanie (wartość 0) lub odpowiedź DNS (wartość 1). Kod operacji (OpCODE) - pole definiuje typ użytego zapytania zawartego w pakiecie. Wartość pola przyjmuje 0 podczas wysyłania standardowego zapytania bądź odpowiedzi na to zapytanie.
8 (Pobrane z slow7.pl) Wartości od 1 do 3 są nieużywane natomiast 4 oznacza powiadomienie zaś 5 aktualizacja. Odpowiedź autorytatywna (AA) - odpowiedź pochodzi z autorytatywnego serwera nazw a nie z bufora. Obcięcie (TC) - ustawienie bitu tego pola oznacza skrócenie odpowiedzi ze względu na przekroczenie rozmiaru datagramu - informacja zajmuje więcej niż 512 bajtów (dotyczy protokołu UDP). Żądanie rekurencji (RD) - ustawienie bitu w zapytaniu, wskazuje, że klient DNS żąda wykonania zapytania rekurencyjnego w sytuacji w której serwer DNS nie będzie zawierał żądanych informacji. Brak ustawienia bitu i brak możliwości odesłania odpowiedzi przez serwer powoduje wysłanie listy innych serwerów nazw, które mogą zostać użyte w procesie odwzorowywania. Gdy klient otrzyma taka odpowiedź może wykorzystać otrzymane informację w celu budowania kolejnych zapytań. Rekurencja jest dostępna (RA) - znacznik ustawiony w odpowiedzi informuje o możliwości wykorzystania przez serwer zapytań rekurencyjnych. Zarezerwowane (Z) - pole przyjmuje wartość 0, pole przeznaczone do wykorzystania w przyszłości. Dane autentyczne (AD) - ustawiona wartość 1 oznacza uwierzytelnienie przekazywanych informacji. Sprawdzanie wyłączone (CD) - wyłączenie mechanizmu weryfikacji zabezpieczeń. Kod odpowiedzi (RCode) - pole wykorzystywane w celu wskazania istnienia ewentualnych błędów. Najczęstsze wartości jakie może przyjąć to pole zostały przedstawione poniżej: 0 - NoError - brak błędu, 1 - FormErr - interpretacja zapytania zakończona niepowodzeniem, 2 - ServFail - błąd po stronie serwera, niepowodzenie w procesie przetwarzanie zapytania, 3 - NXDomain - wskazana domena nie istnieje,
9 (Pobrane z slow7.pl) 4 - NotImp - typ żądania nieobsługiwane przez serwer, 5 - Refused - żądanie odrzucone, brak wysłania odpowiedzi, 9 - NotAuth - brak autoryzacji serwera w strefie, 10 - NotZone - nazwa nie należy do strefy. Liczba zapytań (QDCOUNT) - liczba wpisów w sekcji zapytań. Liczba odpowiedzi (ANCOUNT) - liczba rekordów w sekcji odpowiedzi. Liczba rekordów serwera (NSCOUNT) - liczba rekordów zasobów w sekcji autorytatywnej. Liczba rekordów dodatkowych (ARCOUNT) - liczba rekordów, które pochodzą z innych źródeł. Dynamiczne aktualizacje DNS (ang. DNS Update) przenoszą pola o nazwach ZOCOUNT, PRCOUNT, UPCOUNT oraz ADCOUNT. Sekcja zapytań - sekcja zawierająca zapytanie (sekcja o zmiennej wielkości). Sekcja odpowiedzi - sekcja zawierająca rekordy danych będący odpowiedzią na otrzymane przez serwer zapytania (sekcja o zmiennej wielkości). Sekcja autorytatywna - informacja o innych autorytatywnych serwerach, które mogą być wykorzystane w procesie określania nazw (sekcja o zmiennej wielkości). Sekcja informacji dodatkowych - informacje dodatkowe związane z otrzymanymi zapytaniami. Wymiana pakietów w komunikacji DNS odbywa się z wykorzystaniem protokołu UDP (standardowe zapytania) ale także protokołu TCP (wymiana informacji pomiędzy serwerami DNS tzw. transfer strefy). W obu przypadkach wykorzystywany jest port o numerze 53. Datagram UDP/IPv4 (ten najczęściej wykorzystywany) został pokazany na rysunku poniżej.
10 (Pobrane z slow7.pl) Jeśli w danej strefie obsługa zapytań jest realizowana przez dwa serwery DNS komunikacji pomiędzy nimi odbywa się z wykorzystaniem protokołu TCP raz ze względu na ilość przesyłanych danych a dwa, że konieczne jest zachowanie pewności przesyłu tych danych. Transfer strefy pomiędzy serwerami DNS jest wykonywany w celu synchronizacji danych tak by oba serwery nazw obsługujące strefę posiadały jednolite dane. Do tematu jeszcze powrócimy gdy zaczniemy analizować przechwycone pakiety. Rekordy zasobów DNS zawierają informacje związane z domeną i mogą być pobierane oraz wykorzystywane przez klientów DNS. Każdy serwer DNS obsługuje te rekordy przestrzeni nazw DNS, które są dla niego autorytatywne. Każdy administrator systemu DNS odpowiedzialny jest za poprawność informacji zawartych, w strefie którą zarządza. W wspomnianych dokumentach RFC 1034 i 1035 oraz późniejszych został określone możliwe do przechowywania typy zasobów. Większość typów rekordów praktycznie nie jest wykorzystywana choć nadal w pełni wspierana. Do tych najważniejszych rekordów można zaliczyć następujące: rekord A lub rekord adresu IPv4 (ang. address record) mapuje nazwę domeny DNS na jej 32-bitowy adres IPv4. Jest rekordem wyszukiwania w przód. rekord AAAA lub rekord adresu IPv6 (ang. IPv6 address record) mapuje nazwę domeny DNS na jej 128 bitowy adres IPv6. Rekord AAAA podobnie jak rekord A jest rekordem wyszukiwania w przód. rekord CNAME lub rekord nazwy kanonicznej (ang. canonical name record) ustanawia alias nazwy domeny czyli pozwala na użycie kilku rekordów zasobów odnoszących się do jednego hosta.
11 (Pobrane z slow7.pl) rekord MX lub rekord wymiany poczty (ang. mail exchange record) mapuje nazwę domeny DNS na nazwę serwera mailowego, obsługującego pocztę dla danej domeny. Rekordów MX w danej strefie może być kilka, różnią się one priorytetem. W pierwszej kolejności wybierane są te z niższym priorytetem - serwer z wyższym priorytetem jest wybierany w sytuacji w której serwer do którego został przypisany priorytet niższy nie działa. rekord PTR lub rekord wskaźnika (ang. pointer record) mapuje adres IPv4 na nazwę kanoniczną hosta. Rekord PTR w przeciwieństwie do np. rekordów typu A bądź AAAA jest rekordem wyszukiwania wstecznego, który łączy adres IP z nazwę hosta. Rekordy PTR mogą mieć postać adresów IPv4 lub IPv6. rekord NS lub rekord serwera nazw (ang. name server record) mapuje oraz identyfikuje serwer DNS autorytatywny dla danej domeny. rekord SOA (ang. start of authority record) ustala serwer DNS dostarczający autorytatywne informacje o domenie internetowej (adresy serwerów nazw, parametry czasowe transferu stref czy numer konfiguracji). rekord SRV lub rekord usługi (ang. service record) pozwala na zawarcie dodatkowych informacji dotyczących lokalizacji danej usługi, którą udostępnia serwer wskazywany przez adres DNS. TXT - rekord ten pozwala dołączyć dowolny tekst do rekordu DNS. Proces rozpoznawania nazw przez klienta DNS schematycznie został przedstawiony na rysunku poniżej.
12 (Pobrane z slow7.pl) Jak można zauważyć w pierwszym kroku klient poszukiwaną informację próbuje zdobyć sam. W tym celu sięga do informacji zapisanych w pliku HOSTS, którego zawartość jest kopiowana do pamięci podręcznej. Plik HOSTS jest plikiem tekstowym zawierającym w każdej linii adres IP i jedną lub więcej nazw domenowych danego hosta (oddzielone od siebie spacjami lub tabulatorami). W systemie Windows lokalizacja tego pliku jest następująca: %SystemRoot%\system32\drivers\etc\hosts Przykładowy plik HOSTS został pokazany na rysunku poniżej. W pamięci podręcznej również znajdują się rozwiązane kwerendy DNS uzyskane w odpowiedziach na poprzednie zapytania. Jeśli poszukiwana nazwa hosta zostaje skojarzona z adresem IP cały proces się kończy. W czasie procesu rekursji lub iteracji serwery DNS przetwarzają kwerendy w imieniu klientów i równocześnie gromadzą zdobyte informacje o przetwarzanym obszarze nazw DNS. Te informacje w kolejnym kroku umieszczane są w pamięci podręcznej celem późniejszego wykorzystania. Dzięki zapisu informacji o rozwiązanych kwerendach serwer/host w przypadku wystąpienia ponownego zapytania, które miało miejsce wcześniej nie musi wykonywać procesu rozwiązywania nazwy, gdyż potrzebna informacja jest już dla niego dostępna. Głównym zadaniem użycia bufora jest
13 (Pobrane z slow7.pl) więc zmniejszenie ruchu w sieci związanego z mechanizmem DNS. Kiedy informacja trafia do bufora jest jej przypisywana wartość czasu wygaśnięcia (TTL). Dopóki nie upłynie czas TTL buforowanych kwerend, dany serwer DNS może ponownie wykorzystywać zapisane rekordy do udzielania odpowiedzi klientom na przysyłane przez klientów zapytania odpowiadające tym rekordom. W sytuacji kiedy host w sposób lokalny nie potrafi znaleźć nazwy hosta proces rozwiązywania jest kontynuowany przez klienta poprzez wysłanie zapytania do serwera DNS. Po otrzymaniu pytania serwer DNS podobnie jak klient w pierwszej kolejności sprawdza czy może na nie odpowiedzieć na podstawie informacji zawartych w swoim lokalnym buforze jeśli tak do klienta jest odsyłana odpowiedź. Jeśli nazwa poszukiwanego hosta jest zgodna z rekordem zasobu zarządzanej strefy (bądź stref), serwer odpowiada autorytatywnie, wykorzystując informacje uzyskane z zasobów strefy. Serwer DNS, który posiada pełną informację o przestrzeni nazw DNS jest określany mianem serwera autoratywnego dla tej części przestrzeni nazw i to on jest podstawowym magazynem strefy. Strefa zaś zawiera rekordy zasobów, które mogą należeć do jednej lub więcej domen DNS. Jeśli wszystkie przedstawione wyżej sposoby rozwiązania nazwy (brak informacji w buforze hosta, serwera DNS oraz wśród informacji strefy), okażą się nieskuteczne proces wykonywania kwerendy jest kontynuowany z wykorzystaniem zewnętrznych serwerów DNS (użycie zapytań DNS iteracyjne oraz rekurencyjne). Wyróżnić możemy cztery typy stref DNS (w niektórych źródłach znajdziesz informację o trzech): Strefa podstawowa - strefa tego typu jest niezbędna do funkcjonowania mechanizmu DNS oraz do prawidłowego rozpoznania nazw domen. Przechowuje ona główną kopię strefy i informacje w niej zawarte mogą być replikowane do stref pomocniczych. Strefa podstawowa jest zapisana na serwerze DNS, który jest serwerem autorytatywnym dla strefy. Strefa pomocnicza - zawiera kopię tylko do odczytu informacji o strefie, czyli obejmuje ona wszystkie informacje zawarte w strefie podstawowej. Informacje w niej zapisane są uzyskiwane za pomocą replikacji z wykorzystaniem mechanizmu transferu strefy. Wykorzystanie stref tego typu zwiększa wydajność (zapytania rozkładają się pomiędzy. Strefa skrótowa (czasem też zwana strefą wejściową) zawiera jedynie informacje o rekordach zasobów (SOA, NS), które są niezbędne do zidentyfikowania autorytatywnych
14 (Pobrane z slow7.pl) serwerów DNS. Strefy tego typu wskazują, gdzie można znaleźć pełną informację o strefie. Zintegrowana z Active Directory - ten typ strefy tak naprawdę jest strefą podstawową tylko w przeciwieństwie do tradycyjnej strefy podstawowej, która jest przechowywana w pliku lokalnym jest ona wykorzystywana w środowisku opartym o usługę Active Directory a jej replikacja jest wykonywana przy wykorzystaniu mechanizmów tej usługi. Część teoretyczną z grubsza mamy omówioną choć celem uzupełnienia do pewnych zagadnień wrócimy. Topologia naszej ćwiczebnej sieci w oparciu o którą zostaną omówione pakiety DNS została zaprezentowana na schemacie poniżej: Polecenie poniżej zostało wydane na komputerze XXX i jak widać w cachu znajduje się tylko jeden wpis wiążący nazwę WinServ2012A z adresem IP 10.0.0.10 (bufor pamięci DNS zawierający
15 (Pobrane z slow7.pl) odwzorowania nazw domenowych i odpowiadających im adresów IP poznamy wydając polecenie: ipconfig /displaydns). Prześledźmy zatem wymianę pakietów DNS jaka zachodzi w przypadku rozwiązywania nazw. Z hosta XXX wykonamy test ping w kierunku hosta YYY. Komputer nie zna adresu IP hosta YYY tak więc w pierwszej kolejności zostanie przeprowadzona komunikacja z serwerem DNS w celu ustalenia adresu IP komputera YYY. Jak już wiesz Czytelniku cała funkcjonalność systemu DNS opiera się na modelu zapytania i odpowiedzi. Host, który chce dokonać powiązania danego adresu IP z jego nazwą domenową buduje i wysyła do serwera DNS zapytanie, zaś zadaniem serwera DNS jest znalezienie odpowiedzi na pytanie hosta i jej odesłanie. Proces powiązania adresu IP z nazwą hosta może wymagać wysłania wielu pakietów lecz w najprostszej postaci wystarczą dwa. Prześledźmy zatem jak wygląda wymiana pakietów pomiędzy komputerami właśnie w tej najprostszej sytuacji. Na rysunku poniżej przedstawiono przechwycony pakiet z zapytaniem DNS, które zostało wysłane przez hosta XXX o adresie 172.16.10 do serwera o adresie 10.0.0.10 (punkt 1). Przedstawiony pakiet jest zapytaniem DNS a do jego wysłania został użyty protokół UDP w powiązaniu z portem o numerze 53 (domyślny port usługi DNS) - punkt 2. Pakiet jest pojedynczym zapytaniem wysłanym w celu identyfikacji adresu IP hosta yyy.firma.local (ponieważ komputery są częścią domeny firma.local człon ten został dodany automatycznie). Zapytanie dotyczy adresu internetowego (IN) komputera (A) - punkt 3.
16 (Pobrane z slow7.pl) Odpowiedź na pytanie hosta została zaprezentowana na rysunku poniżej. Ponieważ oba komputery są w jednej wspólnej domenie serwer DNS nie musi odpytywać innych serwerów celem ustalenia adresu IP hosta YYY gdyż informację ta znajduje się w jego bazie (rekurencja w tym przypadku nie jest wykorzystywana). Odpowiedź zostaje udzielona hostowi - punkt 1. Rodzi się pytanie - Skąd wiemy, że przedstawiony pakiet jest odpowiedzią na zapytanie klienta? Łatwo to zweryfikować i łatwo powiązać zapytanie z odpowiedzią gdyż pakiet ten ma taki sam identyfikator jak zapytanie (w naszym scenariuszu 0x4c04) - porównując identyfikatory pakietów łatwo powiążemy pakiety zapytań z odpowiedziami na nie - punkt 2. Informacja o tym, że pakiet jest odpowiedzią możemy zweryfikować również po rozwinięciu sekcji Flags - punkt 3. Dodatkowa weryfikacja może nastąpić po analizie danych umieszczonych w sekcji Answers gdyż przedstawiony pakiet budowany jest w ten sposób, że zawiera on informację o otrzymanym zapytaniu jak i udzielonej odpowiedzi. Adres IP komputera YYY to 172.16.0.11 Host XXX uzyskując informację o adresie IP hosta YYY może rozpocząć z nim komunikację.
17 (Pobrane z slow7.pl) W kolejnym przykładzie nadal będziemy bazować na pytaniu i odpowiedzi w ramach jednej domeny lecz przyjrzymy się sytuacji w której serwer DNS nie znajduje odpowiedzi na pytanie klienta. Przesłane zapytanie w budowie nie różni się od pakietu przedstawionego w poprzednim przykładzie. Jest tylko mała różnica - szukamy adresu IP hosta o nazwie AAA. Host taki oczywiście w naszej sieci nie istnieje.
18 (Pobrane z slow7.pl) Ponieważ nazwa szukanego hosta jest obsługiwana przez serwer DNS WinServ2012A, to tylko on jest władny by udzielić informację o adresie IP poszukiwanego komputera. Serwer DNS odsyła pakiet o nie odnalezieniu dopasowania.
19 (Pobrane z slow7.pl) Wydając na hoście XXX ponownie polecenie: ipconfig /displaydns możemy przejrzeć lokalny cache DNS hosta. Jak widać zostały w nim zapisane oba odwzorowania (jedno mapujące nazwę hosta YYY z adresem IP 172.16.0.11 oraz drugie informujące, że host o nazwie AAA nie istnieje) o które host ten pytał.
20 (Pobrane z slow7.pl) Urozmaicamy trochę Naszą sytuację i sprawdźmy jak przebiegnie wymiana komunikatów w sytuacji w której poszukiwany adres IP hosta będzie znajdował się w Internecie. Odpytajmy serwer DNS o adres IP hosta google.pl Do tej pory hosty mogły prowadzić tylko komunikację w ramach sieci LAN, zmieniamy trochę naszą topologię i hosty uzyskują dostęp do Internetu. Zostaje skonfigurowane łącze pomiędzy routerem a dostawcą Internetu. Konfiguracja routera oczywiście musi ulec modyfikacji (zostaje skonfigurowana zerowa trasa statyczna tak by wszystkie pakiety, które nie znajdują dopasowania mogły zostać nią przesłane oraz NAT) oraz serwer DNS zostaje skonfigurowany w ten sposób by zapytania DNS na które nie znajduje odpowiedzi przesyłał dalej (jak taką konfigurację wykonać opiszę w wpisie, który będzie poświęcony mechanizmowi DNS w kontekście Windows Server 2012). Serwerem DNS do którego będą trafiać zapytania to ogólnodostępny serwer DNS Google czyli host o adresie IP 8.8.8.8 Hostem zadającym pytanie jest komputer YYY. Od hosta YYY (IP 172.16.0.11) do serwera DNS (IP 10.0.0.10) trafia zapytanie - Jaki jest adres IP hosta google.pl? (punkt 1). Serwer DNS na tak postawione pytanie nie zna odpowiedzi gdyż poszukiwany host nie znajduje się w zarządzanej przez niego domenie. Zapytanie musi być przesłane do zewnętrznego serwera DNS a ponieważ możliwe jest wykonanie rekurencji (punkt 2) pakiet z pytaniem zostaje wysłany do serwera DNS o adresie 8.8.8.8 Identyfikator pakietu przyjmuje wartość 0xa238 (punkt 3).
21 (Pobrane z slow7.pl) Zrzut poniżej przedstawia przechwycony pakiet w komunikacji pomiędzy hostami 172.16.0.11 a 10.0.0.10 Tak jak napisałem wyżej celem dokonania mapowania pakiet opuszcza lokalny serwer DNS i zostaje przekazany w kierunku zewnętrznego serwera DNS - punkt 1. Pakiet ten zawiera pytanie zadane przez hosta YYY - punkt 2. Identyfikatorem pakietu jest wartość: 0x14de - punkt 3.
22 (Pobrane z slow7.pl) Zrzut poniżej przedstawia przechwycony pakiet w komunikacji pomiędzy hostami 10.0.0.10 a 8.8.8.8 Ponieważ odpytywany serwer DNS należy do Google (punkt 1) a pytanie dotyczy hosta znajdującego się w tej domenie zostaje udzielona odpowiedź w postaci adresu IP poszukiwanego komputera (punkt 2). Pakiet jest odpowiedzią na wcześniejsze żądanie gdyż pakiet wysłanego zapytania i udzielonej odpowiedzi zawierają ten sam identyfikator (punkt 3).
23 (Pobrane z slow7.pl) Lokalny serwer DNS zna już odpowiedź na pytanie hosta YYY tak więc udziela mu odpowiedzi (punkt 1) w postaci poszukiwanego adresu IP (punkt 2). I tak samo jak poprzednio pakiet pytania i odesłanej odpowiedzi powiążemy ze sobą za pomocą identyfikatora transakcji (punkt 3).
24 (Pobrane z slow7.pl) Mam nadzieję, że przedstawione powyżej przykłady w dość jasny sposób tłumaczą wymianę pakietów jaka jest prowadzona w ramach mechanizmu DNS. Strefa DNS to przestrzeń nazw, którą może zarządzać jeden z serwerów DNS jednak w celu zapewnienia redundancji i wyeliminowania sytuacji w której serwer DNS na wskutek awarii jest nieosiągalny stosuje się zapasowy serwer DNS, który zawiera pełną kopię informacji danej strefy (kopia serwera głównego). Zastosowanie drugiego serwera ma jeszcze jedną zaletę gdyż ruch związany z zapytaniami jest rozkładany pomiędzy nimi. Aby kopie na obu serwerach były spójne i synchronizowane pomiędzy serwerami następuje tzw. transfer strefy DNS. Przyrostowy transfer strefy (IXFR) - pomiędzy serwerami DNS zostaje przesłana tylko
25 (Pobrane z slow7.pl) część informacji, która uległa zmianie bądź modyfikacji. Pełny transfer strefy (AXFR) - pomiędzy serwerami DNS następuje przesłanie całej strefy. Aby przeanalizować jak pełny transfer strefy przebiega w praktyce należy zmodyfikować naszą topologię sieciową - dodajemy do niej dodatkowy serwer DNS WinServ2012B. Host YYY (IP 172.16.0.11) posłuży Nam w celu zbadania przebiegu przyrostowego transferu strefy. Przykład przedstawiający pełny transfer strefy pomiędzy komputerami o adresach IP 10.0.0.10 o 10.0.0.11 został przedstawiony poniżej. Na hoście WinServ2012B została dodana rola serwera DNS (sposób konfiguracji w kontekście
26 (Pobrane z slow7.pl) Windows Server zostanie opisany w oddzielnym wpisie), po jej instalacji komputer zostaje włączony w strukturę istniejącej sieci. Ponieważ dodany host pełni rolę zapasowego serwera DNS przy podłączaniu następuje proces pełnego transferu strefy z serwera głównego. Analizując powyższy zrzut pierwsza rzecz, która powinna przykuć Twoją uwagę Czytelniku jest użyty protokół warstwy transportowej - nie jest to jak było do tej pory protokół UDP lecz TCP. Waga przesyłanych informacji jest zbyt ważna by zadanie to powierzyć protokołowi UDP (brak mechanizmów gwarantujących 100% pewność przesłanych danych) dlatego też proces transferu strefy odbywa się z wykorzystaniem protokołu TCP, który pomimo większego narzutu przesyłanych danych gwarantuje Nam pewność i niezawodność ich dostarczenia (punkt 1). Żądanie pełnego transferu strefy DNS to tak naprawdę standardowe zapytanie kierowane ku
27 (Pobrane z slow7.pl) serwerowi DNS, ale zamiast prośby o rozwiązanie nazwy pojedynczego rekordu klient żąda otrzymanie wszystkich informacji dotyczących zarządzaną strefą. Serwer DNS otrzymuje rekord typu AXFR - punkt 2. Główny serwer DNS po otrzymaniu żądania transferu strefy odsyła stosowane informacje w kierunku klienta (punkt 1). Proces pełnego transferu strefy powoduje przekazanie informacji o wszystkich rekordach w ramach zarządzanej strefy DNS - punkt 2. Zapasowy serwer DNS posiada informację o całej strefie. W razie awarii serwera głównego host może przejąć jego rolę. Po zakończeniu całej wymiany informacji następuje eleganckie zakończenie sesji TCP (patrz pakiety od 142 do 145) - jeśli sposób działania protokołu TCP jest Ci obcy zapraszam do zapoznania się z wpisem: Co w sieci siedzi. Skanowanie portów.
28 (Pobrane z slow7.pl) Przeglądając powyższe dane, które zostały dostarczone zapasowemu serwerowi DNS (nie było ich wiele, gdyż nasza strefa nie jest duża) szybko można dojść do wniosku (a nawet trzeba), że waga przesłanych informacji dla atakującego naszą sieć będzie stanowić prawdziwą kopalnię złota gdyż dzięki ich analizie można utworzyć mapę całej infrastruktury sieci. Dlatego też nie powinny dostać się one w niepowołane ręce. Sposób uzyskiwania wglądu do nich zależy od konfiguracji serwera DNS a nieprawidłowa bądź nierzetelna konfiguracja serwera może doprowadzić do sytuacji w której dostęp do informacji strefy (tak jak to zostało pokazane poniżej) będzie mógł uzyskać każdy. W przykładzie poniżej dzięki wykorzystaniu wbudowanego w systemie Windows narzędzia nslookup i po wydaniu dwóch poleceń do hosta XXX zostaje wykonany pełny transfer sieci. Po wywołaniu narzędzia domyślnym serwerem DNS jest host 10.0.0.10 (serwer ten został zdefiniowany w ustawieniach karty sieciowej) - punkt 1.
29 (Pobrane z slow7.pl) Za pomocą polecenia: set type=any ustalamy zakres interesujących nas rekordów - punkt 2. Komenda: ls -d <nazwa_domeny> nakazuje przesłanie kopii strefy. Poniżej zaprezentowano zrzut wymiany pakietów pomiędzy serwerem DNS (IP 10.0.0.10) a hostem XXX (IP 172.16.0.10). Jak widać przedstawiony pakiet odzwierciedla informację uzyskane dzięki narzędziu nslookup. Przyrostowy transfer stref jest dodatkową funkcją protokołu DNS związaną z replikowaniem stref DNS. Głównym założeniem przyświecającym przy opracowywaniu tego standardu było zmniejszenie obciążeń łączy podczas prowadzonego procesu aktualizacji stref. Przed wprowadzeniem tego
30 (Pobrane z slow7.pl) mechanizmu każda aktualizacja danych związana z przesłaniem rekordów bazy danej strefy wymagała wykonanie procesu pełnego transferu całej strefy (użycie w pakiecie flagi AXFR). W sytuacji, w której wykorzystywany jest przyrostowy transfer strefy (użycie w pakiecie flagi IXFR) serwer, który żąda przesłania informacji wykonuje kopię tych zmian strefy, które są niezbędne do synchronizacji jego kopii strefy ze źródłem. Przebieg procesu przyrostowego transferu strefy został przedstawiony poniżej (komunikacja pomiędzy dwoma serwerami DNS o adresach IP 10.0.0.11 oraz 10.0.0.10). Jak już wspomniałem w naszej ćwiczebnej topologii znajduje się host YYY (IP 172.16.0.11), rekord typu A łączący nazwę hosta YYY z adresem IP został utworzony na serwerze 10.0.0.10. Pomiędzy serwerami DNS (punkt 1) dochodzi do transferu strefy lecz w odróżnieniu od poprzedniej wymiany danych transfer ten jest wykonywany po przesłaniu pakietu z ustawioną flagą IXFR (punkt 2) nakazując tym samym przesłanie nowych rekordów bądź tych, które zostały poddane modyfikacji. W kolejnym pakiecie serwer DNS 10.0.0.10 (punkt 1) przesyła aktualizację strefy i jak widać poniżej znajduje się w nim informacja tylko o hoście YYY (punkt 2).
31 (Pobrane z slow7.pl) W tym wpisie starałem się przedstawić najważniejsze informację związane z działanie mechanizmu DNS. Wiesz już, jak przebiega proces rozpoznawania nazw w sieciach opartych o protokół TCP/IP oraz jak ważnym dla sprawnego funkcjonowania całego Internetu jest spójny mechanizm zarządzania nazwami komputerów i usług. W kolejnym wpisie temat rozwiniemy i zajmiemy się konfiguracją protokołu DNS w systemie Windows Server 2012.