[ Pobierz całość w formacie PDF ]
.Otrzymuj¹c odpowiedŸ od serwera nazw, klient zazwyczaj zwraca uwagê czy jestona autorytatywna — to znaczy, w przypadku problemów z [osi¹gniêciem]rozwi¹zanego adresu hosta.Problem powstaje gdy serwer nazw udzielanieautorytatywnej odpowiedzi dla domeny w której posiada pe³nomocnictwa.Zwyklewskazuje to na pomy³kê we wpisie lub inny b³¹d danych strefy.Poni¿sze podrozdzia³y – „Trafienia pamiêci podrêcznej” i „Chybienia pamiêcipodrêcznej” przedstawiaj¹ i opisuj¹ bardziej szczegó³owo proces buforowaniawyników.Trafienia pamiêci podrêcznejJeœli odpowiedŸ szukana przez klienta znajduje siê w lokalnej pamiêcipodrêcznej serwera nazw, w transakcji pomiêdzy klientem a serwerem zachodzi[sekwencja] przedstawiona na rys.5.6.Rys.5.6 OdpowiedŸ na zapytanie klienta z pamiêci podrêcznej serwera nazwClientKlientQueryZapytanieAnswerOdpowiedŸServerSerwerCachePamiêæ podrêcznaSekwencja [numerowana] z rys.5.6 wygl¹da nastêpuj¹co:Klient wysy³a zapytanie do serwera nazw.Serwer nazw sprawdza lokaln¹ pamiêæ podrêczn¹.Jeœli serwer nazw posiada odpowiedŸ w pamiêci podrêcznej, zwraca odpowiedŸbezpoœrednio do klienta.Chybienia pamiêci podrêcznejJeœli odpowiedzi szukanej przez klienta nie ma w lokalnej pamiêci podrêcznejserwera nazw, w transakcji pomiêdzy klientem a serwerem zachodzi [sekwencja]przedstawiona na rys.5.7.Rys.5.7 OdpowiedŸ na zapytanie klienta z serwera autorytatywnegoClientKlientQueryZapytanieAnswerOdpowiedŸLocal ServerSerwer lokalnyCachePamiêæ podrêcznaServerSerwerSekwencja [numerowana] z rys.5.6 wygl¹da nastêpuj¹co:Klient wysy³a zapytanie do serwera nazw.Serwer nazw sprawdza lokaln¹ pamiêæ podrêczn¹.Jeœli odpowiedŸ nie znajduje siêw niej, serwer musi szukaæ informacji gdzie indziej.Serwer nazw (zale¿nie od konfiguracji) wysy³a zapytanie do serwera poziomug³Ã³wnego i otrzymuje odnoœnik do serwera autorytatywnego w domenie którejdotyczy zapytanie.Po otrzymaniu odpowiedzi z serwera autorytatywnego lokalny serwer klientaumieszcza odpowiedŸ w pamiêci podrêcznej i przesy³a j¹ do klienta.Czas ¿ycia (TTL)TTL jest [timerem] który mówi serwerowi nazw, przez jak d³ugi czas odskontaktowania siê z serwerem autorytatywnym odpowiedŸ jest uznawana za wa¿n¹.Jak powiedziano w rozdziale 4, TTL mo¿e byæ ustawiany dla poszczególnychrekordów lub jako wartoœæ domyœlna pola M-TTL (minimalny czas ¿ycia) wrekordzie SOA domeny.Jeœli TTL pojedynczego rekordu ustawiony jest na wartoœæinn¹ ni¿ domyœlna M-TTL, ka¿dy nastêpny rekord bêdzie posiada³ taki sam TTLdopóki inny rekord nie wróci wyraŸnie do wartoœci M-TTL.Jeœli wartoœæ TTLwynosi zero, klient wie, ¿e nie mo¿e sk³adowaæ wyniku w pamiêci podrêcznej.Sposób wykorzystania TTL jest bardzo prosty.Gdy lokalny serwer u¿ytkownikaotrzymuje zapytanie rekurencyjne o informacjê której jeszcze nie posiada, musipoprzez [ci¹g dzia³añ] otrzymaæ odpowiedŸ od autorytatywnego serwera wkonkretnej domenie.Po otrzymaniu odpowiedzi serwer lokalny zapisuje j¹ wpamiêci podrêcznej, na przypadek zapytania przez innego lokalnego hosta o têsam¹ informacjê.TTL okreœla, przez jak d³ugi czas lokalny serwer nazwprzetrzymuje odpowiedŸ, któr¹ otrzyma³ i zapisa³ w pamiêci podrêcznej.Powygaœniêciu TTL, lokalny serwer usuwa dane z pamiêci podrêcznej i jeœli otrzymakolejne zapytanie o nie, musi ponownie skontaktowaæ siê z autorytatywnymserwerem nazw.Jeœli wartoœæ TTL wynosi zero, odpowiedŸ nie jest buforowana adane uznane s¹ za wa¿ne jedynie dla bie¿¹cej transakcji.Jeœli TTL jest ró¿nyod zera, informacja jest buforowana i u¿ywana do udzielania nieautorytatywnychodpowiedzi.Proces zapytaniaZajmiemy siê tu ponownie ogólnym przetwarzaniem zapytania, lecz tym razemumiejscawiaj¹c je w ca³oœciowym obrazie, zamiast koncentrowaæ siê jedynie nask³adni komunikatu czy dzia³aniach i odpowiedzialnoœci serwera DNS.Rekurencyjne zapytania DNSZapytania rekurencyjne zmuszaj¹ serwer DNS do wziêcia na siebie ca³ego ciê¿aruuzyskania autorytatywnej odpowiedzi w imieniu klienta.Przedstawia to rys.5.8,w którym klient, pc.acme.com, wysy³a zapytanie rekurencyjne do serwera DNS,acme.com.Rys.5.8 Aby rozwi¹zaæ niektóre zg³oszenia klientów, potrzebne s¹ zarównozapytania rekurencyjne jak iteracyjneacme.com DNS serverSerwer DNS acme.com(forwards to ISP first (.)(w pierwszej kolejnoœci przekazuje zapytanie do dostawcy us³ug aby skorzystaæ zjego pamiêci podrêcznej)Query 1, 2, 3, 4, 5Zapytanie 1, 2,.ResponseOdpowiedŸInitial recursive query (.)Pierwsze zapytanie iteracyjne o adres host1.wielkafirma.com wys³ane zostaje doserwera DNS acme.compc.acme.com DNS client (.)Klient DNS (resolwer) pc.acme.comroot domain DNS serverSerwer DNS domeny poziomu g³Ã³wnegocom domain (.)Serwer DNS domeny combigcompany.com (.)Serwer DNS [domeny] wielkafirma.comns.myisp.com (ISP) (.)Serwer DNS ns.mojdostawca.com (dostawcy us³ug internetowych)interactive queries to (.)Interaktywne zapytania [wysy³ane] do innych serwerów DNS„.” (root)„.” (domena g³Ã³wna)Na rysunku 5.8 serwer DNS acme.com po przyjêciu ¿¹dania zapytaniarekurencyjnego od pc.acme.com sam staje siê iteracyjnym klientem-resolweremwobec czterech innych serwerów DNS.W momencie gdy serwer DNS wielkafirma.com udziela odpowiedzi autorytatywnej,acme.com przekazuje j¹ do pc.acme.com, który do koñca rozwi¹zuje zapytanie.Jeœli z jakiegoœ powodu zwrócona zostaje odpowiedŸ [nieautorytatywn¹],rozwi¹zanie nie jest uznane za ostateczne, chyba ¿e klient jest z niegozadowolony.Po otrzymaniu czegokolwiek poza odpowiedzi¹ autorytatywn¹, klientmo¿e skorzystaæ z dodatkowych zapytañ, na przyk³ad skierowanych do innychserwerów DNS które dostêpne s¹ w jego konfiguracji.Gdyby acme.com odmówi³ obs³ugi ¿¹dania zapytania rekurencyjnego z pc.acme
[ Pobierz całość w formacie PDF ]