Přehled terminologie, komponent a konceptů DNS

DNS (Domain Name System) je jednou z klíčových komponent pohánějících internet. Správné pochopení toho, jak DNS funguje, může pomoci diagnostikovat problémy s konfigurací webových stránek a rozšířit vaše chápání toho, co se děje v zákulisí.

V tomto průvodci si povíme o některých základních pojmech DNS, abychom vám poskytli pevný základ při práci s vaší konfigurací DNS. Tento průvodce vám také pomůže nastavit vlastní doménové jméno nebo DNS server.

Začněme!

Doménová terminologie

Nejprve si musíme ujasnit pojmy, které budeme používat. S některými z nich už možná budete obeznámeni z jiných souvislostí. Při hovoru o doménových jménech a DNS však existuje mnoho specifických termínů, o kterých se v jiných oblastech výpočetní techniky příliš nemluví.

• Domain Name System

Systém doménových jmen (zkráceně DNS) je síťový systém, který překládá lidsky srozumitelná doménová jména na jedinečné IP adresy.

• Doménové jméno

Doménové jméno označuje lidsky srozumitelný název používaný ke spojení s internetovým zdrojem. Například “cloudsigma.com” je doménové jméno. Někdo by mohl namítat, že doménovým jménem je pouze část “cloudsigma”, ale obecně se tím myslí celek.

URL adresa “cloudsigma.com” je spojena se servery vlastněnými společností CloudSigma. Při zadání této URL adresy do webového prohlížeče komunikuje s DNS, aby se připojil k IP adrese cílového serveru.

• IP adresa

IP adresa funguje jako síťová adresa pro zařízení připojené k síti. Každá IP adresa musí být v rámci sítě jedinečná. V kontextu webových stránek je touto sítí většinou celý internet.

Existují dva typy IP adres:

• • IPv4: Jedná se o nejběžnější formu IP adresy. Zapisuje se jako sada čtyř čísel, přičemž každá sada má až 3 číslice. Jednotlivé sady jsou odděleny tečkou. Rozsah IPv4 je od 0.0.0.0 do 255.255.255.255.

  • IPv6: Jedná se o modernější standard, který byl vyvinut k vyřešení problému s vyčerpáním adres IPv4. IPv4 podporuje až 232 jedinečných adres, zatímco IPv6 podporuje až 2128 adres. Jakákoli IPv6 adresa se zapisuje v šestnáctkové soustavě. Může obsahovat až 32 číslic rozdělených do 8 sekcí (po 4 číslicích v každé sekci). Každá sekce je oddělena dvojtečkou (:).

Doména nejvyšší úrovně

Doména nejvyšší úrovně (zkráceně TLD) je nejobecnější částí domény. Odkazuje na část nejvíce vpravo (oddělenou tečkou). Mezi běžné domény nejvyšší úrovně patří:

• “com”

• “net”

• “org”

• “edu”

• “io”

• “gov”

Pokud jde o doménová jména, tyto domény jsou na vrcholu hierarchie. ICANN (Internet Corporation for Assigned Names and Numbers) může udělit povolení ke kontrole nad doménami nejvyšší úrovně určitým subjektům. S tímto povolením pak tyto subjekty mohou distribuovat doménová jména pod danou TLD (obvykle prostřednictvím registrátora domén).

• Hostitelé

V rámci domény může vlastník specifikovat jednotlivé hostitele, což odkazuje na samostatné stroje/služby přístupné přes doménu. Běžnou praxí je například zpřístupnit webové servery přes samotnou doménu ( example.com) a definici “hostitele” “www  ( www.example.com).

Pod obecnou doménou je možné mít další hostitele, například přístup k API přes hostitele “api” ( api.example.com), přístup k FTP přes hostitele “ftp” nebo “files” ( ftp.example.com nebo files.example.com).

Upozorňujeme, že doménová jména mohou být libovolná, pokud jsou v rámci domény jedinečná.

• Subdoména

