Przejdź do zawartości

Domain Name System

Z Wikipedii, wolnej encyklopedii

Domain Name System (DNS, pol. system nazw domen) – hierarchiczny rozproszony system nazw, który umożliwia identyfikację usług i zasobów internetowych, pozwalając urządzeniom użytkowników końcowych na korzystanie z usług routingu internetowego i usług łączności w celu dotarcia do tych usług i zasobów[1].

Dzięki DNS nazwa mnemoniczna, na przykład pl.wikipedia.org, jest tłumaczona na odpowiadający jej adres IP, pod którym dostępny jest serwer obsługujący tę stronę.

DNS to złożony system komputerowy oraz prawny. Zapewnia z jednej strony rejestrację nazw domen internetowych i ich powiązanie z adresami IP. Z drugiej strony realizuje bieżącą obsługę komputerów odnajdujących adresy IP odpowiadające poszczególnym nazwom. Jest nieodzowny do działania prawie wszystkich usług sieci Internet[2.1].

Historia

[edytuj | edytuj kod]

Zanim powstał DNS, odwzorowania nazw komputerów na adresy utrzymywał Network Information Center w jednym pliku o nazwie HOSTS.TXT, który wszystkie komputery w sieci pobierały protokołem FTP. Rozwiązanie to przestało się skalować wraz ze wzrostem ARPANETu i wczesnego internetu. Ruch potrzebny do rozesłania nowej wersji pliku rósł proporcjonalnie do kwadratu liczby hostów, a obciążenie samego komputera NIC było znaczne. Zmieniał się przy tym charakter sieci: wieloosobowe komputery z podziałem czasu ustępowały lokalnym sieciom stacji roboczych, a organizacje, które samodzielnie zarządzały swoimi nazwami i adresami, musiały czekać na wprowadzenie zmiany w HOSTS.TXT przez NIC, zanim stała się ona widoczna dla reszty sieci. Chciały też nadać własnej przestrzeni nazw wewnętrzną strukturę[3].

Powstało wówczas kilka propozycji zarządzania przestrzenią nazw, różniących się szczegółami, ale zgodnych co do tego, że przestrzeń ta powinna być hierarchiczna, odpowiadać z grubsza strukturze organizacyjnej, a poziomy hierarchii należy rozdzielać kropką[3]. Jedną z nich był opublikowany w sierpniu 1982 roku dokument RFC 819 autorstwa Zaw-Sing Su i Jona Postela, objaśniający samą konwencję zapisu nazw – zastąpienie prostego oznaczenia komputera nazwą złożoną, czytaną od najbardziej szczegółowej części po lewej do korzenia hierarchii po prawej[4]. Projekt oparty na rozproszonej bazie danych opisano w 1983 roku w dokumentach RFC 882[5] i RFC 883[6], a po doświadczeniach z kilkoma implementacjami system przyjął postać zawartą w obowiązujących do dziś dokumentach RFC 1034[3] i RFC 1035[7] z listopada 1987 roku.

Nazwy domen

[edytuj | edytuj kod]

Rozproszona baza danych DNS jest indeksowana nazwami domen, tworzącymi drzewiastą strukturę hierarchiczną. Węzły drzewa DNS posiadają etykiety tekstowe o długości od 1 do 63 znaków: pusta etykieta o zerowej długości zarezerwowana jest dla węzła głównego. Etykiety węzłów oddzielone kropkami czytane w kierunku od węzła do korzenia drzewa tworzą pełną nazwę domenową[2.2] (na przykład „pl.wikipedia.org.”[a]).

Domena jest poddrzewem hierarchii nazw, obejmującym zbiór domen (subdomen) o wspólnym sufiksie, nazwanym tak jak węzeł na szczycie (na przykład domena funkcjonalna com.pl grupująca nazwy zakończone .com.pl). Nazwy „hostów” są nazwami domen, do których przypisana jest informacja o konkretnych urządzeniach i zazwyczaj występują w liściach drzewa DNS (czyli nie mają swoich poddomen), ale ogólnie jedna nazwa może opisywać zarówno hosta (na przykład główny serwer WWW organizacji), jak i całą domenę[2.2].

Przykładowo, wewnątrz domeny najwyższego poziomu .pl utworzono wiele domen:

  • regionalnych jak „opole.pl”, „dzierzoniow.pl” czy „warmia.pl”,
  • funkcjonalnych jak „com.pl”, „gov.pl” czy „org.pl”,
  • należących do firm, organizacji lub osób prywatnych jak „wikipedia.pl”, „zus.pl”.

Dozwolone znaki

[edytuj | edytuj kod]

Nazwy domen mogą zawierać litery, cyfry i znak „-”. W nazwach niektórych domen można używać znaków narodowych (IDN) takich jak „ą” czy „ż”. Mechanizm ten opisuje standard IDNA2008, ogłoszony w 2010 roku i zastępujący wcześniejszy IDNA2003. Nie wymaga on żadnych zmian w samym DNS, ponieważ nazwa zapisana znakami Unicode jest po stronie aplikacji przekształcana na postać złożoną wyłącznie ze znaków ASCII[8]. W Polsce domeny zawierające znaki diakrytyzowane praktycznie nie występują[9].

Administracja DNS

[edytuj | edytuj kod]

