Laboratorium podstaw sieci komputerowych Zadanie 2

Transkrypt

1 Grzegorz Graczyk numer indeksu imie i nazwisko Paweł Tarasiuk numer indeksu imie i nazwisko Data Kierunek Informatyka Rok akademicki 2009/10 Semestr 4 Grupa dziekańska 2 Grupa laboratoryjna 15 Laboratorium podstaw sieci komputerowych Zadanie 2

2 Część teoretyczna Hierarchiczna struktura systemu DNS: domeny najwyższego poziomu (TLD), delegacja i zarządzanie domenami, rodzaje zapytań. DNS (Domain Name System lub Domain Name Service) można swobodnie przetłumaczyć jako system nazw domen, odpowiadający za tłumaczenie nazw mnemonicznych, czyli ciągów znaków alfanumerycznych, kropek i myślników na adresy IP. Nazwy mnemoniczne, jak sama nazwa wskazuje, są proste do zapamiętania, a ponadto przypadku przeniesienia interesującej nas usługi na inny serwer lub zmiany dostawcy sieci wykorzystywanego przez usługodawcę wystarczy, że rekordy DNS zostaną zmienione, a będziemy mogli nadal używać tej samej nazwy. Ponadto DNS pozwala na gromadzenie wielu dodatkowych informacji związanych z domenami. Struktura DNS jest opisana dokładnie w RFC nr 819. Hierarchiczność struktury pozwala na rozproszenie informacji DNS na wielu serwerach, tworzących (w przybliżeniu) strukturę drzewiastą. Oznacza to, że dany serwer DNS musi przechowywać informacje jedynie o przypisanej mu domenie (subdomenie), a w przypadku zapytania o adres należący do innej domeny wysyła zapytanie do serwera znajdującego się wyżej w hierarchii. Obecnie rozproszenie systemu jest niezbędne ze względu na wielkość Internetu. Dzięki rozproszeniu, obciążenie każdego z serwerów DNS może być stałe i niewielkie, natomiast złożoność problemu ustalania adresu odpowiadającego danej nazwie - może być liniowa w zależności od długości adresu, a zatem logarytmiczna w zależności od liczby nazw w sieci (gdzie podstawa logarytmu może być duża). Istnieje ponad 200 domen najwyższego rzędu (TLD) i każdy adres w Internecie należy do jednej z nich (bądź do ich subdomen). Zarządzaniem tymi domenami zajmują się ICANN (Internet Corporation for Assigned Names and Numbers) i IANA (Internet Assigned Numbers Authority). Istnieją dwie kategorie domen TLD: rodzajowe (generic) - zależne od zastosowania, w tym:.com,.org,.info oraz narodowe (countries), jak np.:.pl,.eu,.ru,.uk. Delegacja to mechanizm przekazywania zapytań do bardziej kompetentnego serwera DNS. Np. przy zapytaniu o scalak.ics.p.lodz.pl serwer domeny pl deleguje zapytanie do serwera domeny lodz.pl ten z kolei do p.lodz.pl itd. (rzeczywista realizacja delegacji różnić, np. pewne kroki mogą być pominięte ze względu na cacheowanie adresów wykonywane przez niektóre serwery DNS). Utworzenie nowej subdomeny polega na dodaniu przez zarządcę domeny wpisu określającego co najmniej dwa serwery DNS dla tworzonej subdomeny. ICANN koordynuje jedynie przydział domen najwyższego poziomu - np. zarządcą domeny.pl jest Naukowa i Akademicka Sieć Komputerowa. Możemy wyróżnić dwa rodzaje zapytań DNS: iteracyjne - od serwera wymagane jest jedynie podanie najlepszej dostępnej mu w danej chwili odpowiedzi, przy czym nie musi on już łączyć się z innymi serwerami. Przykładowo wiarygodny serwer domeny org nie musi znać adresu IP komputera scalak.ics.p.lodz.pl, podaje więc najlepszą znaną mu w tej chwili odpowiedź, czyli adresy serwerów autorytarnych dla domeny lodz.pl. Kolejne iteracje polegają na odpytywaniu wskazywanych kolejno serwerów przez samego klienta, aż do uzyskania ostatecznej odpowiedzi. rekurencyjne - zmusza serwer do znalezienia wymaganej informacji lub zwrócenia wiadomości o błędzie. Ogólną zasadą jest, że zapytania od resolvera (programu, który wysyła zapytania do serwerów DNS) do serwera są typu rekurencyjnego, czyli resolver oczekuje podania od razu przez serwer adresu IP poszukiwanego hosta. Wykonywanie zapytań rekurencyjnych pozwala wszystkim uczestniczącym serwerom zapamiętać odwzorowanie na potrzeby przyszłych takich samych zapytań (DNS caching), co podnosi efektywność systemu, lecz zwiększa obciążenie serwerów wysokiego rzędu. PSK: Grzegorz Graczyk i Paweł Tarasiuk 2 / 9

