Jak fungují žolíci v DNS

Konkrétně v červenci letošního roku vyšlo RFC 4592 nazvané The Role of Wildcards in the Domain Name System. Jeho cílem není měnit původní definici, jež pochází z RFC 1034, základního kamene celého DNS. Snaží se pouze doplnit a upřesnit původní dokument.

Výchozí definice je obsažena v kapitolách 4.3.2 a 4.3.3 RFC 1034. Kapitola 4.3.2 popisuje algoritmus, jímž se řídí DNS server při vyřizování dotazu. Dotazované jméno označuje jako QNAME, požadovaný typ dotazu QTYPE. Chování serveru dělí do šesti kroků, jejichž stručný obsah je zhruba následující:

1. Bude se dotaz řešit rekurzivně? Pokud ano, skok na 5.
2. Vyhledat zónu, která je nejbližším předchůdcem QNAME. Pokud neexistuje, skok na 4.
3. Postupně procházet vybranou zónu a porovnávat jmenovky (labely). Proces může skončit jednou ze tří alternativních možností:
4. Nalezena kompletní shoda. Pokud se jedná o CNAME záznam, zařadit jej do odpovědi, změnit QNAME na kanonické jméno ze záznamu a skok zpět na 1. Jinak zkopírovat všechny záznamy s vyhovujícím QTYPE do odpovědi a skok na 6.
5. Nalezena delegace (NS záznam odkazující na server). Zařadit NS záznam do odpovědi, přidat jako doplněk dostupné adresy a skok na 4.
6. Jméno nenalezeno. Vyhledat vhodnou hvězdičkovou jmenovku. Pokud existuje a shoduje se QTYPE, zařadit záznam do odpovědi, ale jeho vlastníka změnit z hvězdičky na QNAME, následuje skok na 6. Neexistuje-li použitelná hvězdičková jmenovka a jedná se o původní QNAME, zařadit do odpovědi chybu a konec (pokud bylo QNAME dříve změněno na základě CNAME, pouze skončit).
7. Prohledat vyrovnávací paměť. Obsahuje-li vhodné záznamy, zkopírovat do odpovědi a skok na 6.
8. Vyhledat odpověď pomocí lokálního řešiče, výsledky uložit do odpovědi.
9. Do doplňků přidat z lokálních dat případné další užitečné záznamy. Konec.

Žolíci se uplatní v kroku 3c – když server nenašel dané jméno, ani jeho delegaci jinam prostřednictvím NS. Pak se snaží vyhledat v zóně vhodného žolíka. V případě úspěchu na jeho základě vygeneruje odpověď tak, že složí dohromady data nesená žolíkem a jméno z dotazu. Odpověď se tedy vrací nikoli v „žolíkové“ podobě, ale přizpůsobená hledanému jménu. Hvězdička je ovšem přípustná i v dotazu, aby bylo možné zjišťovat přítomnost žolíkových jmen v doménách. Nejedná se o obecný dotaz na „cokoli v dané doméně“, ale o dotaz „Existuje tento žolíkový záznam?“

Pokud například zónový soubor pro doménu kdesi.cz bude obsahovat záznamy

        *       MX  10  mail.kdesi.cz
        mail    MX  10  mail.kdesi.cz.
                A  1.2.3.4
        x       A  1.2.3.5
        je.tam  A  1.2.3.6 

a server bude dotázán na MX záznam pro cosi.kdesi.cz, odpoví, že MX pro cosi.kdesi.cz je mail.kdesi.cz (a jako doplněk přiloží jeho A záznam).

Varianty, jimiž může skončit vyhledávání jména v kroku 3, představují navzájem se vylučující alternativy. Nejpodstatnějším důsledkem je, že je-li nalezeno hledané jméno, postupuje se podle varianty a) a žolíkové záznamy se neuplatní. Proto dotaz na MX záznam pro x.kdesi.cz vrátí prázdnou odpověď, protože jméno x.kdesi.cz v zóně existuje (tudíž pro něj nedochází k uplatnění žolíkového záznamu), ale nemá přiřazen MX záznam.

Kapitola 4.3.3 rozebírá podrobněji vlastní žolíky. Zdůrazňuje se v ní, že účinek žolíkového záznamu nepřetéká z jedné zóny do druhé (zejména delegace prostřednictvím NS záznamu ukončí působnost žolíků z dané zóny). To je důsledkem kroků 2 a 3 ve výše popsaném algoritmu: nejprve se vybere nejvhodnější zóna a ta se pak prohledává. Ostatních zón si server nevšímá a nepřebírá z nich žádné údaje.

Druhou podstatnou informací je, že hvězdička je expandována vždy na celou jmenovku (část doménového jména od tečky k tečce), případně i na několik. Nelze však zadávat záznamy pojmenované *xyz či bfl*.