Za globalną koordynację nazw domen i adresów IP odpowiada ICANN, wykonujący tak zwane funkcje IANA. Nie jest to odrębna instytucja, lecz zestaw zadań administracyjnych, obejmujących między innymi zarządzanie strefą główną DNS. ICANN wykonuje je od 1999 roku, a w latach 2000–2016 robił to na podstawie umowy z amerykańską National Telecommunications and Information Administration. Od 1 października 2016 zadania te realizuje Public Technical Identifiers – spółka niedochodowa zawiązana w sierpniu 2016 roku jako podmiot zależny ICANN, w którym ICANN jest jedynym członkiem[10]. Koordynacja nie polega na przydzielaniu domen poszczególnym chętnym, lecz na wyznaczaniu podmiotów zarządzających domenami najwyższego poziomu (takimi jak „.pl”, „.gov”, „.com”, „.eu”) i zapisywaniu tych delegacji w bazie strefy głównej[11]. Podmiotem, któremu powierzono zarządzanie domeną .pl, jest Naukowa i Akademicka Sieć Komputerowa, rozdzielająca poddomeny w obrębie domeny .pl pomiędzy zainteresowanych[12]. Ci z kolei mogą rozdzielać te domeny pomiędzy poszczególne komputery lub dalej swoim klientom.

Rejestracja nazwy domeny nie jest nabyciem rzeczy ani prawa do niej. Regulamin NASK stanowi, że zawarcie umowy nie oznacza przyznania abonentowi jakichkolwiek praw związanych z nazwą domeny poza tymi, które wynikają wyraźnie z samej umowy, a jej przedmiotem jest usługa utrzymywania nazwy. Umowa zawierana jest na czas nieoznaczony i abonent może ją wypowiedzieć bez zachowania terminów wypowiedzenia, przy czym za wypowiedzenie uznaje się również nieuiszczenie opłaty za kolejny rok utrzymywania nazwy. Po rozwiązaniu umowy nazwa może zostać zarejestrowana przez kogo innego[13].

Instytucje administrujące DNS na świecie:

  • ICANN-IANA – nadzór ogólny nad nazewnictwem i strukturą domen najwyższego poziomu (TLD – ang. Top Level Domains), na przykład: .pl, .gov, .com
  • VeriSign Global Registry Services – rejestracja i nadzór nad domenami: .net, .com
  • Public Interest Registry – rejestracja i nadzór nad domeną .org
  • Cybersecurity and Infrastructure Security Agency (CISA) – rejestracja i nadzór nad domeną .gov[14]
  • DoD Network Information Center – rejestracja i nadzór nad domeną .mil[15]
  • GoDaddy Registry – rejestracja i nadzór nad domeną .biz[16]
  • SITA – rejestracja i nadzór nad domeną .aero[17]
  • Identity Digital – rejestracja i nadzór nad domeną .info[18]
  • VeriSign Information Services – rejestracja i nadzór nad domeną .name[19]
  • EurID – rejestracja i nadzór nad domeną .eu
  • organizacje wyznaczone dla poszczególnych krajów: rejestracja i nadzór nad domenami „krajowymi”, na przykład NASK w przypadku .pl[12]

Aktualny wykaz podmiotów zarządzających wszystkimi domenami najwyższego poziomu prowadzi IANA w bazie strefy głównej[11].

Instytucje administrujące DNS w Polsce:

  • NASK – nadzór nad domeną .pl jako całością oraz obsługa rejestrowania domen: .gov.pl (od 1 lipca 2013)[20], .com.pl, .biz.pl, .org.pl, .net.pl oraz części domen lokalnych, na przykład .waw.pl.

Techniczna strona DNS

[edytuj | edytuj kod]

Ogólny zarys

[edytuj | edytuj kod]

Podstawą technicznego systemu DNS jest ogólnoświatowa sieć serwerów przechowujących informacje na temat adresów domen. Każdy wpis zawiera nazwę oraz odpowiadającą jej wartość, najczęściej adres IP. System DNS jest podstawą dla rozwiązywania nazw hostów w Internecie.

DNS to również protokół komunikacyjny opisujący sposób łączenia się klientów z serwerami DNS. Częścią specyfikacji protokołu jest również zestaw zaleceń, jak aktualizować wpisy w bazach domen internetowych. Na świecie jest wiele serwerów DNS, które odpowiadają za obsługę poszczególnych domen internetowych. Domeny mają strukturę drzewiastą, a na jej szczycie znajduje się 13 głównych serwerów (root servers), które są serwerami autorytatywnymi dla strefy głównej i odsyłają pytających do serwerów obsługujących poszczególne domeny najwyższego poziomu (TLD – top level domains)[21]. Listę serwerów głównych wraz z ich adresami IP można pobrać ze strony InterNIC.

Serwery kolejnych poziomów hierarchii z reguły nie znają szukanego adresu, lecz odsyłają pytającego o poziom niżej. Serwery główne wiedzą, które serwery obsługują domenę com, a dopiero te wskazują serwery odpowiedzialne za domenę example.com. Jeżeli wskazany serwer nazw sam należy do delegowanej domeny – na przykład domenę example.com obsługuje dns.example.com – samo jego wskazanie nie wystarczy, ponieważ żeby poznać jego adres, trzeba by zapytać jego samego. W celu uniknięcia takiego zapętlenia serwery domeny nadrzędnej dołączają do odpowiedzi specjalny rekord (tak zwany glue record), zawierający adres IP wskazanego serwera nazw[3].

Najważniejsze cechy

[edytuj | edytuj kod]