3 Rekordy DNS (z uwzględnieniem IP w wersji 6). Poniższa tabela zawiera opis kilku najpopularniejszych rodzajów rekordów DNS: Oznaczenie Nazwa Wyjaśnienie A AAAA CNAME LOC MX PTR NS SOA SRV TXT rekord adresu (address record) rekord adresu IPv6u (IPv6 address record) rekord nazwy kanonicznej (canonical name record) rekord lokacji (location record) rekord wymiany poczty (mail exchange record) rekord wskaźnika (pointer record) rekord serwera nazw (name server record) rekord adresu startowego uwierzytelnienia (start of authority record) rekord usługi (service record) rekord tekstowy (text record) Mapuje nazwę domeny DNS na adres IPv4 (32 bity). Mapuje nazwę domeny DNS na adres IPv6 (128 bitów). Ustanawia alias nazwy domeny. Wszystkie wpisy DNS oraz subdomeny są poprawne także dla aliasu. Pozwala określić geograficzną lokalizację związaną z nazwą domeny. Mapuje nazwę domeny DNS na nazwę serwera poczty oraz jego priorytet. Mapuje adres IPv4 lub IPv6 na nazwę kanoniczną hosta. Określenie rekordu PTR dla nazwy hosta (hostname) w domenie in-addr.arpa (IPv4), bądź ip6.arpa (IPv6), który odpowiada adresowi IP, pozwala na implementację odwrotnej translacji adresów DNS (reverse DNS lookup). Mapuje nazwę domenową na listę serwerów DNS dla tej domeny. Ustala serwer DNS dostarczający autorytatywne informacje o domenie internetowej, łącznie z jej parametrami (np. TTL). Pozwala na zawarcie dodatkowych informacji dotyczących lokalizacji danej usługi, którą udostępnia serwer wskazywany przez adres DNS. Pozwala dołączyć dowolny tekst do rekordu DNS. Rekord ten może być użyty np. do implementacji specyfikacji Sender Policy Framework. Pełną listę można znaleźć w oficjalnym spisie sporządzonym przez organizację IANA: Pojęcie strefy, strefa a domena, strefy zwykłe i odwrotne. Serwer nazw udostępnia zazwyczaj informacje o tylko pewnej części przestrzeni nazw - właśnie ta część nazywa się strefą zwykłą. W momencie, kiedy znamy adres IP komputera a chcemy uzyskać jego nazwę kanoniczna, musimy posłużyć się tzw. odwzorowaniem odwrotnym. W początkowym etapie odbywa się ono w oparciu o plik hosts i polega na sprawdzeniu, czy plik ten nie zawiera reguł opisujących analizowany adres. Jeżeli wynik tego poszukiwania okaże się negatywny, wtedy zaczyna się problem, gdyż nie jest możliwe przeszukiwanie kolejnych serwerów DNS pod kątem zawierania reguł opisujących posiadany adres. W celu umożliwienia takiej operacji stworzono specjalną domenę in-addr.arpa, zawierającą adresy IP wszystkich hostów zapisane w odwrotnej notacji kropkowej. I tak adresowi odpowiada nazwa in-addr.arpa. Tego typu nazwy są łączone z nazwami kanonicznymi odpowiednich hostów, o ile posiadają one rekord PTR. PSK: Grzegorz Graczyk i Paweł Tarasiuk 3 / 9

