Domain Name System

Z Multimediaexpo.cz

(Přesměrováno)
Broom icon.png Tento článek potřebuje úpravy. Můžete Multimediaexpo.cz pomoci tím, že ho vylepšíte.
Jak by měly články vypadat, popisují stránky Vzhled a styl a Encyklopedický styl. 		Broom icon.png
Internetové protokoly
Aplikační vrstva
Transportní vrstva
Síťová vrstva
Linková vrstva
Fyzická vrstva

DNS (Domain Name System) je hierarchický systém doménových jmen, který je realizován servery DNS a protokolem stejného jména, kterým si vyměňují informace. Jeho hlavním úkolem a příčinou vzniku jsou vzájemné převody doménových jmen a IP adres uzlů sítě. Později ale přibral další funkce (např. pro elektronickou poštu či IP telefonii) a slouží dnes de facto jako distribuovaná databáze síťových informací. Protokol používá porty TCP/53 i UDP/53, je definován v RFC1035. Servery DNS jsou organizovány hierarchicky, stejně jako jsou hierarchicky tvořeny názvy domén. Jména domén umožňují lepší orientaci lidem, adresy pro stroje jsou však vyjádřeny pomocí adres 32bitových (IPv4) A záznam nebo 128bitových (IPv6) - AAAA záznam. Systém DNS umožňuje efektivně udržovat decentralizované databáze doménových jmen a jejich překlad na IP adresy. Stejně tak zajišťuje zpětný překlad IP adresy na doménové jméno - PTR záznam.

Obsah

Něco z historie

Protože je používání názvů pro člověka daleko příjemnější než používání číselných adres, vznikla už v dobách ARPAnetu potřeba takový převod realizovat. Původně byl na všechny počítače distribuován jediný soubor (v Unixu /etc/hosts). Tato koncepce přestala velmi rychle vyhovovat potřebám a především nárokům na rychlou aktualizaci. Přesto se tento soubor dodnes používá, v závislosti na konfiguraci systému je možné jej použít buď prioritně před dotazem na DNS nebo v případě, že DNS neodpovídá. Je možné jej také použít k uložení vlastních přezdívek pro často navštěvované servery, případně také pro blokování reklam a podobně. V roce 1983 vyvinul Paul Mockapetris DNS protokol, který je popsán v RFC 882 a RFC 883. V roce 1987 byl protokol DNS aktualizován v RFC 1034 a RFC 1035, která nahradila původní doporučení.

Jak DNS funguje

Prostor doménových jmen tvoří strom. Každý uzel tohoto stromu obsahuje informace o části jména (doméně), které je mu přiděleno a odkazy na své podřízené domény. Kořenem stromu je tzv. kořenová doména, která se zapisuje jako samotná tečka. Pod ní se v hierarchii nacházejí tzv. domény nejvyšší úrovně (Top-Level Domain, TLD). Ty jsou buď tematické (com pro komerci, edu pro vzdělávací instituce atd.) nebo státní (cz pro Česko, sk pro Slovensko, jo pro Jordánsko atd.). Strom lze administrativně rozdělit do zón, které spravují jednotliví správci (organizace nebo i soukromé osoby), přičemž taková zóna obsahuje autoritativní informace o spravovaných doménách. Tyto informace jsou poskytovány autoritativním DNS serverem. Výhoda tohoto uspořádání spočívá v možnosti zónu rozdělit a správu její části svěřit někomu dalšímu. Nově vzniklá zóna se tak stane autoritativní pro přidělený jmenný prostor. Právě možnost delegování pravomocí a distribuovaná správa tvoří klíčové vlastnosti DNS a jsou velmi podstatné pro jeho úspěch. Ve vyšších patrech doménové hierarchie platí, že zóna typicky obsahuje jednu doménu. Koncové zóny přidělené organizacím připojeným k Internetu pak někdy obsahují několik domén – například doména kdesi.cz a její poddomény vyroba.kdesi.cz, marketing.kdesi.cz a obchod.kdesi.cz mohou být obsaženy v jedné zóně a obhospodařovány stejným serverem.

Složení doménového jména

