11 DNS

Vazba mezi jménem počítače a IP adresou je definována v DNS databázi. DNS (Domain Name Systém) je celosvětově distribuovaná databáze. Jednotlivé části této databáze jsou umístěny na tzv. name serverech.

Domény a subdomény

řetězec.řetězěc.řetězec....řetězec.

kde první řetězec je jméno počítače, další jméno nejnižší vnořené domény, další vyšší domény atd. Pro jednoznačnost se na konci uvádí také tečka, vyjadřující root doménu.

Celé jméno může mít maximálně 255 znaků, řetězec pak maximálně 63 znaky. Řetězec se může skládat z písmen, číslic a pomlčky. Pomlčka nesmí být na začátku ani na konci řetězce. Existují i rozšíření specifikující bohatší repertoár znaků použitelných pro tvorbu jmen. Zásadně se však těmto dalším znakům vyhýbáme, protože jen některé aplikace toto rozšíření podporují.

Mohou se použít velká i malá písmena, ale není to zase tak jednoduché. Z hlediska uložení a zpracování v databázi jmen (databázni DNS) se velká a malá písmena nerozlišují. Tj. jméno newyork.com bude uloženo v databázi na stejné místo jako NewYork.com nebo NEWYORK.com atp. Tedy při překladu jména na IP-adresu je jedno kde uživatel zadá velká a kde malá písmena. Avšak v databázi je jméno uloženo s velkými a malými písmeny, tj. bylo-li tam uloženo např. NewYork.com, pak při dotazu databáze vrátí NewYork.com. Poslední tečka je součástí jména.

V některých případech se může část jména zprava vynechat. Téměř vždy můžeme koncovou část doménového jména vynechat v aplikačních programech. V databázích popisujících domény je však situace složitější.

Je možné vynechat:

• Poslední tečku téměř vždy.
• Na počítačích uvnitř domény se zpravidla může vynechat konec jména, který je shodný s názvem domény. Např. uvnitř domény pipex.cz, je možné psát místo počítač.abc.pipex.cz jen počítač.abc (nesmí se ale uvést tečka na konci!). Do kterých domén počítač patří se definuje příkazy domain a search v konfiguračním souboru resolveru.

Netvořte jména subdomén v kolizi se jmény Top Level Domén. Např. chcete-li rozdělit doménu pipex.cz na subdomény podle krajských měst a použijete dvojznakové řetězce, vznikne problém. Pro Liberec byste si vybrali např. lb.pipex.cz.

Uživatel z domény cbu.pipex.cz bude psát mail uživateli Alois v doméně lb.pipex.cz a napiše podle předchozího pravidla příkaz:

mail Alois@lb

Uvedenému problému předejdete, zvolíte-li si pro Liberec např. doménu lbc.pipex.cz.
 
 

Reverzní domény

Podobně jako domény, tvoří i IP-adresy stromovou strukturu. Domény tvořené IP-adresami se pak často nazývají reverzní domény. Pro účely reverzního překladu byla definována pseudo doména “in-addr.arpa”. Jméno této pseudo domény má historický původ, jde o zkratku ze “inverse addresses in the Arpanet”.
 

Obr. 11.2 Doména 14.17.172.in-addr.arpa

Pod doménou in-addr.arpa jsou domény jmenující se jako první číslo z IP-adresy sítě. Např. síť 194.149.101.0 patří do domény 194.in-addr.arpa. Síť 172.17 patří do domény 172.in-addr.arpa. Dále doména 172.in-addr.arpa se dělí na subdomény, takže síť 172.17 tvoří subdoménu 17.172.in-addr.arpa. Je-li síť 172.17 rozdělena pomocí síťové masky na subsítě. Pak každá subsíť tvoří ještě vlastní subdoménu. Všimněte si, že domény jsou zde tvořeny jakoby IP-adresami sítí psanými ale pozpátku.
 

Doména 0.0.127.in-addr.arpa

Zatímco ostatní IP-adresy jsou v Internetu jednoznačné, adresa 127.0.0.1 se vyskytuje na každém počítači.

Každý name server je autoritou nejen "obyčejných" domén ale ještě autoritou (primárním name serverem) k doméně 0.0.127.in-adr.arpa. V dalším textu budeme tento fakt považovat za samozřejmost a v tabulkách jej pro přehlednost nebudeme uvádět, ale nikdy na něj nesmíte zapomenout.
 

Zóna

Jak jsme již uvedli doména je skupina počítačů, které mají společnou pravou část svého doménového jména. Doména je např. skupina počítačů, jejichž jméno končí cz. Doména cz je však velká. Dělí se déle na subdomény např. pvt.cz, eunet.cz, a tisíce dalších. Každou z domén druhé úrovně si většinou spravuje na svých name serverech majitel domény nebo jeho poskytovatel Internetu. Data pro doménu druhé úrovně např. pvt.cz nejsou na stejném name serveru jako doména cz. Jsou rozložena na mnoho name serverů. Data o doméně uložená na name serveru jsou nazývána zónou. Zóna tedy obsahuje jen část domény.

Zóna je část prostoru jmen, kterou obhospodařuje jeden name server.

Obr. 11.3 Zóna pvtnet.cz

Na obrázku 11.3 je znázorněno, jak může být (hypoteticky) v doméně pvtnet.cz pomocí vět typu NS decentralizována kompetence na nižší správní celky. Takže doména pvtnet.cz obsahuje v sobě všechny subdomény, ale zóna pvtnet.cz delegovala na jiné name servery pravomoci na zóny brn.pvtnet.cz, plz.pvtnet.cz a ova.pvtnet.cz. Takže zóna pvtnet.cz obsahuje doménu pvtnet.cz až na tři uvedené výjimky.

Dotazy (překlady)

Name server po svém startu natáhne do paměti data pro zónu, kterou obhospodařuje. Primární name server natáhne data z lokálního disku, sekundární name server dotazem zone transfer získá pro obhospodařované zóny data z primárního name serveru a rovněž je uloží do paměti. Tato data primárního a sekundárního name serveru se označují jako autoritativní (nezvratná). Dále name server natáhne z lokálního disku do paměti data, která nejsou součástí dat jeho obhospodařované zóny, ale umožní mu spojení s root name servery a případně s name servery, kterým delegoval pravomoc pro obhospodařování subdomén.Tato data se označují jako neautoritativní.

Name server i resolver společně sdílejí paměť cache. Během práce do ní ukládají kladné odpovědi na dotazy, které provedli na jiné name servery, tj. ke kterým jsou jiné name servery autority. Ale z hlediska našeho name serveru jsou tato data opět neautoritativní - pouze šetří čas při opětovných dotazech.

Obr. 11.5 DNS na serveru

Do paměti se ukládají jen kladné odpovědi. Provoz by byl podstatně zrychlen, kdyby se tam ukládali i negativní odpovědi (negativní caching), avšak to je podstatně složitější problém. Podpora negativního cachingu je záležitost posledních několika let.

