Tak mi dnešní setkání address-policy-wg udělalo velkou radost. Těsně po minulé schůzce evropské internetové komunity v rámci RIPE jsme v CZ.NICu začali pracovat na rozšíření politiky přidělování IPv4 a IPv6 adres. Konkrétně pak sekci, která se týká přidělování speciálních bloků adres TLD registrátorům. Tyto adresy musí být využívány pro DNS anycast, což je technika, kdy je v síti na různých (většinou geograficky odlišných) místech více serverů, které obsluhují stejnou IP adresu. (Co je to anycast, se můžete dočíst detailně například v článku AS112 – projekt DNS anycast.) Navrhovaná změna mění počet přidělovaných IP bloků pro DNS anycast z jednoho na celkem čtyři bloky.
Následně jsme spojili své síly s Nominetem (anglický registr pro .UK), který původně navrhoval rozšíření této politiky o ENUM registry. Společně jsme pak vypracovali návrh, který byl ve čtvrté verzi představen na dnešním setkání pracovní skupiny Address Policy.
A proč ta radost? Protože všechny komentáře, které k tomuto dokumentu mělo publikum, byly veskrze pozitivní a doporučili schválení této změnu politiky přidělování IPv4 a IPv6 adres. Tudíž se po zapracování těchto úprav do relevantních dokumentů můžete těšit na změny v konfiguraci DNS serverů pro domény .cz a .0.2.4.e164.arpa. Dojde ke snížení počtu unicast serverů a navýšení počtu anycast serverů na finální čtyři, které byly předmětem navrhovaných změn v politice RIPE.
Ondřej Surý
Klíč pro .gov vložen do DLV registru dlv.isc.org
Dne 1. května 2009 došlo k opětovnému vložení klíče pro doménu .gov do DLV registru provozovaným organizací ISC na adrese dlv.isc.org. Verze Bind 9 starší než 9.5.1-P2 a 9.3.4-P2 obsahují chybu, která způsobí nefunkčnost domény .gov, pokud je zapnutá DNSSEC validace pomocí DLV. Tyto verze daemona Bind 9 špatně pracují s neznámými algoritmy a protože doména .gov používá NSEC3 klíče, dojde k chybě při validaci a všechny domény končící na .gov se jeví jako nedostupné.
V Debianu je verze Bind9 9.5.1-P2 dostupná od 29. dubna 2009 pro aktuální stabilní vydání (lenny). Stav v ostatních distribucích můžete poznamenat v komentářích.
Ondřej Surý
(ne)IPv6 na CiscoExpo 2009
Leží tady přede mnou ještě první verze knihy Pavla Satrapy o IPv6 z roku 2002 a na zadní straně přebalu si čtu:
„Společnost Cisco Systems si je vědoma budoucího významu IPv6 a aktivně se podílí na jeho vývoji.“
Rád bych vám teď zde napsal, že se po sedmi letech od vydání knížky a jen pár let do vyčerpání adresního prostoru v IPv4 dostanete na dnes probíhající konferenci CiscoExpo 2009 v rámci WiFi připojení (ESSID: CiscoExpo) i IPv6 adresu a celá síť je na dual stacku a všechno krásně funguje.
Bohužel nemůžu. Navíc tato konkrétní síť CiscoExpo blokovala protokol Jabber (o ICQ ani nemluvě).
Pozitivní je, že alespoň dle různých signálů je podpora IPv6 ve standardním image IOSu.
Ondřej Surý
Bind 9.6 a DNSSEC
Konsorcium ISC nedávno vydalo novou verzi pravděpodobně nejpoužívanějšího DNS serveru Bind. Bind od verze 9.6 kromě pravidelných oprav chyb a vylepšení přináší také zlepšení podpory pro technologii DNSSEC.
Bind 9.6 konečně podporuje standard NSEC3, který přináší více soukromí do podepsaných zón. Tento standard byl vydán jako RFC5155 před necelým rokem a s novou verzí Bindu je konečně podporován všemi významnými open source DNS servery podporujícími DNSSEC (Bind, NSD, Unbound).
Další novinka by měla výrazně zjednodušit správu DNSSEC podepsaných domén. Bind 9.6 přináší automatické přepodepisování zónových souborů dynamických zón. Osobně jsem ještě neměl čas se podívat na to, jak to celé funguje, protože jsem se zabýval následujícím bodem, ale myslím si, že je to správný krok ke zjednodušení nasazení DNSSECu.
Onen další bod, který mě osobně zaměstnával posledních pár měsíců, je podpora PKCS#11 přímo v Bindu. Nová verze přináší nástroj dnssec-keyfromlabel, který umožňuje vytvořit DNSSEC klíč z dat uložených na kryptografickém zařízení (např. takové ty různé USB tokeny). Mělo by to fungovat s openssl a opencryptoki – tj. musíte mít funkční podporu PKCS#11 v openssl. Dnssec-keyfromlabel pak umí vytvořit dvojici souborů .key/.private ve speciálním formátu, který říká, na kterém zařízení najít soukromou část klíče. Zatím jsem neměl čas vyzkoušet tuto funkci na Linuxu, ale společně s Francisem DuPontem z ISC se nám před týdnem povedlo zprovoznit kartu SCA6000 pod Solarisem 10. Sice to zatím vyžaduje verzi z CVS, ale mám osobně slíbeno od ISC, že tato oprava, kterou je potřeba začlenit do hlavní vývojové větve, bude v další verzi řady 9.6 (tedy pravděpodobně v 9.6.1).
Za další z nových nástrojů pravděpodobně můžu já – dnssec-dsfromkey umí z klíče vytvořit DS záznamy bez toho, aby bylo potřeba podepsat zónový soubor. Nápad na tento nástroj vznikl na základě mé diskuze s inženýry z ISC, že v některých specifických případech trvá podepsání zóny i několik (desítek) minut – a je to dost neefektivní muset podepsat zónu, aby byl soubor s DS záznamy vytvořen.
Poslední věc, která stojí za zmínku je zahrnutí sady nástrojů ZKT do distribučního souboru Bindu (hledejte v adresáři contrib). ZKT obsahuje sadu nástrojů, která umí usnadnit práci s DNSSEC klíči a automatizaci podepisování zónových souborů. Používám jej na automatizaci podepisování našich zón. A také připravuji jeho zabalíčkování do distribuce Debian (a tím pádem časem propadne i do distribucí odvozených), nicméně v současnosti je build systém trochu nevhodný na balíčkování, takže to bude chtít ještě trochu společné práce s autorem na ZKT. A času se nikdy není dost.
Ondřej Surý
Jak zjednodušit DNSSEC?
Minulý týden jsem měl docela pěknou, plodnou debatu s Ondřejem Filipem, Danem Kaminskym a Paulem Wouterem o tom, jak usnadnit použití DNSSECu pro běžné uživatele. Dan je v tom poněkud radikální a vymýšlí systém, kdy by stačilo „nasadit novou verzi“ a všechny spravované domény by byly podepsané, tj. koncový uživatel by nemusel dělat nic. Osobně si myslím, že je to zatím příliš odvážné, a že je zatím potřeba postupovat po menších kouscích. Celé to totiž začíná být složitější ve chvíli, kdy každý doménový registr má vlastní verzi registračního systému a hierarchii dat uvnitř registru.
Nicméně s Paulem jsme pak rozebírali modely toho, jak to zjednodušit a zároveň respektovat různé registrační systémy. Je jasné, že první krok, který je potřeba udělat, bude vždycky muset být ruční – jedná se o vytvoření důvěry mezi doménovým registrem a prvotním DNSSEC klíčem. V případě naší národní domény bude zachovaný proces, kdy držitel doménového jména kontaktuje existujícím komunikačním kanálem svého registrátora a ten pošle zabezpečeným kanálem přes EPP protokol přidání (nebo změnu) DNSSEC klíče do centrálního registru.
Další krok už lze automatizovat. Pokud použijeme specifikaci RFC5011, která říká, jakým způsobem lze měnit DNSSEC kořeny důvěry, tak existuje možnost, že by DNS server podepsané domény mohl poslat speciální UPDATE zprávu (podepsanou stávajícím DNSSEC klíčem) o tom, že dochází ke změně DNSSEC klíče. Specializovaný DNS server by tuto zprávu zaznamenal, ověřil změnu a vygeneroval DS záznam pro nový klíč. Celý tento proces by mohl proběhnout bez lidského zásahu.
Na konci jsme se s Paulem dohodli, že tento koncept rozpracujeme ve formě Internetového Draftu a pokusíme se jej standardizovat na půdě IETF.
Docela by mě zajímalo, co si o tomto nápadu myslíte? Své připomínky můžete psát do diskuze níže.
Ondřej Surý
Více anycast DNS serverů pro ccTLD
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ý
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.