Subdoména je téma související s hostiteli. DNS funguje v hierarchii. TLD pod sebou může mít mnoho domén. Například “ example.com”, “ cloudsigma.com” atd. spadají pod TLD “com”. V tomto ohledu je subdoména odkazem na jakoukoli doménu, která je součástí cílové domény. Můžeme tedy říci, že “example.com” je subdoménou “com”. Část “example” se obecně označuje jako SLD (doména druhé úrovně).

Podobně může doména kontrolovat všechny “subdomény”, které se pod ní nacházejí. To je obvykle to, k čemu se termín “subdoména” používá. Například “ history.example.com” je subdoménou “ example.com”.

Klíčový rozdíl mezi názvem hostitele a subdoménou je ten, že hostitel definuje počítač/prostředek, zatímco subdoména rozšiřuje nadřazenou doménu. Kdykoli mluvíme o subdoménách nebo hostitelích, můžete se o tom ujistit pohledem na nejlevější část domény, protože ta je nejspecifičtější. Tak funguje DNS: od nejspecifičtější (nejvíce vlevo) po nejméně specifickou (nejvíce vpravo).

• Plně kvalifikované doménové jméno

Plně kvalifikované doménové jméno (zkráceně FQDN) označuje absolutní doménové jméno. V systému DNS mohou být domény uváděny relativně vůči sobě navzájem. To může vést k jisté nejednoznačnosti. FQDN je však absolutní název odkazující na absolutní kořen systému doménových jmen.

To znamená, že FQDN specifikuje každou nadřazenou doménu včetně TLD. Vhodným příkladem by bylo “ mail.google.com”. V konkrétních případech nemusí FQDN končit tečkou, ale musí mít koncovou tečku (vyžadováno standardy ICANN).

• Jmenný server

Jmenný server je vyhrazený počítač pro překlad doménových jmen na IP adresy. Jmenné servery nesou většinu zátěže v systému DNS. Protože celkový počet požadavků na překlad domén je příliš vysoký na to, aby jej zvládl jediný server, jsou požadavky často přesměrovávány na jiné jmenné servery, aby se snížil tlak.

Jmenný server může být “autoritativní”, což znamená, že poskytuje odpovědi pouze na dotazy týkající se domén pod jeho správou. Takové servery mohou předat požadavek jiným jmenným serverům nebo poskytnout kopii dat z jiných jmenných serverů uloženou v mezipaměti.

• Zónový soubor

Zónový soubor je textový soubor obsahující mapování mezi doménovými jmény a IP adresami. Slouží jako databáze systému DNS. Toto je katalog, který DNS používá k vyhledání IP adresy, kterou má kontaktovat při vyřizování požadavku uživatele na určitou doménu.

Obecně platí, že jmenné servery hostují zónové soubory a definují prostředky dostupné pod jednou doménou. Mohou také obsahovat informace o tom, kam jít tyto informace získat.

• Záznamy

Zónový soubor se skládá z mnoha záznamů. Záznam je zde definován jako jediné mapování mezi prostředkem a názvem. Záznamy mohou být mapováním doménového jména na IP adresu, prostředky dostupnými pod konkrétní doménou nebo odkazy na místa, kde lze tyto informace získat.

DNS v akci

Dosud jsme se seznámili s některými běžnými termíny souvisejícími s DNS. Jak ale tento systém skutečně funguje? Na vysoké úrovni se systém může zdát velmi jednoduchý. Nicméně hlubší pohled do detailů odhalí jeho skutečnou složitost. Celkově je systém DNS důležitý pro široké rozšíření internetu.

• Kořenové servery

DNS ve svém jádru funguje v hierarchii. Na samém vrcholu systému se nacházejí “kořenové servery”. Tyto servery jsou pod kontrolou různých organizací. Pravomoc těchto serverů je delegována organizací ICANN (Internet Corporation for Assigned Names and Numbers).