4 Rodzaje serwerów DNS, plik strefowy, całkowite i przyrostowe transfery stref, serwery autorytatywne i nieautorytatywne, serwery buforujące. Można wyróżnić następujące podstawowe typy serwerów DNS: Root server - Przechowuje informacje o wszystkich domenach najwyższego poziomu (TLD) w sieci Internet. Informacja o hostach jest zbierana z tych domen. Zatem na przykład root server nie zna w ogóle lokalnej subdomeny ics.p.lodz.pl, lecz poprzez przeprowadzenie zapytania dla komputera z innej strefy (name server query) root server może stwierdzić miarodajnie o istnieniu danego hosta w tej subdomenie. Master server - Jest miarodajny dla całego obszaru bieżącej domeny, oraz prowadzi bazy danych dla całej strefy. Istnieją dwa rodzaje serwerów typu master: primary master server i secondary master server. Może się zdarzyć, że serwer pełni rolę master server jednocześnie dla kilku domen - dla jednych jako primary, dla innych jako secondary master server. Każda domena powinna posiadać przynajmniej dwa serwery master, z których jednym z nich musi być primary master server. Serwery zapasowe mogą pracować jako serwery z kopią zapasową, w razie gdyby serwer główny był przeładowany, uszkodzony bądź w trakcie konserwacji. Caching server - Serwer buforujący. Wszystkie serwery master prowadzą spamiętywanie (cache) informacji które otrzymują, co skutkuje poprawą wydajności i szybkości obsługi. Dzieje się tak aż do zdezaktualizowania danych. Wygasanie określone jest w polu TTL, które jest zawsze dołączane do danych dostarczanych serwerowi. Ono właśnie określa czas w jakim informacje tracą aktualność. Serwery buforujące nie maja pełnomocnictw dla żadnej strefy, a w związku z tym nie zarządzają żadnymi bazami danych. Mogą natomiast odpowiadać poprzez wysyłanie zapytań do innych serwerów posiadających takie pełnomocnictwa, a dane z zapytać przechowywać na później (aż do wyczerpania ich daty ważności). Fowrarding server - serwerem przekierowań może być każdy serwer w Internecie. Może nim być również serwer master lub serwer buforujący. Głównym zadaniem forwarderów jest przeprowadzanie rekursywnych zapytań, które nie mogły zostać rozwiązane lokalnie. Serwer przekierowań ma pełny dostęp do Internetu, przez co jest w stanie otrzymać każdą informację (nieosiągalna w lokalnych serwerach buforujących) od root serwerów. Ponieważ serwery przekierowań otrzymują wiele zgłoszeń od serwerów slave, wskazane jest u nich posiadanie większego bufora lokalnego niż mają serwery slave. Dzięki takiemu rozwiązaniu wszystkie hosty w domenie korzystają ze wspólnego, większego bufora, co powoduje redukcję całkowitej liczby zgłoszeń i przesyłania ich poza Internet, do root serverów. Pozwala to zmniejszyć stan obciążenia sieci oraz komputerów. Slave server - Z uwagi na brak bezpośredniego dostępu do Internetu, serwer slave nie może bezpośrednio kontaktować się np.z root serverami, aby uzyskać informację niedostępną w lokalnym systemie. Zamiast tego, slave server wysyła zapytania do wszystkich serwerów przekierowań wyszczególnionych w swoim pliku konfiguracyjnym. Wysyłane są one aż do otrzymania informacji, lub wyczerpania listy forwarderów. W miarę jak serwery slave żądają nowych informacji do forwarderów, forwardery mają coraz intensywniej wykorzystany bufor. System DNS umożliwia podział obszaru nazw domen na strefy, w których są przechowywane informacje o nazwach jednej lub kilku domenach DNS. Dla każdej nazwy domeny DNS zawartej w strefie, strefa staje się autorytatywnym źródłem informacji o tej domenie. Ze względu na PSK: Grzegorz Graczyk i Paweł Tarasiuk 4 / 9

