Každý dotaz posílaný klientem jmennému serveru sestává ze dvou podstatných částí: doménového jména a typu záznamu. DNS totiž slouží nejen k převodu doménových jmen na IP adresy, ale případně i k jiným účelům. Podívejme se tedy, jaká data můžeme v DNS najít.
Zdrojové záznamy
Základním prvkem databáze DNS je zdrojový záznam (resource record), který si s přijatelnou mírou zjednodušení můžeme představit jako slovníkové heslo, které doménovému jménu a typu záznamu přiřazuje jisté strukturované údaje. Záznamů se stejným doménovým jménem a typem může být i více – server pak klientovi vrátí seznam všech hodnot takových záznamů. Běžně se používají následující typy záznamu:
- A (address) přiřazuje doménovému jménu adresu IPv4.
- AAAA (IPv6 address) přiřazuje doménovému jménu adresu IPv6. Čtverné A naznačuje, že adresa IPv6 je oproti svému staršímu sourozenci čtyřikrát delší.
- SOA (start of authority) je nezbytný pro vytvoření nové zóny autority příslušející doménovému jménu. Určuje primární jmenný server, kontakt na správce zóny, verzi zónových dat a také několik časových intervalů určujících platnost záznamů, frekvenci přenosu dat na sekundární servery aj.
- NS (name server) specifikuje jmenný server příslušející doménovému jménu. Pro každý server je třeba uvést samostatný záznam.
- CNAME (canonical name) naznačuje, že doménové jméno je „přezdívkou“ a uvádí odpovídající hlavní (tzv. kanonické) jméno.
- MX (mail exchange) odkazuje na poštovní server pro danou doménu a uvádí také jeho preferenční číslo. Je-li takových záznamů více, doručují se e-mailové zprávy nejprve serveru s nejnižším preferenčním číslem, a pokud není dostupný, tak dalšímu v pořadí.
- PTR (pointer) slouží ke zpětnému převodu IP adres na doménová jména (viz níže).
Pro některé účely (mimo jiné bezpečnostní) je užitečné dozvědět se doménové jméno příslušející dané IP adrese. K tomu slouží reverzní doména in-addr.arpa, která je standardní součástí hierarchie DNS. Návěští uzlů pod touto doménou jsou zásadně číselná a odpovídají jednotlivým částem adresy IPv4, ovšem v obráceném pořadí. Chceme-li tedy například zjistit doménové jméno odpovídající adrese 10.11.12.13, použijeme ve svém dotazu jméno 13.12.11.10.in-addr.arpa a typ záznamu PTR.
DNS a IPv6
Kdybychom chtěli být struční, můžeme se omezit na konstatování, že DNS funguje v IPv6 prakticky stejně jako v IPv4, až na to, že se místo A používá typ záznamu AAAA a reverzní doména sídlí pod ip6.arpa. Tím bychom ovšem pominuli zajímavou historickou zkušenost – uvedený aktuální stav je totiž výsledkem pokorného návratu k původním jednoduchým principům. V období let 2000–2003 se v rámci IETF intenzivně pracovalo na „chytřejším“ DNS pro IPv6, který měl mimo jiné usnadnit přeadresování sítě a delegování libovolných adresových prefixů. Byl navržen nový typ záznamu A6, který mohl na rozdíl od AAAA obsahovat jen část IP adresy spolu s odkazem na doménové jméno, pod nímž lze najít zbytek. Podobně byl pro reverzní doménu navržen sofistikovanější záznam DNAME. Detaily lze nalézt třeba ve Wikipedii nebo v článcích Pavla Satrapy na serveru Lupa.cz. Nový systém byl sice prokazatelně elegantnější, přesto však zašel na úbytě, především kvůli tomu, že zvýšil počet dílčích kroků při iterativním dotazu, a tím klientům prodloužil průměrnou dobu potřebnou k získání požadované informace. Poučení je zřejmé: internet nesnáší složitá řešení.
Dynamický DNS
Databázový systém DNS byl původně navržen tak, aby byl schopen vyřizovat v reálném čase co největší množství klientských dotazů. Efektivita zápisu do databáze – tedy vytváření nových záznamů a úpravy stávajících – byla považována za druhořadý aspekt. Mělo se totiž zato, že změny dat budou relativně řídké. V dnešní době mobilních klientů, dynamického přidělování IP adres a peer-to-peer protokolů už ale tento statický pohled na DNS neobstojí. V mnoha případech je identita serverů a účastníků komunikace reprezentována právě doménovým jménem a musí být zachována i v případě, že se jejich IP adresa změní.
Klíčem k řešení je dynamický DNS (DDNS), který umožňuje klientům pomocí speciálních zpráv upravovat a doplňovat zónová data na primárním serveru. Nejčastěji přitom jde o přidávání záznamů typu A, popřípadě AAAA a symetrických reverzních záznamů typu PTR. Protokol DDNS je definován v RFC 2136. Jmenný server si dynamické aktualizace od klientů zapisuje bokem do samostatného souboru (tzv. žurnálu) a periodicky je přesouvá do hlavního zónového souboru, který obsahuje autoritativní data.
Dynamické aktualizace mají logicky své místo v lokálních sítích a doménách nižších úrovní. Poté, co byl DDNS implementován v platformách MS Windows (2000 a následujících), však začaly být kořenové jmenné servery – k velkému zděšení jejich správců – doslova bombardovány dynamickými aktualizacemi reverzní domény in-addr.arpa, které se vesměs týkaly adres v privátním adresovém prostoru podle RFC 1918, tedy například reverzní domény 168.192.in-addr.arpa. Příčinou tohoto neblahého stavu se ukázala být kombinace dvou faktorů: Předně se mnoho uživatelů privátního adresového prostoru neobtěžuje se zřizováním reverzní domény pokrývající jimi používané adresy, takže autoritativní zónou je pak skutečně až in-addr.arpa. Druhým faktorem je přespříliš „uživatelsky přívětivé“ implicitní nastavení serverů DHCP a DNS v MS Windows. Výsledek? Studie z poslední doby ukazují, že třeba jen na jeden z kořenových serverů směřují během jediné hodiny až tři miliony takových zmatečných aktualizací a z nich přes 97 % padá na vrub systémů s MS Windows. Musela být proto nasazena technická opatření, která kořenové servery chrání a takový nežádoucí provoz odbočují do předsunutých „černých děr“. Je třeba zdůraznit, že tyto zbloudilé aktualizace nejenom zbytečně zatěžují infrastrukturu internetu, ale také představují bezpečnostní rizika pro jejich původce.
Bezpečnost DNS
Bezpečný provoz klíčové služby DNS je dnes jedním z hlavních otevřených problémů internetu. V podstatě jde o obecnou otázku autentizace, autorizace a integrity dat: Jak spolehlivě ověřit, od koho zpráva DNS pochází a že s ní nebylo cestou manipulováno? Pokud jde o totožnost odesílatele – ať je jím jmenný server anebo klient používající DDNS – jediným dostupným vodítkem je prozatím jen jeho IP adresa. To je ovšem prachmizerná záruka a skutečně také existuje několik poměrně snadných cest, popsaných třeba v RFC 3833, jak informace DNS podvrhnout. Postižený uživatel pak může nevědomky posílat data jinam, než zamýšlí.
| Lék na tyto neduhy se skrývá pod zkratkou DNSSEC (DNS Security Extensions) a je popsán v několika dokumentech RFC: 4033, 4034, 4035 a 4470. Používají se osvědčené postupy asymetrické kryptografie, přesněji té její části, která se zabývá digitálním podpisem – šifrování dat DNSSEC neřeší. Záznamy jsou v zónových datech podepsány tajným klíčem, takže příjemce pak může pomocí odpovídajícího veřejného klíče (který je také součástí zónových dat) ověřit jejich původ i pravost. Hierarchická struktura DNS také poskytuje přirozený „strom důvěry“ – uživateli prakticky stačí ověřit pravost veřejného klíče kořenové domény, jímž jsou podepsány klíče všech top-level domén atd. |
Jenže: DNSSEC se zatím používá jen naprosto okrajově a zdá se, že širší rozšíření nemůžeme v nejbližší době očekávat. Vedle toho, že zatím nejsou zcela uspokojivě vyřešeny některé technické a právní detaily, není příliš jasno v tom, jak postupně rozšířit DNSSEC na celý internet, aniž bychom ho museli na dva měsíce vypnout.
Autor je výzkumným pracovníkem sdružení Cesnet.
Zajímá vás seriál Technologie Internetu?
Všechny dosud publikované díly jsou k dispozici zde.
PŘEDPLATNÉ
ČLÁNKY DO MAILU