DNS RPZ: mocný firewall nejen pro blokování hazardu

Technologie Response Policy Zones, zvaná také DNS firewall, umožňuje ovlivnit lokálně obsah dat, které vrací rekurzivní DNS servery klientům. Navrhl ji Paul Vixie, mimo jiné člen Síně slávy Internetu, který její existenci zdůvodňuje nepříjemným konstatováním, že většina nových doménových jmen je zlomyslná. Tedy, že celý systém DNS funguje příliš dobře. Až tak dobře, že se podvodníkům vyplácí registrovat stále nová a nová doménová jména pouze za účelem šíření nevyžádané pošty, malwaru, nebo třeba pro vzájemnou komunikaci uzlů botnetů, na které se pak celosvětová DNS infrastruktura nechtěně podílí.

Princip DNS blacklistů

Základní myšlenka vychází ze známé technologie DNS blacklistů, kdy se systém DNS používá poněkud nestandardně pro hodnocení důvěryhodnosti dané IP adresy, například při přijímání elektronické pošty. V takovém případě se posuzovaná adresa převede na doménové jméno podobně jako při reverzních DNS dotazech a za toto doménové jméno se připojí přípona daného blacklistu. Pokud hledané jméno neexistuje, není daná adresa na blacklistu. Pokud na něm adresa je, je vrácen nějaký dohodnutý nesmysl, typicky IPv4 adresa z rozsahu  127.0.0.0/8.

Čtěte: Za výpadek známého blacklistu mohla unesená doména

Zóna RPZ funguje podobně. Pokud není nalezena shoda zpracovávaného DNS dotazu s jejím obsahem, funguje DNS jako doposud. Při nalezení shody DNS server výslednou doménu změní dle dat příslušného záznamu, přičemž zde, podobně jako u blacklistů, dochází k drobné změně významu některých záznamů.

Zóna také musí být vždy lokálně dostupná DNS serveru, který podle ní pracuje. Je to důležité jednak vzhledem k výkonnosti (každá DNS transakce vyžaduje několik prohledání RPZ), jednak z důvodu ochrany soukromí.

Příklad zóny

    $ORIGIN RPZ.EXAMPLE.ORG.
    @       IN SOA ns.example.org admin.example org 1 1h 15m 30d 2h
            IN NS localhost.

    1.example.com   IN CNAME . ; return NXDOMAIN
    *.1.example.com IN CNAME . ; return NXDOMAIN

    2.example.com   IN CNAME *. ; return NODATA

    3.example.com   IN CNAME rpz-drop. ; drop the query

    4.example.com   IN CNAME catchall.example.org. ;redirect

    5.example.com   IN CNAME *.catchall.example.org. ;wildcard CNAME 

V uvedeném příkladu jsou vidět různé akce, které RPZ umí. Tou výchozí je přitom zablokování doménového jména návratovým kódem NXDOMAIN, které se provede jednoduše nastavení doménového jména jako aliasu ke kořenové zóně. Zde je nutno poznamenat, že tento návratový kód implikuje neexistenci jakýchkoli subdomén, takže by měl být používán pouze tam, kde je žádoucí blokovat i subdomény; jejich zablokování se provede použitím žolíkového záznamu  *.1.example.com.

Je-li třeba zablokovat pouze konkrétní doménové jméno, bez vlivu na subdomény, je třeba použít prázdnou odpověď s návratovým kódem NOERROR. Tomuto stavu se přezdívá NODATA a je možné ho dosáhnout aliasem na *., což je nesmyslná doména nejvyšší úrovně. Další možné akce shrnuje následující tabulka:

Jakákoli jiná data v RPZ zóně jednoduše přepíší data z původní DNS odpovědi. Můžeme tedy například přidat CNAME alias na vlastní webový server, který bude například poskytovat uživatelsky přátelskou informaci o blokování.

Speciálním případem je takzvaný wildcard CNAME, kdy alias vede na doménové jméno, které začíná hvězdičkou. V takovém případě je při zpracování RPZ za hvězdičku dosazeno původní dotazované doménové jméno, například takto:

blokovane.internetovehazardnihry.cz. 5 IN CNAME blokovane.internetovehazardnihry.cz.poker.cesnet.cz.
blokovane.internetovehazardnihry.cz.poker.cesnet.cz. 600 IN CNAME poker.cesnet.cz. 

To umožňuje na straně autoritativního DNS serveru evidovat, která doménová jména byla na daný cíl přesměrována. Informace však stále zůstane pouze v DNS, její přenos třeba do webového serveru (za účelem personalizace informační stránky) je téměř nemožný.

Spouštěcí mechanizmy

V předchozí ukázce jsme použili nejběžnější způsob spouštění RPZ akce – dotazovaným doménovým jménem. Za povšimnutí stojí, že doménové jméno na levé straně je uvedeno bez tečky na konci a jeho plná forma tedy vypadá například 1.example.com.RPZ.EXAMPLE.ORG. (na velikosti písmen nezáleží). To je nutné, neboť zónový soubor smí obsahovat jen doménová jména, která leží uvnitř dané zóny.

Kromě dotazovaného jména je možné akci RPZ spouštět i prostřednictvím IP adresy klienta, cílové IP adresy daného dotazu, nebo jména/IP adresy autoritativního serveru. Všechny možnosti shrnuje následující tabulka:

Vztah s DNSSEC

Je jasné, že technologie DNSSEC, jejímž cílem je kryptograficky zabezpečit DNS záznamy před změnami, změny způsobené RPZ odhalí. Pro správnou funkci je tedy třeba RPZ aplikovat až po validaci DNSSEC dat. Standardní chování DNS serveru BIND, který je zároveň referenční implementací RPZ technologie, k problému přistupuje tak, že RPZ zásahy provádí pouze v případě, kdy změny nemůže klient detekovat, buď proto, že dotazované doménové jméno je nepodepsané, nebo proto, že klient ve svém dotazu nepožádal o DNSSEC data (prostřednictvím příznaku DO). V případě, kdy by uplatnění RPZ poškodilo vyžádané podpisy, jsou ve výchozím nastavení data předána v nezměněné podobě. Toto chování se dá změnit použitím volby break-dnssec yes; dokumentace však varuje před možným přetížením serveru, budou-li validující klienti opakovat dotazy ve snaze dobrat se správné odpovědi. Také se dá očekávat, že validující klient bude mít k dispozici i nějaké náhradní řešení k dohledání pravdivé odpovědi, například DNS-over-TLS tunel, nebo třeba Google Public DNS over HTTPS.

Problematické je také zabezpečení přenosu RPZ mezi servery. Použití DNSSEC nedává žádný smysl, protože zóna se nikdy nepoužívá v dotazovacím režimu a při zónovém přenosu se DNSSEC nevaliduje. Je možné použít TSIG pro zabezpečení přenosu zón elektronickým podpisem, ale vzhledem k použití sdíleného tajemství takový způsob nelze použít pro autentizaci veřejné služby.

Podpora v DNS serverech

Vzhledem k tomu, že technologie RPZ v sobě kombinuje vlastnosti rekurzivních i autoritativních serverů, funguje nejlépe právě v serveru BIND, který také kombinuje obě funkce v rámci jednoho procesu. Podpora je také v PowerDNS rekurzoru. V Knot DNS resolveru je podpora velmi omezená, chybí například přesměrování pomocí CNAME nebo zónový přenos. V čistě rekurzivním serveru Unbound podpora chybí zcela, existuje pouze proprietární modul.

Elegantní technologie s nedostatkem zdrojů

Je zřejmé, že technologie RPZ dokáže mnohem víc, než jen blokovat nepovolené hazardní hry. Přestože existuje už od roku 2009, její standardizace v rámci IETF stále probíhá. Chybí však v podstatě jakékoli otevřené zdroje, které by bylo možné použít k zablokování prokazatelně škodlivých doménových jmen, případně jako nejjednodušší možnou rodičovskou kontrolu. Také podpora v alternativních resolverech by jistě mohla být lepší. Možná jde o další variaci na známý problém slepice a vejce.