5 ważną role, jaka strefy odgrywają w systemie DNS, pożądane jest, aby były dostępne z kilku serwerów DNS w sieci. Takie rozwiązanie zapewnia dostępność i odporność na uszkodzenia przy rozwiązywaniu zapytań o nazwy. W przeciwnym razie, jeśli jest używany jeden serwer, który przestanie odpowiadać, kwerendy o nazwy zawarte w tej strefie mogą zakończyć się niepowodzeniem. Aby dana strefa mogła być obsługiwana przez dodatkowe serwery, niezbędne są transfery strefy, które pozwalają replikować i synchronizować wszystkie kopie strefy na każdym serwerze skonfigurowanym do roli hosta strefy. Serwer dokonujący całkowitego transferu strefy, robi to aby uzyskać i zreplikować kopie pełnego zestawu rekordów zasobów strefy. Dzieje się to w sytuacji gdy podłączany jest np. nowy serwer pomocniczy. Przyrostowe transfery stref są opisane w specyfikacji RFC gdy jakaś część rekordu strefy zmieni się, w celu uaktualnienia innych serwerów DNS nie jest wysyłany cały rekord strefy, lecz tylko jego zmieniony fragment. Serwery autorytatywne i nieutorytatywne można tłumaczyć to na serwery wiarygodne co do informacji jakie udzielają, i serwery których informacje mogą być zdezaktualizowane. Działanie klienta (resolvera) DNS, plik hosts. Resolver DNS to program (bądź funkcja w obrębie programu), który wysyła zaptania do serwera DNS, w celu uzyskania informacji na temat znanych mu rekordów w systemie DNS. Gdy istnieje potrzeba ustalenia IP komputera na podstawe danej nazwy domenowej, postępowanie można opisać jakościowo w następujący sposób: 1. Resolver przeszukuje lokalny plik hosts na wypadek istnienia w nim reguły opisującej daną domenę. 2. Wysyłane jest zapytanie do serwera DNS. 3. Serwer DNS wysyła zapytanie do jednego z root serverów. 4. Root server odpowiada, podając zarządcę danej domeny najwyższego rzędu (TLD). 5. Serwer DNS wysyła zapytanie do wskazanego w ten sposób zarządcy. 6. W odpowiedzi, serwer DNS otrzymuje informację o serwerze zarządzającym konkretną subdomeną. 7. Po uzyskaniu ostatecznej informacji serwer DNS wysyłą odpowiedź do resolvera działającego w naszym systemie. Serwery DNS posiadają bufor (cache), dzięki czemu adres którego dotyczyło zapytanie jest zapamiętywany i przy kolejnym zapytaniu o ten sam adres (które zazwyczaj jest zupełnie prawdopodobne) nie wysyła zapytań według wyżej opisanego schematu, lecz pomija jego niektóre elementy na podstawie tego, co zapamiętał (może nawet zapamiętać wszystko i od razu odpowiedzieć z pamięci, nie komunikując się już z innymi serwerami). Skraca to czas odpowiedzi, lecz stwarza ryzyko deaktualizacji informacji z bufora na temat zapamiętanych adresów. Aby ograniczyć szkodliwość tego zjawiska, czas przechowywania informacji w buforze jest określany za pomocą TTL. Komunikacja resolvera z serwerem, oraz - między serwerami odbywa się za pomocą protokołu UDP. Część praktyczna Znaleźć listę domen TLD. Oficjalna lista domen TLD udostępniona przez IANA znajduje się pod adresem: PSK: Grzegorz Graczyk i Paweł Tarasiuk 5 / 9

