DNS

DNS ( anglicky  Domain Name System  "domain name system") je počítačově distribuovaný systém pro získávání informací o doménách . Nejčastěji se používá k získání IP adresy z názvu hostitele (počítače nebo zařízení), k získání informací o směrování pošty a/nebo serverových hostitelů pro protokoly v doméně ( záznam SRV ).

Distribuovaná databáze DNS je podporována hierarchií serverů DNS interagujících přes specifický protokol .

Základem DNS je myšlenka hierarchické struktury jmen a zón . Každý server odpovědný za jméno může přenést odpovědnost za další část domény na jiný server (z administrativního hlediska - na jinou organizaci nebo osobu), což vám umožňuje přiřadit odpovědnost za relevanci informací serverům různých organizace (lidé) zodpovědné pouze za „svou“ část doménového jména.

Od roku 2010 systém DNS zavádí kontroly integrity dat nazývané DNS Security Extensions ( DNSSEC ). Přenášená data nejsou šifrována, ale jejich pravost je ověřena kryptografickými metodami. Implementovaný standard DANE zajišťuje přenos spolehlivých kryptografických informací ( certifikátů ) pomocí DNS používaných k navazování bezpečných a bezpečných spojení mezi transportní a aplikační vrstvou.

Klíčové vlastnosti DNS

DNS má následující vlastnosti:

• Rozdělení administrativy . Různí lidé nebo organizace jsou zodpovědní za různé části hierarchické struktury.
• Distribuce úložiště informací . Každý síťový uzel musí nutně ukládat pouze ta data, která jsou zahrnuta v jeho oblasti odpovědnosti , a (případně) adresy kořenových serverů DNS .
• Ukládání informací do mezipaměti . Uzel může ukládat určité množství dat mimo svou oblast odpovědnosti, aby se snížilo zatížení sítě.
• Hierarchická struktura , ve které jsou všechny uzly sloučeny do stromu a každý uzel může buď samostatně určovat práci následujících uzlů, nebo je delegovat (přenášet) na jiné uzly.
• Rezervace . Několik serverů (obvykle) je odpovědných za ukládání a údržbu svých uzlů (zón), fyzicky i logicky oddělených, což zajišťuje bezpečnost dat a pokračování práce, i když jeden z uzlů selže.

DNS je důležitý pro provoz internetu , protože informace o IP adrese hostitele jsou potřebné pro připojení k hostiteli a pro lidi je snazší zapamatovat si abecední (obvykle smysluplné) adresy než posloupnost čísel. V některých případech to umožňuje použití virtuálních serverů, jako jsou servery HTTP, které je rozlišují podle názvu požadavku. Zpočátku se převod mezi doménou a IP adresou prováděl pomocí speciálního textového souboru hosts , který byl centrálně zkompilován a automaticky odeslán na každý ze strojů v jeho lokální síti. S růstem webu vznikla potřeba účinného, ​​automatizovaného mechanismu, kterým se stal DNS.

DNS vyvinul Paul Mokapetris v roce 1983 ; původní popis pracovních mechanismů je obsažen v RFC 882 a RFC 883 . V roce 1987 vydání RFC 1034 a RFC 1035 změnilo specifikaci DNS a zrušilo RFC 882 , RFC 883 a RFC 973 .

Další funkce

• podpora dynamických aktualizací
• ochrana dat ( DNSSEC ) a transakce ( TSIG )
• podpora různých typů informací

Historie

Použití jednoduššího a lépe zapamatovatelného názvu místo číselné adresy hostitele je z éry ARPANET . Stanford Research Institute (nyní SRI International ) udržoval textový soubor HOSTS.TXT, který mapoval názvy hostitelů na číselné adresy počítačů v síti ARPANET . Údržbu číselných adres, nazývaných seznam přidělených čísel, měl na starosti Jon Postel z Institutu informační vědy (ISI) University of Southern California, jehož tým úzce spolupracoval s NII [1] .

Adresy byly přiděleny ručně. Aby uživatelé požádali o název hostitele a adresu a přidali počítač do hlavního souboru, kontaktovali během pracovní doby telefonicky Informační centrum sítě SRI (NIC), které provozuje Elisabeth Feinler .