Celé jméno se skládá z několika částí oddělených tečkami. Na jeho konci se nacházejí domény nejobecnější, směrem doleva se postupně konkretizuje.

  • část nejvíce vpravo je doména nejvyšší úrovně, např. Multimediaexpo.eu má TLD eu.
  • jednotlivé části (subdomény) mohou mít až 63 znaků a skládat se mohou až do celkové délky doménového jména 255 znaků. Doména může mít až 127 úrovní. Bohužel některé implementace jsou omezeny více.

DNS servery (name servery)

DNS server může hrát vůči doméně (přesněji zóně, ale ve většině případů jsou tyto pojmy zaměnitelné) jednu ze tří rolí:

  • Primární server je ten, na němž data vznikají. Pokud je třeba provést v doméně změnu, musí se editovat data na jejím primárním serveru. Každá doména má právě jeden primární server.
  • Sekundární server je automatickou kopií primárního. Průběžně si aktualizuje data a slouží jednak jako záloha pro případ výpadku primárního serveru, jednak pro rozkládání zátěže u frekventovaných domén. Každá doména musí mít alespoň jeden sekundární server.
  • Pomocný (caching only) server slouží jako vyrovnávací paměť pro snížení zátěže celého systému. Uchovává si odpovědi a poskytuje je při opakování dotazů, dokud nevyprší jejich životnost.

Odpověď pocházející přímo od primárního či sekundárního serveru je autoritativní, čili je brána za správnou. Z hlediska věrohodnosti odpovědí není mezi primárním a sekundárním serverem rozdíl, oba jsou autoritativní. Naproti tomu odpověď poskytnutá z vyrovnávací paměti není autoritativní. Klient může požádat o autoritativní odpověď, v běžných případech ale stačí jakákoli.

Root servery

Kořenové jmenné servery (root name servers) představují zásadní část technické infrastruktury Internetu, na které závisí spolehlivost, správnost a bezpečnost operací na internetu. Tyto servery poskytují kořenový zónový soubor (root zone file) ostatním DNS serverům. Jsou součástí DNS, celosvětově distribuované databáze, která slouží k překladu unikátních doménových jmen na ostatní identifikátory. Kořenový zónový soubor popisuje, kde se nacházejí autoritativní servery pro domény nejvyšší úrovně. Tento kořenový zónový soubor je relativně velmi malý a často se nemění – operátoři root serverů ho pouze zpřístupňují, samotný soubor je vytvářen a měněn organizací IANA. Pojem root server je všeobecně používán pro 13 kořenových jmenných serverů. Root servery se nacházejí ve 34 zemích světa, na více než 80 místech. Root servery jsou spravovány organizacemi, které vybírá IANA. Následující tabulka zobrazuje těchto 13 root serverů:

Název root serveru Operátor
A VeriSign Global Registry Services
B University of Southern California - Information Sciences Institute
C Cogent Communications
D University of Maryland
E NASA Ames Research Center
F Internet Systems Consortium, Inc.
G U.S. DOD Network Information Center
H U.S. Army Research Lab
I Autonomica/NORDUnet
J VeriSign Global Registry Services
K RIPE NCC
L ICANN
M WIDE Proje

Více informací o umístění root serverů naleznete na oficiálních stránkách DNS root servers v angličtině. Nároky na kořenové servery jsou popisovány v následujícím dokumentu RFC 2870 v angličtině. Dokument je souhrnem dosavadních zkušeností a vytyčuje obecné požadavky na software a hardware root serverů, zabývá se bezpečnostními aspekty, atd.

SW pro DNS servery

Porovnání nejpoužívanějšího software (implementací DNS serverů) z hlediska podpory výše uvedených typů serverů je v následující tabulce:

Název Pomocný Rekurzivní Autoritativní
BIND Ano Ano Ano
PowerDNS Ano Ano (pomocí pdns_recursor) Ano
djbdns Ano Ano Ano
MyDNS Ano Ne Ano
NSD Ne Ne Ano

Řešení dotazu