System DNS posiada następujące cechy:

  • Nie ma jednej centralnej bazy danych adresów IP i nazw. Najważniejszych jest 13 głównych serwerów (klastrów) rozmieszczonych na wielu kontynentach[22].
  • Serwery DNS przechowują dane tylko wybranych domen.
  • Każda delegowana strefa wymaga istnienia więcej niż jednego serwera, dzięki czemu awaria jednego z nich nie odcina dostępu do nazw. Zaleca się przy tym, by serwery te znajdowały się w odległych od siebie lokalizacjach i były podłączone do sieci różnymi drogami, tak aby ani zanik zasilania, ani awaria pojedynczego łącza nie unieruchomiły ich wszystkich naraz[23].
  • Wśród serwerów autorytatywnych strefy wyróżnia się te, które są źródłem transferu strefy i na których wprowadza się jej konfigurację, oraz te, które pobierają od nich zawartość strefy. Pierwsze określa się dziś jako primary, pozostałe jako secondary, a we wcześniejszych dokumentach IETF nosiły one nazwy master i slave[24].
  • Serwery DNS mogą przechowywać przez pewien czas odpowiedzi z innych serwerów (ang. caching), a więc proces zamiany nazw na adresy IP jest często krótszy niż w podanym przykładzie.
  • Na dany adres IP może wskazywać wiele różnych nazw.
  • Czasami pod jedną nazwą może kryć się więcej niż 1 adres IP po to, aby jeśli jeden z nich zawiedzie, inny mógł spełnić jego rolę.
  • Przy zmianie adresu IP komputera pełniącego funkcję serwera WWW nie ma konieczności zmiany adresu internetowego strony, a jedynie poprawy wpisu w serwerze DNS obsługującym domenę.
  • Protokół DNS posługuje się do komunikacji serwer-klient głównie protokołem UDP, serwer pracuje na porcie numer 53, a transfer strefy między serwerami odbywa się protokołem TCP na tym samym porcie.

Główne serwery DNS

[edytuj | edytuj kod]

DNS opiera się na 13 głównych serwerach, zwanych po angielsku root-servers, noszących nazwy od a.root-servers.net do m.root-servers.net. Liczba ta ma podłoże historyczne: RFC 1035 ograniczało komunikat DNS przesyłany po UDP do 512 oktetów, a dołożenie kolejnego serwera sprawiłoby, że odpowiedź na zapytanie startowe przekroczyłaby ten rozmiar[22]. Ograniczenie to straciło na znaczeniu, odkąd serwery otrzymały również adresy IPv6, strefę główną podpisano mechanizmem DNSSEC, a rozszerzenie EDNS pozwoliło przesyłać większe komunikaty[22].

Trzynaście nazw nie oznacza trzynastu maszyn. Operatorzy serwerów głównych udostępniają usługę z wielu niezależnych instancji rozmieszczonych na świecie, wykorzystując rozsyłanie anycastowe, dzięki czemu pytający trafia do instancji najbliższej sieciowo. Pierwszy operator wdrożył tę technikę w 2002 roku, a obecnie za trzynastoma identyfikatorami stoi ponad 1500 instancji[22]. Serwer k.root-servers.net prowadzi organizacja RIPE NCC, również w oparciu o rozproszone węzły anycastowe IPv4 i IPv6, przy czym węzeł może prowadzić każda organizacja, która zgłosi się i spełni wymagania operatora[25].

Rodzaje zapytań DNS

[edytuj | edytuj kod]

Specyfikacja przewiduje dwa sposoby postępowania serwera, który otrzymał pytanie o dane spoza własnej strefy. Obsługę trybu iteracyjnego musi zapewniać każdy serwer nazw, natomiast tryb rekurencyjny pozostaje opcjonalny. Za właściwsze dla wymiany opartej na datagramach uznano przy tym podejście iteracyjne[3].

  • rekurencyjne
serwer sam prowadzi dalsze poszukiwania u kolejnych serwerów i zwraca pytającemu gotową odpowiedź albo informację o błędzie. Tak działa zwykle zapytanie wysyłane przez resolwer (program, który potrafi wysyłać zapytania do serwerów DNS) do skonfigurowanego dla niego serwera. Skorzystanie z tego trybu wymaga zgody obu stron: klient sygnalizuje swoje oczekiwanie bitem RD, a serwer bitem RA informuje, czy taką usługę świadczy. Rozwiązanie sprawdza się tam, gdzie zamiast osobnej pamięci podręcznej u każdego klienta korzystniej jest utrzymywać jedną wspólną, obsługującą ich wszystkich[3].
  • iteracyjne
serwer nie szuka za pytającego, lecz odsyła go do innego serwera, bliższego odpowiedzi, i pozostawia mu dalsze kroki. W ten sposób porozumiewają się między sobą serwery: przykładowo autorytatywny serwer domeny org nie musi znać adresu IP komputera www.pl.wikipedia.org, podaje więc najlepszą znaną mu w tej chwili odpowiedź, czyli adresy serwerów autorytatywnych dla domeny wikipedia.org[3].

Odpowiedzi na zapytania

[edytuj | edytuj kod]
  • autorytatywne – dotyczące domeny w strefie, nad którą dany serwer ma zarząd, pochodzą one bezpośrednio z bazy danych serwera; jest to pozytywna odpowiedź zwracana do klienta, która w komunikacie DNS zawiera ustawiony bit odpowiedzi autorytatywnej (AA – Authoritative Answer) wskazujący, że odpowiedź pochodzi z serwera autorytatywnego dla poszukiwanej nazwy
  • nieautorytatywne – dane, które zwraca serwer, pochodzą spoza zarządzanej przez niego strefy; odpowiedzi nieautorytatywne są buforowane poprzez serwer przez czas TTL wyrażony w sekundach, wyspecyfikowany w odpowiedzi, a następnie po upływie czasu są usuwane.

Protokół DNS

[edytuj | edytuj kod]

Zapytania i odpowiedzi DNS są najczęściej przesyłane protokołem UDP, ponieważ przy zapytaniach datagramy sprawdzają się lepiej niż połączenia - mają mniejszy narzut i dają lepszą wydajność[7]. Komunikat przesyłany tą drogą nie może przekraczać 512 oktetów, nie licząc nagłówków IP i UDP. Dłuższa odpowiedź zostaje obcięta, a serwer zaznacza to bitem TC w nagłówku, co dla pytającego jest sygnałem, by powtórzyć zapytanie protokołem TCP. Tam komunikat poprzedza dwubajtowe pole długości, podające rozmiar samego komunikatu, bez tych dwóch bajtów[7]. Połączeń, a nie datagramów, wymaga też odświeżanie zawartości stref[7]. Format komunikatu DNS został zdefiniowany w RFC 1035[7], a dwa bity nagłówka - AD i CD - dodano do niego później, wraz z rozszerzeniami DNSSEC[26].