Na počátku 80. let bylo udržování jediné centralizované hostitelské tabulky pomalé a těžkopádné a rostoucí síť potřebovala automatický systém pojmenování, který by se vypořádal s technickými a personálními problémy. Postel si dal za úkol vypracovat kompromis mezi pěti konkurenčními návrhy k vyřešení problému, který nastolil Paul Mokapetris. Mokapetris místo toho vytvořil koncept hierarchického systému doménových jmen.

Pracovní skupina IETF zveřejnila původní specifikace v RFC 882 a RFC 883 v listopadu 1983.

V roce 1984 čtyři studenti UC Berkeley , Douglas Terry, Mark Painter, David Riggle a Songnian Zhou, napsali první verzi jmenného serveru BIND (Berkeley Internet Name Daemon) . V roce 1985 Kevin Dunlap z DEC výrazně přepracoval implementaci DNS. Mike Karel, Phil Almquist a Paul Vixey od té doby BIND podporují. Na počátku 90. let byl BIND portován na platformu Windows NT . Je rozšířený zejména na unixových systémech a stále je nejrozšířenějším DNS softwarem na internetu.

V listopadu 1987 byly přijaty specifikace DNS - RFC 1034 a RFC 1035 . Od té doby byly přijaty stovky RFC , které upravují a doplňují DNS.

Bezpečnostní problémy

Zpočátku nebyly obavy o bezpečnost při vývoji softwaru DNS nebo jakéhokoli softwaru, který měl být nasazen na raném internetu, hlavními důvody, protože síť nebyla otevřena široké veřejnosti. Růst internetu v komerčním sektoru v 90. letech však změnil požadavky na bezpečnostní opatření na ochranu integrity dat a ověřování uživatelů.

Útočníci objevili a zneužili několik zranitelností. Jedním z takových problémů je otrava mezipaměti DNS , při které jsou data šířena do cachovacích překladačů pod záminkou, že jde o autoritativní zdrojový server, čímž dochází k znečištění datového úložiště potenciálně falešnými informacemi a dlouhými daty vypršení platnosti (čas do života). Následně mohou být požadavky z legitimních aplikací přesměrovány na síťové hostitele ovládané útočníkem.

Odpovědi DNS nebyly dříve kryptograficky podepsány, což umožňovalo různé možnosti útoku. Modern Domain Name Security Extensions ( DNSSEC ) upravují DNS a přidávají podporu pro kryptograficky podepsané odpovědi. Další rozšíření, jako je TSIG, přidávají podporu pro kryptografickou autentizaci mezi důvěryhodnými partnery a běžně se používají k autorizaci zónových přenosů nebo operacím dynamických aktualizací.

Některá doménová jména lze použít k dosažení efektů spoofingu. Například paypal.com a paypa1.com jsou různé názvy, ale uživatelé je nemusí být schopni rozlišit v GUI v závislosti na zvoleném písmu uživatelem. V mnoha fontech vypadají písmeno l a číslo 1 velmi podobně nebo dokonce identicky. Tento problém je akutní v systémech, které podporují mezinárodní názvy domén, protože mnoho znakových kódů ISO 10646 lze zobrazit na typických počítačových obrazovkách. Tato chyba zabezpečení je někdy zneužívána při phishingu .

Techniky, jako je reverzní DNS s přímou validací záznamů, lze také použít k ověření výsledků DNS, ale nejsou kryptograficky platné; to nebere v úvahu možnost nahrazení směrovacích informací ( anglicky  BGP hijacking ).

Terminologie a provozní principy

Klíčové pojmy DNS jsou:

• Doména ( anglicky  domain  "area") - uzel ve stromu jmen spolu se všemi jemu podřízenými uzly (pokud existují), tj. pojmenovaná větev nebo podstrom ve stromu jmen. Struktura názvu domény odráží pořadí uzlů v hierarchii; název domény se čte zleva doprava z domén junior do domén nejvyšší úrovně (ve vzestupném pořadí důležitosti): nahoře je kořenová doména (s identifikátorem „.“ (tečka)), níže jsou domény první úrovně ( zóny domén ), pak - domény druhé úrovně, třetí atd. (například pro adresuru.wikipedia.org.je doména první úrovněorg, druhá jewikipedia, třetí jeru). DNS umožňuje nespecifikovat bod kořenové domény.
• Subdoména ( anglicky  subdomain ) - podřízená doména (napříkladwikipedia.org - subdoména doményorgaru.wikipedia.org - doménawikipedia.org). Teoreticky může být takové rozdělení hluboké až 127 úrovní a každý štítek může obsahovat až 63 znaků, dokud celková délka včetně teček nedosáhne 254 znaků. V praxi však registrátoři doménových jmen používají přísnější omezení. Pokud máte například doménu zobrazenímydomain.ru, můžete pro ni vytvořit různé subdomény zobrazenímysite1.mydomain.ruatdmysite2.mydomain.ru.
• Záznam o prostředku  je jednotka pro ukládání a přenos informací v DNS. Každý záznam prostředku má název (to znamená, že je vázán na konkrétní název domény , uzel ve stromu názvů), typ a datové pole , jejichž formát a obsah závisí na typu .
• Zóna  je součástí stromu doménových jmen (včetně záznamů o prostředcích ), hostovaná jako jedna jednotka na nějakém serveru doménových jmen ( DNS server , viz níže) a častěji - současně na několika serverech (viz níže). Účelem izolace části stromu do samostatné zóny je přenesení odpovědnosti (viz níže) za odpovídající doménu na jinou osobu nebo organizaci. Toto se nazývá delegování (viz níže). Jako připojená část stromu je i zóna uvnitř stromem. Pokud budeme jmenný prostor DNS považovat za strukturu zón a nikoli za jednotlivé hostitele / jména, dostaneme také strom; je oprávněné mluvit o rodičovských a dětských zónách, o starších a podřízených. V praxi se většina zón 0 a 1 ('.', ru, com, …) skládá z jediného uzlu, kterému jsou podřízené zóny přímo podřízeny. Ve velkých podnikových doménách (2. nebo více úrovní) někdy dochází k vytvoření dalších podřízených úrovní, aniž by byly rozděleny do podřízených zón.
• Delegování  je operace přenesení odpovědnosti za část stromu doménových jmen na jinou osobu nebo organizaci. Delegování v DNS zajišťuje distribuovanou správu a úložiště. Technicky je delegování vyjádřeno přidělením této části stromu do samostatné zóny a umístěním této zóny na serveru DNS (viz níže), který spravuje tato osoba nebo organizace. Současně jsou v nadřazené zóně zahrnuty „ lepící “ záznamy prostředků (NS a A) obsahující ukazatele na servery DNS podřízené zóny a všechny další informace související s podřízenou zónou jsou již uloženy na serverech DNS podřízené zóny . dětská zóna.
• DNS server  - specializovaný software pro obsluhu DNS a také počítač, na kterém tento software běží. DNS server může být zodpovědný za některé zóny a/nebo může předávat požadavky na upstream servery.
• DNS klient  je specializovaná knihovna (nebo program) pro práci s DNS. V některých případech se server DNS chová jako klient DNS.
• Autorita ( angl.  autoritative ) - označení umístění zóny na serveru DNS. Odpovědi serveru DNS mohou být dvou typů: autoritativní (pokud server tvrdí, že je zodpovědný za samotnou zónu) a neautoritativní ( anglicky  Non-autoritative ), kdy server zpracuje požadavek a vrátí odpověď z jiných serverů. V některých případech může server DNS místo dalšího předání požadavku vrátit hodnotu, kterou již zná (z dřívějších požadavků) (režim ukládání do mezipaměti).
• DNS dotaz ( angl.  DNS query ) - požadavek od klienta (nebo serveru) na server. Dotaz může být rekurzivní nebo nerekurzivní (viz rekurze ).

Systém DNS obsahuje hierarchii serverů DNS , která odpovídá hierarchii zón . Každá zóna je podporována alespoň jedním autoritativním DNS serverem (z anglického  autoritativní  – autoritativní), který obsahuje informace o doméně.

Název a IP adresa nejsou totožné  - jedna IP adresa může mít mnoho jmen, což vám umožňuje podporovat mnoho webových stránek na jednom počítači (říká se tomu virtuální hosting ). Platí to i obráceně – mnoho IP adres lze namapovat na stejný název: to vám umožní vytvořit load balancing .