V současné době je v provozu přibližně 13 kořenových serverů. Kvůli zátěži je však každý z těchto serverů zrcadlen. Je důležité poznamenat, že všechny zrcadlené servery sdílejí stejnou IP adresu jako kořenový server. Kdykoli je na kořenový server odeslán požadavek, je přesměrován na nejbližší zrcadlo tohoto serveru.

Jaké jsou úkoly kořenových serverů? Poskytují informace o doménách nejvyšší úrovně. Kdykoli jmenný server nižší úrovně nedokáže vyřídit požadavek, je přesměrován na kořenový server domény.

Kořenový server však ve skutečnosti nezná umístění domény. Pouze přesměruje požadavek, který bude zpracovávat konkrétně požadovanou doménu nejvyšší úrovně. Například pokud je podán požadavek na “ blog.cloudsigma.com”, kořenový server jej nebude mít ve svých záznamech. Prohledá své zónové soubory, ale nebude v nich pro něj žádný záznam. Místo toho rozpozná TLD “com” a přesměruje žádající entitu na jmenný server obsluhující adresy “com”.

• TLD servery

Pokud budeme pokračovat v našem předchozím příkladu, žádající entita nyní odešle požadavek na IP adresu (poskytnutou kořenovým serverem). V případě “ blog.cloudsigma.com” prohledá jmenný server pro “com” své záznamy ve svých zónových souborech.

Záznam odpovídající požadavku tam nebude. Najde však záznam uvádějící IP adresu jmenného serveru odpovědného za “ cloudsigma.com”.

• Jmenný server na úrovni domény

Nyní má žádající entita IP adresu jmenného serveru, který skutečně hostuje informace o “ blog.cloudsigma.com”. Nyní odešle nový požadavek na server s žádostí o přeložení “www.cloudsigma.com”.

Stejně jako předtím jmenný server zkontroluje své zónové soubory a najde ten, který je spojen s “ cloudsigma.com”. Uvnitř tohoto souboru se bude nacházet záznam pro hostitele “www”. Tento záznam popisuje, kde se hostitel nachází. Konečná odpověď je pak předána žádající entitě.

• Překládající jmenný server

V příkladu jsme zmínili žádající entitu. Co to je? Ve většině případů bude žadatelem “překládající jmenný server”. Je to server, který je nakonfigurován tak, aby kladl dotazy ostatním serverům. Funguje jako zprostředkovatelský server pro uživatele. Ukládá výsledky do mezipaměti pro zvýšení rychlosti.

Každý uživatel má obvykle ve svém systému nakonfigurováno několik překládajících jmenných serverů. Obecně jsou překládající jmenné servery nabízeny poskytovatelem internetového připojení (ISP) nebo jinými organizacemi. Například Google nabízí veřejné překládající DNS servery, na které se lze dotazovat. Můžete je do svého systému nakonfigurovat ručně.

Při zadání URL adresy do webového prohlížeče se vyhledává umístění prostředku. Nejprve se vyhledávání provádí lokálně. To zahrnuje soubor “hosts” (a některá další umístění). Pokud není nalezeno, požadavek se odešle na překládající jmenný server. Po přijetí požadavku překládající jmenný server vyhledá odpověď ve své mezipaměti. Pokud ji nenajde, projde kroky popsanými výše.

Překládající jmenné servery zjednodušují proces podávání požadavků pro koncového uživatele. Klient se musí pouze zeptat překládajících jmenných serverů na umístění prostředku. Jmenný server provede šetření a vrátí konečnou odpověď.

• Zónové soubory

Již jsme diskutovali o pojmech “zónové soubory” a “záznamy”. Jak ale fungují?

Zónové soubory fungují jako databáze pro jmenné servery a ukládají informace o doménách, o kterých vědí. Všechny domény, o kterých jmenný server ví, budou uloženy v jeho zónovém souboru. Většina požadavků přicházejících na jmenný server se však pomocí zónového souboru nevyřeší. Pokud je konfigurace serveru nastavena na zpracování rekurzivních dotazů (například překládající jmenné servery), vrátí odpověď. V opačném případě přesměruje žádající stranu na jiné místo, kde má hledat dál.