Ograniczenie do 512 oktetów pochodzi z pierwotnej specyfikacji i w praktyce bywa obchodzone dzięki rozszerzeniu EDNS(0), opisanemu w dokumencie RFC 6891. Pozwala ono odpytującemu zadeklarować gotowość do przyjęcia większych komunikatów UDP, co ogranicza konieczność ponawiania zapytań przez TCP – ma to znaczenie zwłaszcza przy DNSSEC, gdzie odpowiedzi bywają wyraźnie większe[27].

Format komunikatu DNS:

NAGŁÓWEK – (Header)
ZAPYTANIE – (Question) do serwera nazw
ODPOWIEDŹ – (Answer) zawiera rekordy będące odpowiedzią
ZWIERZCHNOŚĆ – (Authority) wskazuje serwery autorytatywne dla domeny
DODATKOWA – (Additional) sekcja informacji dodatkowych

Forma nagłówka, który określa rolę całego komunikatu:

Sekcja nagłówka występuje zawsze. W sekcji zapytania zawsze znajduje się jedno zapytanie zawierające nazwę domenową, żądany typ danych i klasę (IN). Sekcja odpowiedzi zawiera rekordy zasobów stanowiące odpowiedź na pytanie.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
ID
QR OPCODE AA TC RD RA Z AD CD RCODE
QDCOUNT
ANCOUNT
NSCOUNT
ARCOUNT
  • ID [16 bitów] – (IDentifier) – identyfikator tworzony przez program wysyłający zapytanie; serwer przepisuje ten identyfikator do swojej odpowiedzi, dzięki czemu możliwe jest jednoznaczne powiązanie zapytania i odpowiedzi
  • QR [1 bit] – (Query or Response) – określa, czy komunikat jest zapytaniem (0) czy odpowiedzią (1)
  • OPCODE [4 bity] – określa rodzaj operacji, jest przypisywany przez serwer do odpowiedzi. Wartości przypisane w rejestrze IANA[28]:
    • 0 – QUERY – standardowe zapytanie,
    • 1 – IQUERY – zapytanie zwrotne, uznane za przestarzałe w 2002 roku[29],
    • 2 – STATUS – pytanie o stan serwera,
    • 3 – nieprzypisane,
    • 4 – NOTIFY – powiadomienie o zmianie zawartości strefy,
    • 5 – UPDATE – dynamiczna aktualizacja zawartości strefy,
    • 6 – DSO – (DNS Stateful Operations),
    • 7-15 – nieprzypisane.
  • AA [1 bit] – (Authoritative Answer) – oznacza, że odpowiedź jest autorytatywna.
  • TC [1 bit] – (TrunCation) – oznacza, że odpowiedź nie zmieściła się w jednym pakiecie UDP i została obcięta.
  • RD [1 bit] – (Recursion Desired) – oznacza, że klient żąda rekurencji – pole to jest kopiowane do odpowiedzi
  • RA [1 bit] – (Recursion Available) – bit oznaczający, że serwer obsługuje zapytania rekurencyjne
  • Z [1 bit] – zarezerwowany do przyszłego wykorzystania. Pole powinno być wyzerowane.
  • AD [1 bit] – (Authentic Data) – ustawiany w odpowiedzi przez serwer, który zweryfikował kryptograficznie zawarte w niej dane[26]
  • CD [1 bit] – (Checking Disabled) – ustawiany w zapytaniu przez klienta, który chce, by serwer pominął sprawdzanie podpisów. Serwer przepisuje ten bit do odpowiedzi[26]
  • RCODE [4 bity] – (Response CODE) kod odpowiedzi. W samym nagłówku mieszczą się wartości od 0 do 15, a kody wyższe wymagają ośmiobitowego rozszerzenia przenoszonego w rekordzie OPT mechanizmu EDNS(0) albo w rekordach TSIG i TKEY[30]. Wartości przypisane w rejestrze IANA[28]:
    • 0 – NoError – brak błędu,
    • 1 – FormErr – błąd formatu, serwer nie potrafił zinterpretować zapytania,
    • 2 – ServFail – wewnętrzny błąd serwera,
    • 3 – NXDomain – nazwa domenowa podana w zapytaniu nie istnieje,
    • 4 – NotImp – serwer nie obsługuje typu otrzymanego zapytania,
    • 5 – Refused – serwer odmawia wykonania określonej operacji, na przykład transferu strefy,
    • 6 – YXDomain – nazwa istnieje, choć nie powinna,
    • 7 – YXRRSet – zbiór rekordów istnieje, choć nie powinien,
    • 8 – NXRRSet – zbiór rekordów, który powinien istnieć, nie istnieje,
    • 9 – NotAuth – serwer nie jest autorytatywny dla strefy albo żądanie nie zostało autoryzowane,
    • 10 – NotZone – nazwa nie zawiera się w strefie,
    • 11 – DSOTYPENI – nieobsługiwany typ operacji stanowej,
    • 12-15 – nieprzypisane.
  • QDCOUNT [16 bitów] – określa liczbę wpisów w sekcji zapytania
  • ANCOUNT [16 bitów] – określa liczbę rekordów zasobów w sekcji odpowiedzi
  • NSCOUNT [16 bitów] – określa liczbę rekordów serwera w sekcji zwierzchności
  • ARCOUNT [16 bitów] – określa liczbę rekordów zasobów w sekcji dodatkowej

Transfer strefy

[edytuj | edytuj kod]