Každý koncový počítač má ve své konfiguraci síťových parametrů obsaženu i adresu lokálního DNS serveru, na nějž se má obracet s dotazy. V operačních systémech odvozených od Unixu je obsažena v souboru /etc/resolv.conf, v MS Windows ji najdete ve vlastnostech protokolu TCP/IP (případně můžete z příkazového řádku v XP zadat textový příkaz ipconfig /all). Adresu lokálního serveru počítač typicky obdrží prostřednictvím DHCP. Pokud počítač hledá určitou informaci v DNS (např. IP adresu k danému jménu), obrátí se s dotazem na tento lokální server. Každý DNS server má ve své konfiguraci uvedeny IP adresy kořenových serverů (autoritativních serverů pro kořenovou doménu). Obrátí se tedy s dotazem na některý z nich. Kořenové servery mají autoritativní informace o kořenové doméně. Konkrétně znají všechny existující domény nejvyšší úrovně a jejich autoritativní servery. Dotaz je tedy následně směrován na některý z autoritativních serverů domény nejvyšší úrovně, v níž se nachází cílové jméno. Ten je opět schopen poskytnout informace o své doméně a posunout řešení o jedno patro dolů v doménovém stromě. Tímto způsobem řešení postupuje po jednotlivých patrech doménové hierarchie směrem k cíli, až se dostane k serveru autoritativnímu pro hledané jméno, který pošle definitivní odpověď. Získávání informací z takového systému probíhá rekurzí. Resolver (program zajišťující překlad) postupuje od kořene postupně stromem směrem dolů dokud nenalezne autoritativní záznam o hledané doméně. Jednotlivé DNS servery jej postupně odkazují na autoritativní DNS pro jednotlivé části jména. Příklad: Podívejme se, jak by postupovalo hledání IP adresy ke jménu www.wikipedia.org:

Soubor:Dns-wikipedia.gif
Postup hledání www.wikipedia.org
  1. Uživatel zadal do svého WWW klienta doménové jméno www.wikipedia.org. Resolver v počítači se obrátil na lokální DNS server s dotazem na IP adresu pro www.wikipedia.org.
  2. Lokální DNS server tuto informaci nezná. Má však k dispozici adresy kořenových serverů. Na jeden z nich se obrátí (řekněme na 193.0.14.129) a dotaz mu přepošle.
  3. Kořenový server také nezná odpověď. Ví však, že existuje doména nejvyšší úrovně org, a jaké jsou její autoritativní servery, jejichž adresy tazateli poskytne.
  4. Lokální server jeden z nich vybere (řekněme, že zvolí tld1.ultradns.net s IP adresou 204.74.112.1) a pošle mu dotaz na IP adresu ke jménu www.wikipedia.org.
  5. Oslovený server informaci opět nezná, ale poskytne IP adresy autoritativních serverů pro doménu wikipedia.org. Jsou to ns0.wikimedia.org (207.142.131.207), ns1.wikimedia.org (211.115.107.190) a ns2.wikimedia.org (145.97.39.158).
  6. Lokální server opět jeden z nich vybere a pošle mu dotaz na IP adresu ke jménu www.wikipedia.org.
  7. Jelikož toto jméno se již nachází v doméně wikipedia.org, dostane od jejího serveru nepochybně autoritativní odpověď, že hledaná IP adresa zní 145.97.39.155
  8. Lokální DNS server tuto odpověď předá uživatelskému počítači, který se na ni ptal.

