Vlákno názorů k článku Útok na DNS náhodnými dotazy od Filip Jirsák - To řešení S DNSSEC řeší podle mne jen...

To řešení S DNSSEC řeší podle mne jen okrajový případ, kdy útočník na DNS server domény druhého řádu útočí přes generované názvy 4. řádu. Předpokládám, že ale mnohem častější útoky, než random.www.exam­ple.com budou přímo na random.example­.com, ne? A tam už DNSSEC nepomůže. Má smysl tu „díru“ zazáplatovat, ale asi to moc nepomůže…

Řeší to úplně stejně. konkrétně random.example­.com je pokryto NSEC záznamem

example.com. IN NSEC www.example.com. …

Na tom, kolik teček v sobě dotaz má vůbec nezáleží, NSEC záznamy pokrývají v kruhu celou zónu. Umožňují každému vyčíst, které záznamy v zóně existují a tedy i to, že žádné jiné existovat nemohou.
Ostatně, to, že NSEC záznamy umožňují vylistovat všechna existující jména v zóně je některými vnímáno jako bezpečnostní riziko a je to zároveň důvod, proč byl vynalezen mnohem komplikovanější systém NSEC3 (a možná ještě bude NSEC4). I pro NSEC3 ale platí, že je jej možné použít k určení neexistujícího záznamu. V takovém případě to ale vyžaduje jisté výpočetní nároky na straně rekurzivního serveru, který musí dotazované jméno nejprve několikrát zahashovat a pak najít, zda leží v nějakém rozsahu pokrytém NSEC3 záznamy.

V tomhle případě by ale rekurzivní server musel mít stažený seznam všech NSEC3 záznamů (případně celou zónu při použití NSEC). A pak nejprve podle těchto záznamů určit, zda doménové jméno existuje. To je podle mne mnohem náročnější, než se jenom podívat do cache a zjisti, že nic pod www.example.com neexistuje. Nejspíš má smysl tenhle výpočet dělat až tehdy, pokud by rekurzivní server zjistil, že daná doména je pod útokem. Jenže pak zase hrozí, že autoritativní server zahltí požadavky na ty NSEC/NESC3 záznamy.

Ano, náročnější to bezesporu je. Ale pokud jde o validující resolver, většinu věcí stejně dělá kvůli validaci už teď. Server nemusí mít nutně od začátku všechny NSEC/3 záznamy, ty se postupně naučí při odpovídání na několik prvních dotazů. Nejtěžší tak asi bude nějakým optimálním způsobem implementovat cache těchto záznamů, aby se v ní dalo rychle vyhledávat, zda hledané slovo je pokryté, nebo ne. S indexováním jen podle levého pole to asi nepůjde.

S NSEC3 se to zkomplikuje v tom, že server musí nejprve najít v cache nejdelší shodu na záznamu typu NSEC3PARAM, podle těchto parametrů dotazované jméno zahashovat a pak hledat, zda je dotazované heslo pokryté v cache. Tohle hashování ale není marné, stejně by ho musel provádět při DNSSEC validaci obdrženého NSEC3 záznamu.