Protokol DNS vznikl v 80. letech, tedy v době výrazně nižších propustností sítí a především o mnoho řádů nižším výkonem počítačů. Byl proto navržen na protokolu UDP, s pevnými velikostmi jednotlivých parametrů a s mnoha omezeními podřízenými rychlým zpracováním v omezeném prostředí.
Rychle se ale objevily další nápady, jak původní DNS rozšířit, ovšem původní návrh to nijak jednoduše neumožňoval. Jednak byla velikost UDP paketu omezena na 512 bytů, zároveň měly jednotlivé položky v paketu pevně dané místo a velikost a kvůli zpětné kompatibilitě nebylo možné s tím jednoduše hnout.
V roce 1999 (už před 20 lety!) proto vyšel první standard zvaný EDNS, který je ukotven v RFC 2671 a zavedl rozšíření původního protokolu. Protože do hlavičky nelze nic přidávat, byly využity takzvané pseudo-RR záznamy, které se přidávají na konec samotné zprávy. Tam se tedy v EDNS přilepí doplňující informace, které je potřeba přenést. Později byl ještě tento mechanismus doplněn, konkrétně v roce 2013 v RFC 6891.
Nestandardní implementace
Stále existuje řada provozovatelů DNS služeb, kteří standardy porušují. Jejich software na první pohled funguje dobře, ale v některých okrajových případech se nechová podle standardů. Tomu se musí ostatní implementace přizpůsobovat a postupně v nich narůstá velké množství kódu, který se vypořádává s nejrůznějšími výjimkami z výjimek.
To postupně vytváří samo o sobě další potíže, například se kvůli timeoutům zpomaluje komunikace s nestandardními autoritativními servery nebo kvůli těmto problémům není možné nasadit nové vlastnosti DNS. Například takové DNS cookies by účinně bránily zneužívání DNS serverů k zesilujícím útokům.
Chybné implementace EDNS v čase
Problém nezpůsobují autoritativní servery, které se rozhodly EDNS neimplementovat vůbec. Problém nastává v situaci, kdy nestandardní implementace autoritativního serveru vůbec neodpoví na EDNS dotaz. Pokud server mlčí, resolver nemá tušení, co se stalo: paket se mohl po cestě ztratit, druhá strana má dočasný výpadek nebo se stalo něco jiného. Resolver jednoduše nedostává žádnou zprávu. Může to ovšem znamenat, že server nerozumí EDNS dotazu a proti standardu se rozhodl nereagovat.
Resolvery na to doposud reagovaly tím, že se po určité době pokusí dotaz zopakovat bez EDNS rozšíření. Tohle je právě ono chování, které způsobuje čím dál větší potíže a tvůrci DNS software se rozhodli dále toto chování netolerovat. Autoritativní server tedy bude muset na EDNS dotaz buď odpovědět legitimní odpovědí nebo jej odmítnout pomocí kódu FORMERR, jak je napsáno v příslušném standardu.
Od 1. února
Už za pár dnů nastane takzvaný DNS Flag Day. Bude to den, po kterém už poskytovatelé DNS software a služeb nebudou výše popsané chování tolerovat. Projeví se to tím, že nové verze rekurzorů budou považovat mlčící server za chybný a nebudou se ho dotazovat znovu bez EDNS. Pokud se takto budou chovat všechny autoritativní servery dané domény, vrátí se tazateli SERVFAIL. Konkrétně se úprava týká následujících verzí:
- BIND 9.13.3 (development) and 9.14.0 (production)
- Knot Resolver už tuto změnu implementoval
- PowerDNS Recursor 4.2.0
- Unbound 1.9.0
Zároveň tuto aktivitu podporuje řada velkých poskytovatelů veřejných DNS rekurzorů: Google (8.8.8.8), Quad9 (9.9.9.9), Cloudflare (1.1.1.1), dále také Facebook, Cisco a další. Také oni mají v plánu odstranit kód opravující chyby špatných implementací EDNS.
Aby se s vašimi autoritativní servery tyto rekurzory domluvily podle standardu, musí servery odpovídat na každý EDNS dotaz a váš firewall nesmí blokovat DNS komunikaci obsahující rozšíření.
Jak to otestovat
Nejjednodušší test je k dispozici na webu DNSflagday.net, kam stačí vložit doménové jméno. Podrobnější test včetně výsledků jednotlivých dotazů najdete na ednscomp.isc.org. Měli byste dostat odpověď All OK. Zdrojové kódy testů jsou volně ke stažení.
Základní test můžete provést také manuálně pomocí příkazu dig, který je součástí balíčku dnsutils. Zavolejte postupně následující dva příkazy:
# dig +norec +noedns soa zone @server # dig +norec +edns=0 soa zone @server
První příklad se dotazuje na SOA s vypnutým EDNS, druhý dělá totéž s použitím EDNS. Nejpalčivější problém nestandardního přístupu se projeví tím, že autoritativní server na první příkaz standardně odpoví, ale při odeslání druhého mlčí. Příkaz dig pak skončí timeoutem a při skutečném provozu pak bude takový server považován za nefunkční.
Pozor na to, že nejde o kompletní test, zmíněné webové testy provádějí ještě další dotazy. Jde pouze o základní test jednoho z problémů, které mohou po 1. únoru vaše servery trápit. Pro podrobnější testování použijte formulář na dnsflagday.net.
Pokud jste na takové chování na svých autoritativních serverech narazili, je nejvyšší čas s tím něco dělat.
Jak jsou na tom české domény?
Petr Špaček vydal na blogu CZ.NIC aktuální statistiku připravenosti domén s koncovkou .CZ na zmíněnou únorovou změnu. Měření provedená mezi 11. a 14. lednem ukazují, že problém nastane u 0,12 % domén v registru .CZ. Měření byla předtím opakována a jasně se ukazovalo, jak se situace během předchozího roku zlepšovala:
CZ.NIC se pokusil kontaktovat správce těchto domén, ale bez úspěchu. Správci zbývajících 0,12 % domén dosud nereagovali na žádný z pokusů o komunikaci a není proto jasné, zda přípravu jen odložili na poslední chvíli nebo zda se rozhodli problém ignorovat,
píše Špaček. Ve skutečnosti by to ale neměl být problém, protože většina těchto domén není ve skutečnosti používaná. Značná část namátkově vybraných domén však vypadá, že se nepoužívá a je pouze tzv. ‚zaparkovaná‘, takže dopady na běžné uživatele by měly být velmi malé.
ČLÁNKY DO MAILU