Pro zvýšení stability systému se používá mnoho serverů obsahujících identické informace a protokol má prostředky k udržení synchronizace informací umístěných na různých serverech. Kořenových serverů je 13 , jejich adresy se prakticky nemění. [2]

Protokol DNS používá TCP - nebo UDP - port 53 k odpovědi na dotazy. Tradičně jsou požadavky a odpovědi odesílány jako jeden UDP datagram . TCP se používá, když velikost dat odpovědi překročí 512 bajtů a pro požadavky AXFR .

Rekurze

Termín rekurze v DNS odkazuje na algoritmus chování serveru DNS : „proveďte jménem klienta úplné vyhledání nezbytných informací v celém systému DNS, v případě potřeby s odkazem na jiné servery DNS“ .

DNS dotaz může být rekurzivní  – vyžadující úplné vyhledávání – a nerekurzivní (nebo iterativní ) – nevyžadující úplné vyhledávání.

Podobně může být server DNS rekurzivní (může provádět úplné vyhledávání) a nerekurzivní (nemůže provádět úplné vyhledávání). Některý software serveru DNS, jako je BIND , lze nakonfigurovat tak, aby se na některé klienty dotazoval rekurzivně a na jiné nerekurzivně .

Při odpovědi na nerekurzivní dotaz, stejně jako nemožnost nebo zákaz provádět rekurzivní dotazy, DNS server buď vrátí data o zóně, za kterou je zodpovědný , nebo vrátí chybu. Nastavení nerekurzivního serveru, kdy odpověď vrací adresy serverů, které mají více informací o požadované zóně než odpovídající server (nejčastěji adresy kořenových serverů), jsou nesprávná a takový server může být slouží k organizaci útoků DoS .

V případě rekurzivního dotazu DNS server dotazuje servery (v sestupném pořadí podle úrovně zóny v názvu), dokud nenajde odpověď nebo nezjistí, že doména neexistuje (v praxi se vyhledávání spustí od nejbližšího DNS servery na požadovaný, pokud jsou informace o nich dostupné v mezipaměti a aktuální, server se nemusí dotazovat na jiné servery DNS).

Zvažte příklad fungování celého systému.

Předpokládejme, že jsme do prohlížeče zadali adresu ru.wikipedia.org. Prohlížeč hledá shodu mezi touto adresou a IP adresou v souboru hosts . Pokud soubor neobsahuje shodu, pak se prohlížeč zeptá serveru DNS: „Jaká je IP adresa ru.wikipedia.org“? DNS server však nemusí vědět pouze nic o požadovaném názvu, ale dokonce i o celé doméně wikipedia.org. V tomto případě server kontaktuje kořenový server  – například 198.41.0.4. Tento server říká - "Nemám žádné informace o této adrese, ale vím, že 204.74.112.1 je zodpovědná za zónu org." Poté DNS server odešle svůj požadavek na 204.74.112.1, ale odpoví "Nemám žádné informace o tomto serveru, ale vím, že 207.142.131.234 je zodpovědný za zónu wikipedia.org." Nakonec je stejný požadavek odeslán na třetí DNS server a obdrží odpověď - IP adresu, která je předána klientovi - prohlížeči.

V tomto případě při překladu jména, to znamená v procesu hledání IP podle jména:

• prohlížeč odeslal rekurzivní požadavek na server DNS, který je mu znám - v reakci na tento typ požadavku musí server vrátit „hotový výsledek“, tj. IP adresu nebo prázdnou odpověď a kód chyby NXDOMAIN;
• DNS server, který přijal požadavek z prohlížeče, odeslal nerekurzivní požadavky v pořadí, na které obdržel odpovědi od jiných serverů DNS, dokud neobdržel odpověď od serveru odpovědného za požadovanou zónu;
• ostatní zmíněné DNS servery zpracovávaly požadavky nerekurzivně (a s největší pravděpodobností by nezpracovávaly požadavky rekurzivně, i kdyby takový požadavek v požadavku byl).

Někdy je možné, že požadovaný server odešle rekurzivní dotaz na „upstream“ server DNS a čeká na připravenou odpověď.

