Domain Name System

DNS (Domain Name System) je hierarchický, decentralizovaný 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 a je definován v [url=http://www. faqs. +moreorg/rfcs/rfc1035. html]RFC1035[/url]. 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.

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). +more 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 protokol DNS, 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 s jedním kořenem. 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. +more 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 Českou republiku, 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. +more 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ř. wikipedia. +moreorg má TLD org. * 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 dvou rolí:

* Autoritativní server je ten, na němž jsou trvale uloženy záznamy k dané doméně/zóně. Autoritativních serverů je obvykle více (minimálně dva - primární a sekundární, ale běžně i více) a až na velmi speciální případy se na všech udržují totožné záznamy, tzn. +more každou změnu v záznamech je potřeba propagovat na všechny autoritativní servery. Autoritativní DNS servery jsou obvykle provozovány registrátorem domény nebo poskytovatelem webhostingu.

* Rekurzivní (caching only) server je server, na který se se svými dotazy obracejí klientská zařízení (počítač, mobil aj. ). +more Server pro ně příslušný záznam získá rekurzivními dotazy u autoritativních DNS serverů a po stanovenou dobu (definovanou pomocí parametru TTL Time to live) je má uloženy v cache, aby mohl odpovídat klientům rychleji a šetřil zatížení serverů autoritativních. Na tomto serveru nejsou žádné zóny uloženy trvale. Rekurzivní DNS server se také stará o validaci DNSSEC, pokud tuto technologii podporuje. Rekurzivní DNS server obvykle provozuje ISP (poskytovatel připojení k internetu). Rekurzivních serverů může být na klientu definováno více na různých IP adresách, ale v praxi se spíše zajišťuje vysoká dostupnost serveru na první definované IP adrese. Informaci o DNS serverech na dané síti klient zjišťuje nejčastěji přes protokol DHCP, na IPv6 přes NDP (DHCPv6 tuto informaci neposkytuje).

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. +more 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í [url=https://web. +morearchive. org/web/20170920185613/http://www. iana. org/]IANA[/url].

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. +more Root servery jsou spravovány organizacemi, které vybírá [url=https://web. archive. org/web/20170920185613/http://www. iana. org/]IANA[/url]. 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. +moreS. 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 Project

Více informací o umístění root serverů naleznete na oficiálních stránkách [url=http://www. root-servers. org/]DNS root servers[/url] v angličtině.

Nároky na kořenové servery jsou popisovány v následujícím dokumentu [url=http://www. ietf. +moreorg/rfc/rfc2870. txt. number=2870][[rfc:2870|RFC 2870[/url]]] 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:

wikitable	Název	Autoritativní	Rekurzivní
BIND	center | Ano	center | Ano
NSD	center | Ano	center | Ne
KnotDNS	center | Ano	center | Ano (Knot Resolver)
PowerDNS	center | Ano	center | Ano (pomocí pdns_recursor)
djbdns	center | Ano	center | Ano
MyDNS	center | Ano	center | Ne
Unbound	center | Ano	center | 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. +moreconf, 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. +more Každý DNS server má ve své konfiguraci uvedeny [url=http://www. root-servers. org/]IP adresy kořenových serverů[/url] (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. +more 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ě. +more 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. +moreorg: Postup hledání www. wikipedia. org # 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. # 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. 14. 129) a dotaz mu přepošle. # 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. # 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. # 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). # Lokální server opět jeden z nich vybere a pošle mu dotaz na IP adresu ke jménu www. wikipedia. org. # 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. # 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. +more 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. +more 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. +more 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. +morearpa 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/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. +more 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. +more Příkladem je 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ě. +more 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. +more 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. +more 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. +more 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. +morecz 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 28 800. +more 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. +more 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 ns IN NS ns.jinde.cz.

IN MX 10 mail 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. +morecz. 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. +morecz. 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.

Registrace domény

Internet Corporation for Assigned Names and Numbers (ICANN) je organizace, která má na starost přidělování a správu doménových jmen a IP adres. Zastřešuje také další regionální organizace, které působí na jednotlivých kontinentech. +more Každý stát má potom určeného správce zóny, který se stará o příslušnou TLD. Správce může domény registrovat buď sám nebo prostřednictvím tzv. doménových registrátorů, kteří mají náležitá oprávnění.

ICANN zveřejňuje kompletní seznam všech TLD správců. Informace o vlastnících domén jsou udržovány v online databázi, která je dostupná přes službu WHOIS. +more Doménové registry obsahují informace o více než 240 národních a generických doménách (ccTLD, gTLD). Např. v ČR se o doménu . cz stará CZ. NIC z. s. p. o. .

Příklad založení domény druhého řádu v ČR

# Zvolíme si jméno domény - např. mojedomena. +morecz # Zvolíme vhodného registrátora # Registrátor zřídí primární a sekundární servery # Požádá správce zóny . cz o registraci domény # Správce zavede adresy NS serverů do . cz zóny.

Implementace

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

Související články

Doména nejvyššího řádu (TLD) * TCP/IP * Internetová doména * SRV záznam * DNSSEC

Reference

Externí odkazy

[url=http://www.dnska.cz/]Vyhledávání v DNS záznamech[/url] - je možné hledat v DNS záznamech MX a A * [url=http://www.icann.org/]Oficiální web ICANN[/url] - (anglicky)

Kategorie:Adresářové služby Kategorie:Aplikační protokoly IP