Takto pracuje DNS na serverech (např. s operačním systémem NT nebo UNIX). Avšak např. PC nemívají realizovány servery. V takovém případě se celý mechanizmus redukuje na tzv. pahýlový resolver. Tj. z celého mechanizmu zůstane pouze resolver.

Resolver předává všechny dotazy na lokální name server. Od name serveru pak očekává konečnou (rekurzivní) odpověď. Name server buď odpoví přímo nebo sám kontaktuje další name servery, tj. name server rekurzivně řeší dotaz a klientovi zašle až výsledek.

Lokální name server udržuje společnou cache pro všechny lokální počítače.

Obr. 1.6 Pahýlový resolver

DNS používá jak protokol UDP, tak i protokol TCP. Pro oba protokoly používají port 53 (tj. porty 53/udp a 53/tcp). Běžné dotazy jako je překlad jména na IP-adresu a naopak se provádějí přes protokol UDP. Délka přenášených dat protokolem UDP je implicitně omezena na 512 B (příznakem truncation může signalizováno, že se odpověď nevešla do 512 B a pro přídanou kompletní odpověď je nutné použít protokol TCP). Délka UDP paketu je omezena na 512 B protože u větších IP-datagramů by mohlo dojít k fragmentaci. Fragmeentaci UDP datagramu DNS nepovažuje za rozumnou.

Dotazy, kterými se přenášejí data o zóně (zone transfer) např. mezi primárním a sekundárním name serverem se přenáší protokolem TCP.

Běžné dotazy (např. překlad jména na IP-adresu a naopak) se provádí pomocí datagramů protokolu UDP. Překlad požaduje klient (resolver) na name serveru. Neví-li si name server rady, může požádat o překlad (o pomoc) jiný name server prostřednictvím root name serveru.

V Internetu platí pravidlo, že databáze s daty nutnými pro překlad jsou vždy uloženy alespoň na dvou nezávislých počítačích (nezávislých name serverech). Je-li jeden nedostupný, pak se překlad může provést na druhém počítači.

Obecně se nepředpokládá, že by byly všechny name servery dostupné. V případě, že by se pro překlad použil protokol TCP, pak by navazování spojení na nedostupný počítač znamenalo přečkat časové intervaly protokolu TCP pro navázání spojení a teprve poté by bylo možno se pokusit navázat spojení s dalším name serverem.

Řešení pomocí protokolu UDP je elegantnější: Datagramem se vyšle žádost prvnímu serveru, nedostane-li se odpoveď do krátkého časového intervalu, pak se pošle datagramem žádost dalšímu (záložnímu name serveru), nedostane-li se opět odpověď, pak se pošle dalšímu atd. V případě, že se vyčerpají všechny možné name servery, pak se opět začne prvním a celý kolotoč se zopakuje, dokud nepřijde odpověď nebo nevyprší stanovený časový interval.

Obr. 11.7 Řešení požadavku na překlad

Resolver

Klient (např. zmíněný telnet) zavolá knihovní funkce, které zformulují dotaz a vyšlou jej na server. Server je v UNIXu realizován programem named. Server buď překlad provede sám, nebo si sám vyžádá pomoc od dalších serverů, nebo zjistí, že překlad není možný.

Do hry ještě vstupují časová omezení. Může se totiž stát, že na položený dotaz nedostane resolver odpověď, ale další stejný dotaz již bude korektně zodpovězen (serveru se mezitím podařilo získat odpověď a první dotaz nebyl zodpovězen proto, že odpověď z jiného name serveru dlouho nepřicházela). Z hlediska uživatele se to jeví tak, že napoprvé se překlad nepovede a při dalším zadání téhož příkazu už ano.

Podobný efekt způsobuje i použití protokolu UDP. Může se totiž také stát, že server vůbec žádost o překlad neobdrží protože je síť přetížená a UDP-datagram se prostě někde ztratil.

Klient může sice mít v konfiguračním souboru uvedeno více name serverů, ale použije se vždy jen odpověď, která přišla první. Tj. když jako první přijde negativní odpověď (např., že k danému jménu neexistuje IP-adresa), nepokusí se resolver kontaktovat další name server, který by jméno snad přeložil (jak si mnozí představuji), ale oznámí, že překlad k danému jménu neexistuje.

Konfigurační soubor pro resolver se v operačním systému UNIX jmenuje /etc/resolv.conf. Zpravidla obsahuje dva typy řádků (druhý se může několikrát opakovat):

domain  jméno_místní_domény
nameserver      IP-adresa_name_serveru

Některé resolvery umožňují jmen místních domén zadat více příkazem search.

Příkazem nameserver se specifikuje IP-adresa name serveru, který má resolver kontaktovat. Je možné uvést i další příkazy nameserver pro případ, že některé name servery jsou nedostupné. Musí se zde uvést IP-adresa name serveru – nikoliv doménové jméno nameserveru!

V případě konfigurace resolveru na name serveru může příkaz nameserver ukazovat na místní name server 127.0.0.1 (nemusí to však být pravidlem).

Další parametry resolveru (např. maximální počet příkazů nameserver) lze nastavit v konfiguračním souboru jádra. Tento soubor se často jmenuje /usr/include/resolv.h. Musí pochopitelně pak následovat sestavení jádra operačního systému.

Obecně je možné konfigurovat všechny počítače též bez použití DNS. Pak se veškeré dotazy na překlady adres provádějí lokálně pomocí souboru /etc/hosts. Je možné obě metody i kombinovat (nejčastější případ), pak však je třeba být opatrný na obsah databáze /etc/hosts. Většinou je možné i nastavit v jakém pořadí se mají databáze prohlížet. Zpravidla se prohlíží nejprve soubor /etc/hosts a posléze DNS. V DEC OSF/1 slouží pro konfiguraci pořadí prohledávání soubor /etc/svc.conf.
 

Name server

Name server je program, který provádí na žádost resolveru překlad. V UNIXu je name server realizován programem named.

Podle uložení dat rozlišujeme následující typy name serverů:

• Primární name server udržuje data o své zóně v databázích na disku. Pouze na primárním name serveru má smysl editovat tyto databáze.
• Sekundární name server si kopíruje databáze v pravidelných časových intervalech z primárního name serveru. Tyto databáze nemá smysl na sekundárním name serveru editovat, neboť budou při dalším kopírování přepsány. Primární i sekundární name servery jsou tzv. autoritou pro své domény, tj. jejich data pro příslušnou zónu se považují za nezvratná (autoritativní).
• Caching only server není pro žádnou doménu ani primárním ani sekundárním name serverem (není žádnou autoritou). Avšak využívá obecné vlastnosti name serveru, tj. data, která jím prochází ukládá ve své paměti. Tato data se označují jako neautoritativní. Každý server je caching server, ale slovy caching only zdůrazňujeme, že pro žádnou zónu není ani primárním ani sekundárním name serverem (Pochopitelně i caching only server je primárním name serverem pro zónu 0.0.127.in-addr.arpa, ale to se nepočítá).
• Root name server je name server obsluhující root doménu. Každý root name server je primárním serverem, což jej odlišuje od ostatních name serverů.