6 Dostępny jest także oficjalny plik tekstowy z samą listą domen w formacie ASCII, dostosowane do analizy z poziomu programów, także udostępniony przez IANA: Prykład użycia: wget -q -O /dev/stdout tail -n+2 grep -ci "^edu$" Teoretycznie możnaby uzyskać tą listę za pomocą transferu strefy z jednego z głównych serwerów DNS. Ich konfiguracja (w celach bezpieczeństwa) uniemożliwia wykonanie tej operacji bez autoryzacji. Zbadać ustawienia klienta DNS na własnym stanowisku korzystając zarówno z narzędzi Panelu Sterowania Windows, jak i polecenia ipconfig. Ustalić adres dowolnego, publicznie dostępnego serwera DNS i zmodyfikować konfigurację klienta DNS tak, aby korzystał on z tego właśnie serwera. Konfiguracja serwera za pomocą panelu sterowania jest identyczna jak konfiguracja połączenia sieciowego (opisanego w poprzednim sprawozdaniu). W wypadku użycia konsoli możemy zaoszczędzić sporo czasu, gdyż wyświetlenie i zmiana serwerów dns jest możliwa za pomocną powłoki netsh. W kontekście netsh interface ip możemy użyć poleceń: show dns set dns " Local Area Connection " static Za pomocą programów dig, host, nslookup (do wyboru): a) ustalić nazwy domenowe i odpowiadające im adresy IP wszystkich komputerów SZSK PŁ zarejestrowanych w domenie p.lodz.pl (nazwy zawierające łańcuch znaków zsk), b) znaleźć 2 dowolne komputery, jeden należący do dowolnej domeny na terenie Europy (może być na terenie Polski) oraz drugi należący do domeny spoza Europy (najlepiej z kraju egzotycznego) i uzyskać o nich wszystkie dostępne informacje w systemie DNS (rekordy wszystkich typów zawarte w DNS). Pierwszą rzeczą jaką należy ustalić są serwery autorytatywne dla domeny zsk.p.lodz.pl. Niestety blokują one transfer strefy, zatem możemy się ograniczyć jedynie do pobrania informacji o samej domenie: lodz.pl zsk.p. lodz.pl any ; <<>> DiG P2.1 lodz.pl zsk.p. lodz.pl any ; (1 server found ) ;; global options : printcmd ;; Got answer : ;; ->> HEADER <<- opcode : QUERY, status : NOERROR, id: ;; flags : qr aa rd ra; QUERY : 1, ANSWER : 9, AUTHORITY : 0, ADDITIONAL : 4 ;; QUESTION SECTION : ; zsk.p. lodz.pl. IN ANY ;; ANSWER SECTION : zsk.p. lodz.pl. 60 IN SOA zsko. zsk.p. lodz.pl. PSK: Grzegorz Graczyk i Paweł Tarasiuk 6 / 9

7 dnsadmin. zsk. p. lodz. pl zsk.p. lodz.pl. 60 IN MX 10 zskl. zsk.p. lodz.pl. zsk.p. lodz.pl. 60 IN MX 20 zsku. zsk.p. lodz.pl. zsk.p. lodz.pl. 60 IN NS cc1.p. lodz.pl. zsk.p. lodz.pl. 60 IN NS zskl. zsk.p. lodz.pl. zsk.p. lodz.pl. 60 IN NS zsko. zsk.p. lodz.pl. zsk.p. lodz.pl. 60 IN NS zsku. zsk.p. lodz.pl. zsk. p. lodz. pl. 60 IN TXT " Zaklad Sieci Komputerowych Instytutu Informatyki PL" zsk.p. lodz.pl. 60 IN TXT "v= spf1 +a: zskl. zsk.p. lodz. pl +a: zsku. zsk.p. lodz.pl mx +a:smtp -ext -sj -1. cisco. com +a :smtp -ext -sj -2. cisco. com ~ all " ;; ADDITIONAL SECTION : zskl. zsk.p. lodz.pl. 60 IN A zsku. zsk.p. lodz.pl. 60 IN A cc1.p. lodz.pl IN A zsko. zsk.p. lodz.pl. 60 IN A Możemy również wykonać transfer strefy z wyższego poziomu i odnaleźć w niej adresy domeny zsk.p.lodz.pl. Oferuje to jednak dopiero serwer dns5.man.p.lodz.pl (dns dla lodz.pl), więc nie spodziewamy się dużej liczby wyników: man. lodz.pl p. lodz.pl axfr grep zsk.p. lodz.pl wrs. ftims.p. lodz.pl IN CNAME wrs. ftims. zsk.p. lodz.pl. zsk.p. lodz.pl IN NS cc1.p. lodz.pl. zsk.p. lodz.pl IN NS zsko. zsk.p. lodz.pl. plzsk. zsk.p. lodz.pl IN A zskl. zsk.p. lodz.pl IN A zskn. zsk.p. lodz.pl IN A zsko. zsk.p. lodz.pl IN A zsku. zsk.p. lodz.pl IN A zskl.p. lodz.pl IN CNAME zskl. zsk.p. lodz.pl. zskn.p. lodz.pl IN CNAME zskn. zsk.p. lodz.pl. zsku.p. lodz.pl IN CNAME zsku. zsk.p. lodz.pl. Nie jest to jednak pełna lista domen dostępnych wewnątrz domeny zsk.p.lodz.pl - brak tu przykładowo (który jest rozwiązywany jako CNAME zskl.zsk.p.lodz.pl). Jednym z ciekawszych adresów o jakie możemy zapytać jest adres google.com. W odpowiedzi uzyskujemy 4 typy odpowiedzi: SOA, MX, NS oraz A. dig google. com any ; <<>> DiG P2.1 <<>> google. com any ;; global options : printcmd ;; Got answer : ;; ->> HEADER <<- opcode : QUERY, status : NOERROR, id: ;; flags : qr rd ra; QUERY : 1, ANSWER : 15, AUTHORITY : 0, ADDITIONAL : 0 ;; QUESTION SECTION : ; google. com. IN ANY ;; ANSWER SECTION : google. com IN SOA ns1. google. com. dns - admin. google. com google. com. 416 IN MX 400 google. com. s9b2. psmtp. com. google. com. 416 IN MX 300 google. com. s9b1. psmtp. com. google. com. 416 IN MX 100 google. com. s9a1. psmtp. com. google. com. 416 IN MX 200 google. com. s9a2. psmtp. com. google. com. 265 IN A google. com. 265 IN A PSK: Grzegorz Graczyk i Paweł Tarasiuk 7 / 9