Při rekurzivním zpracování dotazů procházejí všechny odpovědi serverem DNS a ten získá příležitost uložit je do mezipaměti . Opakovaný požadavek na stejná jména obvykle nepřesahuje mezipaměť serveru , neexistují vůbec žádná volání na jiné servery. Povolený čas mezipaměti pro odpovědi přichází s odpověďmi ( pole TTL záznamu o prostředku ).

Rekurzivní požadavky vyžadují více zdrojů ze serveru (a vytvářejí více provozu), takže jsou obvykle přijímány z uzlů, které jsou vlastníkovi serveru „známé“ (poskytovatel například poskytuje možnost zadávat rekurzivní požadavky pouze svým klientům v podnikové sítě, rekurzivní požadavky jsou přijímány pouze z lokálního segmentu). Nerekurzivní dotazy jsou obvykle přijímány od všech hostitelů v síti (a smysluplnou odpověď dostávají pouze dotazy týkající se zóny hostované hostitelem, dotazy DNS pro jiné zóny obvykle vracejí adresy jiných serverů).

Reverzní DNS dotaz

DNS se primárně používá k překladu symbolických jmen na IP adresy, ale může také provádět opačný proces. K tomu se používají stávající nástroje DNS. Faktem je, že s DNS záznamem lze porovnávat různá data, včetně nějakého symbolického jména. Existuje speciální doména, in-addr.arpajejíž položky se používají k převodu IP adres na symbolická jména. Chcete-li například získat název DNS pro adresu 11.22.33.44, můžete se serveru DNS dotázat na položku 44.33.22.11.in-addr.arpaa ten vrátí odpovídající symbolický název. Opačné pořadí zápisu částí IP adresy je způsobeno tím, že v IP adresách jsou vysoké bity umístěny na začátku a v symbolických názvech DNS jsou vysoké bity (umístěné blíže ke kořenu) umístěny na konci.

DNS záznamy

DNS záznamy , neboli záznamy o zdrojích ( anglicky  resource records , RR ), jsou jednotky pro ukládání a přenos informací v DNS. Každý záznam zdroje se skládá z následujících polí [3] :

• název (NAME) – název domény, se kterou je tento záznam zdroje propojen nebo „vlastněn“,
• typ záznamu zdroje (TYPE) - definuje formát a účel tohoto záznamu zdroje,
• třída (CLASS) záznamu o prostředku; teoreticky se má za to, že DNS lze použít nejen s TCP/IP , ale také s jinými typy sítí, kód v poli class určuje typ sítě [3] ,
• TTL (Time To Live) – přípustná doba pro uložení tohoto záznamu o prostředku do mezipaměti nezodpovědného serveru DNS ,
• délka datového pole (RDLEN),
• datové pole (RDATA), jehož formát a obsah závisí na typu záznamu .

Nejdůležitější typy DNS záznamů jsou:

• A ( záznam adresy ) nebo záznam adresy spojuje název hostitele s adresou IPv4. Například dotaz na A-záznam na jméno referrals.icann.orgvrátí jeho IPv4 adresu - 192.0.34.164.
• AAAA ( záznam adresy IPv6 ) spojuje název hostitele s adresou IPv6 . Například dotaz na AAAA záznam na jméno K.ROOT-SERVERS.NETvrátí jeho IPv6 adresu - 2001:7fd::1.
• K přesměrování na jiné jméno se používá záznam CNAME ( canonical name record ) nebo kanonický záznam názvu (alias).
• MX záznam ( mail exchange ) nebo mail exchanger specifikuje mail exchange server(y) pro danou doménu.
• NS záznam ( name server ) ukazuje na DNS server pro danou doménu.
• Záznam PTR ( ukazatel [4] [5] ) je reverzní záznam DNS nebo ukazatel , který spojuje IP adresu hostitele s jeho kanonickým názvem. Dotaz domény na IP adresu hostitele v obráceném tvaru vrátí jméno ( FQDN ) tohoto hostitele (viz Reverzní dotaz DNS ). Například (v době psaní tohoto článku) pro IP adresu dotaz na záznam PTR vrátí její kanonický název . Aby se snížil objem nevyžádané pošty (spamu), mnoho serverů pro příjem e-mailů může kontrolovat záznam PTR pro hostitele, ze kterého je odesílán. V tomto případě musí záznam PTR pro adresu IP odpovídat názvu odesílajícího poštovního serveru, který se zdá být během relace SMTP .in-addr.arpa192.0.34.164164.34.0.192.in-addr.arpareferrals.icann.org
• Záznam SOA ( Start of Authority ) nebo počáteční záznam zóny označuje, na kterém serveru jsou uloženy referenční informace o této doméně, obsahuje kontaktní informace osoby odpovědné za tuto zónu, načasování (časové parametry) pro ukládání informací o zóně do mezipaměti a interakci mezi servery DNS.
• SRV-record ( server selection ) specifikuje servery pro služby, používané zejména pro Jabber a Active Directory .