Výše popsaný postup popisuje kompletní řešení daného dotazu. Může se ale stát, že některý z oslovených serverů má hledanou informaci ve své vyrovnávací paměti, protože odpovídající dotaz nedávno řešil. V takovém případě poskytne neautoritativní odpověď z vyrovnávací paměti a další dotazování odpadá. Ve vyrovnávací paměti mohou být i mezivýsledky - například lokální DNS server v ní skoro jistě bude mít informaci o autoritativních serverech pro doménu org, protože v ní pravděpodobně hledá každou chvíli. V takovém případě by vypadly kroky 2 a 3 a lokální server by se s dotazem rovnou obrátil na některý z autoritativních serverů domény org. Všimněte si, že oslovené servery v popsaném příkladu vykazují dva odlišné druhy chování. Při rekurzivním řešení dotazu se server chopí vyřízení dotazu, najde odpověď a pošle ji tazateli. Rekurzivní přístup server zatěžuje (musí sledovat postup řešení, ukládat si mezivýsledky apod.), ale projde jím odpověď a tu si může uložit do vyrovnávací paměti. Typicky se tak chovají lokální servery, aby si plnily vyrovnávací paměti a mohly dalším tazatelům poskytovat odpovědi rovnou. Při nerekurzivním řešení dotazu server dotaz neřeší, pouze poskytne tazateli adresy dalších serverů, jichž se má ptát dál. Takto se chovají servery ve vyšších patrech doménové hierarchie (kořenové a autoritativní servery TLD), které by rekurzivní chování kapacitně nezvládaly. V příkladu výše se rekurzivně choval lokální server, zatímco autoritativní servery pro kořenovou doménu a doménu org se chovaly nerekurzivně (což odpovídá realitě).

Reverzní dotazy

Nejběžnějším úkolem DNS je poskytnout informace (nejčastěji IP adresu) pro zadané doménové jméno. Dovede ale i opak – sdělit jméno, pod kterým je daná IP adresa zaregistrována. Při vkládání dat pro zpětné dotazy bylo ale třeba vyřešit problém s opačným uspořádáním IP adresy a doménového jména. Zatímco IP adresa má na začátku obecné informace (adresu sítě), které se směrem doprava zpřesňují až k adrese počítače, doménové jméno má pořadí přesně opačné. Instituce připojená k Internetu typicky má přidělen začátek svých IP adres a konec svých doménových jmen. Tento nesoulad řeší DNS tak, že při reverzních dotazech obrací pořadí bajtů v adrese. K obrácené adrese pak připojí doménu in-addr.arpa a výsledné „jméno“ pak vyhledává standardním postupem. Hledá-li například jméno k IP adrese 145.97.39.155, vytvoří dotaz na 155.39.97.145.in-addr.arpa. Obrácení IP adresy umožňuje delegovat správu reverzních domén odpovídajících sítím a podsítím správcům dotyčných sítí a podsítí. V příkladu použitou síť 145.97.0.0/16 spravuje nizozemský SURFnet a ten má také ve správě jí odpovídající doménu 97.145.in-addr.arpa. Kdykoli zavede do sítě nový počítač, může zároveň upravit data v reverzní doméně, aby odpovídala skutečné situaci. Je dobré mít na paměti, že na data z reverzních domén nelze zcela spoléhat. Do reverzní domény se v principu dají zapsat téměř libovolná jména. Nikdo například nemůže zabránit SURFnetu, aby o počítači 145.97.1.1 prohlásil v reverzní zóně, že se jedná třeba o www.seznam.cz. Pokud na tom záleží, je záhodno si poskytnutou informaci ověřit normálním dotazem (zde nalézt IP adresu k www.seznam.cz a porovnat ji s 145.97.1.1). Jestliže odpovědí na něj bude původní IP adresa, jsou data důvěryhodná – správce klasické i reverzní domény tvrdí totéž. Pokud se liší, znamená to, že data v reverzní doméně jsou nekorektní.

Alternativní stromy

Běžní uživatelé internetu se setkají jen s „oficiálním“ stromem domén. Je ovšem možné založit libovolné množství takových stromů, které mohou obsahovat i stejná jména. Příkladem budiž například neoficiální strom czf fungující uvnitř některých privátních sítí v ČR.

DNS v praxi

DNS cache

Téměř každý DNS server funguje zároveň jako DNS cache. Při opakovaných dotazech pak nedochází k rekurzivnímu prohledávání stromu, ale odpověď je získána lokálně. V DNS záznamech je totiž uložena i informace jak dlouho lze záznam používat (TTL) a lze také zjistit, zda byl záznam změněn. Po vypršení platnosti je záznam z DNS cache odstraněn.

Doba uložení záznamu