8 google. com. 265 IN A google. com. 265 IN A google. com. 265 IN A google. com. 265 IN A google. com IN NS ns2. google. com. google. com IN NS ns4. google. com. google. com IN NS ns3. google. com. google. com IN NS ns1. google. com. dig hamachi. cc any ; <<>> DiG P2.1 <<>> hamachi. cc any ;; global options : printcmd ;; Got answer : ;; ->> HEADER <<- opcode : QUERY, status : NOERROR, id: ;; flags : qr rd ra; QUERY : 1, ANSWER : 8, AUTHORITY : 0, ADDITIONAL : 0 ;; QUESTION SECTION : ; hamachi.cc. IN ANY ;; ANSWER SECTION : hamachi.cc IN TXT "v= spf1 mx :3 amlabs. com ip4 : ip4 : /24 ip4 : /24 ip4 : /24 ip4 : /24 ip4 : ip4 : include : salesforce. com - all " hamachi.cc IN MX 5 mail2.3 amlabs. com. hamachi. cc IN MX 10 mail. remotelyanywhere. com. hamachi. cc IN SOA ns2.3 amlabs. com. hostmaster.3 amlabs. net hamachi.cc. 300 IN A hamachi.cc. 300 IN A hamachi.cc IN NS ns2.3 amlabs. com. hamachi.cc IN NS ns3.3 amlabs. com. Zbadać, na jaki adres zostanie rozwiązana nazwa localhost. Ustalić położenie pliku hosts i stwierdzić, czy jego obecność jest niezbędna dla poprawnego rozwiązywania nazwy localhost. Umieścić w pliku hosts dowolne przypisanie nazwa / adres i sprawdzić, czy jest ono wykorzystywane. Localhost domyślnie jest rozwiązywane jako ewentualnie ::1 w wypadku IPv6. Plik hosts znajduje się w katalogu /etc (który pod windowem znajduje się w windows/system32/drivers). W wypadku systemu windows nie jest on konieczny by rozwiązać poprawnie domenę localhost. System linux wymaga tego wpisu, jednak serwery DNS poprawnie odpowiadają na zapytanie o localhost (podając jedynie adres IPv4). Za pomocą polecenia ipconfig wyczyścić zawartość pamięci podręcznej (cache) klienta DNS. ipconfig ipconfig ipconfig / displaydns / flushdns / displaydns Wykonanie tych poleceń czyści pamięć cache a także potwierdza poprawność wykonania. Pierwsze polecenie wyświetli wszystkie zapamiętane domeny. Wykonanie 3 polecenia powinno wyśtwielić tylko domeny zdefiniowane w pliku /etc/hosts. PSK: Grzegorz Graczyk i Paweł Tarasiuk 8 / 9

9 Bibliografia 1. Karol Krysiak, Sieci komputerowe. Kompendium., Wydanie II, Helion Peter Norton, W sercu PC, Helion Różne hasła z angielskiej oraz polskiej wikipedii. PSK: Grzegorz Graczyk i Paweł Tarasiuk 9 / 9