Z hlediska klienta není žádný rozdíl mezi primárním a sekundárním name serverem. Oba mají data stejné důležitosti - oba jsou pro danou zónu autority. Klient nemusí ani vědět, který server pro zónu je primární a který sekundární. Naproti tomu caching server není autoritou, tj. nedokáže-li provést překlad, pak kontaktuje autoritativní server pro danou zónu.

Takže přidá-li správce zóny (hostmaster) do databáze na primárním name serveru další počítač. Pak po době stanovené parametrem ve větě SOA se tato databáze automaticky opraví i na sekundárních name serverech (opravil-li by ručně jen databázi na sekundárním name serveru, pak by po stejné době oprava zmizela!). Problém nastane v případě, že uživatel v době, kdy ještě není sekundární name server aktualizován, dostane první odpověď od sekundárního name serveru. Ta je negativní, tj. takový počítač v databázi není.

Klasickou chybou je, že primární name server pracuje korektně, ale na sekundárním name serveru z nějakého důvodu nejsou data pro zónu. Klienti náhodně autoritativní odpovědi z primárního name serveru či ze sekundárního name serveru. Odpovědi z primárního name serveru správně překládají, kdežto odpovědi ze skeundárního name serveru jsou negativní (uživatele pak říkají: “jednou to jde a podruhé ne”).

Autoritativní data pocházejí z databází na disku. Je zde pouze jedna výjimka. Pro správnou činnost name serveru musí name server znát root name servery. Pro ty však není autoritou, přesto každý name server má na disku databázi informací o root serverech, kterou ale zavádí příkazem cache do sekundární paměti (není k nim autorita).

Na obr. 11.9 je překlad jména abc.pipex.cz na IP-adresu (nejedná se o forwarder nebo slave server):

Obr. 11.9 Překlad jména abc.pipex.cz na IP-adresu

1. Resolver zformuluje požadavek na name server a očekává jednoznačnou odpověď. Umí-li nameserver odpovědět, pak obratem zašle odpověď. Odpověď hledá ve své cache paměti (5). Tam jsou, jak autoritativní data z databází na disku, tak i neautoritativní data získaná při předešlých řešeních. Nezná-li server odpověď, pak kontaktuje další servery. Vždy začíná root name serverem.

 

 
 
 

Nezná-li name server přímo odpověď, pak kontaktuje root name server, proto každý name server musí znát IP-adresy root name serverů. Není-li však žádný root server dostupný (to je např. případ všech uzavřených sítí) pak po několika neúspěšných pokusech celý proces překladu zkolabuje.

Root name server zjistí, že informace o doméně cz delegoval větou typu NS name serveru nižží úrovně a zašle našemu name serveru IP-adresy serverů obhospodařujících doménu cz.

2. Name server se obrátí na server pro doménu cz, který však zjistí, že informace o doméně delegoval větou typu NS name serveru nižší úrovně a zašle našemu name serveru IP-adresy serverů obhospodařujících doménu pipex.cz.
3. Náš server se tedy obrátí na server obhospodařující doménu pipex.cz, který mu požadavek vyřeší (nebo ne). Výsledek předá klientovi.
4. Informace které postupně získal si též uloží do cache.

$ nslookup
 set norecurse
 set nosearch

Forwarding a slave servery

Zatím jsme si řekli, že resolver předává požadavek na překlad name serveru, tj. pošle name serveru dotaz a čeká na odpověď. Když name server neumí odpovědět sám, kontaktuje root name server, který mu poradí, pak z jeho rady kontaktovat další name server, pak ... . Name server posílá do Internetu mnoho paketů.

Je-li podniková síť připojena k Internetu pomalou linkou, pak místní name server zatěžuje linku svými překlady. V takovém případě je výhodné si name server konfigurovat jako forwarding server (viz obr. 11.10). Forwarding server vezme požadavek od klienta a předá jej forwarderovi na rychlé síti jako rekurzivní dotaz. Forwarder je server v Internetu, který je připojen rychlejšími linkami. Dotaz rekurzivně vyřeší a pošle mému forwarding serveru konečný výsledek. Jako forwarder je praktické použít name server posytovatele Internetu.

Forwarding server čeká na odpověď od forwardera. Nedočká-li se odpovědi v danném časovém intervalu, pak sám kontaktuje root name servery a pokouší se sám vyřešit překlad.

Nemá-li forwarding server kontaktovat root name servery, ale pouze čekat na odpověď od forwardera, pak je nutné označit takový server navíc jako slave server. Slave servery se používají v uzavřených podnikových sítích (za firewallem), kde není možný kontakt s root name servery. Slave server pak kontaktuje forwardera, který je součástí firewallu.

Slave server musí být forwarding server. Avšak jak forwarding server, tak slave server mohou být jak caching only servery, tak i primární nebo sekundární name servery pro určitou zónu.

Obr. 11.10 Forwarder server
 

Věty RR

V případě, že DNS klient (resolver) potřebuje získat informace z DNS pak požaduje po name serveru věty RR podle zadaných požadavků. Klient může např. požadovat po serveru věty RR typu A, které obsahují IP adresy pro dané doménové jméno, apod.

Všechny věty RR mají stejnou strukturu. Struktura RR věty je znázorněna na obr. 11.11.

Obr. 11.11 Struktura věty RR

Jednotlivá pole vět RR obsahují:

• NAME - Doménové jméno.
• TYPE - Typ věty.
• CLASS - Třída věty.
• TTL - Time to live. 32 bitové číslo, udávající dobu, po kterou může být tento RR udržován v cache server jako platný. Po vypršení této doby musí být věta považována za neplatnou. Hodnota 0 zabraňuje neautoritativním serverům uložit RR větu do cache.
• RDLENGTH - 16 bitové číslo specifikující délku pole RDATA.
• RDATA - Vlastní data ve tvaru řetězce proměnné délky. Formát tohoto pole závisí na typu a třídě RR.

Tab. 11.1 Nejčastější typy vět RR

Typ	Anglický název	Význam pole RDATA
A	A host address	32 bitová IP adresa
NS	Authoritative name server	Doménové jméno name serveru, který je autoritou pro danou doménu.
CNAME	Canonical name for an alias	Doménové jméno specifikující synonymum k NAME
SOA	Start Of Autority.	Právě jedna věta SOA uvozuje každou zónu. Obsahuje 7 polí. přesný popis viz. DNS databáze.
PTR	Domain name pointer	Doménové jméno. Věta se používá pro reverzní překlad.
HINFO	Host information	Obsahuje dva znakové řetězce. První obsahuje popis HW a druhý popis SW, které jsou používané na počítači NAME.
MX	Mail exchange	Obsahuje dvě pole. První 16 bitové pole bez znaménka obsahuje preferenci a druhé obsahuje doménové jméno maillového serveru.
TXT	Text string	Textový řetězec s popisem.
AAAA	IP6 address	128 bitová IP adresa (IP verze 6)
WKS	Well known service description	Popisuje obvyklých služeb serveru v protokolech TCP a UDP. obsahuje 3 části: 32 bitovou adresu, číslo protokolu, porty služeb.
SIG	Security signature	Podpisová věta, používaná při autentizaci v Secure DNS.
KEY	Security key	Veřejný klíč zony používaný pro podepisování při autentizaci
NXT	Next domain	Další doménové jméno. Autentikace neexistence doménového jména a typu.

