Domain Name System

Principy fungování DNS a praktické otázky spojené s jeho fungováním

Pavel Satrapa

Ondřej Filip

Vydavatel:

CZ.NIC, z. s. p. o.

Milešovská 1136/5, 130 00 Praha 3

Edice CZ.NIC

www.nic.cz

1. vydání, Praha 2023

Kniha vyšla jako 30. publikace v Edici CZ.NIC.

ISBN 978-80-88168-72-0

© 2023 Pavel Satrapa, Ondřej Filip

Toto autorské dílo podléhá licenci Creative Commons BY-ND 4.0

(http://creativecommons.org/licenses/by-nd/4.0/). Dílo však může být překládáno a následně šířeno v písemné či elektronické formě, na území kteréhokoliv státu, za předpokladu, že nedojde ke změně díla a i nadále zůstane zachováno označení autora a prvního vydavatele díla, sdružení CZ.NIC, z. s. p. o. Překlad může být šířen pod licencí CC BY-ND 4.0.

ISBN 978-80-88168-72-0

— Pavel Satrapa, Ondřej Filip

Domain Name

System

Principy fungování DNS a praktické

otázky spojené s jeho fungováním

— Edice CZ.NIC

Předmluva vydavatele

Milí čtenáři,

v Edici CZ.NIC vyšla za patnáct let její existence úctyhodná řada knih pokrývající širokou škálu témat. Knížka Domain Name System, kterou právě držíte v ruce, se však jako vůbec první věnuje dennímu chlebu sdružení CZ.NIC, totiž Systému doménových jmen (DNS). Jejím hlavním autorem je Pavel Satrapa, který si za třicet let působení na poli technické literatury vydobyl velké renomé především díky svému charakteristickému stylu, jímž dokáže podat i složitá témata zábavnou a čtivou formou. Druhý autor, Ondřej Filip, pak přispěl svými bohatými praktickými zkušenostmi z řízení a správy systému DNS, jak na národní, tak i mezinárodní úrovni.

DNS jakožto globální distribuovaná databáze byla a je vedle transportního protokolu TCP hlavním pilířem a předpokladem fenomenálního úspěchu Internetu. Jak TCP, tak i DNS se dokázaly během pěti dekád, byť s jistými úpravami a rozšířeními, skvěle vyrovnat jak s raketovým nárůstem počtu uživatelů a přenosových rychlostí, tak i s poměrně zásadními změnami v architektuře Internetu – přechodem od transparentní end-to-end sítě k všudypřítomnému překladu adres (NAT), dodatečným zabezpečením veškeré komunikace, jakož i zavedením nové třídy adres IPv6.

Postupným přidáváním nových funkcí protokolu i typů záznamů v databázi, navíc za pochodu, se z DNS vcelku logicky stal solidní moloch. Pokud se s ním člověk chce seznámit aspoň do té hloubky, aby si v diskusích s experty nepřipadal trapně, musí přečíst bratru tucet dokumentů RFC, ale navíc si osvojit i některé vědomosti a žargon, které se šíří spíše neformálními kanály. Tato kniha je v tomto ohledu velmi vítaným pomocníkem, neboť tuto sumu informací nejen integruje z různých zdrojů, ale navíc přístupnou formou vysvětluje a doplňuje ukázkami a příklady. Velice se mi líbí i skvělé ilustrace a diagramy, které text doprovázejí, jakož i celkové typografické zpracování knihy.

Speciální pochvalnou zmínku zasluhuje část II (DNS pro starší a pokročilé), která se věnuje několika opravdu komplikovaným součástem DNS. Nevím o jiném textu, který by tak podrobně a přitom srozumitelně popisoval teorii i praxi bezpečnostních rozšíření DNSSEC (DNS Security Extensions). Kapitola 10 pak pěkně vysvětluje složitý algoritmus, jímž se beze změny protokolu DNS realizují doménová jména v neanglických abecedách (IDN, Internationalized Domain Names). Jsou zde také vysvětleny důvody a potíže, kvůli nimž prozatím nebyla jména s nabodeníčky v doméně .cz zavedena.

Velmi zajímavá je i 7. kapitola, v níž jsou popsány principy, aktéři a historie správy kořenové domény DNS i naší „národní“ domény .cz. Jako pamětník a aktivní uživatel předchozí československé domény jsem s nostalgií zavzpomínal na ony pionýrské doby, kdy mnozí opravdoví muži a ženy instalovali DNS server BIND na dnes již neexistující operační systémy a zřízení nových domén druhé úrovně domlouvali „po sousedsku“ s kolegy z VŠCHT.

Knihu mohu doporučit ke studiu i zástupcům netechnických profesí – právníkům, ekonomům, marketérům, ba i politikům – byť z ní třeba přečtou jen pár úvodních kapitol. I z nich se totiž mohou dozvědět nejen jak DNS funguje, ale také proč není dobré tento protokol ohýbat a zneužívat k věcem, pro něž nebyl určen.

Přeji vám příjemné čtení!

Ladislav Lhotka

České Budějovice, srpen 2023

Předmluva

Domain Name System je fascinující hned z několika pohledů. Jedná se o klíčovou službu Internetu, kterou všichni denně využíváme, ale přitom „není vidět“. Automaticky používáme doménová jména k identifikaci webů nebo v poštovních adresách a nezabýváme se tím, jak budou převedena na číselné adresy, jež potřebuje IP pro navázání komunikace.

Druhým fascinujícím aspektem DNS je, jak složitý a košatý systém vyrostl na původně jednoduchých základech. Stále platí RFC 1034 a RFC 1035, která v roce 1987 definovala protokol a datové struktury systému. Od té doby vzniklo (a zaniklo) mnoho typů záznamů, rozhojnily se přenosové protokoly a DNS začalo být využíváno i tam, kde se s ním původně vůbec nepočítalo. V tomhle připomíná samotný Internet, jehož základní principy jsou také velmi jednoduché a nadstavba nad nimi monumentální.

DNS je silně distribuované a o data v něm obsažená se starají miliony správců. Jsme lidé, děláme chyby. Občas nás pozlobí technika, tu a tam se někdo pokouší i cíleně škodit. Navzdory tomu celý tenhle Babylon dlouhodobě velmi dobře funguje. Výpadek DNS je velmi citlivá věc, protože znepřístupní Internet uživatelům i strojům. V globálním měřítku k němu nedošlo nikdy a jakékoli rozsáhlejší výpadky jsou velmi vzácné.

Systém je zkrátka velmi robustní a díky tomu platí, co jsme napsali v prvním odstavci – automaticky používáme doménová jména a nezabýváme se tím, jak je DNS převede na IP adresy. Protože to prostě funguje.

V knize popisujeme, proč a jak DNS funguje. Je rozdělena do čtyř částí: První se věnuje základům. Vysvětlujeme v ní základní pojmy a pravidla komunikace, používané transportní protokoly či konfiguraci klienta a zabýváme se i organizačními záležitostmi, tedy jak je celý systém spravován a jak získat doménu. Ve druhé části se zabýváme pokročilejšími prvky DNS, jako je jeho ochrana pomocí DNSSEC nebo používání národních znaků v doménových jménech. Dostaneme se i k jeho využívání jinými službami či k bezpečnosti protokolu.

Třetí část je poněkud encyklopedická. Probíráme zde různé typy záznamů, do nichž jsou v DNS ukládána data. Je jich přes osmdesát, takže jsme je uspořádali do několika tematických skupin. Čtvrtá část je věnována DNS serverům. Nemůže chybět dominantní BIND, s nímž je historie DNS do velké míry spjata. Kromě něj jsme se pokusili představit několik dalších, které jsou ve větší míře používány. V přílohách pak najdete vybraná RFC a rejstřík pro snazší orientaci v textu.

Děkujeme všem, kteří přispěli ke vzniku tohoto textu. V první řadě si zaslouží poděkování naše rodiny, které statečně snášely naše sepisování a trpělivě nám poskytovaly potřebné zázemí. Za obsahové připomínky děkujeme zejména Ondřeji Caletkovi, Vladimíru Čunátovi, Tomáši Hálovi a Danielu Salzmanovi, jejich návrhy pomohly text vylepšit.

Pavel Satrapa, Ondřej Filip

Liberec, Praha, září 2023

Obsah

1. Předmluva vydavatele

2. 1 Jemný úvod do DNS

1. 1.1 Historie DNS

2. 1.2 K čemu slouží

3. I Základní principy

1. 2 Jak to funguje

1. 2.1 Doménový strom

2. 2.2 DNS záznamy

3. 2.3 Domény a servery

4. 2.4 Resolver čili řešič

5. 2.5 Život jednoho dotazu

6. 2.6 Rekurzivní a nerekurzivní chování serverů

7. 2.7 Domény, zóny a zónové soubory

8. 2.8 Reverzní dotazy aneb hledá se jméno pro adresu

2. 3 Vnitřní život DNS

1. 3.1 Doménová jména

2. 3.2 Formát DNS zpráv

3. 3.3 Komunikace mezi klientem a serverem

1. 3.3.1 Klient

2. 3.3.2 Server

4. 3.4 Zónové přenosy

5. 3.5 Žolíkové záznamy

6. 3.6 Vyrovnávací paměť

3. 4 DNS z pohledu klienta

1. 4.1 Konfigurace

1. 4.1.1 Microsoft Windows 11

2. 4.1.2 Microsoft Windows 10, 8 a 7

3. 4.1.3 Linux a systémy odvozené z Unixu

4. 4.1.4 macOS

2. 4.2 Programy pro dotazování DNS

1. 4.2.1 host

2. 4.2.2 nslookup

3. 4.2.3 dig

3. 4.3 Resolver a relativní jména

4. 4.4 DNS přímo z aplikace

4. 5 Transportní vrstva pro DNS

1. 5.1 UDP

2. 5.2 TCP

3. 5.3 Stavové DNS

4. 5.4 Šifrované DNS

5. 5.5 DNS po TLS (DoT)

6. 5.6 DNS po DTLS (DoD)

7. 5.7 DNS po HTTPS (DoH)

8. 5.8 DNS po QUIC (DoQ)

5. 6 DNS v praxi

1. 6.1 Scénáře použití

1. 6.1.1 Pouze klienti

2. 6.1.2 Klienti a autoritativní server

3. 6.1.3 Neveřejný autoritativní server

4. 6.1.4 DNS hosting

5. 6.1.5 Otevřené rekurzivní servery

2. 6.2 Návrh nasazení DNS

3. 6.3 Podpůrné programy

1. 6.3.1 Programy doprovázející server

2. 6.3.2 Zonemaster

3. 6.3.3 dnswalk

4. 6.3.4 Squish DNS Checker

5. 6.3.5 MX Toolbox

6. 6.3.6 DNSDiag

7. 6.3.7 DNS Benchmark

8. 6.3.8 Programy pro správu DNS dat

6. 7 Správa domén a vlastně i celého Internetu

1. 7.1 Jak to celé začalo

2. 7.2 Éra ICANN

3. 7.3 Rozšiřování domén nejvyšší úrovně

4. 7.4 Správa kořenové zóny

5. 7.5 Klíče od Internetu

6. 7.6 Správa domén – registr, registrátor, držitel

7. 7.7 Registrace domény

8. 7.8 Vlastní registrace

9. 7.9 Informace o doménách a držitelích

10. 7.10 Historie domény cz a sdružení CZ.NIC

4. II DNS pro starší a pokročilé

1. 8 Principy DNSSEC

1. 8.1 Digitální podpisy

2. 8.2 Autentizační řetězec

3. 8.3 Když řetězec nenavazuje

4. 8.4 Ověřená neexistence

5. 8.5 Příklad

6. 8.6 Chování serverů a klientů

7. 8.7 DNSSEC a žolíkové záznamy

2. 9 DNSSEC prakticky

1. 9.1 Ověřování odpovědí

2. 9.2 Klíče

3. 9.3 Podpis vlastní zóny

4. 9.4 Dokumentace

3. 10 Národní znaky v doménách, čili IDN

1. 10.1 Jak funguje IDN

1. 10.1.1 Přípustné znaky a jmenovky

2. 10.1.2 Punycode

3. 10.1.3 IDNA2003 – Nameprep, ToASCII a ToUnicode

2. 10.2 Problémy a otázky

1. 10.2.1 Bezpečnost

2. 10.2.2 Přístupnost

3. 10.2.3 Politika a strategie

3. 10.3 IDN ve světě a u nás

4. 11 Dynamické DNS

1. 11.1 Jak funguje

2. 11.2 Chování serveru

3. 11.3 Zase ta bezpečnost

4. 11.4 Praktický příklad

5. 12 ENUM

1. 12.1 Jak funguje

2. 12.2 Nasazení

3. 12.3 Infrastrukturní ENUM

4. 12.4 Situace v České republice

6. 13 Na pokraji DNS

1. 13.1 Skupinové DNS (mDNS)

2. 13.2 Link-Local Multicast Name Resolution (LLMNR)

3. 13.3 Výběrové adresování aneb anycast

4. 13.4 DNS a rozkládání zátěže

5. 13.5 Aktivní server aneb DNS push

6. 13.6 Katalogové zóny

7. 14 DNS v cizích službách

1. 14.1 SPF – Sender Policy Framework

2. 14.2 Sender ID

3. 14.3 DKIM – DomainKeys Identified Mail

4. 14.4 DNSBL a seznamy hodných, zlých a ošklivých

5. 14.5 Automatická konfigurace poštovních klientů

6. 14.6 DNS a objevování služeb (DNS-SD)

7. 14.7 Certifikáty, klíče, PKI a další bezpečnostní harampádí

8. 14.8 DNS a TLS čili DANE

9. 14.9 Osobní certifikáty a klíče pro elektronickou poštu

8. 15 Bezpečnost protokolu DNS

1. 15.1 Bellovinův útok

2. 15.2 Kaminského útok aneb otrávení vyrovnávací paměti

3. 15.3 Fragmentační útoky

4. 15.4 Útok náhodnými dotazy

5. 15.5 Útok nekonečnou rekurzí

6. 15.6 Zesilované útoky

7. 15.7 Lhaní pod kontrolou aneb RPZ

8. 15.8 Ochrana soukromí a minimalizace dotazů

5. III Typy záznamů

1. 16 Obecně o zdrojových záznamech

2. 17 Základní typy

1. 17.1 A – Address (1)

2. 17.2 AAAA – IPv6 Address (28)

3. 17.3 CNAME – Canonical Name (5)

4. 17.4 MX – Mail Exchange (15)

5. 17.5 NS – Name Server (2)

6. 17.6 PTR – Pointer (12)

7. 17.7 SOA – Start of Authority (6)

8. 17.8 TXT – Text (16)

3. 18 Servisní typy

1. 18.1 AXFR – Full Zone Transfer (252)

2. 18.2 CSYNC – Child-to-Parent Synchronization (62)

3. 18.3 DHCID – DHCP Identifier (49)

4. 18.4 DNAME – Delegation Name (39)

5. 18.5 IXFR – Incremental Zone Transfer (251)

6. 18.6 OPT – Option (41)

4. 19 Typy pro DNSSEC a bezpečnostní mechanismy

1. 19.1 CAA – Certificate Authority Authorization (257)

2. 19.2 CDNSKEY – Child DNS Key (60)

3. 19.3 CDS – Child Delegation Signer (59)

4. 19.4 CERT – Certificate (37)

5. 19.5 DNSKEY – DNS Key (48)

6. 19.6 DS – Delegation Signer (43)

7. 19.7 IPSECKEY – IPsec Key (45)

8. 19.8 KEY (25)

9. 19.9 NSEC – Next Secure (47)

10. 19.10 NSEC3 – Next Secure version 3 (50)

11. 19.11 NSEC3PARAM – NSSEC3 Parameters (51)

12. 19.12 OPENPGPKEY (61)

13. 19.13 RRSIG – RR Signature (46)

14. 19.14 SIG – Signature (24)

15. 19.15 SMIMEA (53)

16. 19.16 SSHFP – SSH Key Fingerprint (44)

17. 19.17 TKEY – Transaction Key (249)

18. 19.18 TLSA (52)

19. 19.19 TSIG – Transaction Signature (250)

20. 19.20 ZONEMD – Zone Message Digest (63)

5. 20 Aplikační a ostatní typy

1. 20.1 AMTRELAY (260)

2. 20.2 EUI48 (108)

3. 20.3 EUI64 (109)

4. 20.4 HIP – Host Identity Protocol (55)

5. 20.5 L32 – Locator32 (105)

6. 20.6 L64 – Locator64 (106)

7. 20.7 LP – Locator Pointer (107)

8. 20.8 NAPTR – Naming Authority Pointer (35)

9. 20.9 NID – Node Identifier (104)

10. 20.10 NULL (10)

11. 20.11 SRV – Service (33)

12. 20.12 URI – Uniform Resource Identifier (256)

6. 21 Typy odmítnuté, zastaralé a nepoužívané

1. 21.1 A6 – IPv6 Address (38)

2. 21.2 AFSDB – AFS Data Base (18)

3. 21.3 APL – Address Prefix List (42)

4. 21.4 ATMA – ATM Address (34)

5. 21.5 DLV – DNSSEC Lookaside Validation (32769)

6. 21.6 EID – Endpoint Identifier (31)

7. 21.7 GID (102)

8. 21.8 GPOS – Geographical Position (27)

9. 21.9 HINFO – Host Information (13)

10. 21.10 ISDN (20)

11. 21.11 KX – Key Exchanger (36)

12. 21.12 LOC – Location (29)

13. 21.13 MAILA – Mail Agent (254)

14. 21.14 MAILB – Mailbox Related (253)

15. 21.15 MB – Mailbox (7)

16. 21.16 MD – Mail Destination (3)

17. 21.17 MF – Mail Forwarder (4)

18. 21.18 MG – Mail Group (8)

19. 21.19 MINFO – Mail Information (14)

20. 21.20 MR – Mail Rename (9)

21. 21.21 NIMLOC – Nimrod Locator (32)

22. 21.22 NINFO – Zone Information (56)

23. 21.23 NSAP – NSAP Address (22)

24. 21.24 NSAP-PTR – NSAP Pointer (23)

25. 21.25 NXT – Next Domain (30)

26. 21.26 PX – X.400 Mail Mapping (26)

27. 21.27 RKEY – Resource Key (57)

28. 21.28 RP – Responsible Person (17)

29. 21.29 RT – Route Through (21)

30. 21.30 SINK – Kitchen Sink (40)

31. 21.31 SPF – Sender Policy Framework (99)

32. 21.32 TA – DNSSEC Trust Authorities (32768)

33. 21.33 UID (101)

34. 21.34 UINFO (100)

35. 21.35 UNSPEC (103)

36. 21.36 WKS – Well Known Service (11)

37. 21.37 X25 – X.25 Address (19)

6. IV DNS servery

1. 22 Obecně ke konfiguraci serveru

1. 22.1 Typ serveru a obsluhovaná komunita

2. 22.2 Zónové soubory

1. 22.2.1 localhost

2. 22.2.2 Reverzní zóny pro localhost

3. 22.2.3 Kořenové servery

3. 22.3 Ošetření nesmyslných reverzních dotazů

2. 23 BIND

1. 23.1 Základní konfigurace

1. 23.1.1 Autoritativní server

2. 23.1.2 Rekurzivní server

3. 23.1.3 Smíšený server

2. 23.2 Doprovodné programy

1. 23.2.1 Kontrola konfigurace a dat

2. 23.2.2 rndc – pan řídící

3. 23.3 Konfigurace pro náročné

1. 23.3.1 Automatické podepisování DNSSEC

2. 23.3.2 Pohledy

4. 23.4 Bundy, dříve BIND 10

3. 24 NSD

1. 24.1 Základní konfigurace

2. 24.2 Doprovodné programy

1. 24.2.1 nsd-checkconf

2. 24.2.2 nsd-control

3. 24.3 Konfigurace pro náročné

1. 24.3.1 DNSSEC

2. 24.3.2 Dynamické zóny

3. 24.3.3 Omezování frekvence dotazů

4. 25 Unbound

1. 25.1 Základní konfigurace

2. 25.2 Doprovodné programy

1. 25.2.1 unbound-checkconf

2. 25.2.2 unbound-control

3. 25.2.3 unbound-host

3. 25.3 Konfigurace pro náročné

1. 25.3.1 Řízení vyrovnávací paměti a optimalizace

2. 25.3.2 Speciální zóny a předávání dotazů

5. 26 Knot DNS

1. 26.1 Základní konfigurace

2. 26.2 Doprovodné programy

1. 26.2.1 knotc

2. 26.2.2 kdig a khost

3. 26.3 Pokročilé nastavení

1. 26.3.1 DNSSEC

2. 26.3.2 Moduly

3. 26.3.3 Dynamické aktualizace

6. 27 Knot Resolver

1. 27.1 Základní konfigurace

2. 27.2 Spuštění a komunikace s programem

7. 28 PowerDNS

1. 28.1 Základní konfigurace

2. 28.2 Doprovodné programy

1. 28.2.1 WWW server

2. 28.2.2 pdns_control

3. 28.2.3 zone2sql

3. 28.3 Konfigurace pro náročné

1. 28.3.1 DNSSEC

2. 28.3.2 Dynamické aktualizace

8. 29 PowerDNS Recursor

1. 29.1 Základní konfigurace

2. 29.2 Doprovodné programy

1. 29.2.1 rec_control

3. 29.3 Konfigurace pro náročné

1. 29.3.1 Speciální zóny

2. 29.3.2 Skriptování

9. 30 OpenDNSSEC

1. 30.1 Koncepce programu

2. 30.2 Instalace a konfigurace

3. 30.3 Provoz

4. 30.4 Bezpečnostní modul

7. V Přílohy

1. A Přehled RFC

1. A.1 Jádro protokolu

2. A.2 Transport

3. A.3 Speciální prvky a typy záznamů

4. A.4 DNSSEC

5. A.5 IDN

6. A.6 ENUM

7. A.7 IPv6

8. A.8 Různé

9. A.9 Související technologie

2. Literatura

3. Rejstřík

Jemný úvod do DNS

Kapitola 1

Jemný úvod do DNS

Domain Name System (DNS) patří mezi nejstarší a nejdůležitější služby sítě Internet. Kdybyste se však běžného uživatele zeptali, zda ji používá, pravděpodobně by vůbec netušil, o čem mluvíte. DNS sice během komunikace v síti využíváme každou chvíli, jedná se však o službu poměrně neviditelnou, která má ryze servisní charakter. Vnímáme jako samozřejmost, že můžeme cíle v síti pojmenovávat ve stylu www.nic.cz a příliš neuvažujeme o tom, že v pozadí této přirozené vlastnosti stojí rozsáhlý mechanismus, na jehož chodu se podílejí statisíce správců z celého světa.

1.1 Historie DNS

Počítačové sítě používají pro identifikaci počítačů číselné adresy. Platí to pro současný Internet a jeho Internet Protocol verze 4, platilo to pro jeho předchůdce i všechny konkurenční síťové architektury a bude to platit i pro nastupující Internet Protocol verze 6. Pro uživatele jsou však číselné adresy nepohodlné a obtížně zapamatovatelné, stejně jako třeba telefonní čísla. Znáte třeba 142.251.37.100? Nebo 2a00:1450:4014:80f::2004? Určitě ano, ovšem nejspíš jej oslovujete jako www.google.com. Je zcela pochopitelné, že snahy zavést pro číselné adresy snadněji zapamatovatelná jména mají kořeny již v šerém síťovém dávnověku.

Už když se Internet ještě jmenoval ARPAnet a byla do něj zapojena jen hrstka počítačů, objevily se první snahy zavést „adresář“ počítačů a používat jména místo číselných adres. Tehdejší přístup se podobal tomu, co dnes známe z kontaktů v mobilních telefonech – každý počítač měl svůj vlastní seznam známých jmen, nezávislý na ostatních. Tato schopnost ostatně zůstala zachována dodnes. V operačních systémech odvozených od Unixu najdete soubor /etc/hosts obsahující jednoduchou převodní tabulku. Slouží jako doplněk DNS a obvykle obsahuje pouze údaje o vlastním počítači, něco jako:

127.0.0.1   localhost

127.0.1.1   pokus.nic.cz      pokus

# IPv6

::1         localhost ip6-localhost ip6-loopback

fe00::0     ip6-localnet

ff00::0     ip6-mcastprefix

ff02::1     ip6-allnodes

ff02::2     ip6-allrouters

ff02::3     ip6-allhosts

Jak vidíte, převod jména localhost na IPv4 adresu 127.0.0.1 či IPv6 adresu ::1 se provádí lokálně prostřednictvím tohoto souboru. V operačních systémech firmy Microsoft najdete soubor hosts také. Počínaje Windows NT a Windows XP se nachází ve složce system32\drivers\etc\, ve starších Windows 95 a 98 byl umístěn přímo v systémové složce. Cestu k němu lze nastavit v registrech.

Izolovaná lokální správa převodu jmen na adresy má zjevně sklon k nekonzistenci. Tentýž cíl se na různých místech může vyskytovat pod odlišnými jmény, ledacos bude chybět, uživatel se zkrátka na cizím počítači nemůže na nic spolehnout. Dokud bylo počítačů v síti málo, snažili se tomu její správci čelit vydáváním centrálního adresáře. Na pevně daném místě udržovali veřejně dostupnou aktuální verzi souboru hosts, zahrnující jména a adresy všech připojených počítačů. Správci jednotlivých systémů si jej stahovali a instalovali. Aktuálnost poskytovaných informací závisela na píli správce centrálního úložiště a správce místního stroje.

S rostoucím počtem připojených počítačů tento systém přestával stačit. Bylo potřeba vymyslet lepší řešení, nejlépe takové, které by adresy vyhledávalo on-line v okamžiku použití a bylo tak vždy aktuální. Počáteční varianty zůstávaly u centralizovaného přístupu. Nadále existoval jeden společný adresář počítačů, jen jeho kompletní distribuci nahradilo cílené dotazování na konkrétní jména. Na tomto principu je postaven Hostname Server definovaný v RFC 811 a později RFC 953. Poskytuje aktuální informace odpovídající stavu centrální databáze, ovšem s rostoucím počtem připojených strojů rychle narazí na meze své škálovatelnosti. Představte si, že by se tímto způsobem někdo pokusil pojmenovat současný Internet s několika miliardami připojených zařízení.

DNS vzniklo jako přímý konkurent Hostname Serveru a řešilo tento problém. Klíčové požadavky a předpoklady, jež stály u jeho kolébky, byly:

- vytvořit konzistentní systém jmen identifikujících jednotlivé zdroje,

- poskytovat aktuální informace,

- umožnit distribuovanou správu dat, aby informace zadával pokud možno místní správce,

- lze očekávat, že většina dat se bude měnit jen velmi pomalu (ale systém musí být schopen zvládat rychle se měnící údaje),

- systém by měl být efektivní a nezatěžovat příliš komunikační infrastrukturu,

- dostupnost údajů je důležitější než stoprocentní konzistence.

Na základě těchto východisek vznikl silně distribuovaný a redundantní Domain Name System. Skládá se ze tří základních částí:

- Data, tedy stromově uspořádaný jmenný prostor a v něm se nacházející záznamy s informacemi o vlastnostech jednotlivých prvků.

- Servery, které mají uloženy části datového stromu – informace o jednotlivých doménách a vztazích mezi nimi – a odpovídají na dotazy.

- Klienti (resolvery) představují rozhraní systému vůči uživatelským aplikacím. Pokládají dotazy serverům a zpracovávají jejich odpovědi.

Požadavek na efektivitu vedl k zavedení vyrovnávacích pamětí (cache). Ty se mohou vyskytovat jak u klientů, tak u serverů a umožňují opětovně využívat nedávno získané informace, které však již nemusí odpovídat aktuálnímu stavu. Odpověď proto obsahuje příznak, zda pochází od autoritativního zdroje či z vyrovnávací paměti.

Vysokou dostupnost řeší DNS redundancí – každá doména musí být poskytována alespoň dvěma nezávislými servery, což opět může ohrozit konzistenci dat (na jednom již byla provedena změna, na druhém zatím ne). Systém se k problému staví pragmaticky. Bere riziko drobných a časově omezených nekonzistencí, jako jsou zastaralé informace ve vyrovnávací paměti či odlišnost verzí poskytovaných pro tutéž doménu různými servery, za přijatelnou cenu, již platíme za dostupnost a efektivitu.

Autorem DNS je Paul Mockapetris, který jeho základní specifikaci publikoval koncem roku 1983 v RFC 882 Domain Names – Concepts and Facilities a RFC 883 Domain Names – Implementation and Specification. Vytvořil také první implementaci navrženého mechanismu a brzy po ní následovaly další. V roce 1984 se objevila první implementace pro operační systém Unix, kterou o rok později významně změnil a přejmenoval Kevin Dunlap. Pro svou verzi zvolil jméno BIND – Berkeley Internet Name Domain a výsledný program se stal legendou. Zcela ovládl pole, prosadil se snad do všech operačních systémů odvozených od Unixu jako jejich standardní součást, dočkal se portace i do jiných systémů, stal se de facto standardem a dodnes jej používá drtivá většina DNS serverů. Od roku 1988 jej udržoval a rozvíjel Paul Vixie, s jehož jménem je BIND nejčastěji spojován.

Praktické zkušenosti s provozem DNS se promítly do druhé generace jeho dokumentů. Koncem roku 1987 vyšla dvojice RFC 1034 a RFC 1035, která nahradila původní specifikace RFC 882 a RFC 883. Tyto dva základní dokumenty zůstávají v platnosti dodnes. Protokolům, jež tvoří jádro DNS, je tedy již přes 30 let. Existuje k nim pochopitelně řada pozdějších doplňků a rozšíření, z nichž mimořádný význam mají zejména Internationalized Domain Names (IDN) umožňující používat ve jménech znaky národních abeced a Domain Name System Security Extensions (DNSSEC), díky němuž lze ověřit pravost obsahu DNS a chránit se proti podvrhům. Neustále se také rozšiřuje sortiment informací, které DNS poskytuje.

1.2 K čemu slouží

Základním úkolem DNS a příčinou jeho vzniku byl převod symbolických jmen na IP adresy, aby si je uživatelé nemuseli pamatovat. To ovšem není zdaleka jediná služba, kterou nabízí. Ostatně, když už se podařilo vyvinout dobře fungující distribuovanou databázi, byla by škoda ji nevyužít i pro další účely. Jako první se samozřejmě nabízí převod opačným směrem aneb zjištění, pod jakým jménem je v DNS zaregistrována určitá IP adresa. Tato informace se hodí pro protokoly o činnosti různých serverů, abychom mohli třeba analyzovat, odkud přichází nejvíce klientů dané služby, nebo pro zobrazení výsledků příkazu traceroute. Výpis ve tvaru:

1  router-h (147.230.16.3)

2  147.230.250.49 (147.230.250.49)

3  195.113.235.101 (195.113.235.101)

4  cesnet.rt1.pra.cz.geant2.net (62.40.124.29)

5  so-6-3-0.rt1.fra.de.geant2.net (62.40.112.38)

6  abilene-wash-gw.rt1.fra.de.geant2.net (62.40.125.18)

7  so-0-0-0.0.rtr.atla.net.internet2.edu (64.57.28.6)

8  so-3-2-0.0.rtr.hous.net.internet2.edu (64.57.28.43)

9  so-3-0-0.0.rtr.losa.net.internet2.edu (64.57.28.44)

10  hpr-lax-hpr--i2-newnet.cenic.net (137.164.26.132)

11  ucla--lax-hpr1-ge.cenic.net (137.164.27.6)

12  border-1--core-1-10ge.backbone.ucla.net (169.232.4.100)

13  core-1--anderson-2-ge.backbone.ucla.net (169.232.8.31)

dává slušnou představu, kterými sítěmi a lokalitami pakety procházely. Rozhodně výrazně lepší než samotné adresy. Ostatně, poznali byste bez DNS, že 64.57.28.6 leží v Atlantě, 64.57.28.43 v Houstonu a 64.57.28.44 v Los Angeles?

DNS využívají všechny síťové služby. Některé jen k tomu, aby mohly používat jména zúčastněných strojů a nikoli jejich adresy, jiné si z DNS berou klíčové informace pro svou činnost. Nejvýznamnějším představitelem této skupiny je nepochybně elektronická pošta. DNS totiž obsahuje údaje o tom, které servery přijímají poštu pro danou doménu. Řekněme, že pošlete dopis na adresu kontakt@nic.cz. Váš poštovní server ji podle zavináče rozdělí na uživatelské jméno a doménu a následně kontaktuje DNS, aby zjistil, které poštovní servery zajišťují příjem pošty pro doménu nic.cz. Dozví se, že nejvhodnější je mail.nic.cz a případně může použít i mx.nic.cz. DNS mu dodá jejich jména, adresy i priority. V uvedeném pořadí se je pokusí kontaktovat a předat jim váš dopis.

Mimochodem, právě díky tomu je elektronická pošta velmi rychlá a efektivní. Stejnou informaci o přijímajících serverech dostane tazatel z celého Internetu – ať se server odesílající dopis nachází v Praze, Paříži či v Buenos Aires, pokaždé se dozví, že má nejprve zkusit kontaktovat mail.nic.cz a doručí díky tomu dopis rovnou skoro až domů. Cesta elektronického dopisu proto obvykle zahrnuje jen několik málo skoků.

Tím však spolupráce elektronické pošty a DNS nemusí zdaleka končit. V rámci boje proti všudypřítomnému spamu se objevila některá řešení, která využívají DNS k posouzení míry důvěryhodnosti přicházejícího dopisu. Do této skupiny patří například Sender Policy Framework (SPF) či DomainKeys Identified Mail (DKIM). DNS totiž kromě jednoúčelových záznamů s pevně definovaným obsahem, jako jsou například IP adresy, nabízí i obecnější prostředky. Značné popularitě se těší zejména obecný textový záznam, díky němuž lze do DNS uložit ledacos. Mechanismy jako SPF či DKIM obvykle stanoví určité pevně dané jméno záznamu a strukturu textové informace v něm obsažené. Příslušný záznam si pak vyzvednou a podle jeho obsahu dopis posoudí.

Příklady táhnou a DNS jako fungující distribuovaná databáze monumentálních rozměrů nachází další a další uplatnění. Po bok elektronické pošty se časem zařadily i další aplikace, které pilně pracují s DNS a hledají v něm informace pro svou potřebu. Patří mezi ně i IP telefonie, která si pod označením ENUM zavedla svůj vlastní typ záznamů i organizaci části doménového stromu. Využívá jej k překladu mezi telefonními čísly používanými v klasickém telefonním světě a IP adresami, protokoly a porty, s nimiž pracuje telefonie v počítačové síti.

Podstatnou nevýhodou DNS je, že své informace poskytuje bez záruk. Pro technicky zdatného a motivovaného útočníka není velkým problémem je podvrhnout a docílit toho, že po zadání jména přistanete na úplně jiném serveru, než jste zamýšleli. Proto vznikl bezpečnostní mechanismus DNSSEC, který tento problém pomocí digitálních podpisů odstraňuje a činí DNS atraktivním pro další aplikace. Mimo jiné se v něm objeví důvěryhodné kryptografické klíče, které lze využít pro šifrování či ověřování podpisů.

Bohužel se DNSSEC do praxe prosazuje jen ztěžka a pomalu, což omezuje některé další možnosti využití DNS. My jsme na tom dobře. Doména cz byla podepsána mezi prvními a patří dlouhodobě v této oblasti ke světové špičce. V polovině roku 2023 byla podepsána více než polovina jejích poddomén, jinde je ale situace o poznání horší. Pokud se DNSSEC dostatečně rozšíří, DNS se docela dobře může stát kýženou infrastrukturou veřejných klíčů (PKI), kterou si bezpečnostní inženýři vysnili už před dlouhými lety, která je však dosud reálná asi jako jednorožec.

Část I

Základní principy

První část knihy popisuje základní konstrukce DNS světa a principy, na nichž je postaven. Seznámíte se s uspořádáním domén, úlohami jednotlivých programů, vzájemnými vztahy mezi nimi a postupu při hledání odpovědi na dotaz.

Další kapitola zevrubně popisuje data – formáty zpráv, pravidla pro komunikaci mezi klienty a servery, či využití vyrovnávacích pamětí. Klientům v nejběžnějších operačních systémech se pak věnuje samostatná kapitola.

Jelikož se nám postupem času zkomplikovala otázka vzájemné komunikace mezi klientem a serverem, vyhradili jsme celou kapitolu popisu transportní vrstvy a jejích různých protokolů využívaných pro DNS.

Závěr první části se zabývá praktickými tématy. Dozvíte se, jak vypadá správa jednotlivých domén, které organizace se na ní podílejí a v jakých úlohách i jak prakticky postupovat, pokud si hodláte pořídit vlastní doménu. Závěrečná kapitola poskytuje praktická doporučení pro návrh a provoz DNS a doporučení užitečných programů, které vám tuto úlohu usnadní.

Kapitola 2

Jak to funguje

V této kapitole se podíváme trochu podrobněji, co se skrývá pod kapotou DNS – jak vypadá doménový strom, jaké informace obsahuje, jakou roli mají servery při vyřizování dotazů a jak všechny součásti vzájemně spolupracují. Stará programátorská poučka říká, že návrh by měl vždy začínat datovými strukturami. Proto se nejprve podívejme na data v DNS – doménový strom a zdrojové záznamy. Pak budeme pokračovat zbývajícími částmi systému – servery a resolvery.

2.1 Doménový strom

Z hlediska obsahu je klíčovou komponentou DNS doménový strom. V této datové struktuře jsou hierarchicky uspořádány veškeré informace, které obsahuje. Všichni víte, že doménová jména se zapisují v podobě www.fm.tul.cz – jednotlivé domény jsou v zápisu oddělovány tečkami a uvádějí se v pořadí od konkrétních k těm nejobecnějším. Jméno však zároveň funguje – směrem zezadu dopředu – jako popis průchodu doménovým stromem. V tomto konkrétním případě říká, že z kořene doménové stromu je třeba jít do domény cz (označující Českou republiku), z ní pokračovat do její poddomény tul (Technická univerzita v Liberci), dále pokračovat do poddomény fm (Fakulta mechatroniky) a v ní navštívit poddoménu www. Doménové jméno tedy jednoznačně identifikuje konkrétní uzel v doménovém stromě a zároveň popisuje cestu od kořene k němu. Zejména tato druhá vlastnost je klíčová, protože je využívána při hledání odpovědi.

Obrázek 2.1: Doménový strom

Zastavme se ještě chvíli u vlastního doménového stromu. Jako každý správný strom obsahuje jediný kořen – tak zvanou kořenovou doménu (root domain). Jelikož je jediná, nemá smysl ji ve jméně uvádět, a proto ji v zápisu nenajdete. V případě nutnosti se zapisuje jako samotná tečka (tímto způsobem je také znázorněna na našich obrázcích).

Některé nástroje či konfigurační soubory rozlišují mezi absolutně a relativně zadaným doménovým jménem. Absolutně zadané jméno končí tečkou – například www.nic.cz. – a znamená to, že je úplné, protože obsahuje všechny údaje až po kořenovou doménu. Používá se pro ně také pojem plné či plně specifikované doménové jméno, v originále Fully Qualified Domain Name (FQDN).

Pokud na konci není tečka, chápe se jako jméno relativní a příslušný program si k němu doplní, či alespoň může doplnit, nějakou koncovku. Zkuste si třeba do WWW prohlížeče zadat jako cílovou adresu jen samotné www a uvidíte, že si k němu iniciativně něco doplní a přistanete na konkrétním webu. Relativní jména jsou běžná v datových souborech DNS, kde se vždy vztahují k aktuální doméně. Jinak bychom se upsali. Problematika je složitější, protože nelze chtít po uživatelích, aby jména důsledně ukončovali tečkou. Operační systémy a aplikace proto odhadují, zda jméno bez tečky na konci skutečně je či není relativní. Jejich chování se budeme věnovat podrobněji v části 4.3 na straně 250.

Hlavní úlohou kořenové domény je držet celý strom pohromadě a poskytnout výchozí bod pro řešení dotazů. Bezprostředně pod ní se nacházejí tak zvané domény nejvyšší úrovně (top-level domains, TLD). Původně vznikly s cílem stručně charakterizovat držitele domény a zároveň snížit pravděpodobnost konfliktů. Když DNS přišlo na svět, mělo na nejvyšší úrovni pět domén: com pro komerční firmy, edu pro vzdělávací instituce, gov pro vládu, mil pro vojáky a org pro organizace nezařaditelné do žádné z ostatních kategorií. Záhy k nim přibyly domény jednotlivých států a postupem času i další. Podle určení a klíčových vlastností je lze rozdělit do čtyř základních kategorií (Carl von Linné by měl radost):

- Obecné domény (generic top-level domains, gTLD) navazují na původní členění. Dělí se do dvou odrůd: Nesponzorované obecné domény, jako například com, net, org nebo info, patří do přímé kompetence ICANN. Sponzorované obecné domény (sTLD) jsou založeny a spravovány určitou organizací, která určuje podmínky pro registraci v nich. Bývají vymezeny geograficky nebo tematicky, například v sTLD aero mohou získat poddoménu jen subjekty působící v oblasti letectví. Jako další příklady sponzorovaných obecných domén lze jmenovat asia, jobs, museum či xxx.

- Státní domény (country-code top-level domains, ccTLD) jsou domény přidělené jednotlivým státům. Jejich zkratky odpovídají (až na několik výjimek) dvoupísmenným zkratkám příslušných států podle standardu ISO 3166-1. Jistě nejvýznamnější výjimkou je doména eu pro Evropskou unii. Za zmínku stojí též britská doména uk, přestože Velká Británie má ve zmiňovaném standardu přidělenu zkratku gb. Důvody výjimek jsou zpravidla historické.

- Státní domény v národních abecedách (internationalized ccTLD, IDN ccTLD) odpovídají, podobně jako předchozí kategorie, jednotlivým státům. Jejich názvy jsou ovšem zapsány v národních abecedách, které nevycházejí z latinky (čínská, arabská a další písma). Problematiku ne-ASCII jmen probereme podrobněji v kapitole 10 na straně 561.

- Infrastrukturní doména (infrastructure top-level domain) je pouze jediná. Jedná se o doménu arpa, která slouží pro některé interní mechanismy DNS, zejména pro reverzní převody IP adres na jména a pro ENUM. Má poměrně zajímavou historii – původně byla určena pro agenturu ARPA (Advanced Research Projects Agency), jež stála u kolébky Internetu. Později doména změnila svůj význam a odpovídajícím způsobem byl upraven i význam zkratky, v současnosti znamená Address and Routing Parameter Area.

Po bouřlivém začátku, kdy kolem poloviny 80. let vznikla valná většina domén nejvyšší úrovně, nastalo dvacetileté období klidu. Kořenová doména byla tou dobou velmi konzervativní, obsahovala kolem 300 poddomén a narůstala průměrným tempem jedné až dvou nových TLD ročně. Roku 2005 pak byl zahájen proces vedoucí ke vzniku celé řady nových obecných domén. Podrobněji se k němu vrátíme v části 7.3 na straně 369.

Kromě výše uvedených čtyř existuje ještě jedna skupina doménových jmen nejvyšší úrovně. Mezi předchozí ovšem nepatří, protože tyto domény neexistují a ani existovat nemohou. RFC 2606 rezervovalo několik jmen nejvyšší úrovně pro speciální účely:

- test pro testování DNS programů,

- example pro příklady v dokumentaci,

- invalid pro vytváření neplatných jmen a

- localhost pro odkaz sama na sebe.

Kromě nich byly vyhrazeny ještě tři domény druhé úrovně (example.com, example.net a example.org), opět pro potřeby příkladů v dokumentaci. Tyto domény nejsou součástí doménového stromu a mohou být volně využívány k daným účelům.

Jelikož se později objevilo ještě několik jmen rezervovaných pro speciální účely, RFC 6761 Special-Use Domain Names je shrnulo a zavedlo pro ně registr, který obhospodařuje IANA. Aktuální přehled doménových jmen se speciálním významem najdete na adrese:

http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

Poddoménami TLD jsou tak zvané domény druhé úrovně. K jejich přidělování existují dva základní přístupy: Většinou jsou přidělovány již konkrétním organizacím či jednotlivcům. Tímto způsobem je spravována například naše doména cz, proto třeba Technická univerzita v Liberci disponuje doménou tul.cz, Seznam doménou seznam.cz a podobně.

V některých doménách se snaží na druhé úrovni rozlišit charakter vlastníka, podobně jako původní nejvyšší domény com, edu a spol. Domény organizací a dalších vlastníků se pak nacházejí až na třetí úrovni. Nejznámějšími příklady tohoto uspořádání jsou Rakousko (at), Velká Británie (uk) či Austrálie (au), ale je jich mnohem víc. Seznam dostupných koncovek doménových jmen obsahuje Public Suffix List, který najdete na adrese:

https://publicsuffix.org/list/

Například vídeňská univerzita je držitelem domény univie.ac.at, kde ac na druhé úrovni signalizuje akademickou instituci. Tento způsob organizace domén je výrazně menšinový a spíše se od něj ustupuje – třeba v Rakousku je dnes již možná také registrace domén druhé úrovně. Podrobnější informace o správě domén se dočtete v kapitole 7 na straně 363.

Hloubka doménového stromu je omezena na 127 úrovní. Tento limit je však ryze teoretický, v praxi se jen zřídka setkáte s hloubkou větší než pět. Výjimkou jsou různé speciální mechanismy – ENUM pro telefonní čísla a zejména reverzní dotazy pro IPv6, které zasahují až do 35. úrovně. To je hodně extrémní případ, přesto se dostal jen do čtvrtiny maximální přípustné hloubky.

Když už jsme u extrémů, zmiňme se o existenci alternativních DNS stromů. Naše kniha je věnována „originálnímu a jedině pravému DNS“. Kromě něj ovšem existují i jeho vedlejší odnože, které používají stejné protokoly, technologie i programy, jen jejich doménový strom je odlišný. Má svůj vlastní kořen, ze kterého obvykle vedou odkazy na všechny TLD oficiálního DNS, ovšem kromě nich ještě některé navíc. Důvody pro jejich existenci mohou být ideové (nesouhlas s některými pravidly a omezeními, jimž podléhá standardní kořenová doména), komerční, nebo se může jednat o čistě interní záležitost určité organizace.

Jejich společnou vlastností je, že vyžadují speciální konfiguraci na straně strojů, které DNS prohledávají, a jejich dosah bývá velmi omezený. Drtivá většina Internetu o nich nemá tušení. Hlavním problémem jejich existence je samozřejmě nekonzistence informací. Kromě toho vznikají nepříjemné konflikty, pokud některý z alternativních kořenů vytvoří svou specifickou TLD a později je stejnojmenná doména založena v oficiálním DNS, což se přihodilo například doméně biz. Internetová komunita nepohlíží na alternativní doménové stromy s žádným nadšením, což se odráží i v RFC 2826 IAB Technical Comment on the Unique DNS Root. Jeho obsah by se dal stručně shrnout heslem „jeden Internet – jedno DNS“. I nám se existence alternativních doménových stromů jeví jako krajně problematická a nebudeme se jim více věnovat.

2.2 DNS záznamy

Doménový strom obsahuje pro jednotlivá jména pestrou směs různorodých údajů. V předchozí kapitole jsme uvedli několik příkladů informací, které lze do DNS ukládat. Ve skutečnosti je jich ale ještě mnohem více. Vše se ukládá do tak zvaných zdrojových záznamů (resource records, RR), které představují základní jednotku informace, s níž DNS pracuje. Zdrojový záznam obsahuje pět položek:

- Jméno (name), ke kterému se vztahuje.

- Životnost (time to live, TTL) udává počet sekund, po které lze záznam uložit ve vyrovnávací paměti.

- Třída (class) určuje rodinu protokolů, pro něž je záznam určen. DNS lze teoreticky používat i pro jiné síťové architektury. V praxi se to samozřejmě neděje, takže třída vždy obsahuje hodnotu 1 reprezentující Internet (je zapisována jako IN).

- Typ (type) určuje, jakého typu jsou informace nesené tímto záznamem. Přehled několika málo nejčastěji používaných typů najdete v tabulce 2.1. Všechny dostupné typy, včetně těch zavedených pozdějšími rozšířeními, shrnuje část III na straně 848.

- Data (data) nesou vlastní datový obsah záznamu. Jejich struktura a interpretace závisí na typu – například záznam typu A obsahuje ve svých datech IPv4 adresu, zatímco záznam typu MX nese prioritu a doménové jméno serveru pro příjem elektronické pošty.

Typ

Význam

A

IPv4 adresa

AAAA

IPv6 adresa

PTR

jméno k příslušné IP adrese

CNAME

přezdívka pro existující jméno

MX

poštovní server pro danou doménu

NS

DNS server pro danou doménu

SOA

základní informace o doméně

Tabulka 2.1: Nejběžnější typy zdrojových záznamů

Pro jedno jméno doménový strom často obsahuje několik záznamů. Jedná se o naprosto libovolnou směs, která může obsahovat kombinaci několika různých typů i opakovaných výskytů stejného typu. Například pro doménové jméno nic.cz existují následující záznamy:

- Začíná zde působnost nového správce (NIC.CZ), obsahuje proto jeden záznam typu SOA se základními informacemi.

- Obhospodařují ji tři autoritativní servery, obsahuje proto tři záznamy typu NS.

- Příjem pošty pro ni zajišťují dva různé poštovní servery, jimž odpovídají dva záznamy MX.

- Má přiřazenu i IP adresu (po jednom záznamu typů A a AAAA), aby se návštěvníci www.nic.cz nemuseli namáhat s úvodním www.

- Obsahuje dva záznamy typu TXT.

- Doména je chráněna DNSSEC, což zahrnuje 12 záznamů tří různých typů (RRSIG, DNSKEY a NSEC3PARAM).

Jak vidíte, pro doménové jméno nic.cz najdeme ve stromě celkem devět typů záznamů, z nichž některé se vyskytují opakovaně. Dohromady napočítáme 21 různých záznamů. Naproti tomu celá řada koncových počítačů má v současnosti jediný záznam typu A, který oznamuje jejich IPv4 adresu. Obecně platí, že domény ve vyšších patrech hierarchie obvykle mívají větší počet záznamů než běžné počítače nacházející se v listech doménového stromu.

Různorodost uložených informací se nutně promítá do složení DNS dotazu. V něm je nutno uvést, co konkrétně tazatele zajímá – tedy jaký typ záznamu a pro jaké doménové jméno požaduje[1]. Iniciátorem DNS transakce bývá aplikace a od ní také pochází rozhodnutí, jaké typy záznamů a pro které jméno má DNS najít. Jestliže ve svém prohlížeči zatoužíte po www.nic.cz, vyvoláte tak dotaz na záznam typu A nebo AAAA pro jméno www.nic.cz. Když pošlete elektronický dopis na adresu info@nic.cz, váš poštovní server bude poptávat záznamy MX pro jméno nic.cz.

1V dotazu se uvádí také požadovaná třída záznamu, což je ovšem ryzí formalita. Veškeré současné DNS se točí kolem třídy IN. Proto budeme v textu až na výjimky třídu ignorovat.

Analogicky jsou i odpovědi tvořeny sadami zdrojových záznamů. Obsahují poptávanou informaci (pokud existuje) – konkrétně všechny záznamy požadovaného typu pro dané doménové jméno. Odesílající server často k odpovědi přibalí i další informace, které by tazatel nejspíš vzápětí poptával. Zvyšuje se tím efektivita celého systému.

Vyjděme z posledního příkladu, kdy tazatel poptával záznamy typu MX pro doménu nic.cz. Existují celkem dva: poštu přijímají mail.nic.cz a mx.nic.cz. To jsou však stále jména, pro vlastní odeslání dopisu bude třeba je převést na adresy. Jelikož odesílající server zná situaci v doméně nic.cz, rovnou ke své odpovědi přibalí i doplňkové informace o odpovídajících IP adresách. Konkrétně pošle záznamy typu A a AAAA pro oba uvedené servery.

2.3 Domény a servery

Klíčovou úlohu v celém systému hrají servery. Obsahují jednotlivé části oné obrovské distribuované databáze, zasílají si dotazy a odpovědi a spolupracují při distribuci informací. Díky jejich vzájemné provázanosti a spolupráci celý systém vůbec může fungovat. DNS servery mají ke konkrétním doménám různý vztah, ze kterého pak vyplývá jejich úloha při řešení dotazů. Pro určitou konkrétní doménu může mít server jednu z následujících rolí:

- Autoritativní server obsahuje data dané domény a zodpovídá dotazy na ně. Obsah autoritativních serverů tvoří onu distribuovanou databázi, kterou DNS představuje. O odpovědích autoritativního serveru ohledně dané domény se nepochybuje, jsou považovány za správné, protože pocházejí přímo od zdroje. Na základě vzájemných vztahů lze rozlišit dvě varianty autoritativních serverů: primární a sekundární.

- Primární server (master) je místo, kde vznikají informace o doméně. Pokud je třeba udělat v jejích datech změny, musí být provedeny na primárním serveru. Z podstaty věci je jasné, že každá doména má obvykle právě jeden primární server.

- Sekundární server (slave) je automatickou kopií primárního. V pravidelných intervalech se na něj obrací s dotazem, zda v doméně nedošlo ke změně, a pokud ano, stáhne si aktuální verzi dat. Současné implementace zpravidla umožňují, aby primární server aktivně upozornil sekundární, že se cosi změnilo a je čas přihlásit se o aktuální data. Díky tomu je synchronizace údajů podstatně rychlejší.

Úloha sekundárního serveru je jasná – dokáže zastoupit primární v případě výpadku a slouží i pro rozkládání zátěže. Je také autoritativní, jeho odpovědi mají v DNS stejnou váhu jako odpovědi primárního serveru. Každá doména musí mít dva autoritativní servery, typicky jeden primární a jeden sekundární, který by měl být z hlediska síťové topologie co nejnezávislejší na primárním.

- Rekurzivní server má dvojí tvář. Vůči svým klientům, což bývají typicky stroje z místní sítě, vystupuje jako server. Přijímá jejich dotazy, řeší je a posílá odpovědi. Během řešení se dotazuje autoritativních serverů, vůči kterým vystupuje jako klient. Informace, které při řešení získá, si ukládá do vyrovnávací paměti a dokud nevyprší jejich životnost, využívá je pro své další odpovědi. Hlavním smyslem rekurzivních serverů je poskytnout společnou vyrovnávací paměť pro místní klienty. Aby se například adresy často používaných webů nehledaly znovu a znovu. Zopakuje-li se dotaz na jméno, které má rekurzivní server v paměti, rovnou pošle odpověď. Zvyšuje tak efektivitu celého systému, zmenšuje počet dotazů a odpovědí přenášených po síti a zrychluje odezvy. Jeho odpovědi samozřejmě nejsou autoritativní. Proto se pro něj používá také pojem pomocný server (caching only).

Ještě jednou zdůrazněme, že výše zmiňované role serverů se vždy vztahují ke konkrétní doméně. Jeden a tentýž server může být primární pro tři domény, sekundární pro dalších pět a pomocný pro všechny ostatní. Rozhoduje o tom pouze a jedině jeho konfigurace.

Z pohledu DNS komunikace není žádný rozdíl mezi primárním a sekundárním serverem. Dokonce ani není viditelný. Pro doménu se ukládají (v záznamech typu NS) všechny autoritativní servery, primární a sekundární se nijak nerozlišují. Odpověď v sobě nese příznak (označovaný AA – Authoritative Answer), zda je autoritativní nebo nikoli. Jeho hodnota závisí na tom, zda odpověď odeslal přímo některý z autoritativních serverů, nebo zda ji odeslal server pomocný ze své vyrovnávací paměti.

Rozdělení na primární a sekundární servery je čistě organizační záležitost, která se promítá do jejich konfigurace. Týká se toho, jak data vznikají, nikoli jejich věrohodnosti. Z pohledu DNS jsou odpovědi všech autoritativních serverů pro doménu stejně důvěryhodné. Některé domény koncept primárních a sekundárních serverů vůbec nepoužívají. Data mají například uložena v databázi, ze které si je berou jejich autoritativní servery. Synchronizaci jejich obsahu zajišťují databázové prostředky.

Mimochodem, jedny z nejošklivějších chyb vznikají, pokud se rozejde obsah primárního serveru se sekundárními. K této situaci může dojít, pokud správce domény upravuje její obsah ručně a zapomene zvětšit sériové číslo, které slouží jako indikátor změny. Sekundární servery si pak nechají původní obsah domény a jejich odpovědi se budou lišit od primárního. Jednotliví klienti se budou obracet na různé autoritativní servery (v závislosti na softwarové implementaci klienta a dobách odezvy jednotlivých serverů) a budou dostávat nekonzistentní odpovědi. Rozložení příjemců špatných odpovědí bude v podstatě náhodné, což řešení problému rozhodně neulehčí.

Případné problematické stavy ještě zhoršují pomocné servery. Na jedné straně výrazně zkracují doby odezvy DNS a snižují zátěž autoritativních serverů, na straně druhé však do něj zavádějí určitou setrvačnost. Dojde-li ke změně, vyrovnávací paměti pomocných serverů nadále obsahují původní údaje a dokud nevyprší jejich platnost, budou je poskytovat svým tazatelům. Tyto servery jsou rozesety po celém světě, jsou zcela mimo působnost správce domény a dotyčné záznamy si uložily v různém čase. Postupně budou nahrazovány aktuální verzí, ale tento proces může trvat několik dnů. Správce domény jej může ovlivňovat jen nepřímo – vhodným nastavením životnosti záznamů. K problematice se vrátíme později. Zde pouze konstatujme, že DNS neposkytuje za každých okolností stoprocentně konzistentní a aktuální informace. Je to cena, kterou platíme za jeho škálovatelnost a efektivitu.

Obecně platí, že čím významnější je doména, tím větší péče bývá věnována jejím autoritativním serverům. Má jich zpravidla větší počet a jsou vhodně rozmístěny v různých částech Internetu. Počet autoritativních serverů poslouží jako orientační měřítko významu domény. Posuďte sami: doména tul.cz má dva, nic.cz tři, doména cz čtyři, com hned třináct a stejný počet má i kořenová doména. Ve skutečnosti je jich podstatně více, protože za jedním jménem v záznamu typu NS se může skrývat mnoho fyzických serverů. Více se dočtete v části 13.3 na straně 663.

Vyšší počet autoritativních serverů má dva významy: větší robustnost, protože lépe dokáže překonat i větší výpadky sítě, a také rozkládání zátěže. Na autoritativní servery velkých domén se valí obrovské množství dotazů, jejich obsluhování více stroji rozloženými v různých částech sítě je holou nezbytností.

Zcela zásadní roli mají autoritativní servery kořenové domény, tak zvané kořenové servery (root servers). U nich začíná řešení všech dotazů, které pak postupuje doménovým stromem po jednotlivých patrech od kořene až k cíli. Hnedle se mu budeme věnovat. Případná nedostupnost všech kořenových serverů by učinila DNS nefunkčním. Proto se za jejich třinácti adresami ve skutečnosti skrývají stovky serverů[2]. Používají se tak zvané výběrové adresy (anycast), kdy se stejná adresa přidělí několika strojům a směrování se postará o doručení paketu nejbližšímu z jejích majitelů. Více se o tomto způsobu adresování dočtete v části 13.3 na straně 663. Podrobnosti o kořenových serverech včetně mapky jejich rozložení najdete na adrese:

2Konkrétně v polovině roku 2023 jich bylo zhruba 1500.

www.root-servers.org

Budiž autorům a správcům DNS připsáno ke cti, že za celou jeho historii nedošlo k vyřazení všech kořenových serverů, přestože se vyskytlo několik cílených útoků na ně.

Zmíněných třináct adres kořenových serverů je velmi konzervativních, protože je musí znát miliony dalších serverů v celém Internetu. Mění se proto zhruba rychlostí pohybu kontinentů. Jejich nejvýznamnější změnou v posledních letech byla postupná implementace IPv6 a s ní přidávané IPv6 adresy.

2.4 Resolver čili řešič

Máme tedy data, máme i servery a zbývá nám už jen klient, který se bude systému ptát. V oficiální terminologii se pro něj používá termín resolver (čili řešič). Jeho hlavní úlohou je zprostředkovávat místním aplikacím styk s DNS – na základě jejich požadavků sestavuje DNS dotazy, zasílá je serverům a zpracovává příchozí odpovědi. Obvykle také mívá vlastní vyrovnávací paměť, aby zbytečně neobtěžoval stále stejnými dotazy.

Resolver bývá součástí operačního systému. Z programátorského hlediska má zpravidla podobu knihovny funkcí, které tvoří jeho rozhraní (API) vůči aplikacím. Touto cestou mu jednotlivé programy zadávají úkoly a přebírají si výsledky. Uživatel se na něj přímo obrátit nemůže, proto bývají součástí systému jednoduché aplikace, jejichž prostřednictvím lze komunikovat s resolverem poměrně přímo a zjišťovat tak aktuální informace v DNS. Podrobněji se jim budeme věnovat v kapitole 4 na straně 169.

Podle schopností existují dva základní druhy resolverů:

- Plnohodnotný (též rekurzivní) resolver je schopen samostatné existence. Zná adresy kořenových serverů a pokud nemá ve vyrovnávací paměti nic, co by pomohlo s vyřešením aktuálního dotazu, obrátí se na některý z nich. Podrobněji celý proces popíšeme vzápětí. Tento typ resolverů bývá základem výše zmíněných rekurzivních DNS serverů.

- Jednoduchý resolver (v originále pahýlový, stub resolver) představuje minimalistický přístup. Potřebuje ke své činnosti adresu místního serveru (případně několika serverů), na který se má obracet se svými dotazy. Dostane-li od aplikace požadavek, převede jej do podoby DNS dotazu a pošle danému serveru. Ten dotaz vyřeší a pošle zpět výslednou odpověď. Jednoduchý resolver nezná adresy kořenových serverů a není schopen samostatné existence. Sám dotazy neřeší, jen je předává místnímu serveru. Součástí běžných operačních systémů bývají právě takové resolvery.

Jednoduchý resolver se snadněji implementuje. Sortiment jeho funkcí je omezený, a kód programu tudíž jednodušší. Vyžaduje však konfiguraci – potřebuje se dozvědět adresu lokálního serveru, který bude řešit jeho dotazy. Její nastavení musí zajistit místní správce, a to buď přímo odpovídajícím konfiguračním zásahem na koncovém stroji, nebo (častěji) prostřednictvím konfiguračního protokolu DHCP. Otázkám konfigurace DNS klienta se budeme opět věnovat v kapitole 4 na straně 169.

Nabízí se otázka, proč operační systémy neobsahují plnohodnotné resolvery. Jejich kód i nároky by sice byly o něco větší, rozdíl by však nebyl nijak zásadní a pro současný hardware v podstatě zanedbatelný. Zato bychom získali jednoduchost použití – plnohodnotný resolver je soběstačný a téměř bezúdržbový. Potřebuje jen adresy kořenových serverů, které se prakticky nemění, a případnou změnu by šlo řešit obvyklou cestou systémových aktualizací.

Tím bychom se ale připravili o hlavní výhodu, společnou vyrovnávací paměť. Jednoduché resolvery strojů v lokální síti posílají své dotazy místnímu rekurzivnímu serveru, který je řeší a výsledky si ukládá do vyrovnávací paměti. Jelikož se všechny lokální stroje obracejí na stejný server, mohou využívat záznamy, které zjistil při řešení dřívějších dotazů jejich sousedů. To podstatným způsobem zvyšuje efektivitu vyrovnávací paměti a snižuje objem síťového provozu odcházejícího mimo lokální síť.

Kromě toho může rekurzivní server něco přidat k datům z veřejného DNS stromu. Jestliže se například v místní síti používají neveřejné adresy, neměly by se objevit ve veřejném DNS. Ovšem interně pro ně chcete používat jména. Často se tato situace řeší tak, že se rekurzivní server nastaví jako autoritativní pro speciální doménu, která obsahuje záznamy s neveřejnými adresami. Tato doména není v doménovém stromě, takže nedostává dotazy zvenčí. Ovšem místní stroje mu posílají všechny své dotazy, takže jim může zasílat odpovědi z této nestandardní domény.

Zanedlouho se k vyrovnávací paměti vrátíme, ale nejprve se podívejme na reálný příklad.

2.5 Život jednoho dotazu

Máme už pohromadě základní stavební kameny DNS – doménový strom, zdrojové záznamy, servery a klienty. Je načase podívat se, jak jednotlivá kolečka zapadají do sebe a jak celý systém funguje. Projděme si kroky, které proběhnou mezi položením dotazu a příchodem odpovědi.

Řekněme, že sháníte informace o Technické univerzitě v Liberci. Do webového prohlížeče proto zadáte www.tul.cz a DNS klient ve vašem počítači dostane za úkol najít k tomuto jménu odpovídající IP adresu. Ve své konfiguraci má zapsáno, kde začít – IP adresu lokálního DNS serveru obsluhujícího místní síť.

Obrázek 2.2: Hledání adresy pro    www.tul.cz

Celá DNS transakce začne tím, že klient na základě požadavku vašeho prohlížeče vytvoří DNS dotaz požadující záznam typu A pro jméno www.tul.cz a zašle jej lokálnímu serveru. Zatím necháme stranou vyrovnávací paměti a popíšeme postup řešení dotazu bez nich. Je znázorněn na obrázku 2.2, jednotlivé kroky jsou opatřeny pořadovými čísly – toto byl krok 1.

Oslovený server se chopí řešení dotazu. Odpověď samozřejmě nezná, ale zaúkoluje svůj plnohodnotný resolver, jenž má k dispozici adresy kořenových serverů, u nichž začíná řešení všech dotazů. Lokální server některý z nich vybere, řekněme k.root-servers.net, a pošle mu stejný dotaz: hledám záznam typu A pro www.tul.cz (krok 2).

Hierarchické uspořádání domén svádí k myšlence, že dotaz bude postupně „probublávat“ hierarchií vzhůru. Tak to ale není, cestu nahoru absolvuje jedním skokem. Je to rychlejší a snadněji udržitelné – stačí, aby každý místní server znal třináct adres kořenových serverů, které jsou pro všechny společné a stabilní. Mívá je ve své konfiguraci a při startu si zjišťuje jejich aktuální složení pomocí tak zvaných přípravných dotazů (priming queries, podrobněji se problematice věnuje RFC 8109 Initializing a DNS Resolver with Priming Queries).

Hierarchické uspořádání se začne uplatňovat až při sestupu doménovým stromem dolů. Oslovený kořenový server zná situaci v kořenové doméně. Ví, že doména nejvyšší úrovně cz skutečně existuje a kdo jsou její autoritativní servery. Na rozdíl od lokálního serveru však nemá čas dotaz řešit – dostává jich příliš mnoho. Proto rovnou pošle tazateli odpověď, která však místo požadovaného záznamu A pro www.tul.cz napovídá, kde se ptát dál (krok 3). V tomto konkrétním případě bude obsahovat informace o autoritativních serverech pro doménu cz:

cz.                 NS      d.ns.nic.cz.

cz.                 NS      a.ns.nic.cz.

cz.                 NS      b.ns.nic.cz.

cz.                 NS      c.ns.nic.cz.

d.ns.nic.cz.        AAAA    2001:678:1::1

c.ns.nic.cz.        AAAA    2001:678:11::1

b.ns.nic.cz.        AAAA    2001:678:10::1

a.ns.nic.cz.        AAAA    2001:678:f::1

d.ns.nic.cz.        A       193.29.206.1

c.ns.nic.cz.        A       194.0.14.1

b.ns.nic.cz.        A       194.0.13.1

a.ns.nic.cz.        A       194.0.12.1

Lokální server nyní může sestoupit o jedno patro hierarchie níže. Dozvěděl se jména a adresy autoritativních serverů pro doménu cz, takže stejný dotaz (hledám záznam typu A pro www.tul.cz) položí jednomu z nich, například a.ns.nic.cz (krok 4). Opakuje se podobná situace jako v kořeni, jen jsme o něco blíže řešení. Oslovený server opět nezná odpověď a nemá kapacitu dotaz řešit, ale zná doménu cz. Proto ví, že tul.cz skutečně existuje a jaké jsou její autoritativní servery. Tuto informaci pošle tazateli jako odpověď (krok 5):

tul.cz.             NS      tul.cesnet.cz.

tul.cz.             NS      bubo.tul.cz.

bubo.tul.cz.        A       147.230.16.1

bubo.tul.cz.        AAAA    2001:718:1c01:16::aa

Lokální server se zase o krok přiblížil vyřešení dotazu. Vybere si jeden z autoritativních serverů pro doménu tl.cz, třeba bubo.tul.cz, a zopakuje mu svůj dotaz (krok 6). Jelikož je poptávané jméno jen o jedno patro níže, je jisté, že tentokrát již dostane definitivní odpověď (krok 7). V daném případě:

www.tul.cz.         CNAME   novy.tul.cz.

novy.tul.cz.        A       147.230.18.195

Říká se v ní, že jméno www.tul.cz je ve skutečnosti přezdívkou pro novy.tul.cz, jehož adresa je v odpovědi také obsažena. Předá ji klientovi (krok 8). Zdůrazněme, že postup řešení bude víceméně stejný odkudkoli z celého Internetu. Lišit se bude jen výběr oslovených serverů, vždy však lokální server nejprve osloví jeden z kořenových serverů, pak některý z autoritativních serverů pro doménu cz a do třetice vybere jeden z autoritativních serverů domény tul.cz. Obecně platí, že dotaz se vždy vyhoupne do kořene doménového stromu a pak postupně sestupuje po jednotlivých patrech blíže a blíže danému cíli.

Možná vám trochu vrtá hlavou, jak může kořenový server poslat záznam typu A třeba pro a.ns.nic.cz. Kořenová doména obsahuje pro cz záznamy typu NS, v nichž jsou uvedena doménová jména jejích autoritativních serverů. Vyvstává klasický problém slepice versus vejce: abychom se mohli zeptat autoritativního serveru a.ns.nic.cz na informace ohledně domény cz, potřebujeme jeho adresu. Ta je ovšem uložena kdesi v doméně cz.

Tento problém řeší tak zvané slepující záznamy (glue records). Jedná se o adresní záznamy (typy A a AAAA) umístěné ve vyšších patrech doménové hierarchie, než by jim náleželo. Jestliže jméno autoritativního serveru pro určitou poddoménu samo leží v této poddoméně, je standardním postupem nezjistitelné. Proto se do nadřízené domény společně se záznamem typu NS uvádějícím jméno serveru umístí i záznamy obsahující IP adresy tohoto serveru. Kořenová doména tedy obsahuje slepující záznamy typu A a AAAA pro a.ns.nic.cz a doména cz podobně obsahuje slepující záznam A pro bubo.tul.cz. Pokud server odesílá příslušný záznam NS, automaticky do své zprávy přibalí i odpovídající slepující záznamy, pokud je má k dispozici.

V příkladu jsme zatím zcela ignorovali existenci vyrovnávacích pamětí (cache). Nastal čas věnovat jim trochu pozornosti. Lokální server si samozřejmě uloží získanou odpověď pro www.tul.cz a pokud se v době jeho životnosti bude po této informaci shánět některý z místních klientů, odpoví mu rovnou. Celá DNS komunikace pak bude mít jen dva kroky: klient se zeptá místního serveru a ten mu rovnou pošle odpověď s příznakem, že není autoritativní.

Obrázek 2.3: Hledání poštovních serverů pro    tul.cz s využitím cache

Server si však neukládá jen výsledné řešení, ale veškeré informace, které během jeho hledání získal. V tomto případě autoritativní servery pro domény cz a tul.cz. Když po chvíli brouzdání po stránkách pošlete elektronickou poštou na adresu info@tul.cz nějaký dotaz, bude váš poštovní server poptávat záznamy typu MX pro doménu tul.cz. Situaci ilustruje obrázek 2.3. Jeho resolver se obrátí na lokální DNS server, který má ve vyrovnávací paměti platné údaje o autoritativních serverech pro tuto doménu. Díky tomu se zeptá rovnou některého z nich a obratem se dozví:

tul.cz.             MX    0 bubo.tul.cz.

tul.cz.             MX    50 tul.cesnet.cz.

bubo.tul.cz.        A     147.230.16.1

bubo.tul.cz.        AAAA  2001:718:1c01:16::aa

Dorazí-li zanedlouho lokálnímu DNS serveru dotaz na www.liberec.cz (chystáte se studovat v Liberci a zajímá vás, co je ve městě k vidění) využije uložené informace o autoritativních serverech pro doménu cz a zeptá se některého z nich, aniž by začínal u kořenového serveru. Jak by to zhruba vypadalo, vidíte na obrázku 2.4.

Obrázek 2.4: Hledání adresy    www.liberec.cz s využitím cache

Při řešení dotazů a uplatňování vyrovnávacích pamětí hraje klíčovou roli skutečnost, že doménové jméno je zároveň jednoznačným popisem cesty doménovým stromem, jež vede k získání požadované informace. Díky tomu každý z oslovených serverů okamžitě ví, kudy se má pokračovat k vyřešení. Zároveň si dokáže najít ve vyrovnávací paměti nejkonkrétnější relevantní informaci a tu využít k omezení síťové komunikace a zrychlení odezvy.

2.6 Rekurzivní a nerekurzivní chování serverů

V příkladu z předchozí části jsme popsali dva výrazně odlišné způsoby chování DNS serverů. Zatímco lokální server se dotazu chopil, vyřešil jej a poslal výslednou odpověď, kořenový server se dotazem nezabýval a jako odpověď poskytl obratem informace o serverech, které mají blíže k řešení. Pro tyto dva duhy chování existují i oficiální názvy:

- Rekurzivní řešení dotazu je takové, kdy se server dotazu ujme, vyřídí veškerou potřebnou korespondenci až po získání odpovědi, kterou pak odešle tazateli. Rekurzivní chování server samozřejmě zatěžuje. Musí si uchovávat datové struktury pro rozpracované dotazy, přeposílat dotazy a podle reakcí na ně se rozhodovat, jak pokračovat dál. Hlavní a základní výhodou rekurzivního řešení dotazů je, že si server plní vyrovnávací paměť. Procházejí jím dílčí i finální odpovědi, které si ukládá a může je využít při řešení dalších dotazů. Toto chování je typické pro lokální servery, které fungují jako rekurzivní resolvery obsluhující jednoduché resolvery místních strojů.

- Nerekurzivní řešení dotazu znamená, že server jednoduše odkáže tazatele jinam. Obdrží dotaz, nahlédne do svých dat, odešle jako odpověď informace o autoritativních serverech bližších k řešení (nebo chybový kód, pokud jste se zeptali na doménu, k níž nemá co říci) a pustí dotaz z hlavy. Nemusí si nic uchovávat, zátěž serveru je minimální, což je přesně ten důvod, proč se nerekurzivně chovají autoritativní servery v horních patrech doménové hierarchie – tedy kořenové a servery domén nejvyšší úrovně.

Obecné doporučení zní, že v každé síti připojené k Internetu by měl být místní rekurzivní server, na nějž se obracejí zdejší klienti. Jeho hlavní úlohou je poskytnout společnou vyrovnávací paměť a omezit tak objem DNS komunikace směřující do Internetu. Pokud hledáte hojně používaný server, třeba www.seznam.cz, skoro jistě budete obslouženi z vyrovnávací paměti, protože adresu před vámi požadoval někdo jiný. Čím více klientů se schází na jednom lokálním serveru, tím vyšší je pravděpodobnost opakování dotazů a efektivita využití uložených informací. Proto není dobrý nápad stavět rekurzivní servery na každém rohu. Ideální počet je jeden pro celou místní síť. Tím ovšem vzniká slabé místo, protože při jeho výpadku přestane místním strojům fungovat DNS. Pokud je síť větší, je rozumné postavit do ní dva rekurzivní DNS servery – jeden hlavní a jeden záložní pro případ výpadku prvního. Více rozhodně ne.

Na druhé straně je však třeba upozornit, že rekurzivnímu serveru se dají podstrčit falešné informace a on následně bude své klienty mystifikovat. Je proto velmi důležité, aby byl správně konfigurován a chránil se před podobnými pokusy. Naprostou samozřejmostí by mělo být, že rekurzivní služby poskytuje jen strojům z místní sítě, nikoli veřejně do Internetu. Otázkami bezpečnosti DNS se budeme zabývat v kapitole 15 na straně 799.

Pokud má koncová síť přidělenu vlastní doménu, otevírá se zajímavá otázka vztahu autoritativních serverů této domény a pomocných (rekurzivních) serverů koncové sítě. Lze k ní přistoupit dvěma způsoby: puristicky nebo úsporně. Vhodnější puristická varianta používá zcela oddělené servery, zatímco úsporná sází na jeden společný server pro obě role. Rozebereme to podrobněji v části 6.1.2 na straně 304.

2.7 Domény, zóny a zónové soubory

V textu jsme opakovaně zdůraznili distribuovaný charakter DNS databáze. Jednotlivé části doménového stromu jsou spravovány různými subjekty a informace poskytovány různými servery. Souvislá část doménového stromu, jejíž správa byla delegována jednomu subjektu, je označována jako zóna (zone). Jednou zónou je například kořenová doména, jejíž správu vykonává ICANN. Pod ní se nachází například zóna odpovídající doméně cz spravovaná sdružením CZ.NIC.

Hranice mezi zónami prochází vždy hranou doménového stromu, jež spojuje nadřazenou doménu spadající do jedné zóny s podřazenou, která je již v jiné zóně. Pro tyto hranice se používá pojem zónový řez (zone cut) a označují vlastně hranice zodpovědnosti jednotlivých subjektů. Zónový řez znamená „od tohoto místa spravuje připojený podstrom někdo jiný“. Dotyčný správce může skutečně spravovat celý podstrom, nebo jeho části odřízne a svěří do správy dalším subjektům. To už je čistě otázkou jeho rozhodnutí.

Obrázek 2.5: Rozdělení domén do zón

Podívejme se na příklad části doménového stromu na obrázku 2.5, který popsaný princip ilustruje. Správce kořenové zóny odřízl její poddoménu cz a svěřil ji CZ.NIC. Ten pochopitelně neobhospodařuje celý příslušný podstrom, ale opět svěřuje jednotlivé domény druhé úrovně subjektům, které o ně projeví zájem. Takže například doménu tul.cz získala do správy Technická univerzita v Liberci a vznikla tak další zóna. Celou doménu zde obhospodařuje centrální správa sítě, proto pod tul.cz nenajdete žádné další řezy a zóna zahrnuje celý podstrom. Jiný přístup zvolila podstatně větší Univerzita Karlova, která delegovala fakultní domény do správy příslušných fakult. Pod zónou cuni.cz spravovanou centrálním Ústavem výpočetní techniky UK tak vznikly zóny mff.cuni.cz, lf1.cuni.cz, ff.cuni.cz a další, jejichž správu si zajišťují přímo odpovídající fakulty.

Existence zón se promítá i do obsahu DNS. V doméně bezprostředně nad zónovým řezem musí být informace o tom, že podřízená doména existuje, avšak má už jiné autoritativní servery. To zajišťují záznamy typu NS. Například doména cz proto obsahuje dvojici záznamů NS pro doménu tul.cz se jmény jejích autoritativních serverů bubo.tul.cz a tul.cesnet.cz. Jména obou serverů leží v zónách podřízených zóně cz, proto musí obsahovat také slepující záznamy s jejich adresami. Právě tyto záznamy pošle autoritativní server domény cz tazateli, který se bude zajímat o nějaké informace z domény tul.cz.

Každá zóna ve svém kořeni obsahuje záznam typu SOA (Start of Authority), ze kterého zjistíte jméno jejího primárního serveru, e-mail správce a časové konstanty, které ovlivňují zacházení s jejími daty. Podrobně je popsán v části 17.7 na straně 873.

Data zóny bývají na serveru uložena v podobě tak zvaného zónového souboru, jehož podobu definuje RFC 1035 pod názvem master file. Je to poněkud nezvyklé, protože formát lokálních dat by měl být spíše věcí implementace a některé se skutečně od standardní podoby odchylují[3]. Nicméně většina serverů tuto syntaxi dodržuje a používá se také ve všech dokumentech o DNS. Budeme se jí držet i v naší knize.

3Existují i servery, jež si lokálně data ukládají do databází, tedy principiálně odlišně od oficiální podoby.

Jedná se o textový soubor, v němž je každý záznam zapsán na jeden řádek. Pokud jsou data dlouhá (například v záznamu typu SOA), lze je pro lepší čitelnost uzavřít do závorek a rozdělit do několika řádků. Uvnitř závorek má konec řádku stejný význam jako mezera. Záznam má pět položek vzájemně oddělených libovolnou kombinací mezer a/nebo tabulátorů:

doménovéJméno   životnost   třída   typ   data

Doménové jméno určuje jméno, k němuž se záznam vztahuje. Bývá také označováno jako vlastník záznamu. Pokud je zakončeno tečkou, chápe se jako absolutní a úplné. V opačném případě se za ně doplní aktuální doména. Takže například jméno www v zónovém souboru pro nic.cz znamená www.nic.cz. Jméno může na začátku záznamu zcela chybět, v takovém případě se zdědí z předchozího. Jestliže jako jméno použijete samotný znak „@“, označuje aktuální doménu. Tedy doménu, v jejímž zónovém souboru se vyskytuje nebo která byla určena direktivou $ORIGIN, jíž se zanedlouho budeme věnovat.

Životnost určuje počet sekund životnosti záznamu ve vyrovnávací paměti a třída jeho třídu. Jejich pořadí může být prohozeno. Údaje také mohou chybět a server za ně dosadí implicitní hodnoty. Poslední dvě položky jsou jako jediné povinné. Určují typ záznamu a v závislosti na něm pak data, která obsahuje.

Hodnoty jednotlivých položek tvoří celá čísla, doménová jména, IP adresy a řetězce znaků. Jejich zápisy odpovídají běžným konvencím. V případě celých čísel zdůrazněme, že jsou zapisována v desítkové soustavě jako souvislé sekvence číslic. Nelze do nich vkládat oddělovače řádů (mezery, čárky a podobně).

Výše jsme uvedli, že zóna cz musí obsahovat záznamy NS pro autoritativní servery tul.cz a také odpovídající slepující záznamy. Příslušný úsek zónového souboru by vypadal takto:

tul           NS    bubo.tul

NS    tul.cesnet

bubo.tul      A     147.230.16.1

AAAA  2001:718:1c01:16::aa

tul.cesnet    A     195.113.233.250

Všimněte si, že všechna jména jsou relativní (nekončí tečkou), takže se za ně doplní doména, v jejímž souboru se vyskytují. Například tul proto znamená tul.cz.

Řetězce znaků, jsou-li souvislé, lze psát přímo tak jak jsou. Pokud však má řetězec obsahovat mezery, je třeba obklopit jej uvozovkami ("), aby nebyly pochopeny jako oddělovače položek. Řetězec v uvozovkách může obsahovat i konce řádků a být tedy rozdělen do několika řádků za sebou. Pokud má obsahovat uvozovky, vložte před ně zpětné lomítko (\"). Tento přístup je obecný – chcete-li potlačit speciální význam libovolného znaku, zapište před něj zpětné lomítko. O vložení zpětného lomítka do řetězce se tudíž postará \\. Zcela libovolný znak lze vložit konstrukcí \DDD, kde DDD jsou číslice udávající kód znaku v osmičkové soustavě. Také tyto znaky jsou interpretovány jako pasivní část textu a je potlačen jejich případný speciální význam. Alternativním zápisem pro vložení uvozovek by tedy bylo \042, protože znak " má ASCII kód 34, v osmičkové soustavě 42.

$ORIGIN jméno

změní aktuální doménu – počínaje následujícím řádkem bude za relativní doménová jména doplňováno uvedené jméno

$INCLUDE soubor

vloží obsah daného souboru jako by jeho text byl zapsán v místě výskytu direktivy

$TTL čas

nastavuje implicitní dobu životnosti záznamů v zóně (definována v RFC 2308)

Tabulka 2.2: Direktivy zónových souborů

Ke zvýšení čitelnosti lze do zónového souboru vkládat prázdné řádky a komentáře. Ty začínají středníkem, všechny následující znaky až po konec řádku jsou interpretovány jako komentář a serverem ignorovány. Kromě běžných záznamů se v zónovém souboru mohou objevit také tak zvané direktivy, které představují příkazy ovlivňující způsob interpretace souboru. Různé servery si přidávají vlastní, ale standardně jsou definovány jen tři, jež shrnuje tabulka 2.2.

Zónový soubor pro velmi zjednodušenou zónu tul.cz, která obsahuje jen web, server pro příjem pošty a jednu poddoménu s vlastním webem, by mohl vypadat například takto:

$TTL 48h

$ORIGIN tul.cz.

@      SOA  bubo.tul.cz. pavel\.satrapa.tul.cz. (

2023071001 ;sériové číslo

86400      ;aktualizovat po 1 dni

7200       ;opakovat po 2 hod

3600000    ;zrušit po 1000 hod

172800  )  ;minimum 2 dny

NS    bubo

NS    tul.cesnet.cz.

MX    0  bubo

MX    50 tul.cesnet.cz.

bubo   A     147.230.16.1

AAAA  2001:718:1c01:16::aa

MX    0  bubo

web    A     147.230.16.27

AAAA  2001:718:1c01:16:216:3eff:fe1a:d23f

www    CNAME web

$ORIGIN fm.tul.cz.

; poddoména fm.tul.cz

; zavádíme sirius.fm.tul.cz a www.fm.tul.cz

sirius A     147.230.72.241

www    CNAME sirius

V souboru používáme relativní jména, abychom jej zkrátili a učinili o něco přehlednějším. U jmen ležících mimo tul.cz (zde například tul.cesnet.cz) je třeba nezapomenout na konci tečku, aby byla správně interpretována jako absolutní. Bez závěrečné tečky by tul.cesnet.cz bylo interpretováno jako tul.cesnet.cz.tul.cz.

Zde zónový soubor obsahuje kompletní data pro celou zónu. To odpovídá logice věci, nicméně není to nezbytné a pro velké zóny to nebude ani příliš praktické – se soubory obludné velikosti se po všech stránkách špatně pracuje. Bylo by klidně možné pro fm.tul.cz vytvořit samostatnou zónu s vlastním souborem:

$TTL 48h

$ORIGIN fm.tul.cz.

@      SOA  bubo.tul.cz. pavel\.satrapa.tul.cz. (

2023071001 ;sériové číslo

86400      ;aktualizovat po 1 dni

7200       ;opakovat po 2 hod

3600000    ;zrušit po 1000 hod

172800  )  ;minimum 2 dny

NS    bubo

NS    tul.cesnet.cz.

sirius A     147.230.72.241

www    CNAME sirius

Pokud jsou obsluhovány stejnými servery, není třeba ani do tul.cz zavádět delegaci záznamem NS. Tazatel hledající www.fm.tul.cz se propracuje k autoritativním serverům pro tul.cz, jež mají oba zónové soubory a rovnou mu odpovědí. Z původního zónového souboru by tedy stačilo vymazat závěrečné řádky (počínaje druhým $ORIGIN). Koncepčnější ale je přidat do rodičovské domény záznamy s delegací, stejně jako by podřízenou doménu spravoval jiný subjekt. Závěrečné řádky původního zónového souboru je tedy lépe nahradit dvojicí:

fm     NS    bubo

NS    tul.cesnet.cz.

Pokud spravujete zónu s poddoménami, je jen na vašem rozhodnutí, zda ji celou uložíte do jednoho souboru, nebo zda ji rozdělíte po jednotlivých doménách – obě varianty mají své přednosti.

2.8 Reverzní dotazy aneb hledá se jméno pro adresu

Reverzní dotaz vychází z IP adresy (verze 4 nebo 6) a snaží se zjistit, jaké doménové jméno jí náleží. Zlidšťují se tak protokoly o činnosti serverů, výstupy testovacích programů typu traceroute, záznamy o cestě elektronického dopisu a podobně. Aby se dalo DNS použít k řešení tohoto typu problémů, musí se z adresy vytvořit určité speciální doménové jméno, které se následně stane předmětem dotazu. Nepůjde to ale udělat přímočaře, protože doménové jméno má obecné části vzadu a směrem dopředu se zpřesňuje, zatímco v případě adresy je směr přesně opačný. Začíná obecnou adresou sítě, za ní následuje podsíť a až na konci se nachází adresa konkrétního stroje v podsíti.

DNS je postaveno na principu distribuované správy, aby informace mohli upravovat místní správci. Proto bylo třeba vymyslet způsob převodu IP adresy na dotazované jméno, který by umožnil například doménu odpovídající síťovému prefixu 147.230.0.0/16 svěřit do správy organizaci, jíž byla přidělena dotyčná síť.

Řešením je prosté otočení adresy. Konkrétně z IPv4 adresy se vytvoří poptávané doménové jméno tak, že se vyjde z jejího standardního zápisu, v něm se obrátí pořadí jednotlivých bajtů a na konec se přidá přípona in-addr.arpa. Pokud bychom například hledali, pod jakým jménem je registrována adresa 147.230.16.27, poptávali bychom doménové jméno:

27.16.230.147.in-addr.arpa

Síti 147.230.0.0/16 odpovídá v tomto pojetí doména 230.147.in-addr.arpa, kterou lze snadno svěřit do správy držiteli adresy. Distribuovaná správa je možná a informace nadále mohou být do DNS vkládány přímo tam, kde vznikají. Pro reverzní dotazy byl vytvořen speciální typ zdrojových záznamů nazvaný PTR (pointer). Jeho hodnotou je doménové jméno odpovídající příslušné adrese. Například dotaz na záznam typu PTR pro výše uvedené doménové jméno vás oblaží odpovědí, že náleží stroji web.tul.cz.

TUL, jejíž doménu tul.cz jsme používali pro příklady v předchozí části, disponuje právě sítí 147.230.0.0/16. Zónový soubor pro její reverzní doménu 230.147.in-addr.arpa, který by odpovídal našemu příkladu výše, by vypadal následovně:

$TTL 48h

$ORIGIN 230.147.in-addr.arpa.

@      SOA   bubo.tul.cz. pavel\.satrapa.tul.cz. (

2023071001 ;sériové číslo

86400      ;aktualizovat po 1 dni

7200       ;opakovat po 2 hod

3600000    ;zrušit po 1000 hod

172800  )  ;minimum 2 dny

NS    bubo.tul.cz.

NS    tul.cesnet.cz.

1.16   PTR   bubo.tul.cz.

27.16  PTR   web.tul.cz.

241.72 PTR   sirius.fm.tul.cz.

Jsme v reverzní doméně, relativní jména jsou proto vztažena k ní – například 1.16 znamená 1.16.230.147.in-addr.arpa. Veškerá jména z domény tul.cz musí být zapsána jako absolutní. Považujeme za rozumné držet celou zónu pohromadě v jednom souboru, nedelegovat její části do dalších zón.

Popsaný systém byl navržen v době, kdy IPv4 adresy patřily do tříd A, B nebo C a přidělované prefixy končily vždy na hranici bajtů. Když bylo v polovině 90. let nasazeno beztřídní adresování (CIDR, Classless Inter-Domain Routing), vznikl problém, protože najednou mohla koncová síť dostat prefix libovolné délky. Poskytovatel Internetu, který má při správě adres roli lokálního internetového registru (LIR), například dostal pro své zákazníky k dispozici prefix 10.1.2.0/24. Vzhledem k velikosti koncových sítí a aktuálním pravidlům se jej rozhodl rozdělit na čtyři části různé velikosti a ty přidělit jednotlivým zákazníkům:

- prefix 10.1.2.0/25 dostal zákazník xyz1,

- prefix 10.1.2.128/26 dostal zákazník xyz2,

- prefix 10.1.2.192/27 dostal zákazník xyz3 a

- prefix 10.1.2.224/27 dostal zákazník xyz4.

Při zachování původní koncepce reverzních zón bylo jedinou možností, aby jejich společnou zónu 2.1.10.in-addr.arpa spravoval poskytovatel a na základě požadavků jednotlivých zákazníků do ní vkládal záznamy pro jejich stroje. Takové uspořádání je ale dost nepraktické a popírá princip, aby si reverzní zónu spravoval sám držitel příslušného prefixu. Bylo potřeba vymyslet způsob, jak reverzní zónu delegovat kdesi uprostřed bajtu.

S řešením přišlo RFC 2317 Classless IN-ADDR.ARPA delegation. Do reverzního jména navrhlo vložit další doménu, která popisuje rozdělení bajtu a umožňuje delegovat jednotlivé poddomény různým subjektům. Toto vložení nelze udělat obecně, protože adresní prostor je členěn podle potřeby, jeho jednotlivé části se liší a zdaleka ne každá potřebuje delegaci uvnitř bajtu. Držitel či správce prefixu, na jehož konci došlo k rozdělení, musí tuto skutečnost zanést do odpovídající reverzní zóny. V bajtu, ve kterém došlo k rozdělení, zavede poddomény pro jeho jednotlivé části a hodnoty do nich rozdělí. Používají se k tomu záznamy typu CNAME (přezdívka, viz 17.3 na straně 859).

Konkrétně v našem příkladu by poskytovatel v doméně 2.1.10.in-addr.arpa zavedl poddomény 0/25, 128/26, 192/27 a 224/27 a delegoval je příslušným zákazníkům. Kromě toho by do domény 2.1.10.in-addr.arpa vložil záznamy CNAME, jimiž by převedl původní reverzní jména na jména v těchto poddoménách. Všechny adresy přidělené prvnímu zákazníkovi by byly převedeny do domény 0/25.2.1.10.in-addr.arpa, takže například jméno 15.2.1.10.in-addr.arpa by se stalo přezdívkou pro 15.0/25.2.1.10.in-addr.arpa. Pro adresy druhého zákazníka by přezdívky vedly do domény 128/26.2.1.10.in-addr.arpa – například 137.2.1.10.in-addr.arpa by se díky CNAME změnila na 137.128/26.2.1.10.in-addr.arpa a tak dále.

Výhodou je, že dělící zónu lze připravit předem a celou, bez ohledu na to, zda adresy byly přiděleny nebo nikoli. Zóna bude obsahovat záznamy CNAME pro všech 256 možných hodnot a až při dotazu autoritativních serverů jednotlivých poddomén spravovaných zákazníky se zjistí, zda pro danou adresu existuje PTR záznam či nikoli. Okamžitě po přidělení prefixů by tedy poskytovatel mohl vytvořit zónový soubor pro doménu 2.1.10.in-addr.arpa s následujícím obsahem:

$TTL 48h

$ORIGIN 2.1.10.in-addr.arpa.

@       SOA  ...

;poddomény spravované zákazníky

0/25    NS  ns1.xyz1.cz

NS  ns2.xyz1.cz

128/26  NS  ns1.xyz2.cz

NS  ns2.xyz2.cz

192/27  NS  ns1.xyz3.cz

NS  ns2.xyz3.cz

224/27  NS  ns1.xyz4.cz

NS  ns2.xyz4.cz

;pro všechny adresy v rozsahu prvního zákazníka

0       CNAME  0.0/25

1       CNAME  1.0/25

2       CNAME  2.0/25

...

127     CNAME  127.0/25

;pro všechny adresy v rozsahu druhého zákazníka

128     CNAME  128.128/26

129     CNAME  129.128/26

130     CNAME  130.128/26

...

191     CNAME  191.128/26

;pro všechny adresy v rozsahu třetího zákazníka

192     CNAME  192.192/27

193     CNAME  193.192/27

...

223     CNAME  223.192/27

;pro všechny adresy v rozsahu čtvrtého zákazníka

224     CNAME  224.224/27

225     CNAME  225.224/27

...

255     CNAME  255.224/27

Poddomény pak budou obsahovat běžné záznamy typu PTR pro existující stroje. Reverzní zóna 0/25.2.1.10.in-addr.arpa spravovaná zákazníkem xyz1 by mohla obsahovat například:

$TTL 48h

$ORIGIN 0/25.2.1.10.in-addr.arpa.

@       SOA  ...

NS   ns1.xyz1.cz.

NS   ns2.xyz1.cz.

1       PTR  www.xyz1.cz.

2       PTR  ns1.xyz1.cz.

3       PTR  ns2.xyz1.cz.

4       PTR  podpora.xyz1.cz.

35      PTR  pc1.xyz1.cz.

36      PTR  pc2.xyz1.cz.

127     PTR  router.xyz1.cz.

Pro IPv6 adresy se používá analogický postup, jen je vzhledem k zápisu adres o něco složitější. Opět vychází ze zápisu adresy, který se rozvine na úplný tvar – tedy doplní se všechny vynechané nuly. Pořadí jednotlivých šestnáctkových číslic v adrese se obrátí a každá z nich se stane samostatnou doménou. Za ně se pak přidá konstantní přípona ip6.arpa. Vezměme jako příklad adresu 2001:db8:89ab:1:2a0:ecff:fe12:345. Doplníme chybějící nuly:

2001:0db8:89ab:0001:02a0:ecff:fe12:0345

otočíme pořadí šestnáctkových číslic, uděláme z nich poddomény a připojíme ip6.arpa. Výsledný dotaz tedy bude poptávat doménové jméno:

5.4.3.0.2.1.e.f.f.f.c.e.0.a.2.0.1.0.0.0.b.a.9.8.8.b.d.0.1.0.0.2.ip6.arpa

Tento přístup opět umožňuje delegovat poddomény v souladu s přidělenými částmi adresního prostoru, navíc to vzhledem k důsledné agregaci adres půjde dělat hierarchicky. Vlastní informace o příslušném doménovém jméně je uložena v záznamu typu PTR, stejně jako v případě IPv4.

Nikde není zaručeno, že dopředná a reverzní informace budou konzistentní. Tedy že odpověď získaná reverzním dotazem je skutečným doménovým jménem, pod nímž je zaregistrována daná adresa. Nesrovnalosti vznikají chybami, v horším případě úmyslně s cílem podvádět. Nikdo totiž nemůže zabránit správci reverzní domény 230.147.in-addr.arpa, aby do ní zanesl, že některá ze zdejších adres přísluší třeba www.google.cz. Pokud na tom záleží (například při omezování přístupu ke službě podle klientovy domény), je záhodno si získané jméno ověřit – nechat si pro ně najít adresy a podívat se, zda je původní adresa mezi nimi. Pokud ne, nejsou data v reverzní doméně v pořádku.

Řekněme, že nejmenovaný server má povolen přístup pouze pro stroje z domény tul.cz. Dorazí-li mu paket z IPv4 adresy 147.230.33.44, získá reverzním dotazem jeho jméno, řekněme pc33.tul.cz. Jelikož se této informaci nedá věřit, poptá vzápětí záznamy typu A pro pc33.tul.cz. Ty už do DNS vkládá správce domény tul.cz a má je pod kontrolou. Pokud se v odpovědi dozví třeba:

pc33    A    147.230.11.12

A    147.230.33.44

může nalezenému jménu důvěřovat, protože zkoumaná adresa se nachází v jeho záznamech A.

Daleko častější chybou než úmyslné falšování je chybějící reverzní záznam. Nemálo správců se jejich údržbou nezatěžuje a pokus o zjištění jména k takové adrese skončí neúspěchem.

Kapitola 3

Vnitřní život DNS

V předchozí kapitole jsme stručně popsali základní komponenty a principy, na nichž je systém postaven. Nyní se budeme jeho složkám věnovat podrobněji a podíváme se jim důkladně na zoubek. Začněme daty, která mají dvě základní složky: jména identifikující jednotlivé domény a formát zpráv, jež tvoří DNS komunikaci. Po nich probereme protokol a chování jednotlivých účastníků.

3.1 Doménová jména

Jak už jsme uvedli, jméno určuje cestu doménovým stromem, jež vede od kořene (případně z jiného bodu, pokud je jméno relativní) až k dané doméně. Formálně je tvořeno posloupností tak zvaných jmenovek (label), jež jsou navzájem odděleny tečkami. Oficiálně se na ně vztahuje jen několik málo kvantitativních omezení:

- maximální délka jedné jmenovky je 63 znaků,

- celé jméno nesmí být delší než 255 znaků,

- počet jmenovek ve jméně je omezen na 127.

Upřímně řečeno, jen málokteré z nich skutečně pocítíte. Nikdo nemá zájem vytvářet dlouhatananánská jména ve stylu

www.polni.mys.hrabosi.savci.prirodovedne.sbirky.narodnimuzeum.cz

a to se ještě pořád pohybujeme hluboko v povolené zóně – délka této obludy dosahuje pětiny přípustné velikosti.

Jmenovky mohou teoreticky obsahovat ledacos. Postupem času se však objevila řada chyb a nedokonalostí programů používajících údaje z DNS, proto RFC 1035 doporučuje držet se u jednotlivých jmenovek následujících omezení:

- používat jen písmena anglické abecedy, číslice a pomlčky,

- začínat jmenovku vždy písmenem,

- zakončit jmenovku písmenem nebo číslicí, nikoli pomlčkou.

Je lépe vyhýbat se řadě populárních znaků, jako jsou podtržítka, lomítka, dvojtečky, procenta či jiné exotičtější znaky. Speciální případ představují znaky národních abeced, které jsou velmi žádány zejména v oblastech, jejichž písmo není odvozeno od latinky. Pro ně bylo vytvořeno rozšíření jménem IDN, kterému ze budeme věnovat v kapitole 10 na straně 561.

Doménová jména musí být jednoznačná. Proto sourozenci v doménovém stromě (poddomény stejné rodičovské domény) musí mít odlišné jmenovky. Nebo opačně: pokud se vyskytne několik záznamů se stejným jménem a typem, jsou považovány za záznamy stejného vlastníka – například několik záznamů MX pro jednu doménu nebo několik IP adres jednoho počítače.

Tatáž jmenovka se samozřejmě může opakovat v různých místech doménového stromu – jako nejlepší příklad poslouží www, kterou najdete na každém rohu.

Při porovnávání se v DNS nerozlišují malá písmena od velkých. Nemohou tedy existovat domény nic.cz a NIC.cz, protože jsou považovány za shodné. Na druhé straně se ale od DNS software požaduje, aby při předávání informací neměnil velikost znaků v nich obsažených. Takže například jméno k IP adrese při reverzním dotazu dostanete v té podobě, jak je zapsáno v DNS databázi, i s případnými malými/velkými písmeny. Při jeho porovnávání s dalšími jmény ale velikost znaků nehraje roli. Zadáte-li do webového prohlížeče adresu www.NIC.cz, skončíte zcela korektně na stránce www.nic.cz.

Oficiálně se délka jedné jmenovky musí pohybovat v rozmezí od 0 do 63 znaků. Prázdnou jmenovku však nelze používat – byla vyhrazena pro kořenovou doménu. Jestliže jsme v předchozí kapitole psali, že pro zdůraznění absolutního jména se na jeho konec píše tečka (www.nic.cz.), vlastně to znamená, že za touto tečkou je ještě uvedena prázdná jmenovka kořenové domény.

V DNS zprávách se doménová jména nepřenášejí jako řetězce znaků, ale jako sled po sobě jdoucích jmenovek. Každá začíná jednobajtovou informací o své délce, za níž pak následují znaky tvořící vlastní obsah jmenovky. Přesněji řečeno, nejvyšší dva bity počátečního bajtu jmenovky jsou interpretovány jako kód určující její typ. Jejich hodnoty (binárně) mají následující význam:

- 00: Obyčejná jmenovka. Proto je délka omezena na 63 znaků, což je maximální hodnota zbývajících šesti bitů délkového bajtu.

- 01: Rozšířená jmenovka. Následujících šest bitů obsahuje kód určující její konkrétní typ. Rozšířené jmenovky jako obecný princip zavedlo EDNS(0), zatím však byly definovány jen nepoužívané experimentální binární jmenovky. Podrobněji je popíšeme společně s EDNS(0) na straně 130.

- 10: Zatím nedefinováno.

- 11: Zkratka, která se odkazuje na jiné jméno ve zprávě, případně jeho část. Zanedlouho ji popíšeme podrobněji.

Specifikace doporučují, aby stejný formát používaly interně také aplikace, které s DNS pracují.

3.2 Formát DNS zpráv

Formát zpráv, které si účastníci DNS komunikace vyměňují, definuje RFC 1035. Obsahuje celkem pět částí. Začíná pevnou hlavičkou se základními informacemi. Za ní následuje vlastní obsah, rozdělený do čtyř sekcí: dotaz, odpověď, autorita a doplňky. Rámcovou podobu DNS zprávy představuje obrázek 3.1. V základní podobě je přenášena protokolem UDP v jednom paketu a její celková délka nesmí překročit 512 B.

Obrázek 3.1: Formát DNS zprávy

K párování dotazů a odpovědí slouží počáteční Identifikátor (ID). Odesilatel do něj pro každý svůj dotaz vloží jednoznačnou hodnotu, kterou server zkopíruje do odpovědi. 16 bitů následujících za identifikátorem je věnováno různým příznakům a stavovým kódům charakterizujícím zprávu. Jednobitových příznaků je definováno celkem sedm:

- QR (Query/Response) rozlišuje, zda se jedná o dotaz (hodnota 0) nebo odpověď (hodnota 1). DNS je zde zcela minimalistické, zavádí pouhé dva základní typy zpráv, takže k jejich rozlišení slouží jediný bit.

- AA (Authoritative Answer) obsahuje jedničku, pokud je server autoritativní pro data obsažená v Odpovědi.

- TC (Truncated) indikuje, že zpráva byla zkrácena, protože překročila délkový limit 512 B. Tazatel by měl zopakovat dotaz protokolem TCP.

- RD (Recursion Desired) nastaví klient v dotazu, pokud požaduje jeho rekurzivní zpracování.

- RA (Recursion Available) umožňuje serveru oznámit, že podporuje rekurzivní zpracování dotazů.

- následující příznak není definován a povinně musí mít hodnotu 0

- AD (Authentic Data) ohlašuje, že server posílající zprávu úspěšně ověřil autentičnost dat pomocí DNSSEC (více v kapitole 8 na straně 431).

- CD (Checking Disabled) se používá v dotazu a je-li nastaveno, klient si vysloveně nepřeje ověření DNSSEC, chce si je zkontrolovat sám.

Čtyřbitová položka OpKód (Opcode) je spojena s dotazem. Upřesňuje, jaká činnost se od serveru očekává. Nejběžnější hodnotou je nepochybně nula, která ohlašuje standardní dotaz, kdy se ke jménu hledají záznamy daného typu. Další možné varianty shrnuje tabulka 3.1. K nejvýznamnějším z nich se později dostaneme.

Kód

Význam

Popis

0

QUERY

standardní dotaz

1

IQUERY

inverzní dotaz (zavržený)

2

STATUS

dotaz na stav serveru

3

nepřiřazeno

4

NOTIFY

upozornění na novinky

5

UPDATE

žádost o změnu

6

DSO

stavový provoz DNS

7–15

nepřiřazeno

Tabulka 3.1: Kódy dotazů (hodnoty položky    OpKód)

K odpovědi se váže návratový kód uložený v položce VýslKód (RCode). Pouze pokud obsahuje nulu, vše proběhlo v pořádku a má smysl zabývat se dalšími položkami odpovědi. Jak DNS postupně košatělo, návratové kódy jsou jedním z míst, kde brzy začala tlačit bota. Do 4 bitů, které jsou k dispozici, se vejde jen 16 hodnot. Rozšíření EDNS(0), kterému se za chvilku budeme věnovat, proto přidalo dalších 8 bitů v pseudozáznamu OPT, který doplňuje základní hlavičku. Přehled všech definovaných kódů včetně rozšiřujících najdete v tabulce 3.2.

Kód

Význam

Popis

0

NoError

vše v pořádku

1

FormErr

server nedokázal dotaz interpretovat

2

ServFail

problém na straně serveru

3

NXDomain

dané jméno neexistuje

4

NotImp

požadovaná operace není implementována

5

Refused

dotaz odmítnut na základě lokální politiky

6

YXDomain

jméno existuje, ale nemělo by

7

YXRRSet

sada záznamů existuje, ale neměla by (nesplněná podmínka)

8

NXRRSet

sada záznamů neexistuje, ale měla by (nesplněná podmínka)

9

NotAuth

server není pro zónu autoritativní

9

NotAuth

neautorizovaný požadavek (pro TSIG)

10

NotZone

jméno v zóně neexistuje (nesplněná podmínka nebo špatný cíl dynamické aktualizace)

11–15

nepřiřazeno

16

BADVERS

chybná verze OPT

16

BADSIG

selhání podpisu TSIG

17

BADKEY

neznámý klíč

18

BADTIME

podpis mimo dobu platnosti

19

BADMODE

chybný režim TKEY

20

BADNAME

duplicitní jméno klíče

21

BADALG

nepodporovaný algoritmus

22

BADTRUNC

špatné zkrácení

23–3840

nepřiřazeno

3841–4095

rezervováno pro privátní využití

4096–65534

nepřiřazeno

65535

rezervováno

Tabulka 3.2: Kódy odpovědí (hodnoty položky    VýslKód)

Navzdory prodloužení návratového kódu stále platí, že ke stejnému výsledku mohou vést různé příčiny a hodily by se větší podrobnosti. RFC 8914 Extended DNS Errors proto přišlo s konceptem rozšířených chyb. Jedná se o doplňkovou informaci upřesňující, proč odpověď obsahuje daný návratový kód. Specifikace zakazuje měnit podle těchto informací chování DNS, jedná se skutečně jen o doplněk, který slouží zejména pro diagnostiku problémů a ladění. Podrobnosti se dočtete na straně 914.

Všechny čtyři hlavní sekce DNS zprávy mají proměnlivou velikost. Proto jsou předcházeny čtveřicí položek základní hlavičky obsahujících jejich délky. Za nimi postupně následují:

- Dotaz (Question) specifikuje hledanou informaci. Jako jediný má pevnou strukturu – obsahuje hledané jméno, třídu a typ záznamů. Nelze se ptát na několik jmen či typů najednou. Pokud vznikne taková potřeba[1], je třeba odeslat několik samostatných dotazů, každý s jednou kombinací hledaných parametrů. Formát této části zprávy znázorňuje obrázek 3.2.

1Například v současnosti se často hledají ke jménu jak adresy protokolu IPv4 (záznamy typu A), tak IPv6 (typ AAAA).

Obrázek 3.2: Formát sekce    Dotaz v DNS zprávě

- Odpověď (Answer) obsahuje zdrojové záznamy přímo odpovídající na dotaz. Tedy záznamy požadovaného jména, typu a třídy. Formát zdrojového záznamu najdete na obrázku 3.3. Obsah sekce je tvořen prostou posloupností těchto záznamů, stejně jako zbývající dvě části.

- Autorita (Authority) poskytuje informace o autoritativních serverech příslušných pro řešení dotazu.

- Doplňky (Additional) nesou informace, které by mohly být tazateli užitečné. Mohou zde být například adresy serverů ze sekce autorit nebo materiál pro DNSSEC. Tato sekce zprávy není klíčová, pouze doplňuje informace z předchozích částí. Údaje zde obsažené klient v principu může získat následně samostatnými dotazy. Například poptával záznamy typu MX a dozvěděl se v Odpovědi doménová jména poštovních serverů, v Doplňcích byly přibaleny jejich adresy – záznamy typu A a/nebo AAAA. Pokud tam nebudou, zeptá se na ně. Bude to vyžadovat přenos dalších zpráv a bude to pomalejší, ale v principu je to možné. Přínos Doplňků spočívá ve zvýšení efektivity a zrychlení celého mechanismu.

Samozřejmě zdaleka ne každá zpráva obsahuje data ve všech čtyřech sekcích. Pokud se jedná o DNS dotaz, bývají Odpověď, Autorita i Doplňky prázdné a naplněn je pouze Dotaz. Když jsme se kořenového serveru ptali na adresu www.tul.cz, zkopíroval do své odpovědi Dotaz, Odpověď nechal prázdnou, protože ji nezná, ale v sekci pro Autoritu poslal jména autoritativních serverů domény cz a v Doplňcích jejich adresy (slepující záznamy). Pokud se zeptáte autoritativního serveru na adresu z jeho kompetence, často dostanete odpověď, jejíž všechny čtyři sekce jsou neprázdné.

Obrázek 3.3: Formát zdrojového záznamu v DNS zprávě

Poslední dílek do skládačky datových formátů představují zdrojové záznamy, jimiž jsou naplněny závěrečné tři sekce DNS zprávy. Každý záznam obsahuje pět základních informací: jméno, k němuž se vztahuje, svůj typ, třídu, nesená data a dobu životnosti této informace. Jsou přenášeny ve tvaru podle obrázku 3.3. Jméno (Name) je uloženo ve formátu popsaném v předchozí části. Samo v sobě obsahuje informace o délce, proto nejsou nutné žádné doprovodné položky. Přehled existujících Tříd (Class) podává tabulka 3.3. Definovaných Typů (Type) je dnes kolem devadesáti. Jejich výčet s veškerými podrobnostmi obsahuje část III na straně 848, postupem času se pozvolna mění – vznikají nové typy, jiné jsou opouštěny. Aktuální seznam tříd i typů zveřejňuje IANA na adrese

http://www.iana.org/assignments/dns-parameters.

Doba životnosti (TTL) zdrojového záznamu je uvedena relativně. Tato položka obsahuje počet sekund, po které smí příjemce ponechat záznam ve vyrovnávací paměti. Je-li nulová, záznam se sice může použít, ale uložit jej nelze.

Nesená data mají proměnlivou strukturu i délku. Tu proto uvádí samostatná položka Délka dat (RDlength), jejímž obsahem je délka položky Data (Rdata) v bajtech.

Kód

Zápis

Popis

0

rezervováno

1

IN

Internet

2

nepřiřazeno

3

CH

Chaosnet

4

HS

Hesiod

5–253

nepřiřazeno

254

NONE

žádná třída

255

ANY

libovolná třída

256–65279

nepřiřazeno

65280–65534

rezervováno pro privátní využití

65535

rezervováno

Tabulka 3.3: Třídy záznamů

V obsahu zpráv se urputně bojuje o místo – 512 bajtů není nijak oslnivé číslo, zejména pokud se do něj mají vejít i digitální podpisy a klíče DNSSEC. Jedním z významných spotřebitelů jsou jména, která se navíc často opakují. Proto RFC 1035 zavedlo jednoduchou komprimační metodu umožňující nahradit celé jméno či jeho část odkazem na jiné. Jedná se o šestnáctibitovou hodnotu, jejíž první dva bity obsahují jedničku[2] a ve zbývajících čtrnácti je uloženo číslo bajtu v DNS zprávě, kde začíná odkazovaná jmenovka. Pokud se ve zprávě opakuje stejné jméno (například jména zdrojových záznamů v Odpovědi se zpravidla shodují se jménem v Dotazu), lze je jednoduše nahradit odkazem. Dají se ale používat i části jmen – odkázat se třeba na závěrečné dvě jmenovky – a odkazy kombinovat se jmenovkami – začít jméno normálně, ale konec nahradit odkazem. Jediným omezením odkazů je, že skončí vždy až koncem odkázaného jména. Nelze převzít první jmenovku a za ni doplnit něco jiného. Doménové jméno v DNS zprávě může tedy mít jednu ze tří podob:

2Díky tomu lze odkaz snadno odlišit od běžné jmenovky. Ta začíná délkovým bajtem a jelikož jeho maximální hodnotou je 63, počáteční dva bity budou zaručeně nulové.

- plné jméno – sekvence jmenovek ukončená jmenovkou nulové délky,

- odkaz,

- sekvence jmenovek ukončená odkazem.

Komprimace je jednoduchá, výpočetně nenáročná, ale poměrně účinná, protože recyklovatelných jmen a jejich částí je v DNS zprávách dost. Extrémním příkladem je dotaz na kořenové servery. V odpovědi dostanete 13 jmen, která sdílejí poměrně dlouhou doménu root-servers.net. V sekci Doplňky se každé jméno dvakrát opakuje v záznamech typu A a AAAA. V nekomprimované podobě by všechna jména v odpovědi zabrala 741 B. Komprimace zmenší jejich objem na 116 B, tedy méně než šestinu. Díky tomu celá odpověď včetně všech adres měří 811 B.

Formát zprávy poskytuje dost malý prostor pro případné doplňky či rozšíření. Paul Vixie proto v roce 1999 přišel s návrhem, jak otevřít prostor těmto aktivitám. Vžilo se pro něj označení EDNS(0) a jeho definici přineslo RFC 2671 Extension Mechanisms for DNS (EDNS0), později nahrazené stejnojmenným RFC 6891. Jedná se o stručný dokument, který vlastně definuje jen dva prvky: pseudozáznam OPT a rozšířené typy jmenovek.

Pseudozáznam OPT zvětšuje počet možných kódů pro výsledek operace z původních šestnácti na 4096, s čímž si snad DNS nějakou dobu vystačí, a umožňuje přidat další příznaky. Podstatný přínos spočívá také v tom, že ohlašuje velikost UDP dat, která je jeho odesilatel schopen zpracovat naráz, a umožňuje tak posílat odpovědi přesahující standardních 512 B. Jeho podrobný popis najdete v části 18.6 na straně 899.

Rozšířené typy jmenovek se poznají podle toho, že v nejvyšších dvou bitech svého prvního bajtu obsahují hodnotu 01. Zbývajících šest bitů pak obsahuje typ této rozšířené jmenovky a na jejich hodnotě záleží, jak budou interpretována její následující data. Žádné konkrétní rozšířené typy RFC 2671 nezavedlo, jen definovalo tento obecný mechanismus pro jejich vytváření. RFC 6891

Na základní specifikaci navázalo RFC 2673 Binary Labels in the Domain Name System, které zavedlo binární jmenovky. Jejich formát byl jednoduchý– první bajt obsahoval konstantní hodnotu 65 identifikující tento typ jmenovky. Následovala jednobajtová délka a po ní až 256 bitů vlastní jmenovky v „nativní“ podobě. Textový zápis binární jmenovky byl uzavřen do znaků \[ a ], vlastní jmenovka pak byla zapsána v binární (prefix b), oktalové (prefix o) nebo hexadecimální (prefix x) soustavě, případně jako čtveřice tečkami oddělovaných desítkových čísel, stejně jako IPv4 adresa. Součástí zápisu jmenovky mohlo být i lomítko následované její délkou v bitech.

Pokud by doména nic.cz obsahovala desetibitovou jmenovku s hodnotou (binárně) 1001101101, mohla by být v textové podobě zapsána následujícími třemi způsoby: \[b1001101101].nic.cz, \[x9b4/10].nic.cz, \[o4664/10].nic.cz nebo \[155.64.0.0/10].nic.cz.

Binární jmenovky se ovšem neujaly. Chybějící podpora ze strany serverů způsobovala provozní potíže a žádný z návrhů na jejich konkrétní využití (například reverzní záznamy pro IPv6 podle později odmítnurého RFC 2874) se neprosadil. Když v roce 2013 vyšla v RFC 6891 aktualizovaná specifikace EDNS(0), nařídila povinnou podporu pseudozáznamu OPT, ovšem binární jmenovky uložila k ledu a změnila jejich statut na experimentální. Tato nová specifikace se k rozšířeným jmenovkám obecně staví velmi rezervovaně, protože způsobují řadu praktických problémů při nasazení.

EDNS(0) je podporováno snad všemi moderními implementacemi DNS. Staví na něm některá pozdější rozšíření, jako například DNSSEC (viz kapitola 8), pro jehož objemné záznamy by původní maximální délka zprávy 512 B byla příliš omezující.

3.3 Komunikace mezi klientem a serverem

Že je protokol DNS postaven na principu klient-server už víte. V běžných případech je komunikace mezi nimi triviální, zahrnuje výměnu pouhých dvou paketů: klient pošle dotaz a server na něj odpoví. Nemá tudíž valný smysl řešit ztrácení paketů či přehození jejich pořadí, k němuž by při přenosu Internetem mohlo dojít. Proto DNS jako standardní transportní protokol používá UDP, konkrétně jeho port 53.

Kromě základní komunikace však existují i případy, kdy je objem přenášených dat větší. Tím nejčastějším je přenos zóny z primárního serveru na sekundární. Případně může potřebná velikost odpovědi překročit délkový limit (standardně 512 B, při použití EDNS(0) může být vyšší, ale ani ten nemusí stačit). V takových případech přijde ke slovu protokol TCP (opět port číslo 53). DNS je tedy jednou z mála služeb využívajících oba základní transportní protokoly internetové architektury. Valnou většinu práce však zajistí UDP.

Situace s transportními protokoly se postupem času stále více zamotává a nově do ní vstupuje i šifrování. Zde popíšeme tradiční model, se kterým DNS přišlo na svět a který dosud převažuje. Specialitám, odchylkám a novotám se budeme věnovat v kapitole 5 na straně 265.

3.3.1 Klient

Vzájemnou komunikaci zahajuje vždy klient (resolver). Podle požadavků aplikace sestaví dotaz – DNS zprávu, které do sekce Dotaz uloží hledané jméno, typ a třídu záznamu. Jako typ může uvést libovolný konkrétní typ, nebo některou ze speciálních hodnot z tabulky 3.4. Za zmínku stojí zejména hodnota 252 (označovaná jako AXFR), jejímž prostřednictvím klient požaduje zaslání celé zóny. Používá se pro synchronizaci dat mezi servery, ke které se dostaneme později. Druhým zajímavým případem je hodnota 255 (označovaná jako hvězdička nebo ANY), která říká, že na typu záznamu nezáleží.

Typ

Význam

ANY (255)

libovolný typ

AXFR (252)

přenos celé zóny

IXFR (251)

přenos rozdílů v zóně

Tabulka 3.4: Speciální typy záznamů pro dotazy

Na první pohled by se tyto dva typy mohly zdát totožnými – oba chtějí „všechno“. Ve skutečnosti je mezi nimi podstatný rozdíl. Typ ANY požaduje záznamy, které se vztahují přesně k zadanému jménu. Například pro jméno nic.cz dostanete přes dvacet záznamů devíti typů – SOA, NS, MX, A, AAAA, TXT, RRSIG, NSEC3PARAM a DNSKEY. Všechny jsou svázány se jménem nic.cz. Požádáte-li o AXFR pro stejné jméno, dostali byste kompletní zónu. Tedy nejen záznamy pro vlastní nic.cz, ale také vše, co obsahuje – záznamy pro www.nic.cz, mail.nic.cz, a.ns.nic.cz, enum.nic.cz a řadu dalších[3]. Podíváte-li se na doménový strom, ANY se týká jen jednoho konkrétního vrcholu, zatímco AXFR žádá o celou zónu začínající daným vrcholem.

3Teoreticky. V praxi nedostanete nic, protože zónové přenosy bývají povoleny pouze sekundárním serverům, takže váš požadavek bude odmítnut – příchozí odpověď ponese výsledný kód Refused.

Popsaná interpretace ANY ve smyslu „chci všechny typy“ je tradiční a většina serverů se jí drží. Bohužel může vést ke dlouhým a snadno zneužitelným odpovědím. RFC 8482 Minimal Responses for ANY Queries proto zdůrazňuje, že toto chování nemá oporu ve specifikacích a ve skutečnosti ANY znamená „jakýkoli typ“, nikoli „všechny typy“. Navrhuje také několik možností, jak odpovědi zkrátit. Například autoritativní servery domény tul.cz pošlou jen záznam typu A.

Základní chování klienta je jednoduché. Pošle dotaz a čeká na odpověď. Pokud nepřichází, zkusí to znovu, pokud možno s jiným serverem. Když dorazí výsledky, předá je žadateli. Oficiálně jeho základní algoritmus definuje RFC 1034 následovně:

1. Pokud je odpověď k dispozici lokálně (ve zdejší vyrovnávací paměti), poskytne ji rovnou aplikaci a skončí.

2. Najde nejvhodnější servery.

3. Posílá jim dotazy, dokud některý neodpoví.

4. Analyzuje odpověď a vybere jednu z následujících variant:

1. Pokud obsahuje odpověď na dotaz, uloží si ji do vyrovnávací paměti a předá aplikaci.

2. Pokud odpověď obsahuje lepší delegaci (autoritativní servery blíže k řešení), uloží si ji do vyrovnávací paměti a vrátí se k bodu 2.

3. Pokud odpověď obsahuje přezdívku (CNAME) a tento typ záznamu nebyl aplikací požadován, uloží si záznam CNAME do vyrovnávací paměti, změní hledané jméno na kanonické jméno uvedené v CNAME a vrátí se k bodu 1.

4. Pokud odpověď oznamuje selhání serveru nebo je nekorektní, odstraní server ze seznamu dotazovaných a vrátí se k bodu 3.

Asi nejzajímavější je druhý bod, kde klient vybírá nejvhodnější servery. Je triviální u jednoduchého resolveru, který má svůj jeden server (nebo dva) a vše posílá jemu. V zajímavější situaci je plnohodnotný resolver pracující na rekurzivním serveru. Základním materiálem pro výběr serverů jsou záznamy typu NS v jeho vyrovnávací paměti. Vybere z nich autoritativní servery pro doménu, která má nejdelší shodu s hledaným jménem (shoduje se největší počet po sobě jdoucích jmenovek od konce doménového jména).

Hledá-li například www.uibk.ac.at a ve vyrovnávací paměti má záznamy NS pro domény ., nic.cz, cz a at, zvolí si v bodu 2 autoritativní servery pro doménu at, které jsou z nich nejblíže řešení. Jako odpověď od nich dostane záznamy NS pro doménu ac.at, které si podle bodu 4b přidá do vyrovnávací paměti, vrátí se k bodu 2 a nově si pro dotazování vybere právě tuto skupinu serverů, protože jsou nyní nejrelevantnější.

Pokud nenajde ve vyrovnávací paměti žádný vhodný server, musí mít k dispozici „krabičku poslední záchrany“ s adresami serverů pro tento případ. Standardně se jedná o adresy kořenových serverů.

Jak vybírat mezi servery, které se chystá oslovit, či v jakém pořadí je oslovovat specifikace neřeší a ponechává rozhodnutí na implementaci. Ta je buď náhodně střídá, nebo si vede statistiky o dobách odezvy a oslovuje nejprve ty nejrychlejší. Cílem je nalézt vhodnou rovnováhu mezi rychlostí odezvy a zatížením sítě.

3.3.2 Server

DNS server naslouchá na UDP a TCP portech číslo 53 a zodpovídá přicházející dotazy. Nejjednodušší variantou je nerekurzivní server, který zasílá pouze data vycházející z lokálních informací. Složitější je úloha rekurzivního serveru, který musí být doplněn resolverem a vyrovnávací pamětí, do níž si ukládá získané záznamy. RFC 1034 opět popisuje základní algoritmus jeho činnosti při sestavování odpovědi, později lehce doplněný v RFC 6672:

1. Podle svých vlastností nastaví nebo vymaže v odpovědi příznak RA oznamující dostupnost rekurzivního řešení dotazů. Pokud podporuje rekurzi a klient ji příznakem RD požadoval, pokračuje bodem 5. Jinak přejde k bodu 2.

2. Hledá v dostupných zónách takovou, která je nejbližším předkem hledaného jména. Jestliže ji najde, pokračuje bodem 3, při neúspěchu bodem 4.

3. Začne postupně shora dolů prohledávat jmenovky v zóně a porovnávat je s hledaným jménem. Může skončit několika různými způsoby:

1. Najde kompletní hledané jméno, tedy přesně požadovaný uzel doménového stromu. Pokud je nalezený záznam typu CNAME a tazatel nepožadoval záznam tohoto typu, vloží nalezený záznam CNAME do sekce Odpověď, nahradí hledané jméno za kanonické jméno podle záznamu a vrátí se ke kroku 1. Jinak vloží do sekce Odpověď všechny záznamy odpovídajícího typu pro nalezené jméno a pokračuje krokem 6.

2. Najde záznam typu NS, který znamená, že hledané jméno leží mimo zónu, pro niž je tento server autoritativní. Vloží nalezené záznamy NS do sekce Autorita a pokud pro ně zóna obsahuje slepující záznamy s adresami, přidá je do sekce Doplňky. Pokračuje bodem 4.

3. Pokud je shoda nemožná (odpovídající jmenovka neexistuje), podívá se, zda poslední nalezené jméno obsahuje záznam typu DNAME (více o něm v části 18.4 na straně 894). Pokud ano, vloží jej do Odpovědi, změní podle něj hledané jméno, vygeneruje záznam CNAME převádějící hledané jméno na změněné a také jej přidá do Odpovědi. Následně se vrátí ke kroku 1.

Když neexistuje DNAME, hledá použitelný žolíkový záznam. Budeme se jim věnovat v části 3.5, ale pro úplnost zde rozepíšeme příslušné chování. Použité pojmy vysvětlíme později..

4. Prohledá vyrovnávací paměť. Pokud v ní najde hledané jméno, vloží všechny záznamy vyhovujícího typu do sekce Odpověď. Nenajde-li jméno, ale jeho předek obsahuje záznam DNAME, vloží tento záznam do Odpovědi. Jestliže autoritativní data neobsahují žádnou delegaci, najde nejlepší použitelnou ve vyrovnávací paměti a přidá ji do sekce Autorita. Pokračuje bodem 6.

5. Použije místní resolver (nebo jeho ekvivalent) k nalezení odpovědi. Uloží výsledky, včetně všech mezilehlých záznamů CNAME a DNAME do sekce Odpověď.

6. Do sekce Doplňky přidá záznamy, které by mohly být užitečné. V této fázi už nezasílá žádné další dotazy, využívá jen lokálně dostupné informace. Tím příprava odpovědi končí.

3.4 Zónové přenosy

- starší SOA

- smazané záznamy

- novější SOA

- přidané záznamy

Jestliže v některém záznamu dojde ke změně, projeví se jako smazání původního záznamu a přidání jeho nového znění.

Obrázek 3.4: Kompletní rozdílový přenos

Obrázek 3.5: Komprimovaný rozdílový přenos

3.5 Žolíkové záznamy

@              SOA    a.ns.tul.cz. ...

NS     a.ns.tul.cz.

NS     tul.cesnet.cz.

MX     0  mail.tul.cz.

a.ns.tul.cz.   A      147.230.1.1

cosi.tul.cz.   A      147.230.1.100

mail.tul.cz.   A      147.230.1.2

*.tul.cz.      MX     0  mail.tul.cz.

www.*.tul.cz.  CNAME  cosi.tul.cz.

Obrázek 3.6: Příklad části doménového stromu

Dotaz: Záznam MX pro www.tul.cz.

www.tul.cz.       MX     0  mail.tul.cz.

Dotaz: Záznam A pro www.tul.cz.

www.obed.tul.cz.  MX     0  mail.tul.cz.

www.*.tul.cz.     CNAME  cosi.tul.cz.

cosi.tul.cz.      A      147.230.1.100

3.6 Vyrovnávací paměť

- Životnost všech záznamů v sadě musí být stejná. Pokud vytvoříte sadu s odlišnými hodnotami TTL, vaše data jsou chybná. Měnit životnost je třeba u všech záznamů sady stejně.

- Když klient obdrží sadu záznamů s různými TTL od autoritativního serveru, změní jejich životnosti na nejmenší z hodnot. Jestliže takto nekonzistentní odpověď dostal od neautoritativního serveru a má k dispozici alternativu, měl by odpověď ignorovat a získat ji z jiného zdroje. Není-li alternativa k dispozici, zkrátí životnosti jako u autoritativní odpovědi.

Table of Contents

Předmluva vydavatele

1 Jemný úvod do DNS

1.1 Historie DNS

1.2 K čemu slouží

I Základní principy

2 Jak to funguje

2.1 Doménový strom

2.2 DNS záznamy

2.3 Domény a servery

2.4 Resolver čili řešič

2.5 Život jednoho dotazu

2.6 Rekurzivní a nerekurzivní chování serverů

2.7 Domény, zóny a zónové soubory

2.8 Reverzní dotazy aneb hledá se jméno pro adresu

3 Vnitřní život DNS

3.1 Doménová jména

3.2 Formát DNS zpráv

3.3 Komunikace mezi klientem a serverem

3.3.1 Klient

3.3.2 Server

3.4 Zónové přenosy

3.5 Žolíkové záznamy

3.6 Vyrovnávací paměť

4 DNS z pohledu klienta

4.1 Konfigurace

4.2 Programy pro dotazování DNS

5 Transportní vrstva pro DNS

6 DNS v praxi

6.1 Scénáře použití

6.3 Podpůrné programy

7 Správa domén a vlastně i celého Internetu

II DNS pro starší a pokročilé

8 Principy DNSSEC

9 DNSSEC prakticky

10 Národní znaky v doménách, čili IDN

10.1 Jak funguje IDN

10.2 Problémy a otázky

11 Dynamické DNS

12 ENUM

13 Na pokraji DNS

14 DNS v cizích službách

15 Bezpečnost protokolu DNS

III Typy záznamů

17 Základní typy

18 Servisní typy

19 Typy pro DNSSEC a bezpečnostní mechanismy

20 Aplikační a ostatní typy

21 Typy odmítnuté, zastaralé a nepoužívané

IV DNS servery

22 Obecně ke konfiguraci serveru

22.2 Zónové soubory

23 BIND

23.1 Základní konfigurace

23.2 Doprovodné programy

23.3 Konfigurace pro náročné

24 NSD

24.2 Doprovodné programy

24.3 Konfigurace pro náročné

25 Unbound

25.2 Doprovodné programy

25.3 Konfigurace pro náročné

26 Knot DNS

26.2 Doprovodné programy

26.3 Pokročilé nastavení

27 Knot Resolver

28 PowerDNS

28.2 Doprovodné programy

28.3 Konfigurace pro náročné

29 PowerDNS Recursor

29.2 Doprovodné programy

29.3 Konfigurace pro náročné

30 OpenDNSSEC

V Přílohy

A Přehled RFC