Spójność danych między serwerami autorytatywnymi tej samej strefy utrzymują trzy mechanizmy protokołu: pełny transfer strefy (AXFR), transfer przyrostowy (IXFR) oraz powiadomienie o zmianie (NOTIFY). AXFR opisano pierwotnie w RFC 1034 i RFC 1035, ale opis ten okazał się na tyle nieprecyzyjny, że implementacje musiały przyjmować własne założenia. Dokładną specyfikację zawarto dopiero w RFC 5936 z czerwca 2010 roku. Zapytanie AXFR ma postać zwykłego zapytania DNS z typem o wartości 252 i nazwą żądanej strefy, a odpowiedź składa się z jednej lub wielu wiadomości, z których pierwsza zaczyna się rekordem SOA strefy, a ostatnia kończy tym samym rekordem. Transfer odbywa się wyłącznie po TCP, ponieważ dla tej operacji istotna jest niezawodność dostarczenia i przesyłanie strefy przez UDP nie zostało zdefiniowane[31].

Możliwość ograniczenia dostępu do AXFR nie była przewidziana w pierwotnym projekcie DNS i pojawiła się jako wymaganie dopiero z czasem. Powodem bywa chęć ukrycia pełnej zawartości strefy, niekiedy wynikająca z wymogów prawnych, albo ochrona serwera przed obciążeniem. Specyfikacja zaleca, by implementacje pozwalały ograniczać transfer do wskazanych klientów, na podstawie adresów IP albo z użyciem uwierzytelniania kluczem współdzielonym TSIG, oraz by domyślna konfiguracja nie udostępniała transferu wszystkim pytającym[31].

Przykład działania systemu DNS

[edytuj | edytuj kod]

Poniższy przykład ilustruje przebieg odpytywania systemu DNS. Użytkownik wpisuje w przeglądarce stron WWW adres www.example.com; przeglądarka musi poznać adres IP serwera obsługującego tę stronę. W przykładzie wykorzystano nazwę domenową oraz adresy IP zarezerwowane na potrzeby dokumentacji[32][33].

Pobieranie adresu DNS
Wysyła Odbiera Komunikat Uwagi
Przeglądarka Serwer DNS dostawcy (192.0.2.1) Czy znasz adres IP komputera www.example.com? Przeglądarka wysyła pakiet UDP z pytaniem do serwera DNS zdefiniowanego w konfiguracji systemu operacyjnego – najczęściej jest to serwer DNS dostawcy usług internetowych.
Serwer DNS dostawcy (192.0.2.1) Główny serwer DNS Czy znasz adres IP komputera www.example.com? Serwer DNS dostawcy wysyła zapytanie do jednego z 13 serwerów głównych.
Główny serwer DNS Serwer DNS dostawcy (192.0.2.1) Nie znam, ale domenę com obsługują serwery o adresach 198.51.100.10 i 198.51.100.11. Serwer główny nie zna adresu poszukiwanego hosta, wskazuje jednak serwery domeny wyższego rzędu.
Serwer DNS dostawcy (192.0.2.1) Serwer DNS domeny „com” (198.51.100.10) Czy znasz adres IP komputera www.example.com? Serwer DNS wysyła zapytanie do jednego ze wskazanych serwerów.
Serwer DNS domeny „com” (198.51.100.10) Serwer DNS dostawcy (192.0.2.1) Nie znam, ale domenę example.com obsługują serwery o adresach 203.0.113.20 i 203.0.113.21. Serwer domeny „com” odpowiada.
Serwer DNS dostawcy (192.0.2.1) Serwer domeny „example.com” (203.0.113.20) Czy znasz adres IP komputera www.example.com? Serwer DNS wysyła zapytanie do jednego ze wskazanych serwerów.
Serwer DNS domeny „example.com” (203.0.113.20) Serwer DNS dostawcy (192.0.2.1) www.example.com ma adres IP 203.0.113.80. Serwer domeny „example.com” jest dla niej serwerem autorytatywnym i udziela odpowiedzi autorytatywnej.
Serwer DNS dostawcy (192.0.2.1) Przeglądarka www.example.com ma adres IP 203.0.113.80. Serwer DNS dostawcy przekazuje odpowiedź przeglądarce i zapamiętuje ją na czas określony wartością TTL.
Przeglądarka Serwer „www.example.com” (203.0.113.80) Transakcja pobrania strony WWW. Przeglądarka łączy się z serwerem i wyświetla otrzymaną stronę.

W rzeczywistości przebieg bywa bardziej złożony: nazwa może być aliasem (rekordem CNAME) innej nazwy, a duże serwisy stosują odwzorowanie zależne od położenia pytającego, dzięki czemu użytkownik trafia do najbliższego geograficznie centrum danych.

Typy rekordów DNS

[edytuj | edytuj kod]