DNS protokol

DNS protokol je protokol aplikační vrstvy, neřeší tedy otázku vlastního přenosu paketů. Přenos svých paketů svěřuje transportnímu protokolu. Na rozdíl od drtivé většiny ostatních aplikačních protokolů využívá DNS jako transportní protokoly UDP i TCP. Dotaz i odpověď jsou přenášeny vždy stejným transportním protokolem.

U dotazů na překlad (tj. žádosti o RR record) je dávána přednost protokolu UDP. V případě, že je DNS odpověď delší než 512 B, vloží se do odpovědi pouze část informací nepřesahující 512B a v záhlaví se nastaví bit TC, specifikující, že se jedná o neúplnou odpověď. Klient si může kompletní odpověď vyžádat protokolem TCP.

U přenosu zón např. mezi primárním a sekundárním name serverem se používá protokol TCP. Name server standardně očekává dotazy jak na portu 53/udp tak na portu 53/tcp.

DNS query

DNS protokol používá několik typů operací. Standardní nejčastěji používanou operací je DNS QUERY. Tedy získání RR rekordu. Z novými rozšířeními DNS protokolu přibývají i nové typy operací. např. DNS NOTIFY nebo DNS UPDATE.

Formát DNS paketu

Záhlaví paketu

Obr. 11.13 Pole záhlaví DNS paketu

První dva bajty (16 bitů) záhlaví obsahují identifikátor zprávy. Identifikaci zprávy generuje klient a server jej kopíruje do odpovědi. Identifikáace slouží k párování dotazu a odpovědi. Jednoznačně určuje, ke kterému dotazu patří která odpověď. Identifikace umožňuje klientovi posílat více dotazů současně, aniž by musel čekat na odpověd.

Další dva bajty záhlaví obsahují řídící bity. Tabulka 11.2 uvádí význam jednotlivých hodnot těchto řídících bitů.

Tab. 11.2 Význam jednotlivých řídících bitů ze záhlaví DNS paketu
 

Pole	Počet bitů	Hodnota
QR	1	0 pokud je zpráva dotazem 1 pokud je zpráva odpovědí
Opcode	4	Typ otázky je stejný v dotazu i odpovědi:  0 – standardní otázka (QUERY)  1 - inverzní otázka (IQUERY) 2 - otázka na status (STATUS) 4 - notify otázka (NOTIFY) 5 - update otázka (UPDATE)
AA	1	0 – odpověď není autoritativní 1 – odpověď je autoritativní
TC	1	1 – odpověď byla zkrácena na 512 bajtů. Pokud má klient zájem o celou odpověď, pak musí dotaz zopakovat pomocí protokolu TCP.
RD	1	1 - pokud klient požaduje rekurzivní překlad (důležité pro dotaz)
RA	1	1 - pokud server umožňuje rekurzivní překlad (důležité pro odpověd)
Z	3	rezervované pro budoucí použití
Rcode	4	Výsledkový kód odpovědi 0 - Bez chyby (Noerror) 1 - Chyba ve formátu dotazu, server jej neumí interpretovat (FormErr) 2 - Server neumí odpovědět (ServFail)  3 - Jméno z dotazu neexistuje (tj. negativní odpověď),     tuto odpověď mohou vydat pouze autoritativní name servery (NXDomain) 4 - Server nepodporuje tento typ dotazu (NotImp) 5 - Server odmítá odpovědět, např. z bezpečnostních důvodů (Refused)

Další čtyři dvojbajtová pole obsahují počet vět obsažených v sekcích, které následují za záhlavím.

• QDCOUNT - číslo určující, z kolika vět se skládá dotaz
• ANCOUNT - číslo určující, z kolika vět se skládá odpověď
• NSCOUNT - číslo určující, z kolika vět se skládá sekce obsahující odkazy na autoritativní name servery
• ARCOUNT - číslo určující, z kolika vět se skládá sekce doplňující informace

Sekce dotaz (Quetion section)

Pakety DNS dotazů obsahují většinou pouze jednu sekci a to sekci dotazu (QDCOUNT=1). Sekce dotazu obsahuje tři pole:

QNAME - obsahuje doménové jméno. DNS protokol nepoužívá pro vyjádření doménového jména tečkovou notaci. Každá část doménového jména (v běžném zápisu mezi tečkami) je uvozena bajtem obsahujícím délku řetězce. Na konci doménového jména je nula označující konec doménového jména (nulová délka řetězce). Příkladem obsahu tohoto pole v dotazu na překlad doménového jména info.pvt.net: 4info3pvt3net0. Délky řetězce jsou v binárním tvaru.

QTYPE - specifikuje typ dotazu, tj, požadovaný typ věty v odpovědi.

Nejčastější typy dotazu uvádím v tabulce 11.4.

Tab. 11.4 Hodnoty typů dotazů
 

Typ	Hodnota (desítkově)	Význam
A	1	Požadavek na získání IP adresy verze 4
NS	2	Požadavek na získání autoritativních name serverů
CNAME	5	Požadavek na získání věty CNAME
SOA	6	Požadavek na získání věty SOA
WKS	11	Požadavek na získání věty WKS
PTR	12	Požadavek na získání PTR věty
HINFO	13	Požadavek na získání HINFO věty
MX	15	Požadavek na získání věty MX
TXT	16	Požadavek na získání TXT věty
SIG	24	Požadavek na získání věty SIG
KEY	25	Požadavek na získání věty KEY
NXT	30	Požadavek na získání věty NXT
AAAA	28	Požadavek na získání IP adresy verze 6
AXFR	252	Požadavek na získání transferu celé zony
IXFR		Požadavek na získání inkremetálního zóne transferu
*	255	Požadavek na získání všech vět

QCLASS - třída dotazu (viz tab. 11.5)
 

Tab. 11.5 Jednotlivé třídy

Číselná hodnota (desítkově)	Význam
1	IN - Internet
3	CH - Chaos
4	HS - Hesiod
255	* - všechny třídy (pouze jako QCLASS)

Sekce odpověď, autoritativní servery a doplňující informace

Pakety odpovědi obsahují obvykle vedle záhlaví a zopakované sekce dotazu ještě tři sekce: sekci odpovědi, sekci autoritativních serverů a sekci doplnujících informací. Sekce autoritativní name servery obsahuje jména name serverů uvedených ve větách NS. Sekce doplňkové údaje obsahuje obvykle IP adresy autoritativních name serverů. Věty v těchto sekcích jsou běžné resource recordy (RR) - obdobné větám v cache name serveru a mají společný formát:

NAME - doménové jméno, stejný formát jako v sekci dotazu QNAME
TYPE - typ věty, stejný formát jako v sekci dotazu QTYPE
CLASS - třída věty, stejný formát jako v sekci dotazu QCLASS
TTL - doba platnosti RR, tj. jak douho může být odpověď udržovaná jako platná v cache.
RDLENGTH - délka části RDATA
RDATA - pravá strana zdrojové věty (IP adresa nedo doménové jméno)
 

Komprese

Doménové jméno, jak jsem již uvedla není v DNS paketu uvedeno v tečkové notaci, ale jako oddělovač jednotlivých částí doménového jména je použito číslo určující délku následující části. Tento oddělovač je uložen v jednou bajtu. Každá část doménového jména může být dlouhá maximálně 63 znaků, tedy oddělovací bajt bude mít maximální hodnotu 63 vyjádřenou dvojkově 00111111_{2 = 6310}. Pokud je v tomto bajtu číslo 192 nebo větší, pak je to příznak toho, že nebude uvedeno doménové jméno, ale pouze odkaz na jeho předcházející výskyt. Ukazatel je dlouhý 16 bitů. V prvních dvou bitech obsahuje jedničku, čímž se odlišuje od běžného oodělovače. V dalších bitech pak obsahuje pořadové číslo bajtu od začátku DNS paketu, kde začíná doménové jméno, na které má odkaz ukazovat.

Posun 0 by ukazoval na první bajt, tj. pole ID v sekci záhlaví.

Obr. 11.14 Komprese DNS paketu

Inverzní dotaz

1. Inverzní dotazy nemusí být name serverem podporovány. Jejich specifikace je uvedena v RFC 1035.
2. UPDATE

DNS UPDATE umožnuje dynamicky opravovat záznamy v DNS databázi. Umožnuje přidat jednu nebo několik vět do zonového souboru, nebo jednu případně několik vět ze zonového souboru zrušit. Záznamy v DNS databázi tedy nemusí již staticky opravovat správce serveru, ale je mozné záznamy v DNS databázi opravit dynamicky pomocí príslušného klinta na dálku použitím DNS protokolu.

S DNS UPDATE se setkáváme v BIND 8, proto budeme používat i terminologii BIND 8, tj. master/slave name server.

Data v zoně lze pomocí DNS update opravovat pouze na primary master serveru. Pokud DNS Update dotaz obdrží slave server, pak tento dotaz forwarduje primary master serveru.

DNS UPDATE neumožňuje vytvářet nové zony, umožňuje pouze opravovat zony již existující. Pomocí DNS Update tedy není možné přidávat novou SOA větu nebo SOA větu rušit, SOA větu je možné pouze opravit.

Jedním DNS Update dotazem je možné opravit jednu nebo několik vět v jedné zoně.

Opravu zony pomocí DNS Update je možné provést za specifikovaných podmínek. Podmínkou je existence nebo neexistence daných RR vět v master zoně před opravou. Např. požaduji-li rušit větu v zoně, musí tato věta v zoně před opravou existovat. Podmínek tohoto typu může být pro provedení opravy specifikováno několik. Z hlediska splnění jsou podmínky posuzovány jako celek. Tedy není-li splněna jedna z uvedených podmínek, nejsou splněny podmínky jako celek a žádná z požadovaných oprav se neprovede.

V DNS update paketu jsou odděleně specifikovány podmínky pro provedení opravy a odděleně jsou uvedeny RR věty, které se mají do zonového souboru přidat nebo z něho zrušit.

DNS UPDATE využívá specifikaci DNS protokolu tak, jak jej definuje RFC 1035 a jak jsme si jej vysvětlili v kapitole 11.14. Norma RFC2136 však definuje některá rozšírení tohoto protokolu, např. nový typ zprávy, nové výsledkové kódy. Formát DNS paketu pro UPDATE tedy zustává stejný, skládá se opět z pěti částí. Jednotlivé části však mají v tomto případě specifický obsah i pojmenování.

Paket DNS UPDATE se skládá ze sekcí (viz obr. 11.15):

• záhlaví
• sekce zony - definuje, zonu, ke které se vztahují opravy
• sekce předpokladu - sada RR vět, které musí v zone existovat
• sekce update - sada RR vět, které se mají opravit nebo zrušit
• sekce doplňkových informací - informace jež nejsou součástí update, ale jsou třeba k provedení update

Obr. 11.15 Formát paketu DNS UPDATE
 

Sekce záhlaví

Sekce záhlaví podobně jako u DNS QUERY obsahuje v prvních dvou bajtech identifikaci (pole ID), dále následují dva bajty řídících polí a délky jednotlivých sekcí (každá délka je 2 B):

ZOCOUNT - počet vět v sekci zone
PRCOUNT - počet vět v sekci předpokladu
UPCOUNT - počet vět v sekci update
ADCOUNT - počet vět v sekci dodatečné informace

Tab. 11.9 Význam jednotlivých řídících polí

 

Pole	Počet bitů	Hodnota
ID	16	Identifikátor zprávy, je kopírován do odpovědi.
QR	1	0 pokud je zpráva dotazem, 1 pokud je zpráva odpovědí. Ostatní kontrolní bity DNS dotazu Update nepoužívá. Za QR bezrostředně následuje pole Opcode.
Opcode	4	5(UPDATE), kopíruje se z dotazu do odpovědi
Z	7	Rezerva, musí být naplněna binárními nulami
Rcode	4	V odpovědi výsledkový kód, v dotazu nedefinované.

 

Kód chyby	číselná hodnota	popis chyby
NOERROR	0	Bez chyby
FORMERR	1	Chybný formát zprávy, name server ji neumí interpretovat
SERVFAIL	2	Při zpracování zprávy došlo k interní chybě serveru (např. chybě OS nebo vypršel timeout při forwardingu)
NXDOMAIN	3	Jméno, které by mělo existovat, neexistuje
NOTIMP	4	Name server nepodporuje daný typ zprávy (Opcode)
REFUSED	5	Name server odmítá provést zprávu např. z bezpečnostních důvodů
YXDOMAIN	6	Jméno, které by nemělo existovat, existuje.
YXRRSET	7	Sada RR vět, která by neměla existovat, existuje.
NXRRSET	8	Sada RR vět, která by měla existovat, neexistuje.
NOAUTH	9	Server není autoritou pro danou zonu.
NOTZONE	10	Jméno uvedené v sekci předpokladů nebo v sekci update není v dané zoně.

Sekce zóny

Sekce je tvořena třemi částmi:

ZNAME - jméno zony
ZTYPE - musí být retězec SOA
ZCLASS - třída zony - IN (Internet)

Sekce předpokladu

1. V zóně musí existovat minimálně jedna RR věta s daným NAME a TYPE (RR set exists, value independent).

Sekce předpokladu obsahuje jednu větu s daným NAME a TYPE, kterou očekává v zóně. Ostatní položky jsou nevýznamné, proto se použije RDLENGTH=0, RDATA je prázdné, CLASS=ANY, TTL=0.
Např. Požaduji aby v doméně existovala věta typu A s doménovým jménem aaa.firma.cz s libovolným RDATA.
2. V zóně musí existovat sada vět RR daného NAME a TYPE a jejich pravá strana se musí shodovat s pravou stranou vět v UPDATE paketu(RR set exists, value dependent). Na pořadí vět nezálezí.

