Security World

Čtěte také: DNSSEC: Začínáme od píky (1)

 

Formát DNS zpráv

Nyní se ponoříme ještě hlouběji do protokolu DNS a podíváme se, jak vypadá samotný DNS protokol. DNS servery mezi sebou komunikují pomocí DNS zpráv, které mají vždy standardní formát. Ten je v nejvyšší úrovni rozdělen na pět základních sekcí:

 

Název sekce	Popis
Hlavička (Header)	Hlavička DNS zprávy
Dotaz (Question)	Dotaz pro DNS server
Odpověď (Answer)	Odpověď DNS serveru
Autorita (Autority)	Sekce ukazující na autoritativní servery
Další (Additional)	Sekce obsahující další záznamy

 

Hlavička je v DNS zprávě vždy přítomna a obsahuje informace o příznacích zprávy, návratovou hodnotu odpovědi zprávy, informaci o přítomnosti dalších částí a identifikátor transakce. Bohužel hlavička DNS zprávy má fixní formát a velikost, z čehož vyplývá první omezení DNS protokolu, tak jak byl definován v RFC1035 – hlavička DNS zprávy může obsahovat pouze omezené množství příznaků. Toto omezení lze naštěstí obejít, na což se podíváme na závěr tohoto článku.

V tuto chvíli uděláme malou odbočku k příznakům, které jsou definovány v hlavičce DNS zprávy. Jsou to QR, AA, TC, RD a RA. QR (QueRy) je příznak, který určuje, zdali je zpráva dotaz nebo odpověď. AA (Authoritative Answer) je příznak, který vrací autoritativní servery u odpovědí na dotazy, které vedly do zón, které obsluhují. Dotaz, který položíte rekurzivnímu serveru, by jej nikdy neměl obsahovat.

TC (TrunCation) je příznak, který označuje, že DNS zpráva byla zkrácena a dotazující se má zeptat znovu přes TCP protokol. RD a RA jsou dva příznaky, které spolu souviejsí. RD (Recursion Desired) posílá klient (například stub resolver), který se ptá rekurzivního serveru a vyžaduje od něj, aby provedl rekurzivní doptávání na jeho dotaz.

RA (Recursion Available) posílá zpátky dotazovaný server, aby dal najevo, že je ochotný toto rekurzivní doptávání provést. Pokud se zeptáte serveru, který je pouze autoritativní, tak příznak RA nebude nastaven.

 

QNAME, QTYPE a QCLASS

Další sekcí DNS zprávy je dotaz. Dotaz zprávy obsahuje tři části – QNAME, QTYPE a QCLASS. QNAME (z Query Name) obsahuje doménové jméno, na které se dotazujeme, a skládá se z jednotlivých labelů (label je vždy část mezi dvěma tečkami), resp. samotný label předchází jeho délka reprezentovaná jedním bajtem.

Pro samotnou délku je využíváno pouze nižších 6 bitů, a z toho vyplývá, že maximální délka jednoho labelu je 63 bajtů (tj. samé jedničky na nižších 6 bitech). Celý QNAME je ukončen speciálním označením pro kořenovou zónu – labelem o délce 0.

Maximální délka sekce je 255 bajtů včetně jejich bajtů s délkami labelů a včetně labelu pro kořenovou zónu. QTYPE a QCLASS odpovídají Typu a Třídě RR záznamu, nicméně jsou lehce rozšířeny o některé další hodnoty, např. 255 znamená: vrať mi libovolný DNS záznam (tzv. dotaz ANY).

Další tři sekce obsahují vždy pouze RR záznamy. Rozdíl mezi sekcí dotazu a ostatními je jen v zápisu – doménové jméno vlastníka záznamu je rozloženo na jednotlivé labely, tak jak to bylo rozebráno v sekci Dotaz pro QNAME a samotná data záznamu v DNS zprávě předchází jejich délka vyjádřená 16bitový číslem.

Pro úsporu místa v DNS zprávě byl vymyšlen mechanizmus komprese doménových jmen. Pokud délka labelu na horních dvou bitech obsahuje jedničky, pak dolních šest bitů neobsahuje délku, ale ukazatel na předchozí výskyt doménového jména. Protože je doménové jméno rozkouskováno na jednotlivé oktety, může jeho zápis v DNS zprávě začínat jedním nebo několika labely (např. „www“) a končit ukazatelem na předchozí výskyt (např. „dnssec.cz“).