Jména rezervovaných domén

RFC 2606 ( Reserved Top Level DNS Names ) definuje názvy domén, které by měly být použity jako příklady (například v dokumentaci) a také pro účely testování. Do této skupiny patří kromě example.com, example.orgaexample.net také test, invalidatd.

Mezinárodní názvy domén

Název domény se může skládat pouze z omezené sady znaků ASCII , což umožňuje zadat adresu domény bez ohledu na jazyk uživatele. ICANN schválila systém IDNA založený na Punycode , který převádí jakýkoli řetězec Unicode na platnou znakovou sadu DNS.

DNS Software

Jmenné servery:

• BIND (Berkeley Internet Name Domain) [1]
• djbdns ( DNS Daniela J. Bernsteina ) [2]
• dnsmasq [3]
• MaraDNS [4]
• NSD (Démon jmenného serveru) [5]
• PowerDNS [6]
• OpenDNS [7]
• Microsoft DNS Server (v serverových verzích operačních systémů Windows NT )
• MyDNS [8]

Viz také

• EDNS  je nový standard protokolu DNS
• Alternativní kořenové servery DNS
• OpenDNS
• Veřejné DNS společnosti Google
• Yandex.DNS
• Cybersquatting
• Typsquatting
• Dynamické DNS
• Round robin DNS  - vyrovnávání zátěže mezi identickými servery.
• ICANN
• DNSSEC
• DNS klient
• DNS server
• NSLOOKUP
• Přenos zóny DNS

Poznámky

1. ↑ IEEE annals [3b2-9] man2011030074.3d 11:54. . - 29/7/011. - Strana 74 Str.
2. ↑ Aktuální verze kořenové zóny je vždy umístěna na: ftp://ftp.internic.net/domain/named.root
3. ↑ 1 2 Domain Name System (DNS)  Aspekty IANA . Tools.ietf.org. Získáno 7. února 2019. Archivováno z originálu dne 2. srpna 2020.
4. ↑ pv mockapetris. Doménová jména - koncepty a zařízení  . Tools.ietf.org. Získáno 7. února 2019. Archivováno z originálu dne 23. června 2018.
5. ↑ pv mockapetris. Doménová jména - implementace a specifikace  (anglicky) . Tools.ietf.org. Získáno 7. února 2019. Archivováno z originálu dne 3. dubna 2019.

Odkazy

•  Adresář zdrojů DNS
• Zdroje DNS & BIND Archivovány 2. září 2006 na Wayback Machine 
• Society Circleid DNS  (anglicky)
• Vylepšení zabezpečení DNS (DNSSEC  )
• Pracovní výbor IETF pro rozšířenou specifikaci DNS (DNSEXT  )
•  Webové stránky kořenových serverů DNS
• Zobrazit DNS domény
• Katalog DNS Web Tools na dmoz.org Archivováno 13. listopadu 2018 na Wayback Machine 

Články

• Přehled diagramů a typů DNS útoků

RFC dokumenty

• RFC 1034  - Domain Names - Concepts and Facilities
• RFC 1035  - Doménová jména - Implementace a specifikace
• RFC 1912  – Běžné chyby provozu a konfigurace DNS
• RFC 1591  - Struktura a delegování systému doménových jmen
• RFC 1713  - Nástroje pro ladění DNS
• RFC 2606  – vyhrazené názvy DNS nejvyšší úrovně