V sekci je skupina RR vět s daným NAME a TYPE a RDATA, TTL=0, CLASS je určená v zone sekci.
Např. Požaduji, aby v zoně existovaly věty:

mail.firma.cz.  A       195.47.11.11
www.firma.cz.   A       195.47.11.12
firma.cz.       MX   10 mail.firma.cz.

3. V zóně neexistuje žádná RR věta s daným NAME a TYPE (RR set does not exist).

Sekce obsahuje jednu RR větu s daným NAME a TYPE, RDLEGTH=0, RDATA je prázdné, CLASS=NONE, TTL=0.
Např. Požaduji, aby v zoně neexistovala žádná věta typu A s doménovým jménem mail.firma.cz.
4. V zóně musí existovat alespoň jedna věta s daným NAME a typem definovaným v ZONE sekci (Name is in use). V sekci je jedna věta RR s daným NAME, RDLENGTH=0, RDATA je prázdné, CLASS=ANY, TYPE=ANY, TTL=0.

Např. Požaduji, aby v zoně existovala alespoň jedna věta, jejíž doménové jméno obsahuje řetězec firma.cz. Tj. Nejde o prázdnou zonu.
5. V zóně neexistuje žádná RR věta jakéhoko-li typu s daným NAME (Name is not in use).

Sekce obsahuje jednu RR větu s daným NAME, RDLENGTH=0, RDATA je prázdné, CLASS=NONE, TYPE=ANY, TTL=0.
Např. Požaduji, aby v zoně neexistovala žádná věta, jejíž doménové jméno obsahuje řetězec firma.cz. Tj. Jde o prázdnou zonu.

1. Sekce update

1. Přidat věty RR

Sekce update obsahuje několik vět. Do souboru se přidají věty s daným NAME, TYPE, TTL, RDLENGTH a RDATA. CLASS se převezme ze sekce zone. Duplicitní věty v tomto seznamu se ignorují.
Např. Požaduji přidat věty:

firma.cz.       MX      20      mh.firma.cz.
mh.firma.cz.    A               195.47.13.12

2. Zrušit sadu RR vět daného typu.

Sekce obsahuje jednu větu, uvedené NAME aTYPE určuje, které věty mají být zrušeny. TTL=0, CLASS=ANY, RDLENGTH=0, RDATA je prázdné.
Např. Požaduji zrušit všechny věty s doménovým jménem mail.firma.cz.
3. Zrušit všechny RR věty daného jména.

Sekce obsahuje jednu RR větu, dané NAME určuje, které věty mají být zrušeny. TYPE=ANY, TTL=0, CLASS=ANY, RDLENGTH=0, RDATA je prázdné.
Např. Požaduji zrušit všechny věty typu MX s doménovým jménem firma.cz.
4. Zrušit jednu RR větu

Sekce obsahuje větu, která má být zrušena (NAME, TYPE, RDLENGTH, RDATA). TTL=0, CLASS=NONE. Např. požaduji zrušit větu:

firma.cz.       IN      MX  10   mail.firma.cz.

1. Sekce doplňujících informací

DNS notify

Komunikaci o zóně mezi master a slave serverem při použití DNS notify iniciuje master server. Master server posílá v případě změny zony zprávu slave serverům " Požádej mě o zone transfer". Slave server po obdržení zprávy notify může okamžitě požádat o zone transfer.

Zprávu o změně zóny (DNS notify) obdrží všechny servery, které jsou uvedeny v NS větách pro zónu. Není informován server uvedený ve větě SOA, protože se předpokládá, že právě tento server zprávy generuje. Některé implementace umožňují správci master serveru sadu name serverů doplnit další IP adresy dalších name serverů. Tyto další servery se nazývají stealth servery. Množina serverů, pro které se DNS notify generuje se nazývá Notify set.

Obr. 11.17 Notify
 

Zpráva notify používá formát DNS paketu definovaný v RFC 1035. DNS Notify používá pouze podmnožinu polí v paketu, nepoužitá pole musí být vyplněna binárními nulami. Typ zprávy (Opcode) je nastaven na hodnotu 4 (NOTIFY). Master server může jako součást notify zprávy poslat NAME, CLASS, TYPE i RDATA změných vět v zoně. Notify zprávy nevyužívají sekci autoritativních serverů ani sekci doplňkových informací.
 

K přenosu Notify paketu se používá přenosový protokol UDP nebo TCP. Pokud je použit TCP protokol, je zpráva notify vyslána pouze jednou. Na master serveru je nastaven časový interval, po který master server čeká na odpověď. Při použití TCP slave server ani master server nesmí přerušit poskytování služeb během transakce.

Pokud je použit UDP protokol, master server periodicky posílá notify zprávy na slave server. Vysílání notify zpráv master server zastaví po obdržení odpovědi. Pokud master server neobdrží odpověď, pak vysílání těchto zpráv zastaví po vyčerpání nastaveného počtu opakování zpráv nebo poté co ICMP oznámí, že port je nedostupný. Interval mezi vysíláním jednotlivých zpráv může být specifikován jako parametr v konfiguraci master serveru (zpravidla 60 s). Podobně může být nastaven i počet povolených opakování (zpravidla 5).

Jediná událost, která aktivuje vyslání notify zprávy je změna SOA věty. Po obdržení zprávy Notify by se měl slave server chovat stejně jako když zóně uvedené v QNAME vyprší interval uvedený v poli refresh věty SOA. Slave server by tedy měl požádat master server o SOA pro zónu a zkontrolovat pole serial number. Pokud došlo ke zvýšení seriového čísla pak iniciovat AXFR nebo IXFR.

Ve zprávě zone transfer by měl slave dělat z masteru, který poslal na slave server notify zprávu.

V notify otázce může master poslat i změněné RR věty (změněné jméno, třídu, typ a nepovinně i RDATA). V žádném případě však nemohou být tyto informace (změněné RR věty v answer sekci notify otázky) použity pro opravu dat na slave serveru nebo jako indikace toho, že je třeba provést zone transfér nebo změnit refresh time u zony. Jedná se pouze o informaci, ze které může slave server např. zjistit, že má již aktuální data a nepotřebuje iniciovat zone transfer.

Notify odpověď neobsahuje žádné podstatné informace, rozhodující je pouze fakt, že master server notify odpověď obdrží.

Pokud slave obdrží zprávu Notify obsahující QNAME od uzlu, který není master pro zonu, měl by totu zprávu ignorovat a generovat chybovou hlášku do logu.

Při startu by server měl poslat Notify pro každou autoritativní zonu. Při restartu serveru je poslání notify zprávy volitelné.

Každý slave server pravděpodobně obdrží více stejných zpráv Notify. Notify protokol musí tuto multiplicitu podporovat.