Najważniejsze typy rekordów DNS(inne języki) oraz ich znaczenie:

  • rekord A lub rekord adresu IPv4 (ang. address record) mapuje nazwę domeny DNS na jej 32-bitowy adres IPv4.
  • rekord AAAA lub rekord adresu IPv6 (ang. IPv6 address record) mapuje nazwę domeny DNS na jej 128-bitowy adres IPv6.
  • rekord CNAME lub rekord nazwy kanonicznej (ang. canonical name record) ustanawia alias nazwy domeny, wskazując nazwę kanoniczną, pod którą należy szukać danych. Przy nazwie, dla której istnieje rekord CNAME, nie powinny występować inne rekordy – dzięki temu dane nazwy kanonicznej i jej aliasu nie mogą się różnić[3]. Alias obejmuje wyłącznie samą nazwę, a nie poddomeny pod nią. Do przekierowania całego poddrzewa nazw służy osobny rekord DNAME[34].
  • rekord MX lub rekord wymiany poczty (ang. mail exchange record) mapuje nazwę domeny DNS na nazwę serwera poczty oraz jego priorytet, który określa kolejność wraz ze wzrostem wartości.
  • rekord PTR lub rekord wskaźnika (ang. pointer record) mapuje adres IPv4 lub IPv6 na nazwę kanoniczną hosta. Określenie rekordu PTR dla nazwy hosta (ang. 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 (ang. reverse DNS lookup, revDNS).
  • rekord NS lub rekord serwera nazw (ang. name server record) mapuje nazwę domenową na listę serwerów DNS dla tej domeny.
  • rekord SOA (ang. start of authority record) wskazuje serwer DNS dostarczający autorytatywne informacje o domenie internetowej, łącznie z jej parametrami (na przykład TTL).
  • 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.
  • rekord TXT – rekord ten pozwala dołączyć dowolny tekst do rekordu DNS. Rekord ten może być użyty np. do implementacji specyfikacji Sender Policy Framework (SPF) lub do weryfikacji własności domeny przykładowo w usługach firmy Google.

Inne typy rekordów dostarczają informacje o położeniu hosta (na przykład rekord LOC) lub o danych eksperymentalnych.

Narzędzia

[edytuj | edytuj kod]

W systemach operacyjnych zapytania do DNS zwykle są wykonywane w sposób niewidoczny dla użytkownika przez dedykowany podsystem (ang. resolver). Do bezpośredniego odpytywania DNS na przykład w celach diagnostycznych, można się posłużyć programami nslookup, host(inne języki) lub dig(inne języki) dostępnymi w wielu systemach operacyjnych.

Konfiguracja

[edytuj | edytuj kod]

Zwykle dane o konfiguracji protokołu DNS w domowym komputerze przekazywane są przez dostawcę Internetu (ISP). Większość operatorów udostępnia w swojej sieci protokół DHCP. Dzięki niemu komputer może automatycznie pobrać konfigurację sieciową sugerowaną przez operatora, w tym adresy serwerów DNS. Adresy te z reguły – ale nie zawsze[35] – wskazują na serwery dobrane relatywnie dogodnie dla użytkowników. Kiedy system automatycznego pobierania adresów serwera DNS nie działa, można je wprowadzić ręcznie. W systemach typu uniksowego służy do tego /etc/resolv.conf, który zawiera listę serwerów DNS.

Jeżeli użytkownik chce w swojej sieci lokalnej uruchomić własny serwer DNS, może posłużyć się programem BIND.

Bezpieczeństwo

[edytuj | edytuj kod]

Protokół DNS w pierwotnej postaci nie przewidywał mechanizmów uwierzytelniania odpowiedzi ani ochrony ich poufności. Odbiorca nie ma możliwości sprawdzenia, czy otrzymana odpowiedź rzeczywiście pochodzi od serwera autorytatywnego dla danej domeny i czy nie została po drodze zmieniona, a zapytania i odpowiedzi przesyłane są tekstem jawnym[36]. Wraz ze wzrostem znaczenia usług internetowych ograniczenia te stały się podstawą wielu rodzajów ataków[37].

Zatruwanie pamięci podręcznej

[edytuj | edytuj kod]

Serwery rekurencyjne przechowują otrzymane odpowiedzi przez czas określony wartością TTL, co ogranicza liczbę zapytań kierowanych do serwerów autorytatywnych. Jeżeli napastnik zdoła umieścić w takiej pamięci sfałszowaną odpowiedź, wszyscy użytkownicy korzystający z danego serwera będą przez czas jej ważności kierowani pod wskazany przez niego adres. Atak tego rodzaju, określany jako zatruwanie pamięci podręcznej DNS (cache poisoning), polega na dostarczeniu odpowiedzi wcześniej niż serwer autorytatywny, z poprawnie odgadniętym identyfikatorem zapytania i numerem portu[36].

Wykorzystanie w atakach odmowy usługi

[edytuj | edytuj kod]

Bezpołączeniowy charakter protokołu UDP pozwala napastnikowi wysyłać zapytania z podrobionym adresem źródłowym, wskazującym na komputer ofiary; odpowiedź serwera trafia wtedy nie do pytającego, lecz do celu ataku. Ponieważ odpowiedź DNS bywa wielokrotnie większa od zapytania, uzyskuje się w ten sposób wzmocnienie ruchu – według CERT Polska nawet ponad dwudziestokrotne, co osobie dysponującej łączem 10 Mb/s pozwala wygenerować atak o wolumenie 200 Mb/s[38]. Technika ta, określana po angielsku jako DNS amplification lub DNS reflection, jest wykorzystywana w rozproszonych atakach odmowy usługi[36][37].

Wyprowadzanie danych

[edytuj | edytuj kod]

Ruch DNS jest zwykle przepuszczany przez zapory sieciowe i rzadziej niż inne protokoły poddawany szczegółowej analizie, co pozwala wykorzystać go jako ukryty kanał przesyłania informacji. Dane koduje się wówczas w etykietach nazwy domenowej kierowanej do domeny kontrolowanej przez napastnika, której serwer autorytatywny je odczytuje. Techniką tą wyprowadzano między innymi dane kart płatniczych i dane uwierzytelniające użytkowników[39].

Komunikację tego rodzaju rozpoznaje się po cechach samego zapytania. Ponieważ przeniesienie danych wymaga zapisania ich w nazwie domenowej, wskazówką jest nietypowo duża liczba etykiet w nazwie oraz znaczna długość zapytania, przy czym im dłuższe zapytanie, tym większe prawdopodobieństwo, że służy przesyłaniu danych. Kryteria te stosuje się łącznie, ponieważ nazwy o zbliżonej budowie występują także w zapytaniach kierowanych do sieci dostarczania zawartości[40].

Zapytania o podobnej budowie generuje również część legalnego oprogramowania instalowanego na stacjach roboczych, na przykład program antywirusowy ESET. Rozstrzygnięciu, czy obserwowane zapytania pochodzą od takiej aplikacji, służy wzbogacenie obserwacji o dane rejestrowe odpytywanej domeny – w przywołanym przypadku rejestr WHOIS wskazuje jako jej serwery nazw maszyny należące do producenta oprogramowania[40].

Sam zapis dziennika serwera nazw może przy tym nie wystarczyć, ponieważ nie obejmie zapytań kierowanych przez zainfekowany komputer bezpośrednio do serwerów zewnętrznych. Z tego względu zaleca się obserwowanie również samego ruchu sieciowego[40].

DNSSEC

[edytuj | edytuj kod]

Odpowiedzią na brak uwierzytelniania jest zestaw rozszerzeń DNSSEC, opierający się na podpisach cyfrowych i łańcuchu zaufania prowadzącym od strefy głównej. Strefę tę podpisano w 2010 roku, a obecnie ponad 90% domen najwyższego poziomu obsługuje DNSSEC[41].

Wdrożenie pozostaje jednak nierównomierne. Według pomiarów APNIC w 2025 roku walidację podpisów prowadziły serwery obsługujące około 36% użytkowników internetu, natomiast podpisanych było jedynie około 7% delegacji domen niższego poziomu[42]. Wśród domen niepodpisanych pozostają serwisy o największym ruchu[41].

Szyfrowanie zapytań

[edytuj | edytuj kod]

DNSSEC zapewnia integralność odpowiedzi, nie chroni jednak poufności – treść zapytań pozostaje widoczna dla podmiotów pośredniczących w transmisji. Opracowano w związku z tym protokoły szyfrujące komunikację między klientem a serwerem rekurencyjnym: DNS over TLS (DoT), opisany w 2016 roku w dokumencie RFC 7858 i korzystający z portu 853[43], oraz DNS over HTTPS (DoH), opisany w 2018 roku w dokumencie RFC 8484, w którym zapytania przesyłane są jako żądania HTTPS na porcie 443[44].

Zobacz też

[edytuj | edytuj kod]

Uwagi

[edytuj | edytuj kod]
  1. ↑ Pusty ciąg za kropką to „nazwa” domeny głównej, obejmującej całą przestrzeń nazw DNS; końcową kropkę najczęściej się pomija.

Przypisy

[edytuj | edytuj kod]
  1. ↑ Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa na terytorium Unii, zmieniająca rozporządzenie (UE) nr 910/2014 i dyrektywę (UE) 2018/1972 oraz uchylająca dyrektywę (UE) 2016/1148 (dyrektywa NIS 2) (CELEX: 32022L2555).
  2. Paul Albirz, Cricket Liu: DNS i BIND. Warszawa: Wydawnictwo RM, 1999. ISBN 83-87216-88-7.
    1. ↑ S. 9.
    2. 1 2 S. 11–16.
  3. 1 2 3 4 5 6 7 8 P.V. Mockapetris, Domain names - concepts and facilities, STD 13, RFC 1034, IETF, listopad 1987, DOI: 10.17487/RFC1034, ISSN 2070-1721, OCLC 943595667 (ang.).
  4. ↑ Zaw-Sing Su, Jon Postel, The Domain Naming Convention for Internet User Applications, RFC 819, IETF, sierpień 1982, DOI: 10.17487/RFC0819, ISSN 2070-1721, OCLC 943595667 (ang.).
  5. ↑ P.V. Mockapetris, Domain names: Concepts and facilities, RFC 882, IETF, listopad 1983, DOI: 10.17487/RFC0882, ISSN 2070-1721, OCLC 943595667 (ang.).
  6. ↑ P.V. Mockapetris, Domain names: Implementation specification, RFC 883, IETF, listopad 1983, DOI: 10.17487/RFC0883, ISSN 2070-1721, OCLC 943595667 (ang.).
  7. 1 2 3 4 5 P.V. Mockapetris, Domain names - implementation and specification, STD 13, RFC 1035, IETF, listopad 1987, DOI: 10.17487/RFC1035, ISSN 2070-1721, OCLC 943595667 (ang.).
  8. ↑ Internationalized Domain Names in Applications (IDNA): Protocol, RFC 5891, IETF, sierpień 2010, DOI: 10.17487/RFC5891, ISSN 2070-1721, OCLC 943595667 (ang.).
  9. ↑ Nazwy domen z polskimi znakami diakrytycznymi (IDN) [online], 24 marca 2023 [dostęp 2023-08-01].
  10. ↑ Public Technical Identifiers (PTI). ICANN. [dostęp 2026-09-23]. (ang.).
  11. 1 2 Root Zone Management. IANA. [dostęp 2026-09-02]. (ang.).
  12. 1 2 Delegation Record for .PL. IANA. [dostęp 2026-09-22]. (ang.).
  13. ↑ Regulamin nazw domeny .pl z 18 grudnia 2006 r. (w brzmieniu obowiązującym od 1 grudnia 2015 r.). NASK. [dostęp 2026-09-22].
  14. ↑ Delegation Record for .GOV. IANA. [dostęp 2026-09-22]. (ang.).
  15. ↑ Delegation Record for .MIL. IANA. [dostęp 2026-09-22]. (ang.).
  16. ↑ Delegation Record for .BIZ. IANA. [dostęp 2026-09-02]. (ang.).
  17. ↑ Delegation Record for .AERO. IANA. [dostęp 2026-09-02]. (ang.).
  18. ↑ Delegation Record for .INFO. IANA. [dostęp 2026-09-02]. (ang.).
  19. ↑ IANA WHOIS: .name. IANA. [dostęp 2026-09-02]. (ang.).
  20. ↑ Rafał Galiński: Domeny gov.pl w NASK. 2013-06-18. [dostęp 2013-07-02].
  21. ↑ M. Blanchet, L-J. Liman, DNS Root Name Service Protocol and Deployment Requirements, BCP 40, RFC 7720, IETF, grudzień 2015, DOI: 10.17487/RFC7720, ISSN 2070-1721, OCLC 943595667 (ang.).
  22. 1 2 3 4 RSSAC FAQ. ICANN. [dostęp 2026-09-22]. (ang.).
  23. ↑ R. Elz, M. Patton, Selection and Operation of Secondary DNS Servers, BCP 16, RFC 2182, IETF, lipiec 1997, DOI: 10.17487/RFC2182, ISSN 2070-1721, OCLC 943595667 (ang.).
  24. ↑ P. Hoffman, K. Fujiwara, DNS Terminology, BCP 219, RFC 9499, IETF, marzec 2024, DOI: 10.17487/RFC9499, ISSN 2070-1721, OCLC 943595667 (ang.).
  25. ↑ K-root. RIPE NCC. [dostęp 2026-09-22]. (ang.).
  26. 1 2 3 Roy Arends, Rob Austein, Matt Larson, Dan Massey, Scott Rose, Protocol Modifications for the DNS Security Extensions, RFC 4035, IETF, marzec 2005, DOI: 10.17487/RFC4035, ISSN 2070-1721, OCLC 943595667 (ang.).
  27. ↑ J. Damas, M. Graff, Extension Mechanisms for DNS (EDNS(0)), STD 75, RFC 6891, IETF, kwiecień 2013, DOI: 10.17487/RFC6891, ISSN 2070-1721, OCLC 943595667 (ang.).
  28. 1 2 Domain Name System (DNS) Parameters. IANA. [dostęp 2026-09-20]. (ang.).
  29. ↑ D. Lawrence, Obsoleting IQUERY, RFC 3425, IETF, listopad 2002, DOI: 10.17487/RFC3425, ISSN 2070-1721, OCLC 943595667 (ang.).
  30. ↑ Domain Name System (DNS) IANA Considerations, BCP 42, RFC 6895, IETF, kwiecień 2013, DOI: 10.17487/RFC6895, ISSN 2070-1721, OCLC 943595667 (ang.).
  31. 1 2 E. Lewis, A. Hoenes, DNS Zone Transfer Protocol (AXFR), RFC 5936, IETF, czerwiec 2010, DOI: 10.17487/RFC5936, ISSN 2070-1721, OCLC 943595667 (ang.).
  32. ↑ D. Eastlake 3rd, A. Panitz, Reserved Top Level DNS Names, BCP 32, RFC 2606, IETF, czerwiec 1999, DOI: 10.17487/RFC2606, ISSN 2070-1721, OCLC 943595667 (ang.).
  33. ↑ M. Cotton, L. Vegoda, IPv4 Address Blocks Reserved for Documentation, RFC 5737, IETF, styczeń 2010, DOI: 10.17487/RFC5737, ISSN 2070-1721, OCLC 943595667 (ang.).
  34. ↑ W. Wijngaards, DNAME Redirection in the DNS, RFC 6672, IETF, czerwiec 2012, DOI: 10.17487/RFC6672, ISSN 2070-1721, OCLC 943595667 (ang.).
  35. ↑ Bernhard Ager, Wolfgang Mühlbauer, Georgios Smaragdakis, Steve Uhlig, Comparing DNS resolvers in the wild, [w:] ICM'10: proceedings of the 2010 ACM Internet Measurement Conference; November 1 – 3, 2010, Melbourne, Australia, ACM Press, listopad 2010, s. 15–21, DOI: 10.1145/1879141.1879144, ISBN 978-1-4503-0483-2 (ang.).
  36. 1 2 3 Aminollah Khormali, Jeman Park, Hisham Alasmary, Afsah Anwar, David Mohaisen, Domain Name System Security and Privacy: A Contemporary Survey, 27 czerwca 2020, DOI: 10.48550/arXiv.2006.15277 [dostęp 2026-09-22] (ang.).
  37. 1 2 Jan Bayer i inni, Study on Domain Name System (DNS) Abuse: Technical Report, 2022, DOI: 10.2759/473317 [dostęp 2026-09-22] (ang.).
  38. ↑ Otwarte serwery DNS – najlepszy przyjaciel ataków DDoS. CERT Polska, 2013-03-28. [dostęp 2026-09-02].
  39. ↑ Asaf Nadler, Avi Aminov, Asaf Shabtai, Detection of Malicious and Low Throughput Data Exfiltration Over the DNS Protocol, „Computers & Security”, 80, 2019, s. 36–53 [dostęp 2026-09-23] (ang.).
  40. 1 2 3 Adam Ziaja: Threat hunting using DNS firewalls and data enrichment. REDTEAM.PL, 2019-08. [dostęp 2026-09-23]. (ang.).
  41. 1 2 None of the biggest internet services are DNSSEC-enabled. SIDN, 2025-04. [dostęp 2026-09-02]. (ang.).
  42. ↑ Towards an industry best practice for DNSSEC automation. APNIC Blog, 2026-02-25. [dostęp 2026-09-02]. (ang.).
  43. ↑ Z. Hu, L. Zhu, J. Heidemann, D. Wessels, Specification for DNS over Transport Layer Security (TLS), RFC 7858, IETF, maj 2016, DOI: 10.17487/RFC7858, ISSN 2070-1721, OCLC 943595667 (ang.).
  44. ↑ Patrick McManus, DNS Queries over HTTPS (DoH), RFC 8484, IETF, październik 2018, DOI: 10.17487/RFC8484, ISSN 2070-1721, OCLC 943595667 (ang.).

Linki zewnętrzne

[edytuj | edytuj kod]
Źródło: „https://pl.wikipedia.org/w/index.php?title=Domain_Name_System&oldid=80860242”