Čím více zónových souborů jmenný server hostuje, tím autoritativnější budou jeho odpovědi. Zónové soubory popisují DNS “zónu” (podmnožinu celého systému pojmenování DNS). Obecně zónový soubor obsahuje konfigurační data pouze jedné domény. Může obsahovat četné záznamy definující umístění prostředků dané domény.

Parametr $ORIGIN zóny odpovídá nejvyšší úrovni autority dané zóny. Například zónový soubor pro “ cloudsigma.com” bude mít svůj $ORIGIN nastaven jako “ cloudsigma.com”. Hodnota parametru může být uložena na začátku zónového souboru nebo v konfiguraci DNS serveru. V každém případě parametr popisuje, pro kterou zónu je soubor autoritativní.

Parametr $TTL nastavuje informaci o “době životnosti” (time to live) výsledku, který poskytuje. Lze jej popsat jako časovač, který může ukládací server použít ke sledování platnosti odpovědí v mezipaměti. Pokud hodnota TTL vyprší, odpověď již není platná a je zahozena.

• Typy záznamů

Zónové soubory se skládají z mnoha záznamů. Existují různé typy záznamů. Dále si projdeme některé z nejběžnějších (a povinných) typů záznamů:

Záznamy SOA

Záznam Start of Authority (zkráceně SOA) je povinný ve všech zónových souborech. Musí to být první skutečný záznam v souboru. Nicméně záznamy jako $ORIGIN nebo $TTL se mohou objevit před ním.

Záznam SOA je jedním ze složitějších typů záznamů. Jeho struktura vypadá přibližně takto:

Pojďme si to rozebrat:

• • example.com: Tato část definuje kořen zóny. V tomto příkladu je zónový soubor pro doménu “ example.com”. Někdy může být tato hodnota nahrazena @ (zástupný symbol pro nahrazení hodnoty $ORIGIN).

  • IN SOA: Výraz “IN” znamená “internet”. Najdete ho v mnoha záznamech. Výraz “SOA” označuje, že se jedná o záznam SOA.

  • ns1.example.com: Tato hodnota obsahuje primární jmenný server pro doménu “ example.com”. Jmenné servery mohou být buď primární, nebo sekundární. Pokud byl nakonfigurován s dynamickým DNS, pak je vyžadován jeden “primární” server. Pokud nebylo dynamické DNS nakonfigurováno, bude to jeden z primárních jmenných serverů.

  • admin.example.com: Zde se uvádí e-mailová adresa správce zóny. Všimněte si, že @ je zde nahrazen .. Pokud původní e-mailová adresa obsahuje tečku, je nahrazena \. Například “ my.domain@example.com” by se změnilo na “ my\domain.example.com”.

  • 12083: Jedná se o sériové číslo zónového souboru. Při každé úpravě zónového souboru musí být toto číslo aktualizováno, aby se soubor správně propagoval. Sekundární servery používají toto sériové číslo ke sledování, zda jsou jejich vlastní zónové soubory aktuální.

  • 3h: Představuje interval obnovení zóny. Sekundární servery budou po tuto dobu čekat, než zkontrolují aktualizace zónového souboru.

  • 30m: Tato hodnota představuje interval opakování zóny. Pokud se sekundárnímu serveru nepodaří připojit k primárnímu serveru po uplynutí doby obnovení, počká tuto dobu, než se znovu dotáže primárního serveru.

  • 3w: Tato hodnota představuje dobu exspirace. Pokud se sekundárnímu serveru nepodaří připojit k primárnímu serveru po tuto dobu, přestane vracet odpovědi jako “autoritativní”.

  • 1h: Tato hodnota představuje dobu, po kterou bude jmenný server ukládat do mezipaměti chybu názvu (name error), pokud nebyl nalezen v jeho zónovém souboru.

A and AAAA Records