Master server se snaží vyhnout velkému množství současných zone trasferů. Může tedy zprávu notify posílat s určitým zpožděním. Toto zpoždění bude vybíráno náhodně, takže každý slave server začne svůj zone transfer v jiném čase. Toto zpoždění nesmí být větší než pole refresh. Zpoždění může být nastavitelné parametrem master zony (30-60s). Slave server, který obdrží notify musí nejprve tuto iniciovanou transakci dokončit a teprve potom posílat další notify zprávy níže.

V Bind 8.1 je mechanismus DNS Notify standardně implementován.

Incrementální zone transfer specifikuje RFC 1995.

Incrementální zone transfer (IXFR) umožňuje přenášet při změně dat v zóně z master serveru na slave server pouze změněná data, tedy pouze část zony. Naproti tomu klasický zone transfer (AXFR) přenáší při sebemenší změně zony celou zonu.

K tomu aby mohl master server poskytovat slave serveru pouze změněné věty, musí udržovat jednotlivé stavy databáze po jednotlivých změnách. Master server tedy musí udržovat nejnovější verzi zóny a rozdíly mezi nejnovější verzí a několika staršími verzemi. Verze souborů se liší sériovým číslem v SOA větě. Pokud slave server zjistí, že potřebuje nová data k zóně a podporuje IXRF, pošle dotaz na master server, kde uvede jakou verzi zony má jako poslední např.: 98052001 (serial). Master server jako odpověď pošle slave serveru pouze změněné věty, tj. věty, které mají být zrušeny a věty nové. Alternativně může server poslat v odpovědi celou zonu. Celou zonu posílá server i tehdy, když má klient tak starou větu SOA, že již server není schopen poslat IXFR.

Po opravě zony v paměti musí slave server uložit změny do souboru, teprve potom může sám poskytovat odpověď na IXFR dotaz. Pokud master server obdrží dotaz s vyšším číslem SOA, než má sám, pak jako odpověď vrací pouze svou aktuální SOA větu.

Pro přenos IXFR dotazů je možné použít TCP i UDP. Pokud klient zašle dotaz UDP měl by server zaslat UDP odpověď. Pokud je odpověď delší než 512 B, pošle server v UDP odpovědi pouze větu SOA a klient musí navázat TCP spojení.

Slave server, který požaduje inkrementální zone transfér bývá označován jako IXFR klient. Master nebo slave server, který poskytuje inkrementální zone transfer bývá označován jako IXFR server.

IXFR používá formát DNS paketu tak, jak je definovaný v RFC 1035.

Jako typ otázky (Opcode) je uvedeno IXFR a sekce autoritativních name serverů obsahuje SOA větu zony uložené na slave serveru.

Jako typ otázky (Opcode) je v odpovědi opět uvedeno IXFR. První a poslední RR v sekci odpovědi je SOA věta zony, která se má aktualizovat.

V IXFR je možné poslat jako odpověď jednu nebo několik změn (poslední nebo několik posledních verzí zony) v rámci jedné zony. Seznam všech změn v rámci jedné verze je v sekci odpovědi uzavřen z obou stran větami SOA.

Za změnu se považuje přidání nebo zrušení RR. Zrušené věty jsou předcházeny starou SOA a přidané věty jsou předcházeny novou SOA RR. Oprava věty je chápána jako zrušení věty původní a přidání věty nové.

Změny jsou v sekci odpovědi uspořádány od nejstarší po nejnovější.

IXFR klient může změnit starou verzi souboru na novou pouze po úspěšném provedení všech obdržených změn.

Inkrementální odpověď se liší od neinkrementální odpovědi tím, že začíná dvěmi SOA větami.

V IXFR není možné vracet v odpovědi celou zónu. Pokud se zjistí, že změn v zóně je příliš a nevyplatí se použít IXFR, pak musí klient vyslat dotaz znovu a požádat o AXFR přenos.

IXFR server nemusí udržovat všechny předcházející verze zón, může staré verze kdykoli zrušit. U velkých a často se měnících zón můžeme narazit na rozpor mezi velikostí obsazeného diskového prostoru a možností dělat IXFR. Informace ze starších verzí souborů mohou být zahozeny v okamžiku, kdy by byl IXFR přenos delší než eventuální AXFR.
 

Negativní caching (DNS NCACHE)

Pod pojmem negativní caching chápeme uložení informací v paměti serveru o tom, že neexistuje v DNS požadovaná RR věta nebo doménové jméno.

Dnes používané resolvery negenerují stejné negativní odpovědi na stejný dotaz. Aby bylo možné negativní odpovědi korektně používat, je třeba přesně definovat obsah negativní odpovědi a dobu, po kterou má být negativní odpověď udržovaná v paměti.

RFC1034 definovalo negativní caching jako nepovinný. Některé implementace BINDu negativní caching podporují. Negativní caching je např. implementován v BINDu 4.9.2. RFC2308 definuje negativní caching jako povinnou vlastnost resolveru a definuje obsah negativní odpovědi.

RFC2308 definuje jako povinné ukládání negativních odpovědí s RCODE nastaveným na NXDOMAIN a NOERROR_NODATA.

Pokud server podporuje ukládání odpovědí jiných typů než NXDOMAIN a NOERROR_NODATA, nesmí tyto odpovědi udržovat v paměti déle než 5 minut. Jako součást ukládání informace musí udržovat i IP adresu serveru z odpovědi.

Všechny RR věty uložené v paměti jsou považovány za platné, pokud mají TTL vetší než 0. TTL je tedy rozhodující položka vzhledem ke paměti. I negativní odpovědi, pokud mají být udržovány v paměti musí mít definováno TTL. Jak však TTL negativní odpovědi určit, když negativní odpověď obvykle neobsahuje žádnou RR větu v sekci odpověď, jak je patrné z příkladu č.1 z kapitoly 11.1.7.

Určení TTL pro negativní odpověď se řeší vložením SOA věty pro zónu do autoritativní sekce odpovědi.
 

Pole MINIMUM ve větě SOA

1. Minimum ttl pro všechny věty RR v zóne. (Nikdy se v praxi takto nepoužívalo.)
2. Implicitní ttl pro všechny věty RR v zóně, které neobsahují ttl pole. (Pouze na primary name serveru). Po provedení zone transferu mají všechny RR věty ttl pole naplněno.
3. ttl negativní odpovědi pro zónu.

Syntaxe příkazu:

$TTL ttl komentář

Všechny RR věty uvedené v souboru za příkazem $TTL, které nemají explicitně uvedeno ttl, přebírají ttl z příkazu $TTL.

Reálné TTL se určuje jako minimum z pole TTL obsaženého v SOA větě a z pole MINIMUM. TTL se u negativních odpovědí v paměti snižuje stejným způsobem jako u kladných odpovědí. Pokud je TTL u negativní odpovědi 0, je informace v paměti neplatná.

Pravidla ukládání negativních odpovědí