Problém s uložením záznamů v cache nastává v případě změny záznamu. Pokud administrátor nastaví TTL na 6 hodin, a poté provede změnu záznamu, nastane situace, že někteří uživatelé sítě dostanou informaci již novou a někteří ještě starou. Tato situace bude trvat právě oněch 6 hodin, v závislosti na nastavení ostatních serverů a také v závislosti na době která uplynula od jejich posledního dotazu. Je proto nutné zvolit správný poměr mezi rychlostí šíření změn a ušetřeným výkonem a přenosovým pásmem DNS serveru. Pokud se změny provádí často, je vhodné zvolit kratší TTL v řádu jednotek hodin, pokud se změny téměř neprovádějí, může být TTL ve dnech.

Zónové soubory

Obsah zóny (domény či několika domén) je uložen v tzv. zónovém souboru. Skládá se z jednotlivých záznamů (přesný název zní zdrojové záznamy, resource records, RR) obsahujících dílčí informace. Jejich názvy a nesené informace jsou přesně definovány v příslušných dokumentech, většina v RFC 1035. Formát textového zápisu zónového souboru se liší v závislosti na použitém serveru, zde použijeme nejrozšířenější BIND. Záznamy v něm mají tvar

jméno životnost třída typ parametry
  • jméno je doménové jméno, pro něž záznam vytváříte. Zpravidla patří do aktuálně definované domény, pak se píše jen samotné jméno bez tečky na konci a bude k němu doplněna aktuální doména. Pokud jméno ukončíte tečkou, nic se k němu nedoplňuje a bere se jako kompletní. Nemusí být uvedeno, pak se přebírá z předchozího záznamu.
  • životnost určuje dobu platnosti záznamu v sekundách. Většinou se neuvádí a záznamům se ponechává implicitní životnost. Umožňuje vám však udělat výjimku.
  • třída určuje rodinu protokolů, k níž se záznam vztahuje. DNS lze teoreticky používat i pro jiné síťové architektury, v praxi však třída vždy bývá IN, což znamená Internet.
  • typ určuje typ definovaného záznamu (viz níže).
  • parametry se vztahují k typu záznamu, poskytují mu potřebná data. Obsahem parametrů často bývají doménová jména. Je třeba zdůraznit, že v parametrech se smí vyskytovat jen skutečná jména, nikoli přezdívky zavedené pomocí CNAME (viz níže).

Zónový soubor vždy musí začínat záznamem typu SOA.

Typy záznamů

Nejčastěji používané jsou následující typy zdrojových záznamů (v abecedním pořadí):

  • A (address record) obsahuje IPv4 adresu přiřazenou danému jménu, například když jménu cosi.kdesi.cz náleží IP adresa 1.2.3.4, bude zónový soubor pro doménu kdesi.cz obsahovat záznam 
cosi     IN   A   1.2.3.4
  • AAAA (IPv6 address record) obsahuje IPv6 adresu. Zmíněnému stroji bychom IPv6 adresu 2001:718:1c01:1:02e0:7dff:fe96:daa8 přiřadili záznamem 
cosi     IN   AAAA   2001:718:1c01:1:02e0:7dff:fe96:daa8
  • CNAME (canonical name record) je alias - jiné jméno pro jméno již zavedené. Typicky se používá pro servery známých služeb, jako je například WWW. Jeho definice pomocí přezdívky umožňuje jej později snadno přestěhovat na jiný počítač. Pokud náš cosi.kdesi.cz má sloužit zároveň jako www.kdesi.cz, vložíme do zónového souboru 
www      IN   CNAME   cosi
  • MX (mail exchange record) oznamuje adresu a prioritu serveru pro příjem elektronické pošty pro danou doménu. Tentokrát jsou parametry dva - priorita (přirozené číslo, menší znamená vyšší prioritu) a doménové jméno serveru. Pokud poštu pro počítač cosi.kdesi.cz přijímá nejlépe počítač mail.kdesi.cz a případně jako záložní i mail.jinde.cz, bude zónový soubor obsahovat záznamy (všimněte si použití jmen s tečkou a bez tečky) 
cosi     IN   MX   10 mail
         IN   MX   20 mail.jinde.cz.
  • NS (name server record) ohlašuje jméno autoritativního DNS serveru pro danou doménu. Bude-li mít doména kdesi.cz poddoménu obchod.kdesi.cz, jejímiž servery budou ns.kdesi.cz (primární) a ns.jinde.cz (sekundární), bude zónový soubor pro kdesi.cz obsahovat 
