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

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.”[3]).

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 „ż”. Trwają prace nad nowymi standardami odpowiadającymi DNS, które będą obsługiwać kodowanie Unicode, co pozwoli na umieszczanie w nazwach domen dowolnych znaków na przykład polskich albo chińskich równocześnie. W Polsce domeny zawierające znaki diakrytyzowane praktycznie nie występują[4].

Administracja DNS

[edytuj | edytuj kod]

DNS, jako system organizacyjny, składa się z dwóch instytucji – IANA i ICANN. Nadzorują one ogólne zasady przyznawania nazw domen i adresów IP. Nie zajmują się jednak one przydzielaniem domen poszczególnym chętnym, jedynie rozdzielają domeny najwyższego poziomu (takie jak „.pl”, „.gov”, „.com”, „.eu”) pomiędzy kraje lub wybrane organizacje i przekazują im prawa do zarządzania tymi domenami. Te mogą dalej przekazywać nadzór nad całością bądź częścią swoich domen, i tak Rząd Polski przekazuje nadzór nad domeną .pl Naukowej i Akademickiej Sieci Komputerowej, która rozdziela poddomeny w obrębie domeny .pl pomiędzy zainteresowanych. Ci z kolei mogą rozdzielać te domeny pomiędzy poszczególne komputery lub dalej swoim klientom.

W wielu krajach domena internetowa przyznana przez system DNS staje się własnością tego, kto pierwszy ją kupi. W Polsce jest ona tylko wynajmowana na określony czas. Jeżeli ktoś zrezygnuje ze swojej domeny i zwróci ją administratorowi DNS, może ona trafić w inne ręce.

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
  • Rząd USA – rejestracja i nadzór nad domenami .mil i .gov
  • GoDaddy Registry – rejestracja i nadzór nad domeną .biz[5]
  • SITA – rejestracja i nadzór nad domeną .aero[6]
  • Identity Digital – rejestracja i nadzór nad domeną .info[7]
  • VeriSign Information Services – rejestracja i nadzór nad domeną .name[8]
  • EurID – rejestracja i nadzór nad domeną .eu
  • rządy poszczególnych krajów: rejestracja i nadzór nad domenami „krajowymi”, na przykład .pl (zwykle rządy poszczególnych krajów przekazują ten nadzór wyspecjalizowanym instytucjom)

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

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)[10], .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ą, na szczycie znajduje się 13 głównych serwerów (root servers) obsługujących domeny najwyższego poziomu (TLD – top level domains), których listę z ich adresami IP można pobrać ze strony InterNIC.

Serwery najwyższego poziomu z reguły posiadają tylko odwołania do odpowiednich serwerów DNS odpowiedzialnych za domeny niższego rzędu, na przykład serwery główne (obsługujące między innymi TLD.com) wiedzą, które serwery DNS odpowiedzialne są za domenę example.com. Serwery DNS zwracają nazwę serwerów odpowiedzialnych za domeny niższego rzędu. Możliwa jest sytuacja, że serwer główny odpowiada, że dane o domenie example.com posiada serwer dns.example.com. W celu uniknięcia zapętlenia w takiej sytuacji serwer główny do odpowiedzi dołącza specjalny rekord (tak zwany glue record) zawierający także adres IP serwera niższego rzędu (w tym przypadku dns.example.com).

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[11].
  • Serwery DNS przechowują dane tylko wybranych domen.
  • Każda domena powinna mieć co najmniej 2 serwery DNS obsługujące ją, jeśli więc nawet któryś z nich będzie nieczynny, to drugi może przejąć jego zadanie[12].
  • Każda domena posiada jeden główny dla niej serwer DNS (tak zwany master), na którym to wprowadza się konfigurację tej domeny, wszystkie inne serwery obsługujące tę domenę są typu slave i dane dotyczące tej domeny pobierają automatycznie z jej serwera głównego po każdej zmianie zawartości domeny.
  • 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, przesyłanie domeny pomiędzy serwerami master i slave odbywa się protokołem TCP na porcie 53.

RFC

[edytuj | edytuj kod]

Podstawy protokołu DNS zostały opisane w 1982 roku w dokumencie RFC 819 ↓ przez Jona Postela i Zaw-Sing Su. Dokumenty z 1983 r. – RFC 882 ↓ i RFC 883 ↓ były oficjalną specyfikacją DNS aż do roku 1989. Nowa, aktualna specyfikacja DNS jest zawarta w RFC 1034 ↓ i RFC 1035 ↓.

