Mít anycast DNS server je dobrá věc. A co je to vlastně ten anycast? Je to velmi jednoduchý způsob, jak mít více serverů se stejnou IP adresou. IP paket je směrovacím protokolem BGP poslát do nejbližší (myšleno síťově nejbližší, nikoli geograficky) lokality, kde server odpoví např. na DNS dotaz a pošle původnímu tazateli odpověď. Protože se směrovací informace můžou poměrně dynamicky měnit, je dobré používat anycast pouze pro protokoly, které fungují v krátkém časovém okně. Což DNS, které hlavně používá protokol UDP a komunikace probíhá v jednom paketu s dotazem do DNS a druhém s odpovědí, splňuje.
Anycast DNS servery mají několik výhod. Jednak se dá elegantně a jednoduše rozkládat zátěž, protože DNS klienti jsou rozloženi mezi více serverů, a jednak poskytují ochranu pro DoS útokům. V případě útoku na DNS server je většinou z provozu vyřazený jen jeden ze serverů a ostatní servery stále vyřizují požadavky klientů, kteří jsou v jiných sítích. Technicky pro provoz anycast DNS serverů potřebujete číslo autonomního systému a dedikovaný rozsah IP čísel (nejlepé IPv4 i IPv6).
CZ.NIC momentálně provozuje jeden anycast DNS server – d.ns.nic.cz. Jednotlivé servery jsou umístěny v Praze, Frankfurtu a San Francisku a obsluhují požadavky přes IPv4 i IPv6. Možná se zeptáte, proč CZ.NIC nemá více anycast DNS serverů, když je to tak dobrá věc. Bohužel v současné době to není možné, protože pravidla organizace RIPE, která má na starosti přidělování bloků IP adres, toto neumožňují. Přidělování IP adres je v současné době definováno v dokumentech ripe-424 pro IPv4 a ripe-421 pro IPv6. Oba dva dokumenty obsahují speciální klauzuli, která umožňuje operátorům ccTLD DNS serverů, získat přesně jeden adresní rozsah /24 v IPv4 a jeden adresní rozsah /48 v IPv6.
Protože se dlouhodobě snažíme zajistit, co nejlepší služby našim uživatelům, zahájili jsme proceduru na změnu těchto dokumentů. Prosazujeme změnu obou dokumentů tak, aby nelimitoval počet rozsahů, které může operátor TLD DNS serverů získat. Zároveň tak dojde k sladění těchto pravidel mezi ostatními regiony – ARIN, APNIC, LACNIC i AfriNIC umožňují získat více rozsahů pro přesně definované subjekty. A např. společnost Afilias, která provozuje např. doménu .org a další menší, získala od ARINu 6 /24 rozsahů v IPv4 a 6 /48 rozsahů v IPv6 pro každou doménu, kterou provozuje. Pokud se obáváte, že by toto mohlo urychlit vyčerpání IPv4 adres, tak je to obava zbytečná. Počet přidělených IPv4 adres je mnohem menší, než jaký rozsah dostává standardně nový LIR (ISP, poskytovatel obsahu, atp.), a počet subjektů, který může o tento speciální rozsah požádat je pevně definovaný.
Proces změny pravidel je zdlouhavý, ale doufám, že do příští konference RIPE, která proběhne v první polovině příštího roku, dojde internetová komunita ke shodě, jak přesně pravidla změnit, a bude možné požádat o další rozsahy určené pro anycast DNS servery. Již v tuto chvíli máme podporu dalších velkých ccTLD – .fr a .de, a pravděpodobně se další přidají, takže nepředpokládám, že by při prosazování změny, mělo dojít k velkým problémům. Navíc CZ.NIC už jednu změnu v pravidlech RIPE úspěšně prosadil, takže zatím máme 100% úspěšnost při prosazovaní změn ;), a doufejme, že to tak zůstane i nadále.
Ondřej Surý
28 dní poté
Neděste se, nepůjde o žádnou hrůzu jako ve stejnojmenném filmu, ale o malou statistiku po měsíci plného provozu DNSSEC pro domény .cz a 0.2.4.e164.arpa (ENUM). Tedy:
- celkově registr obsahuje 245 domén chráněných pomocí DNSSEC (239 .cz a 6 ENUM)
- domény jsou rozděleny mezi 93 různých držitelů
- podíly registrátorů na trhu DNSSEC jsou Active 24 84 %, INTERNET CZ 5 %, General Registry 2 % a Media4web a Ignum po 0,5 % (zbytek do sta procent jsou domény CZ.NIC).
Bez mála 250 domén je celkem úspěch, i když je to spíše pocitová záležitost, není totiž moc s čím porovnávat…
PT
Kéž by byl DNSSEC všude
Jak si povídám s mnoha lidmi o technologii DNSSEC, setkal jsem se s názorem, že trochu přeháníme, že možnost napadnout DNS server je pouze teoretická a že se vlastně nic neděje. Proto bych rád uvedl jednu poměrně dobře popsanou kauzu, na kterou před časem upozornil Websense. DNS servery jednoho ISP v Číně byly napadeny právě cache poisoningem. A nebyl to ISP nijak malý, mluvíme o China Netcom (CNC) s 20 milióny broadband uživatelů a se 110 miliony dialupisty! Nešlo o zcela klasický útok proti konkrétní stránce. Totiž v případě, že zákazník CNC napíše špatnou adresu, je přesměrován na reklamní stránku CNC. Ta slouží k vylepšení příjmů CNC a je jistě celkem hojně navštěvována. Nicméně v důsledku útoku byli zákazníci přesměrováni na stránky útočníka, které se snažily zneužít chyby v prohlížeči a pluginech a zavirovat počítače zákazníků.
Je evidentní, že CNC díky počtu uživatelů útočníky láká, ale je jen otázkou času, kdy přijdou útoky i proti menším sítím (tedy jestli už nepřišly). Získat na Internetu program, který na DNS útočí je otázka pár minut…
Ondřej Filip
Spamující UnifiedRoot
Alternativní root servery provází internet už nějakou řádku let. Současný seznam TLD domén (to jsou domény .com, .cz, .eu a další) je udržován organizací ICANN. Každá změnu v tomto seznamu provází vcelku složitý schvalovací proces. Za provozem alternativních root serverů stojí snaha přivést na svět nové TLD domény, které nebudou muset projít tímto složitým schvalovacím procesem. Motivace může být různá – od snahy vylepšit internet po snahu vylepšit stav svého bankovního konta. Pamatuji, že i v Čechách existovalo pár alternativních TLD domén (už si bohužel nevzpomenu, kdo to tenkrát provozoval). Každopádně celý systém alternativních root serverů je založený na tom, že se místo klasických root serverů ptáte alternativních, které mohou (ale nemusí) obsahovat další domény. Aby systém fungoval je zapotřebí změnit ve vlastním počítači rekurzivní DNS servery, které používáte (a které jste například dostali od svého správce sítě), na rekurzivní DNS servery s podporou alternativních root serverů. Případně použít speciální program, který toto nastavení provede za vás. V každém případě je to netriviální operace a v některých sítích (např. firemních) taková změna nemusí být vítána, ba naopak bude spíše zakázána a je vcelku možné, že poté, co provedete změnu nastavení, vám přestane fungovat internet nebo vám za pár minut bude stát za zády funící síťový správce, kterého jste tímto donutili vyběhnout schody z kumbálu ve sklepě.
Proč o tom vlastně píšu? Dneska mi spadnul do schránky klasický spam (a pak druhý, to když od písmenka ‚a‘ došli k písmenku ‚t‘) od společnosti UnifiedRoot (link sem dávat nebudu, ať jim nezvedám PageRank ;)), kde se vychvalují, jak posílili svou infrastrukturu alternativních root serverů, která teď už funguje na IPv6. UnifiedRoot patří k těm společnostem, které za provozem alternativních root serverů vidí peníze. Nabízejí registraci vlastních TLD domén za variabilní poplatek (dle atraktivity jména). Co už v e-mailu zapomínají dodat je, že celá tahle sranda nebude fungovat, pokud si uživatel nenastaví ručně jejich root servery nebo nepoužije speciální software. A proč by to ostatně uživatelé dělali?
Takže máte možnost si koupit něco, co bude fungovat jenom vám a pár dalším jednotlivcům, které UnifiedRoot přesvědčí, že jim vlastně neprodává teplou vodu. Jsem si jistý, že zaspamování velkého množství lidí, kteří mají s doménama něco společného (ať už je to CZ.NIC nebo Paul Vixie (primární autor Bindu), který si na tenhle spam v konferenci taky stěžoval), jim na popularitě moc nepřidá.
Nicméně si představuju docela vtipný telefonický hovor:
Franta: „Hele, mrkni na moje nové webovky…“
Pepa: „A kde je máš?“
Franta: „Na www.franta.novak.“
Pepa: „Mě to nefunguje…“
Franta: „No to si musíš změnit root servery“
:-)
A co si myslíte o alternativních root serverech vy?
Ondřej Surý
DNSCurve – alternativní návrh k DNSSECu
Enfant terrible DNS scény opět zasahuje. Daniel J. Bernstein přichází z vlastním návrhem řešení kryptografické autentizace DNS záznamů. Tento návrh si můžete v originále přečíst na stránkách projektu DNSCurve.
Ve stručnosti se jeho návrh dá shrnout do několika bodů:
- Všechny NS záznamy budou speciálně pojmenované
- Speciální pojmenování bude obsahovat šifrovací klíč
- Rekurzivní DNS bude komunikovat s autoritativním pomocí tohoto šifrovacího klíče
- Šifrovaná komunikace bude obalená a schovaná do TXT RDATA
Návrh obsahuje pár zajímavých myšlenek (použítí Elliptic Curve Kryptografie), v zásadě ale vidím několik nedostatků tohoto návrhu:
- Informace o tom, že se má začít šifrovat k rekurzivnímu DNS, jde nešifrovaně. Návrh neobsahuje Pevné body důvěry (Trust Anchors).
- V případě, že bychom DNSCurve použili i na root servery a všichni začali DNSCurve používat, tak by došlo k paradoxní situaci, kdy by veškeré DNS pakety chodily obalené do DNS TXT. Což mi lehce připomíná IP over DNS protokol.
- Bernstein píše o tom, jak je Elliptic Curve algoritmus milionkrát složitější na rozlousknutí a zjevně z tohoto důvodu nedefinuje mechanismy, jak měnit klíče. Bude to však pravda i za dalších několik let?
- Nevím jestli název nameserveru uz51gmc1jjicekrm676rorncvjpale915vhd94bj2fddj1be1ntbg5.nic.cz bude patřit mezi něco, co je srozumitelné pro pouhého smrtelníka a zda administrátoři budou s nadšením hledat problémy, když se něco pokazí.
Můj názor je takový, že vzhledem k výše uvedeným faktům a kontroverznosti autora návrhu, který naštval snad úplně všechny, se návrh nikterak nerozšíří. Příjemnou věcí je ovšem to, že DNSCurve nikterak nekoliduje s DNSSECem a administrátor serveru bude mít na výběr.
Ondřej Surý
Aktualizace:
Z diskuze na namedroppers a dnsop se objevilo pár dalších problémů.
- Zdá se, že Elliptic Curve algoritmy jsou problémové z hlediska amerických patentů.
- Protože DNSCurve šifruje, tak je velmi pravděpodobné, že se na něj budou vztahovat americká exportní omezení.
DNSSEC v .gov
Kancelář pro plánování a rozpočet Bílého domu vydala nařízení, podle kterého musí správce domény .gov do ledna roku 2009 nasadit technologii DNSSEC a dále připravit plány na nasazení DNSSECu pro všechny systémy, kterých se týká doménový prostor pod TLD doménou .gov. Originální článek vyšel například zde.
Na tomto faktu by nebylo v zásadě nic tak zajímavého, kdyby:
a) se nejednalo o vládní doménu – administrativa Spojených Států se zajímá o ochranu DNS prostoru
b) nebylo nasazení povinné – zatímco všechny ostatní TLD domény, k nimž se brzy připojí i naše česká doména .cz, fungují na principu dobrovolnosti; všechny poddomény v doméně .gov budou muset implementovat DNSSEC povinně.
V každém případě bude zajímavé sledovat, jak se jim nasazení zdaří, za jak dlouho budou schopni začít podepisovat všechny poddomény a kdy budou mít nasazeny rekurzivní DNS, které si rozumí s DNSSECem.
Ondřej Surý
DNS útok podle Kaminského
Útoky typu DNS Cache Poisoning fungují na principu podvržení odpovědi DNS serveru. DNS server, který se ptá na určité doménové jméno, pak dostane falešné informace např. o IP adrese webového serveru. Způsob, jak podvrhnout DNS odpověď, spoléhá na několik vlastností DNS protokolu:
1. DNS dotazy a odpovědi v sobě mají uloženo 2-bytové Transaction ID, tedy počet kombinací je přibližně 65 tisíc.
2. Nezáplatované DNS servery používají pro všechny dotazy stejný zdrojový port.
3. Většina DNS dotazů a odpovědí používá UDP. UDP je bezstavové a v současných sítích je relativně jednoduché podvrhnout zdrojovou IP adresu.
Útočník musí uhodnout správné Transaction ID (nebo vygenerovat všechny možné kombinace) a poslat je ve velmi rychlém sledu za sebou s podvrženou zdrojovou adresou na adresu DNS serveru, na který útočí. Odpověď od útočníka musí přijít v časovém okně na jedné straně vymezeným DNS dotazem a na druhé straně DNS odpovědí od legitimního autoritativního DNS serveru.
Typický útok tohoto typu musel „čekat“ na chvíli, kdy dotazující server nemá záznam uložený ve vyrovnávací paměti server a musí se zeptat autoritativního serveru. Takový záznam je pak uložen po dobu uvedenou v TTL záznamu ve vyrovnávací paměti serveru a útočník musí čekat než tato doba vyprší. Časové okno, kdy lze zaútočit na DNS serveru, tohoto útoku je tak díky TTL velmi malé a se vzrůstajícím TTL se pravděpodobnost takového útoku snižuje. Šance podvrhnout správné Transaction ID je 1 ku 65 tisícům a i v případě, že se útočník vygeneruje DNS odpovědi se všemi Transaction ID, tak je vzhledem k faktu, že lze útočit pouze ve chvíli, kdy záznam není ve vyrovnávací paměti server, šance na úspěch takového útoku malá.
Podvržená odpověď bude vypadat nějak takto (Transaction ID je vyznačeno tučně):
; <<>> DiG 9.4.2-P1 <<>> www.dnssec.cz
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47457
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2;; QUESTION SECTION:
;www.dnssec.cz. IN A;; ANSWER SECTION:
www.dnssec.cz. 86400 IN A 192.168.1.1;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug 8 14:17:41 2008
;; MSG SIZE rcvd: 139
Dan Kaminsky odhalil způsob jak obejít data uložena ve vyrovnávací paměti a falešnou IP adresu podvrhnout v libovolnou chvíli bez ohledu na TTL. Útočník se při útoku neptá přímo na IP adresu webového serveru, ale na libovolný náhodně zvolený neexistující záznam a IP adresu webového serveru podvrhne pomocí sekce AUTHORITATIVE a ADDITIONAL pomocí mechanismu tzv. GLUE záznamu.
Příklad:
Útočník se zeptá DNS serveru, na který útočí, na 007.dnssec.cz
a podvrhne odpověď: Odpověď 007.dnssec.cz neznám, ale zná ho
server www.dnssec.cz s IP adresou 192.168.1.1.
; <<>> DiG 9.4.2-P1 <<>> 007.dnssec.cz
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55309
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 11;; QUESTION SECTION:
;007.dnssec.cz. IN A;; AUTHORITY SECTION:
dnssec.cz. 86400 IN NS www.dnssec.cz.;; ADDITIONAL SECTION:
www.dnssec.cz. 86400 IN A 192.168.1.1;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug 8 14:20:58 2008
;; MSG SIZE rcvd: 139
V tu chvíli dojde k přepsání A záznamu pro www.dnssec.cz ve vyrovnávací paměti serveru a další dotazy na www.dnssec.cz, na které bude odpovídat tento DNS serveru, budou obsahovat podvrženou IP adresu.
Šance na uhodnutí správného Transaction ID zůstává stále stejná, ale útočník může volbou dotazů na různé neexistující domény zkoušet podvrhnout IP adresu stokrát až tisíckrát za sekundu. Navíc je schopen lépe řídit čas dotazu (vždy se ptá útočník) a tím pádem lépe načasovat i generování podvržených odpovědí.
Výrobci a autoři DNS serverů vydali aktualizace, které do dotazu vkládají další prvek náhody – náhodný zdrojový port. Před aktualizací byl zdrojový port dotazu zvolen náhodně při startu serveru a po celou dobu běhu serveru byl používaný stejný port. Po aktualizaci se pro každý dotaz používá nové
náhodně zvolené číslo zdrojového portu (pokud budeme počítat, že se využije celý rozsah, což většinou nebývá pravdou) a šance na uhodnutí kombinace Transaction ID a čísla zdrojového portu je 1 ku 4 milardám. Útočník se může pokoušet vygenerovat i takovýto počet podvržených DNS odpovědí, ale šance, že se mu povede trefit se se správnou odpovědí je výrazně menší a provoz, který tímto vygeneruje jen těžko zůstane bez povšimnutí.
Útok, který předvedl Dan Kaminsky, na vyrovnávací pamět DNS serveru je po instalaci opravných aktualizací nepravděpodobný, ale stále možný. Podle kalkulací, které proběhly poštovní konferencí namedroppers, je pravděpodobnost takového útoku po 24 hodinách cca 64%. Takový útok by si ovšem vyžádal generování obrovského množství podvržených DNS odpovědí a u méně výkonných instalací by spíše způsobil zahlcení a přerušení provozu. Tak než jsem stihl napsat tento příspěvek do blogu, tak se objevil první úspěšný útok v laboratorních podmínkách na DNS server s náhodnými zdrojovými porty, který byl schopný vložit do DNS falešnou adresu během 10 hodin.
Jediné řešení, které DNS servery ochrání před tímto stylem DNS útoků je v současné době technologie DNSSEC.
Prezentaci Dana Kaminského z konference BlackHat USA 2008 naleznete na jeho stránkách DoxPara.
Malé (a nevýznamné) IPv6 překvapení
Jak už bylo mnohokrát řečeno (třeba zde), pomalu docházejí volné bloky IPv4 adres. Přechod na IPv6 rozhodně neprobíhá zrovna „nadzvukovou“ rychlostí a tak je poměrně překvapující následující statistika, která popisuje strukturu DNS dotazů přicházející na name servery CZ.NIC.
Jak je vidět dotazy týkající se IPv6 (AAAA a A6), tvoří už dnes skoro 20 % celkového provozu nebo pokud porovnáme s odpovídajícím IPv4 dotazem, je to dokonce 25 %. To není málo. Abychom se ale nedívali na svět příliš růžovými brýlemi, podíváme-li se za stejné období minulého týdne na návštěvníky www.nic.cz, tak situace už vypadá zcela (a bohužel i očekávaně) jinak. Zatímco přes IPv4 přišlo 8041 unikátních uživatelů, přes IPv6 jen 32, tedy 0,3 %. A to už není žádná sláva :(
Pavel Tůma (PT)
Jak bude fungovat DNSSEC v .CZ?
Na začátku března jsme ohlásili záměr a „cestovní plán“ na zavedení technologie DNSSEC v doménách .CZ a ENUM. Dokument Implementace DNSSEC v CZ.NIC obsahuje návrh, jak bude implementace do registru domén vypadat a jakým způsobem bude provedena. Tímto jej dáváme všem otevřeně k dispozici. Budeme velice rádi, když nám napíšete své komentáře či připomínky k jeho obsahu a přispějete tak k tomu, aby se DNSSEC stal užitečným nástrojem pro všechny uživatele internetu v České republice. Své reakce vkládejte přímo sem pod článek do komentářů nebo e-mailem na adresu kontakt@nic.cz.
Ondřej Filip
IPv6 v kořenové zóně
O IPv6 se diskutuje už dlouhá léta. Někdy okolo roku 1992 začalo být IETF jasné, že IPv4 adresy dochází a byla nastartována iniciativa IPng (první RFC na toto téma bylo RFC 1550). Přibližně o tři roky později byl vybrán návrh IPv6 (základní specifikace IPv6 se nachází v dokumentu RFC 2460). Proces, který následoval v běžném světě, bych označil jako: „Jak se vyhnout nasazení IPv6.“ Masivní nasazení technologie překladu adres (NAT/PAT) postupné ubývání IPv4 adres zpomalil, ale nezastavil. Velmi pěkné pojednání o tom, kdy IPv4 adresy dojdou má na svých stránkách Geoff Huston. Podle jeho posledního modelu nám dojdou adresy někdy v roce 2011-2012.
Nicméně rozhodně nelze sedět a čekat, až IPv4 adresy dojdou. Přechod na IPv6 nejde udělat přepnutím jednoho přepínače a internetová infrastruktura na tento přechod musí být připravena. Všechny systémy provozované sdružením CZ.NIC jsou v tuto chvíli provozovány na IPv4 i IPv6 adresách, včetně našich DNS serverů.
Z pohledu IPv6 došlo minulý týden k důležitému kroku na straně serverů obsluhující kořenovou (root) zóny. IANA přidala do této zóny IPv6 záznamy pro polovinu (přesněji šest ze třinácti) DNS serverů – A,F,H,J,K a M.
Běžného uživatele se tato změna nejspíš nedotkne, i když vím o minimálně jedné komunitní síti, která má (a možná, že už to opravili) IPv6 routing natolik rozbitý, že by to mohlo dělat problémy. Nicméně z pohledu další budoucnosti je to výrazný signál, že je potřeba začít IPv6 brát vážně.
Krátká poznámka na závěr. Pokud provozujete BIND jako resolver a zároveň používáte IPv6, budete asi chtít zaktualizovat named.root soubor. Stáhnout si jej můžete z Internicu.
Ondřej Surý