Tyto záznamy vytvářejí mapování mezi hostitelem a IP adresou. Záznam “A” označuje mapování IPv4 na hostitele a AAAA mapování IPv6.

Toto je základní struktura záznamů A a AAAA:

V příkladu záznamu SOA jsme jmenný server nazvali “ ns1.exampel.com”. Jmenný server spadá pod doménu “ example.com”. Zde je ukázka toho, jak by vypadal jeho záznam A:

Všimněte si, že jsme nemuseli uvádět celý název. Pouze s názvem hostitele (bez FQDN) může DNS server doplnit zbytek hodnotou z $ORIGIN. Můžeme však stále použít FQDN:

Zde je návod, jak definovat webový server jako “www”:

Měli bychom také zahrnout mapování na základní doménu. Záznam by vypadal takto:

Případně můžeme použít @ symbol pro označení základní domény (místo jejího celého názvu):

Je dobrou praxí zahrnout zástupný záznam, který umožňuje překládat cokoli pod touto doménou, co nebylo explicitně definováno:

Stejná struktura platí pro záznamy AAAA. Jediným rozdílem jsou IPv6 adresy.

CNAME Records

Záznamy CNAME fungují jako alias pro kanonický název serveru (definovaný záznamem A nebo AAAA). Podívejte se na následující příklad:

Zde jsme použili “server1” jako alias pro definování názvu “www”. Všimněte si, že takové zkratky s sebou nesou snížení výkonu, protože server musí provádět další dotazy, aby získal konečnou odpověď. V závislosti na počtu vrstev aliasů to může snadno způsobit velký pokles výkonu. Existuje však jeden specifický případ, který z aliasování CNAME těží, například poskytování prostředku mimo aktuální zónu.

MX Records

Záznamy MX definují poštovní servery pro doménu. Pomáhají správnému doručení e-mailu na server. Na rozdíl od jiných záznamů nemapují záznamy MX hostitele na konkrétní cíl, protože platí pro celou zónu. Proto záznamy MX vypadají nějak takto:

Všimněte si, že na začátku záznamu není žádný název hostitele. Také si všimnete, že na řádku je další hodnota. Je to číslo priority, které pomáhá rozhodnout, na který server se má pošta odeslat (pokud je definováno více poštovních serverů). Čím nižší číslo, tím vyšší priorita.

Záznam MX by měl ukazovat na hostitele definovaného záznamem A nebo AAAA (nikoli CNAME). S ohledem na to, pokud jsou nakonfigurovány dva poštovní servery, záznamy by vypadaly takto:

V tomto příkladu je podle čísla priority server “mail1” preferovanější než “mail2”. Kód můžeme dále zkrátit vynecháním celého názvu domény:

NS Records

Tyto záznamy definují jmenné servery pro konkrétní zónu. Nabízí se samozřejmě otázka: pokud se soubor zóny nachází v jmenném serveru, proč vyžaduje odkaz sám na sebe? Jednou z odpovědí na tuto otázku jsou vícenásobné mechanismy mezipaměti systému DNS. Soubor zóny může být ve skutečnosti kopie uložená v mezipaměti na jiných serverech.

Podobně jako záznamy MX platí i záznamy NS pro celou zónu. Ve výchozím nastavení tedy nemají žádného konkrétního hostitele. Záznamy NS budou vypadat nějak takto:

Doporučuje se mít definované dva jmenné servery pro případ, že by jeden server nefungoval správně. Většina DNS serverů navíc soubor zóny odmítne, pokud obsahuje pouze jeden jmenný server.

Měli byste také zahrnout mapování hostitelů pomocí záznamů A nebo AAAA:

PTR Records

Záznamy PTR jsou opakem klasického záznamu A nebo AAAA. Tyto záznamy se používají k definování názvu přidruženého k IP adrese. Tyto záznamy mají jedinečnou vlastnost, protože začínají na .arpa kořeni a představují vlastníka IP adresy. IP adresy organizacím a poskytovatelům služeb distribuují RIR (Regional Internet Registries – regionální internetové registry). Mezi RIR patří APNIC, AFRINIC, LACNIC, RIPE NCC a ARIN.