Główne serwery DNS

[edytuj | edytuj kod]

DNS opiera się na 13 głównych serwerach, zwanych po angielsku root-servers, posiadającymi nazwy od a.root-servers.net do m.root-servers.net. Liczba ta wynika z ograniczenia rozmiaru komunikatu DNS przesyłanego w pojedynczym pakiecie UDP do 512 oktetów – tyle miejsca wystarcza na informacje o maksymalnie 13 serwerach. Ponieważ główne serwery DNS są podstawą działania Internetu i otrzymują ogromne ilości zapytań, zostały one skopiowane. Kopie głównych serwerów umieszczone są w różnych częściach świata (posiadają one te same adresy IP co serwery główne). Użytkownicy z reguły łączą się z najbliższym im serwerem. Przykładowo globalne węzły serwera k.root-servers.net zarządzanego przez organizację RIPE NCC umieszczone są w Amsterdamie, Londynie, Tokio, Delhi oraz Miami, podczas gdy jeden z jego polskich węzłów lokalnych znajduje się w Poznańskim Centrum Superkomputerowo-Sieciowym[13], a drugi w centrum przetwarzania danych Aplitt sp. z o.o. w Gdyni[14].

Rodzaje zapytań DNS

[edytuj | edytuj kod]
  • rekurencyjne
zmusza serwer do znalezienia wymaganej informacji lub zwrócenia wiadomości o błędzie. Ogólną zasadą jest, że zapytania od resolwera (program, który potrafi wysyłać zapytania do serwerów DNS) do serwera są typu rekurencyjnego, czyli resolwer oczekuje podania przez serwer adresu IP poszukiwanego hosta. Wykonywanie zapytań rekurencyjnych pozwala wszystkim uczestniczącym serwerom zapamiętać odwzorowanie (ang. DNS caching), co podnosi efektywność systemu.
  • iteracyjne
wymaga od serwera jedynie podania najlepszej dostępnej mu w danej chwili odpowiedzi, przy czym nie musi on łączyć się jeszcze z innymi serwerami. Zapytania wysyłane pomiędzy serwerami są iteracyjne, przykładowo wiarygodny 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

