DNS servery mezi sebou komunikují pomocí DNS zpráv, které mají vždy standardní formát. Tento formát 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 hodnoty odpovědi zprávy, a informaci o přítomnosti dalších částí. Pokud si vzpomenete na článek o útoku na DNS, se kterým tento rok přišel Dan Kaminsky, tak ono zmiňované transakční ID se také nalézá v hlavičce zprávy. Bohužel hlavička DNS zprávy má fixní formát a velikost, z čehož vyplývá první omezení DNS protokolu, tak jak byl definovaný v RFC1035 – hlavička DNS zprávy může obsahovat pouze omezené množství příznaků. Jak lze toto omezení obejít, se dozvíte ke konci tohoto článku.
V tuto chvíli udělám 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, zda 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 nikdy neměl obsahovat tento příznak. 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 souvisí. Příznak 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) je pak příznak, který 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í, příznak RA nebude nastaven.
Před přechodem k další sekci bych rád představil termín oktet. Nejedná se o skladbu pro osm nástrojů, v počítačové terminologii je oktet označení pro 8 bitů. Zde je důležité si uvědomit, že standardy RFC 1034 a 1035 vznikaly v době, kdy nebylo tak přirozené, že bajt má 8 bitů. Proto je místo slova bajt použit termín oktet.
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. QNAME se skládá s 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 oktetem. 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 oktetů (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 oktetů včetně jejich oktetů 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. Formát RR záznamu jsme si již představili v minulém článku. RR záznam obsahuje:
| Název | Popis |
|---|---|
| Vlastník (Owner Name) | Doménové jméno vlastníka RR záznamu |
| Typ (Type) | Typ RR záznamu (2 oktety) |
| Třída (Class) | Třída RR záznamu (2 oktety) |
| TTL | Délka platnosti záznamu (4 oktety) |
| Délka sekce RDATA (RDLENGTH) | Délka sekce RDATA (2 oktety) |
| RDATA | Data RR záznamu |
Rozdíl je tedy 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ým číslem.
Pro úsporu místa v DNS zprávě byl vymyšlen mechanismus 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, zda server posílá přímo odpověď (sekce Odpověď), posílá-li informaci o delegaci na jiné servery (sekce Autorita) nebo posílá-li např. IP adresy DNS serverů, tzv. GLUE záznamy (sekce 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.
Na závěr jsem vám slíbil 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 (pořád se pohybujeme v roce 1987). Dnes je toto omezení spíše historické. Velká část systémů má v sobě toto omezení „zadrátováno“ a změnit toto omezení 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 příští rok oslaví deset 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 zprávě končí a příště si už konečně povíme něco technologii DNSSEC.
Autor je technickým ředitelem sdružení CZ.NIC.
