Principy fungování DNS: reverzní dotazy aneb hledá se jméno pro adresu

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.

Převod IP na jméno

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.

Různá délka prefixu

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 s názvem 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).

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ív kou 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ělicí 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.00/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.

Reverzní záznamy pro IPv6

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

Poté 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.

Nezaručená konzistence

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. V odpovědi se dozví třeba:

pc33    A    147.230.11.12
        A    147.230.33.44

Pak 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.

Kniha Domain Name System

Text, který jste právě dočetli, je součástí knihy „Domain Name System: Principy fungování DNS a praktické otázky spojené s jeho používáním“ autorů Pavla Satrapy a Ondřeje Filipa, která vyšla v Edici CZ.NIC.