DNS odpověď bude vždy obsahovat alespoň jeden RR záznam nebo v hlavičce DNS zprávy v sekci návratového kódu bude obsahovat důvod, proč nemohl být dotaz vyřízen. Mezi nejčastější důvody je neexistence doménového jména (NXDOMAIN), odmítnutí dotazu (REFUSED) nebo chyba na straně serveru (SERVFAIL).

Jednotlivé sekce budou naplněny podle toho, zdali server posílá přímo odpověď (sekce Odpověď), posílá-li informaci o delegaci na jiné servery (viz Autorita) nebo posílá-li např. IP adresy DNS serverů, tzv. GLUE záznamy (viz Další). DNSSEC následně tyto sekce využívá také pro informace o vlastních RR záznamech, ale k tomu se dostaneme v další sekci našeho seriálu.

 

Některá omezení

Na závěr si ještě rychle řekneme něco o omezeních DNS protokolu. RFC 1035 jich definuje hned několik a některá jsme zmínili už v průběhu článku, jsou to:

 

• maximální délka labelu je 63 oktetů
• maximální délka doménového jména je 255 oktetů
• TTL je 32bitové číslo
• pro zachování interoperability byl label striktně omezen na alfanumerické znaky a pomlčku
• maximální velikost UDP paketu je 512 oktetů
• počet použitelných příznaků v hlavičce DNS zprávy je omezený

 

Maximální velikosti labelu, doménového jména a TTL zůstaly zachovány do dnešních dní. TTL změnit asi už nepůjde a ani se nezdá, že by existovala potřeba toto pole zvětšit. Maximální délka labelu již také nejspíš zvětšit nepůjde. Nejméně problematická je maximální délka doménového jména.

Toto omezení nevychází ze struktury DNS zprávy, ale bylo definováno, aby lidé, kteří implementují DNS protokol, měli jednodušší práci (bavíme se o roce 1987). Dnes je toto omezení spíše historické. Velká část systémů má v sobě toto omezení „zadrátováno“ a změnit je by byl úkol téměř nadlidský.

Omezení znaků v labelu již dávno neplatí. Plně osmibitové znaky do něj sice stále vkládat nelze, ale např. SRV záznamy používané pro směrování různých služeb obsahují podtržítko na začátku záznamu a nikdo se nad tím nepozastavuje. Čistě teoreticky lze do DNS stromu ukládat libovolná binární data, protože návrh byl hodně obecný, nicméně prakticky to moc nebude fungovat.

Poslední dvě omezení – maximální velikost DNS zprávy posílané přes UDP a počet příznaků v hlavičce – byly vyřešeny ve standardu pojmenovaném Extension Mechanisms for DNS, zkráceně také EDNS0, který je popsán v RFC2671. Toto RFC definuje speciální typ RR záznamu pojmenovaný OPT, který se „schovává“ v sekci Další a přetěžuje jednotlivé pole RR záznamu takto:

Název pole	Popis
Vlastník	Vždy kořenová zóna
Typ	OPT
Třída	Maximální akceptovaná velikost UDP paketu
TTL	Rozšířený návratový kód a verze EDNS
RDATA	Rozšířené příznaky

 

Standard EDNS0 vznikl v roce 1999 a letos oslaví již dvanáct let. I proto je vcelku pozoruhodné, že více než 30 % DNS serverů, které se ptají autoritativních serverů pro doménu .cz, nepoužívá EDNS0. Z hlediska technologie DNSSEC je podpora EDNS0 nutná pro samotné fungování DNSSEC, protože jsou využívány rozšířené příznaky i větší velikost DNS zpráv.

Dnešní část seriálu věnovaná DNS správě končí – příště se už detailně zaměříme na technologii DNSSEC.

 

Autor je vedoucím Laboratoří CZ.NIC, výzkumného a vývojového centra správce české národní domény.

 

***Vložák 1:

Slovníček pojmů

Autoritativní DNS – DNS server, který zná informace o konkrétní zóně,tedy je pro ni autoritativní.
GLUE záznam – informace o IP adrese, která se posílá navíc v odpovědích, kdy je delegace zóny směrovaná do nameserverů uvnitř zóny.
Rekurzivní DNS – Resolver – DNS server, který umí rekurzivně procházet DNS strom a odpovídat na dotazy klientů.
RR záznam (Resource Record)– jednotlivá položka v DNS, obsahuje vlastníka, TTL, typ, třídu a data záznamu.
TTL (Time To Live) – údaj označující dobu platnosti, po kterou si může rDNS držet RR záznam ve vyrovnávací paměti.
Zóna – část DNS stromu, která je delegovaná na samostatné DNS servery.

autor Ondřej Surý