[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 uwierzytelniania (AA – Authoritative Answer) wskazujący, że odpowiedź została uzyskana z serwera dokonującego bezpośredniego uwierzytelnienia 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 transportowane w pakietach UDP. Każdy komunikat musi się zawrzeć w jednym pakiecie UDP (standardowo 512 oktetów, ale wielkość tę można zmieniać, pamiętając również o ustawieniu takiej samej wielkości w MTU – Maximum Transmission Unit). W innym przypadku przesyłany jest protokołem TCP i poprzedzony dwubajtową wartością określającą długość zapytania i długość odpowiedzi (bez wliczania tych dwóch bajtów). Format komunikatu DNS został zdefiniowany w RFC 1035 ↓.

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[15].

Format komunikatu DNS:

NAGŁÓWEK – (Header)
ZAPYTANIE – (Question) do serwera nazw
ODPOWIEDŹ – (Answer) zawiera rekordy będące odpowiedzią
ZWIERZCHNOŚĆ – (Authority) wskazuje serwery zwierzchnie 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 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 zapytania wysyłanego od klienta, jest przypisywany przez serwer do odpowiedzi. Wartości:
    • 0 – QUERY – standardowe zapytanie,
    • 1 – IQUERY – zapytanie zwrotne,
    • 2 – STATUS – pytanie o stan serwera,
    • 3-15 – zarezerwowane do przyszłego użytku.
  • 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 [3 bity] – zarezerwowane do przyszłego wykorzystania. Pole powinno być wyzerowane.
  • RCODE [4 bity] – (Response CODE) kod odpowiedzi. Przyjmuje wartości:
    • 0 – brak błędu,
    • 1 – błąd formatu – serwer nie potrafił zinterpretować zapytania,
    • 2 – błąd serwera – wewnętrzny błąd serwera,
    • 3 – błąd nazwy – nazwa domenowa podana w zapytaniu nie istnieje,
    • 4 – nie zaimplementowano – serwer nie obsługuje typu otrzymanego zapytania,
    • 5 – odrzucono – serwer odmawia wykonania określonej operacji, na przykład transferu strefy,
    • 6-15 – zarezerwowane do przyszłego użytku.
  • 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

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[16][17].

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 zwierzchnim 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. Wszystkie wpisy DNS oraz subdomeny są poprawne także dla aliasu.
  • 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 lub rekord adresu startowego uwierzytelnienia (ang. start of authority record) ustala 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[18] – 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. Jednak jest on dosyć skomplikowany w użytkowaniu.

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 zwierzchniego dla danej domeny i czy nie została po drodze zmieniona, a zapytania i odpowiedzi przesyłane są tekstem jawnym[19]. Wraz ze wzrostem znaczenia usług internetowych ograniczenia te stały się podstawą wielu rodzajów ataków[20].

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 zwierzchnich. 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 zwierzchni, z poprawnie odgadniętym identyfikatorem zapytania i numerem portu[19].

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

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[22].

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

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[24], 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[25].

Zobacz też

[edytuj | edytuj kod]

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. ↑ Pusty ciąg za kropką to „nazwa” domeny głównej, obejmującej całą przestrzeń nazw DNS; końcową kropkę najczęściej się pomija.
  4. ↑ Nazwy domen z polskimi znakami diakrytycznymi (IDN) [online], 24 marca 2023 [dostęp 2023-08-01] (pol.).
  5. ↑ Delegation Record for .BIZ. IANA. [dostęp 2026-09-02]. (ang.).
  6. ↑ Delegation Record for .AERO. IANA. [dostęp 2026-09-02]. (ang.).
  7. ↑ Delegation Record for .INFO. IANA. [dostęp 2026-09-02]. (ang.).
  8. ↑ IANA WHOIS: .name. IANA. [dostęp 2026-09-02]. (ang.).
  9. ↑ Root Zone Management. IANA. [dostęp 2026-09-02]. (ang.).
  10. ↑ Rafał Galiński: Domeny gov.pl w NASK. 2013-06-18. [dostęp 2013-07-02]. (pol.).
  11. ↑ Why Are There Only 13 DNS Root Name Servers?, „Lifewire” [dostęp 2018-02-23] (ang.).
  12. ↑ Co to są serwery DNS? Jak działają? [online], Jak Wybrać Hosting? [dostęp 2023-02-22] (pol.).
  13. ↑ K-root Homepage. (ang.).
  14. ↑ Created: 16 Feb 2018-Last updated: 12 Mar 2018, K-root [online], RIPE Network Coordination Centre [dostęp 2019-07-22].
  15. ↑ RFC 6891: Extension Mechanisms for DNS (EDNS(0)). RFC Editor, 2013-04. [dostęp 2026-09-02]. (ang.).
  16. ↑ RFC 2606: Reserved Top Level DNS Names. RFC Editor, 1999-06. [dostęp 2026-09-02]. (ang.).
  17. ↑ RFC 5737: IPv4 Address Blocks Reserved for Documentation. RFC Editor, 2010-01. [dostęp 2026-09-02]. (ang.).
  18. ↑ Bernhard Ager, Wolfgang Mühlbauer, Georgios Smaragdakis, Steve Uhlig, Comparing DNS Resolvers in the Wild, „Proceedings of the 10th ACM SIGCOMM Conference on Internet Measurement”, IMC '10, New York, NY, USA: ACM, 2010, s. 15–21, DOI: 10.1145/1879141.1879144, ISBN 978-1-4503-0483-2 [dostęp 2019-03-25].
  19. 1 2 3 Yazan Alshboul i inni, Domain Name System Security and Privacy: A Contemporary Survey [online], 2020 [dostęp 2026-09-02] (ang.).
  20. 1 2 Study on Domain Name System (DNS) Abuse: Technical Report [online], 2022 [dostęp 2026-09-02] (ang.).
  21. ↑ Otwarte serwery DNS – najlepszy przyjaciel ataków DDoS. CERT Polska, 2013-03-28. [dostęp 2026-09-02]. (pol.).
  22. 1 2 None of the biggest internet services are DNSSEC-enabled. SIDN, 2025-04. [dostęp 2026-09-02]. (ang.).
  23. ↑ Towards an industry best practice for DNSSEC automation. APNIC Blog, 2026-02-25. [dostęp 2026-09-02]. (ang.).
  24. ↑ RFC 7858: Specification for DNS over Transport Layer Security (TLS). RFC Editor, 2016-05. [dostęp 2026-09-02]. (ang.).
  25. ↑ RFC 8484: DNS Queries over HTTPS (DoH). RFC Editor, 2018-10. [dostęp 2026-09-02]. (ang.).

Linki zewnętrzne

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