Například záznam PTR pro 111.222.333.444 by vypadal nějak takto:

V dalším příkladu záznamu PTR se podívejte na IPv6 DNS server společnosti Google 2001:4860:4860::8888:

Můžeme použít nástroj dig s příznakem -x k vyhledání reverzního DNS názvu IP adresy. Podívejte se například na reverzní DNS IP adresu pro 8.8.4.4:

Internetové servery používají záznamy PTR ke sledování doménových jmen v záznamech protokolů (logech), k informovanému rozhodování o nakládání se spamem a k zobrazování snadno čitelných informací o jiných zařízeních.

Běžně používané e-mailové servery vyhledávají záznam PTR pro IP adresu, ze které byl e-mail odeslán. Pokud je záznam PTR prázdný, je vysoká pravděpodobnost, že e-mail je spam (a bude tedy odmítnut). Upozorňujeme, že shoda mezi FQDN a doménovým jménem v záznamu PTR není tím hlavním problémem. Důležitým faktorem je, zda je platný záznam PTR spojen s odpovídajícím dopředným záznamem A.

Síťové směrovače na internetu mají obecně záznamy PTR odpovídající jejich fyzickému umístění. Například “NYC” nebo “CHI” jsou platné odkazy pro směrovače umístěné v New Yorku a Chicagu. Tato technika je užitečná při provádění traceroute nebo MTR a kontrole trasy, kterou pakety procházejí.

Záznamy CAA

Tyto záznamy určují certifikační autority (CA), které mohou pro vaši doménu vydat certifikát SSL/TLS. Od 8. září 2017 jsou všechny certifikační autority povinny před vydáním certifikátu zkontrolovat záznamy CAA. Pokud žádný záznam CAA neexistuje, může certifikát vydat jakákoli CA. V opačném případě mohou certifikáty vydávat pouze konkrétní certifikační autority. Záznamy CAA lze použít buď na jednotlivé hostitele, nebo na celou doménu.

Zde je příklad záznamu CAA:

Část záznamu specifická pro CAA je 0 issue "letsencrypt.org". Tato část se skládá ze tří částí:

• Příznaky: Jedná se o celočíselnou hodnotu, která určuje, jak má certifikační autorita zacházet se značkami, kterým nerozumí. Pokud je hodnota příznaku nastavena na 0, pak bude záznam ignorován. Pokud je hodnota 1, pak musí certifikační autorita odmítnout certifikát vydat.
• Značky: Jedná se o řetězce označující účel záznamu CAA. V současné době mezi platné hodnoty patří issue (opravňující CA k vydávání certifikátů pro konkrétní doménu), issuewild (opravňující k vydávání wildcard certifikátů) a iodef (definující URL, kde certifikační autority hlásí porušení zásad).
• Hodnoty: Jedná se o řetězce spojené se značkou záznamu. Pokud je značka issue nebo issuewild, hodnota bude obvykle doména certifikační autority, které udělujete oprávnění. Pokud je značka iodef, bude to URL kontaktního formuláře nebo odkaz mailto: pro e-mailovou zpětnou vazbu.

K načtení záznamů CAA můžeme použít nástroj dig:

Podrobnější informace o záznamech CAA naleznete v RFC 6844.

Závěrečné myšlenky

Tato příručka popisuje různé termíny související s DNS. Popisuje také, jak do sebe všechny komponenty zapadají. S tímto uceleným přehledem byste měli dobře porozumět fungování systému DNS. Zatímco obecná myšlenka je jednoduchá a snadno pochopitelná, detaily se mohou velmi rychle zkomplikovat. Pro nezkušené administrátory může být obtížné tyto koncepty a strategie uplatnit.

Jste zákazníkem CloudSigma? Pak se podívejte na správu a aktualizaci reverzních DNS/PTR záznamů pro vaši infrastrukturu CloudSigma.

Příjemnou práci!