Domain Name System

Nazwy domen

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ą (na przykład „pl.wikipedia.org.”). Łączna długość nazwy w postaci wewnętrznej, czyli wszystkich etykiet wraz z bajtami określającymi ich długość, jest ograniczona do 255 oktetów.

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

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

Nazwy bezwzględne i względne

 Zobacz też: BadWPAD.

Nazwa zakończona kropką, czyli pustą etykietą korzenia, jest nazwą bezwzględną i oznacza jeden konkretny węzeł drzewa. Nazwa bez końcowej kropki może być nazwą względną, którą lokalne oprogramowanie uzupełnia o znaną sobie domenę albo o kolejne domeny z listy przeszukiwania (ang. search list). Sposób uzupełniania nazw względnych zależy od implementacji. Ponieważ najczęściej jedną z domen na liście jest sam korzeń, wieloczłonowa nazwa względna jest zwykle po prostu nazwą pełną z pominiętą dla wygody końcową kropką.

Dozwolone znaki i nazwy IDN

 Zobacz też: Internationalized Domain Name i Punycode.

Nazwy domen mogą zawierać litery, cyfry i znak „-”, przy czym według zalecanej składni etykiety nie powinny zaczynać się ani kończyć łącznikiem. 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. Rejestr domeny .pl przyjmuje nazwy ze znakami diakrytycznymi od września 2003 roku i według NASK był pierwszym rejestrem w Europie, który to umożliwił. Takie nazwy stanowią jednak niewielki ułamek wszystkich nazw w domenie .pl.

Strefy i delegacja

Baza danych DNS jest podzielona według klas, a w obrębie klasy na strefy. Strefy powstają przez „przecięcia” drzewa nazw między sąsiednimi węzłami: każda spójna część drzewa po dokonaniu przecięć stanowi osobną strefę, a nazwa jej najwyższego węzła zwykle służy do jej oznaczania. Przecięć dokonuje się tam, gdzie jakaś organizacja chce przejąć kontrolę nad poddrzewem. Właściciel strefy może samodzielnie zmieniać jej dane, dodawać nowe gałęzie drzewa, usuwać węzły i delegować kolejne podstrefy.

Dane strefy składają się z rekordów autorytatywnych wszystkich jej węzłów, rekordów NS i SOA węzła szczytowego, rekordów NS wskazujących serwery podstref (które nie należą do danych autorytatywnych strefy nadrzędnej) oraz rekordów sklejających (ang. glue records). Te ostatnie zawierają adresy serwerów nazw podstref i są niezbędne, gdy nazwa serwera leży w delegowanej podstrefie. Gdyby domenę example.com obsługiwał serwer dns.example.com, samo wskazanie jego nazwy nie wystarczyłoby, ponieważ żeby poznać jego adres, trzeba by zapytać jego samego. Serwery strefy nadrzędnej dołączają więc do odesłania adres IP wskazanego serwera.

Każda strefa musi być dostępna na co najmniej dwóch serwerach, 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. 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. Zmiany wprowadza się na serwerze podstawowym, zwykle edytując plik strefy, a serwery zapasowe okresowo sprawdzają numer seryjny w rekordzie SOA strefy i po wykryciu zmiany pobierają jej nową kopię.

Elementy systemu

Na system składają się trzy rodzaje elementów: przestrzeń nazw wraz z przypisanymi do nazw rekordami zasobów, serwery nazw oraz resolwery. Serwer nazw przechowuje pełne informacje o pewnej części drzewa, dla której jest autorytatywny, oraz wskazania na inne serwery, prowadzące do informacji z pozostałych części drzewa. Może też buforować dane z innych stref. Resolwer to program, który na żądanie aplikacji wydobywa informacje z serwerów nazw. Zwykle jest procedurą systemową dostępną bezpośrednio dla programów użytkownika, dlatego między nim a aplikacją nie jest potrzebny żaden protokół.

