LaboratoriumpodstawsiecikomputerowychZadanie2 Grupalaboratoryjna 15 Grupadziekańska 2 Semestr 4 Rokakademicki 2009/10 Kierunek Informatyka Data 2010-03-03

(1)

150875

numer indeksu

Grzegorz Graczyk

imie i nazwisko

151021

numer indeksu

Paweł Tarasiuk

imie i nazwisko

Data 2010-03-03

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ę drze- wiastą. 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 (In- ternet 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. pew- ne 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 Aka- demicka 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 autorytar- nych 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 wiado- moś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 oczeku- je 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.

(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 rekord adresu

(address record) Mapuje nazwę domeny DNS na adres IPv4 (32 bity).

AAAA rekord adresu IPv6u

(IPv6 address record) Mapuje nazwę domeny DNS na adres IPv6 (128 bitów).

CNAME rekord nazwy kanonicznej (canonical name record)

Ustanawia alias nazwy domeny. Wszystkie wpisy DNS oraz subdomeny są poprawne także dla aliasu.

LOC rekord lokacji

(location record)

Pozwala określić geograficzną lokalizację związaną z nazwą domeny.

MX rekord wymiany poczty (mail exchange record)

Mapuje nazwę domeny DNS na nazwę serwera poczty oraz jego priorytet.

PTR rekord wskaźnika

(pointer record)

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).

NS rekord serwera nazw (name server record)

Mapuje nazwę domenową na listę serwerów DNS dla tej domeny.

SOA

rekord adresu startowego uwierzytelnienia (start of authority record)

Ustala serwer DNS dostarczający autorytatywne informacje o domenie internetowej, łącznie z jej parametrami (np. TTL).

SRV rekord usługi

(service record)

Pozwala na zawarcie dodatkowych informacji dotyczących lokalizacji danej usługi, którą udostępnia serwer wskazywany przez adres DNS.

TXT rekord tekstowy

(text record)

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:

http://www.iana.org/assignments/dns-parameters/.

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 po- czą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ę negatyw- ny, 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 127.0.0.1 odpowiada nazwa 1.0.0.127.in-addr.arpa.

Tego typu nazwy są łączone z nazwami kanonicznymi odpowiednich hostów, o ile posiadają one rekord PTR.

(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 reduk- cję 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 zawar- tej w strefie, strefa staje się autorytatywnym źródłem informacji o tej domenie. Ze względu na

(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ę niepowodze- niem. 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 sytu- acji gdy podłączany jest np. nowy serwer pomocniczy. Przyrostowe transfery stref są opisane w specyfikacji RFC 1995 - 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 praw- dopodobne) 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 odpo- wiedzieć 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:

(6)

http://www.iana.org/domains/root/db/

Dostępny jest także oficjalny plik tekstowy z samą listą domen w formacie ASCII, dostoso- wane do analizy z poziomu programów, także udostępniony przez IANA:

http://data.iana.org/TLD/tlds-alpha-by-domain.txt Prykład użycia:

wget -q http://data.iana.org/TLD/tlds-alpha-by-domain.txt -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ń:

s h o w dns

set dns " L o c a l A r e a C o n n e c t i o n " s t a t i c 1 9 2 . 1 6 8 . 0 . 2 0 0

Za pomocą programów dig, host, nslookup (do wyboru): a) ustalić nazwy do- menowe i odpowiadające im adresy IP wszystkich komputerów SZSK PŁ za- rejestrowanych 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 tere- nie 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. Nie- stety blokują one transfer strefy, zatem możemy się ograniczyć jedynie do pobrania informacji o samej domenie:

dig @ c c 1 . p . l o d z . pl zsk . p . l o d z . pl any

; < < > > DiG 9.5.1 - P2 .1 < < > > @ c c 1 . p . l o d z . pl zsk . p . l o d z . pl any

; (1 s e r v e r f o u n d )

;; g l o b a l o p t i o n s : p r i n t c m d

;; Got a n s w e r :

;; - > > HEADER < < - o p c o d e : QUERY , s t a t u s : NOERROR , id : 1 6 9 2 1

;; f l a g s : qr aa rd ra ; Q U E R Y : 1 , A N S W E R : 9 , A U T H O R I T Y : 0 , A D D I T I O N A L : 4

;; Q U E S T I O N S E C T I O N :

; zsk . p . l o d z . pl . IN ANY

;; A N S W E R S E C T I O N :

zsk . p . l o d z . pl . 60 IN SOA z s k o . zsk . p . l o d z . pl .

(7)

d n s a d m i n . zsk . p . l o d z . pl . 2 0 1 0 0 2 2 3 0 1 1 0 8 0 0 1 8 0 0 6 0 4 8 0 0 30

zsk . p . l o d z . pl . 60 IN MX 10 z s k l . zsk . p . l o d z . pl .

zsk . p . l o d z . pl . 60 IN MX 20 z s k u . zsk . p . l o d z . pl .

zsk . p . l o d z . pl . 60 IN NS cc1 . p . l o d z . pl .

zsk . p . l o d z . pl . 60 IN NS z s k l . zsk . p . l o d z . pl .

zsk . p . l o d z . pl . 60 IN NS z s k o . zsk . p . l o d z . pl .

zsk . p . l o d z . pl . 60 IN NS z s k u . zsk . p . l o d z . pl .

zsk . p . l o d z . pl . 60 IN TXT " Z a k l a d S i e c i K o m p u t e r o w y c h I n s t y t u t u I n f o r m a t y k i PL "

zsk . p . l o d z . pl . 60 IN TXT " v = s p f 1 + a : z s k l . zsk . p . l o d z . pl + a : z s k u . zsk . p . l o d z . pl mx + a : smtp - ext - sj -1. c i s c o . com + a

: smtp - ext - sj -2. c i s c o . com ~ all "

;; A D D I T I O N A L S E C T I O N :

z s k l . zsk . p . l o d z . pl . 60 IN A 2 1 2 . 5 1 . 2 2 0 . 3

z s k u . zsk . p . l o d z . pl . 60 IN A 2 1 2 . 5 1 . 2 2 0 . 2

cc1 . p . l o d z . pl . 8 6 4 0 0 IN A 2 1 2 . 5 1 . 2 0 7 . 6 7

z s k o . zsk . p . l o d z . pl . 60 IN A 2 1 2 . 5 1 . 2 2 0 . 1 2

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:

dig @ d n s 5 . man . l o d z . pl p . l o d z . pl a x f r | g r e p zsk . p . l o d z . pl

wrs . f t i m s . p . l o d z . pl . 8 6 4 0 0 IN C N A M E wrs . f t i m s . zsk . p . l o d z . pl .

zsk . p . l o d z . pl . 8 6 4 0 0 IN NS cc1 . p . l o d z . pl .

zsk . p . l o d z . pl . 8 6 4 0 0 IN NS z s k o . zsk . p . l o d z . pl . p l z s k . zsk . p . l o d z . pl . 8 6 4 0 0 IN A 2 1 2 . 5 1 . 2 2 0 . 4

z s k l . zsk . p . l o d z . pl . 8 6 4 0 0 IN A 2 1 2 . 5 1 . 2 2 0 . 3 z s k n . zsk . p . l o d z . pl . 8 6 4 0 0 IN A 2 1 2 . 5 1 . 2 2 0 . 5 z s k o . zsk . p . l o d z . pl . 8 6 4 0 0 IN A 2 1 2 . 5 1 . 2 2 0 . 1 2 z s k u . zsk . p . l o d z . pl . 8 6 4 0 0 IN A 2 1 2 . 5 1 . 2 2 0 . 2

z s k l . p . l o d z . pl . 8 6 4 0 0 IN C N A M E z s k l . zsk . p . l o d z . pl . z s k n . p . l o d z . pl . 8 6 4 0 0 IN C N A M E z s k n . zsk . p . l o d z . pl . z s k u . p . l o d z . pl . 8 6 4 0 0 IN C N A M E z s k u . zsk . p . l o d z . pl .

Nie jest to jednak pełna lista domen dostępnych wewnątrz domeny zsk.p.lodz.pl - brak tu przy- kładowo www.zsk.p.lodz.pl (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 g o o g l e . com any

; < < > > DiG 9.5.1 - P2 .1 < < > > g o o g l e . com any

;; f l a g s : qr rd ra ; Q U E R Y : 1 , A N S W E R : 15 , A U T H O R I T Y : 0 , A D D I T I O N A L : 0

; g o o g l e . com . IN ANY

g o o g l e . com . 8 6 2 8 0 IN SOA ns1 . g o o g l e . com . dns - a d m i n . g o o g l e . com . 1 4 1 1 1 0 0 7 2 0 0 1 8 0 0 1 2 0 9 6 0 0 300

g o o g l e . com . 416 IN MX 400 g o o g l e . com . s 9 b 2 . p s m t p . com .

g o o g l e . com . 416 IN MX 300 g o o g l e . com . s 9 b 1 . p s m t p . com .

g o o g l e . com . 416 IN MX 100 g o o g l e . com . s 9 a 1 . p s m t p . com .

g o o g l e . com . 416 IN MX 200 g o o g l e . com . s 9 a 2 . p s m t p . com .

g o o g l e . com . 265 IN A 2 0 9 . 8 5 . 1 3 5 . 1 4 7

g o o g l e . com . 265 IN A 2 0 9 . 8 5 . 1 3 5 . 1 0 6

(8)

g o o g l e . com . 265 IN A 2 0 9 . 8 5 . 1 3 5 . 1 0 5

g o o g l e . com . 265 IN A 2 0 9 . 8 5 . 1 3 5 . 1 0 3

g o o g l e . com . 265 IN A 2 0 9 . 8 5 . 1 3 5 . 9 9

g o o g l e . com . 265 IN A 2 0 9 . 8 5 . 1 3 5 . 1 0 4

g o o g l e . com . 2 1 4 3 0 7 IN NS ns2 . g o o g l e . com .

dig h a m a c h i . cc any

; < < > > DiG 9.5.1 - P2 .1 < < > > h a m a c h i . cc any

;; f l a g s : qr rd ra ; Q U E R Y : 1 , A N S W E R : 8 , A U T H O R I T Y : 0 , A D D I T I O N A L : 0

; h a m a c h i . cc . IN ANY

h a m a c h i . cc . 2 1 6 0 0 IN TXT " v = s p f 1 mx :3 a m l a b s . com ip4 : 8 3 . 2 1 6 . 3 3 . 1 2 ip4 : 6 3 . 2 0 9 . 2 5 1 . 0 / 2 4 ip4 : 7 2 . 5 . 7 6 . 0 / 2 4 ip4 : 7 7 .

2 4 2 . 1 9 2 . 0 / 2 4 ip4 : 6 9 . 2 5 . 2 0 . 0 / 2 4 ip4 : 6 4 . 2 5 . 8 7 . 4 2 ip4 : 8 3 . 2 1 6 . 3 4 . 1 6 2 i n c l u d e : s a l e s f o r c e . com - all "

h a m a c h i . cc . 2 1 6 0 0 IN MX 5 m a i l 2 .3 a m l a b s . com .

h a m a c h i . cc . 2 1 6 0 0 IN MX 10 m a i l . r e m o t e l y a n y w h e r e . com . h a m a c h i . cc . 2 1 6 0 0 IN SOA ns2 .3 a m l a b s . com . h o s t m a s t e r .3 a m l a b s . net . 2 0 0 6 0 7 3 4 0 4 4 3 2 0 0 3 6 0 0 6 0 4 8 0 0 2 1 6 0 0

h a m a c h i . cc . 300 IN A 7 4 . 2 0 1 . 7 4 . 4 5

h a m a c h i . cc . 300 IN A 6 9 . 2 5 . 2 0 . 3 5

h a m a c h i . cc . 2 1 6 0 0 IN NS ns2 .3 a m l a b s . com .

h a m a c h i . cc . 2 1 6 0 0 IN NS ns3 .3 a m l a b s . 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 127.0.0.1 ewentualnie ::1 w wypadku IPv6.

Plik hosts znajduje się w katalogu /etc (który pod windowem znajduje się w windows/sys- tem32/drivers). W wypadku systemu windows nie jest on konieczny by rozwiązać poprawnie

”domenę” localhost. System linux wymaga tego wpisu, jednak serwery DNS poprawnie odpo- wiadają na zapytanie o localhost (podając jedynie adres IPv4).

Za pomocą polecenia ipconfig wyczyścić zawartość pamięci podręcznej (cache) klienta DNS.

i p c o n f i g / d i s p l a y d n s i p c o n f i g / f l u s h d n s i p c o n f i g / d i s p l a y d n s

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.

(9)

Bibliografia

1. Karol Krysiak, Sieci komputerowe. Kompendium., Wydanie II, Helion 2005.

2. Peter Norton, W sercu PC, Helion 2003.

3. Różne hasła z angielskiej oraz polskiej wikipedii.