RFC 1034 také zdůrazňuje, že pokud některé jméno existuje, zastaví rozvoj žolíků. Ve výše uvedeném příkladu proto server na dotaz požadující MX pro e.mail.kdesi.cz odpoví, že dotyčné jméno neexistuje, protože existující mail.kdesi.cz nepřipustí rozvoj žolíkového záznamu. Naproti tomu dotazu na MX pro no.cosi.kdesi.cz žolík vyhoví a server odpoví, že MX je mail.kdesi.cz.

Jedním z cílů RFC 4592 bylo postavit tento spíše intuitivní popis na formální základ. Definuje k tomu účelu dva pojmy: nejbližšího obsahujícího a zdroj syntézy. Nejbližší obsahující je uzel ve stromě existujících doménových jmen zkoumané zóny, který má největší počet jmenovek vyhovujících dotazu. Zdroj syntézy je pak žolíkové doménové jméno, které je přímým potomkem nejbližšího obsahujícího (čili *.nejbližší_ob­sahující), pokud existuje.

Neexistuje-li zdroj syntézy, nelze vytvořit odpověď. Z toho důvodu skončí dotaz na e.mail.kdesi.cz neúspěchem, zatímco jména cosi.kdesi.cz a no.cosi.kdesi.cz budou DNS serverem syntetizována.

RFC 4592 také upřesňuje otázku existence uzlu v doménovém stromě: uzel existuje, pokud obsahuje alespoň jeden záznam, nebo má existujícího potomka. Mohou tak vznikat uzly, které dokument označuje jako prázdné neterminály. Samy o sobě neobsahují žádná data (žádný záznam), ale mají potomky, a proto existují. V naší ukázkové doméně je prázdným neterminálem tam.kdesi.cz, pro nějž zóna obsahuje pouze potomka je.tam.kdesi.cz. Prázdný neterminál ovšem existuje, algoritmus vytvářející odpověď proto v jeho případě půjde cestou 3a a neuplatní se žolíkové záznamy. Dotaz na MX pro tam.kdesi.cz tudíž vrátí prázdnou odpověď.

Do bodu 3c je novým dokumentem doplněna instrukce pro případ, kdy nalezený žolíkový záznam je typu CNAME. Pak by se server měl chovat konzistentně s 3a, vložit záznam do odpovědi, nahradit QNAME kanonickým jménem z něj a opakovat algoritmus.

Celá jedna kapitola je věnována speciálním typům záznamů. Nedoporučuje používat žolíky pro záznamy typu NS (tím pádem postrádají smysl pro SOA a DS) a DNAME. Upozorňuje, že nemá smysl snažit se pro záznamy typu SRV o definici univerzálních serverů ve stylu

        _telnet._tcp.*   SRV 0 1 23 x.kdesi.cz. 

Vlastníkem dotyčného záznamu je doménové jméno _telnet._tcp.*­.kdesi.cz, které není žolíkové (hvězdička v něm není nejlevější jmenovkou). Kýžený efekt se proto nedostaví.

Pozitivní je, že žolíci nedělají problémy při zabezpečení pomocí DNSSEC. Záznam RRSIG s podpisem obsahuje údaj o počtu jmenovek doménového jména, na něž se podpis vztahuje. Jeho hodnota umožní při kontrole ignorovat syntetizovaný začátek jména. NSEC záznam se pak přidává, jen pokud se jméno v dotazu přesně shoduje se jménem záznamu.

Praktické důsledky

Prvním nápadem pro použití žolíkových záznamů by mohlo být zavedení určitých implicitních hodnot. Například přesměrování poštovního provozu všech strojů na centrální mail server záznamem

        *                MX  10 mail.kdesi.cz. 

Přesně tohle bohužel nefunguje. Jak vidno z předchozího textu, žolík se vztahuje pouze na neexistující jména, takže o dopravě pošty pro počítače zavedené v DNS neříká tento záznam vůbec nic.

Relativně smysluplné by mohlo být zachytávání požadavků s překlepem ve jméně a jejich přesměrování pomocí CNAME na centrální server:

        *                CNAME server.kdesi.cz. 

Zacházení s žolíky závisí na serveru, čili na konkrétní implementaci. Před jejich použitím si rozhodně ověřte, jak s žolíky zachází nejen program implementující váš primární DNS server, ale i programy používané ostatními autoritativními (sekundárními) servery. Chování serverů se totiž někdy liší od požadavků RFC (příklady najdete ve Wikipedii).

Osobně považuji za docela dobrou strategii se žolíkům vyhýbat širokým obloukem. Náměty na jejich rozumné využití uvítám v diskusi.