obchod   IN   NS   ns
         IN   NS   ns.jinde.cz.
  • PTR (pointer record) je speciální typ záznamu pro reverzní zóny. Obsahuje na pravé straně jméno počítače přidělené adrese na straně levé (adresa je transformována na doménu výše popsaným postupem). Držme se našeho příkladu pro záznam typu A - v souladu s ním by zónový soubor pro doménu 3.2.1.in-addr.arpa měl obsahovat (zónový soubor definuje reverzní doménu, proto je třeba psát na pravé straně kompletní jméno s tečkou, jinak by za ně připojil reverzní doménu) 
4        IN   PTR   cosi.kdesi.cz.
  • SOA (start of authority record) je zahajující záznam zónového souboru. Obsahuje jméno primárního serveru, adresu elektronické pošty jejího správce (zavináč je v ní ale nahrazen tečkou) a následující údaje:
    • Serial — sériové číslo, které je třeba zvětšit s každou změnou v záznamu. Podle něj sekundární server pozná, že v doméně došlo ke změně. Pokud jej zapomenete zvětšit, rozejde se obsah sekundárních serverů s primárním, což rozhodně není dobré. Pro přehlednost často ve formátu YYYYMMDDHH.
    • Refresh — jak často se má sekundární server dotazovat na novou verzi zóny (v sekundách).
    • Retry — v jakých intervalech má sekundární server opakovat své pokusy, pokud se mu nedaří spojit s primárním.
    • Expire — čas po kterém označí sekundární servery své záznamy za neaktuální, pokud se jim nedaří kontaktovat primární server.
    • TTL — implicitní doba platnosti záznamů.

Časové údaje jsou v sekundách. Novější implementace umožní pro vyšší pohodlí používat k číslům přípony 'M','H','D' a 'W' (minuta, hodina, den, týden) – například 8h znamená 8 hodin, čili totéž co hodnota 28800. Podívejme se na příklad SOA záznamu: 

@        IN   SOA   ns.kdesi.cz.  franta.kdesi.cz. (
                    200605140
                    1h
                    5m
                    1w
                    1d
                    )

Příklad zónového souboru

Zkusme dát dohromady lehce upravené úseky popsané výše a vytvořit příklad zónového souboru pro fiktivní doménu kdesi.cz. O takovýto záznam se stará správce (majitel) domény a má možnost jej měnit. 

$TTL 1w
@         IN   SOA   server.kdesi.cz.  franta.kdesi.cz. (
                     200605140
                     1h
                     5m
                     1w
                     1d
                     )
          IN   NS   server
          IN   NS   ns.jinde.cz.

          IN   MX   10 server
          IN   MX   20 mail.jinde.cz.
 
cosi      IN   A      1.2.3.4
          IN   AAAA   2001:718:1c01:1:02e0:7dff:fe96:daa8
server    IN   A      1.2.3.1
www       IN   CNAME  server

V příkladu je uvedena implicitní životnost jeden týden, dále SOA záznam popsaný výše, určující, že se záznam týká domény kdesi.cz, jejíhož správce je možné kontaktovat na emailu franta@kdesi.cz. Následují odkazy na dva DNS servery, které o doméně poskytují autoritativní informace – jeden místní a druhý externí. Dále MX záznamy, určující kam se bude doručovat elektronická pošta pro tuto doménu. Další dva řádky obsahují A a AAAA záznamy určující adresy počítače cosi.kdesi.cz. Za nimi je definována IPv4 adresa pro server.kdesi.cz a konečně je mu přidělena přezdívka www.kdesi.cz.

Implementace

U UNIX-like systémů je asi nejpoužívanější BIND https://www.isc.org/software/bind . Někteří poskytovatelé používají kvůli velkému počtu záznamů MyDNS http://mydns.bboy.net/ . Jako caching-only DNS server se osvědčuje také djbdns http://cr.yp.to/djbdns.html .

Související články

Externí odkazy


Citováno z „http://ww.multimediaexpo.cz/mmecz/index.php/Domain_Name_System“