Resolwer może samodzielnie podążać za odesłaniami do kolejnych serwerów albo przekazać całą pracę serwerowi obsługującemu zapytania rekurencyjne (ang. recursive resolver). Taki uproszczony resolwer (ang. stub resolver) nie potrafi sam przeprowadzić pełnego rozwiązywania nazw i potrzebuje jedynie listy adresów serwerów rekurencyjnych, zwykle zapisanej w pliku konfiguracyjnym. Takie rozwiązanie pozwala korzystać z DNS komputerom o niewielkich zasobach i skupić pamięć podręczną w jednym miejscu dla całej sieci lokalnej.

Odpowiedzi serwerów są przechowywane w pamięci podręcznej przez czas określony polem TTL rekordu, które ustala administrator strefy. Krótkie wartości TTL ograniczają buforowanie, a TTL równe zeru je wyklucza. W praktyce dla typowych hostów zaleca się wartości rzędu dni, a przed planowaną zmianą danych można TTL tymczasowo obniżyć, by skrócić okres niespójności, i po zmianie przywrócić poprzednią wartość. Pamięć podręczna wspólna dla wielu procesów, użytkowników lub komputerów jest wydajniejsza od osobnych. Na dany adres IP może wskazywać wiele różnych nazw, a pod jedną nazwą może kryć się więcej niż jeden adres IP. 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ę.

Serwery główne

 Zobacz też: Anycast.

Nie ma jednej centralnej bazy danych adresów IP i nazw. Na szczycie drzewa domen 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. Noszą one 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. 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. Listę serwerów głównych wraz z ich adresami IPv4 i IPv6 publikuje InterNIC w pliku named.root.

Trzynaście nazw nie oznacza trzynastu maszyn. Operatorzy serwerów głównych udostępniają usługę z wielu niezależnych instancji (klastrów) rozmieszczonych na wielu kontynentach, 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. Ich liczba stale rośnie: według wykazu prowadzonego przez samych operatorów w październiku 2026 roku działało ponad 2000 instancji. 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.

Rodzaje zapytań

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

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

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

Odpowiedzi na zapytania

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

Przykład rozwiązywania nazwy

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.

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.

Transport

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ść. Serwer nazw nasłuchuje na porcie 53, zarówno UDP, jak i TCP. Komunikat przesyłany datagramem 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. Połączeń, a nie datagramów, wymaga też odświeżanie zawartości stref.

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.

Format komunikatu

Format komunikatu DNS został zdefiniowany w RFC 1035, a dwa bity nagłówka – AD i CD – dodano do niego później, wraz z rozszerzeniami DNSSEC. Komunikat składa się z pięciu sekcji:

Sekcja nagłówka występuje zawsze i określa rolę całego komunikatu. 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. Nagłówek ma następującą postać:

• 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:
  • 0 – QUERY – standardowe zapytanie,
  • 1 – IQUERY – zapytanie zwrotne, uznane za przestarzałe w 2002 roku,
  • 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
• 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
• 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. Wartości przypisane w rejestrze IANA:
  • 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

 Zobacz też: DDNS.

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.

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.

Zatruwanie pamięci podręcznej

 Zobacz też: Zatruwanie DNS.

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.

Wykorzystanie w atakach odmowy usługi

 Zobacz też: Blokada usług.

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. Technika ta, określana po angielsku jako DNS amplification lub DNS reflection, jest wykorzystywana w rozproszonych atakach odmowy usługi.

Wyprowadzanie danych

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.

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.

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.

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.

DNSSEC

 Zobacz też: DNSSEC.

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.

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. Wśród domen niepodpisanych pozostają serwisy o największym ruchu.

Szyfrowanie zapytań

 Zobacz też: DNS over TLS i DNS over HTTPS.

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, 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. W 2022 roku w dokumencie RFC 9250 opisano także DNS over QUIC (DoQ), w którym komunikaty DNS przesyła się w połączeniach QUIC, domyślnie na porcie UDP 853.