• Ukládání negativních odpovědí je povinné. Pokud resolver ukládá odpovědi do paměti, musí ukládat i negativní odpovědi.
• Neautorizované negativní odpovědi nemohou být ukládáný.
• V paměti musí být uložena i věta SOA z autoritativní sekce odpovědi.
• Negativní odpověď bez věty SOA nesmí být ukládána.
• Věta SOA z paměti musí být přidávána do odpovědi.
• Odpověď NXDOMAIN musí být ukládána spolu s QNAME a QCLASS.
• Odpověď NOERROR_NODATA musí být ukládána spolu s QNAME, QTYPE a QCLASS.
• V master souboru musí být vložen příkaz $TTL.

Věta typu SRV

Cílem věty SRV je v databázi DNS udržovat nejen jména počítačů, ale i jména služeb. Již jsme se s takovým případem setkali – větamy MX kde službou byla elekgtronická pošta. Věty MX specifikují poštovní servery na které se má pošta zasílat. Pomocí pripority je vyjádřeno, který poštovní server má být kontaktován jako první a které poštovní servery následně.

Zastavme se u případu www-serveru. V praxi pokud chceme získat nějaké informace o české firmě, tak do prohlížeče napíšeme:

http://www.firma.cz

Věta typu SRV zavádí do DNS informace k nalezení příslušeného web-serveru. V našem případě budeme v  DNS hledat jméno:

http.tcp.www.firma.cz.

Syntaxe věty SRV je (kód v protokolu DNS má pro větu typu SRV hodnotu 33):

Služba.Protokol.doménové_jméno [TTL] IN SRV Priorita Váha Port Počítač.

Kde:

Služba specifikuje symbolické jméno služby (serveru). Např. ldap, http, smtp atd.

Protokol specifikuje protokol, např. tcp či udp.

Priorita určuje prioritu. Firma může provozovat několik www-serverů, aby v případě výpadku byl vždy nějaký server dostupný. Firma bude chtít zavést prioritu, který server se má klient pokoušet kontaktovat jako první a který jako další.

Váha - firma může mít web-server extrémně zatížen, proto zřídí několik paralelně běžících web-serverů o stejné prioritě. Každý bude spštěn na počítači o jiném výkonu. Zavádí se proto váha (váha ve smyslu váženého průměru). V DNS jsou např. dva záznamy:

http.tcp.www.firma.cz. IN SRV 10 1 80 server1.firma.cz.
IN SRV 10 3 88 server2.firma.cz.

Jelikož oba záznamy mají stejnou prioritu (10), tak v případě, že oba servery jsou dostupné může klient náhodně kontaktovat libovolný z nich. Avšak server2.firma.cz je výkonější než server1.firma.cz. Váha proto sděluje, že servery mají být kontaktovány sice náhodně, ale při velkém počtu navazovaných spojení má být 25% spojení navázáno se server1.firma.cz a 75% spojení se server2.firma.cz, tj. server2 je třikrát výkonější než server1.

Váha nula je určena pro administrátory, tj. neprovádí se žádné vyrovnávání výkonu mezi počítači.

Port specifikuje port na kterém server běží.

Počítačspecifikuje jméno počítače (odkaz na větu typu A) na kterém je služba poskytována (na kterém běží server). Pokud je jako počítač uvedena pouze tečka, pak služba není poskytována.
 
 

X.500 a LDAP

Aby nedošlo k nedorozumění, musím v úvodu zdůraznit, že slovo adresář zde není míněno jako adresář souborů, ale v původním významu. Potřebujete-li nějakou představu, pak si představte jako adresář “bílé stánky” telefonního seznamu.

Cílem X.500 je zavést celosvětové “bílé stránky” všech objektů světa. Představme si, že bychom měli bílé stránky všech telefonních seznamů světa. Pokud bychom v nich chtěli něco nalézt, tak bychom si je museli nejprve roztřídit podle zemí, pak podle měst a podle telefonních operátorů. V konkrétním telefonním seznamu bychom pak vyhledávali konkrétní záznam. Záznam se častěji označuje jako relativní jedinečné jméno (Relative Distinguished Name).

Každý záznam adresářové struktury je složen z atributů. Záznam je zpravidla tvořen jedním adributem, ale může být tvořen i více atributy.

Jednotlivé záznamy toří ztromovou strukturu – viz obr. 11.18.

Obr. 11.18 Jedinečné jméno CN= server.firma.cz,O=firma,C=CZ

Jedinečné jméno (Distinguished Name) konkrétního objektu světa je pak posloupnost všech relativních rozlišitelných jmen (Distinguished Name) od kořene adresáře.
 

Rozlišitelná jména

C=CZ
O=firma
CN= server.firma.cz

Každý záznam má tvar:

identifikátor atributu = hodnota

Identifikátory jednotlivých atributů záznamů vznikly zkrácením:

C – Country
O – Organization
CN – Common Name atd.

V počítačové komunikaci se nepoužívají slovní idedntifikáory atributů, ale každý identifikátor je určen svou hodnotou, tj. jednoznačnou řadou číslel. Tyto řady tvoří celosvětově jednoznačnou nomenklatůru identifikátorů objeků, která má opět stromovou strukturu.

Základní normou popisující jednotlivé záznamy (relativní rozlišitelná jména) je norma X.520, která mj. zavádí:
 

Velice důležitý atribut je atribut CN specifikující lokálně jednoznačný název objektu.

Uveďme několik příkladů (mohou být případně doplněny o další atributy SP, L atd.):

Libora Dostálek jako obyvatel Česka:

CN=Libor Dostálek,C=CZ

Libor Dostálek jako zaměstnance PVT, které je v Česku:

CN=Libor Dostálek,O=PVT,C=CZ

Libor Dostálek, zaměstnanec oddělení ET, které je součástí PVT:

CN=Libor Dostálek,OU=ET,O=PVT,C=CZ

Avšak, specifikace PVT jako firmy:

CN=PVT,C=CZ

Server firmy PVT:

CN=server.firma.cz,O=PVT,C=CZ

Firma RSA zavedla v normě PKCS#9 identifikátor atributu pro internetovský e-mail:
 

I když může server specifikovat, tj. v Common Name uvedeme DNS-jméno serveru, tak chybí možnost specifikovat části serveru (např. procesy). RFC-2247 proto zavádí normu na specifikaci atributů pro doménová jména:
 

Před tím, než si uvedeme příklad, tak musíme upozornit na skutečnost, že jeden záznam může obsahovat více atributů.

Příklad:

Relativní jedinečné jméno (záznam) pro doménové jméno server.cbu.firma.cz lze zapsat jako:

DC=server,DC=cbu,DC=firma,DC=CZ
 

LDAP

Protokol LDAP verze 3 je specifikován normami: RFC-2251 až RFC-2255. Pro programátory je navrženo API v RFC-1823.

Obr. 11.19 LDAP-klient pokládá dotaz LDAP-serveru, který odpovídá

Přehled norem týkajících se DNS

• RFC-1032 - Domain administrators guide.
• RFC-1033 - Domain administrators operations guide
• RFC-1034 - Domain names - concepts and facilities.