Problémy DNS

Kdyby byl voják, mohl by celkem s klidným svědomím hulákat tradiční Během mé služby se nic zvláštního nestalo. Díky své skvěle navržené distribuované koncepci se dokázal vypořádat s obrovským kvantitativním nárůstem uložených dat, ale i s různými snahami o útok na jeho klíčové prvky. Jeho celková bilance je v každém případě pozitivní, přesto ale není zcela bez problémů.

Jejich přehled shrnul Duane Wessels do své prezentace What is Wrong With the DNS? [PDF, 91 kB], která sice pochází již z loňského října, tématicky je ale dost nadčasová. Nedostatky v ní rozdělil do čtyř hlavních skupin: na problémy vlastního protokolu, implementační, provozní a registrační.

Z protokolových jako první zmiňuje omezení velikosti UDP paketu na 512 B, které si stanoví RFC 1035 (část 2.3.4). Hovoří o něm v souvislosti s IPv6 a jeho čtyřnásobnou délkou adres. Daleko větší nárůst objemu dat však představuje DNSSEC, kdy se k záznamům přidávají ještě informace pro ověření autenticity. Kromě nich ale každou chvíli přicházejí nové a nové návrhy, co všechno ještě ukládat do DNS. Všechny se musí nějakým způsobem vypořádat s omezením velikosti dat. To je navíc celkem zbytečné, když IPv6 požaduje, aby infrastruktura přenášela více než dvojnásobné pakety, a vzhledem k všudypřítomnosti Ethernetu sítě obecně konvergují k omezení velikosti datagramů na 1500 B.

Pro tento problém sice již delší dobu existuje řešení (rozšíření DNS paketů nazývané EDNS0 definované v RFC 2671), ale podle Wesselse míra jeho rozšíření stále není uspokojivá. Jinou možností řešení tohoto a některých dalších problémů je použití TCP jako přenosového protokolu pro DNS. Ale mám-li být upřímný, připadá mi to jako vyhánění čerta ďáblem.

TCP znamená nezanedbatelnou režii na straně serveru, který si musí udržovat stavové informace o připojených klientech. Způsobí také určité zpoždění, protože navázání TCP spojení vyžaduje výměnu tří paketů. Duane Wessels je toho názoru, že TCP vyřeší také problém s asymetrickou komunikací, kdy server odpovídá klientovi, jehož adresa je nedosažitelná. Podle mého názoru ale jen přesune problém jinam (do TCP vrstvy, která bude čekat na třetí paket dokončující navázání spojení) a spíše ho zhorší. Připadá mi jako méně zatěžující odpovědět do prázdna, než udržovat polotovar TCP spojení v příslušných datových strukturách, dokud nevyprší timeout. Nota bene takové „polootevírání“ spojení je jádrem některých DoS útoků. A jako třešničku na dortu autor samotný o něco dál upozorňuje na blokování TCP portu 53 používaného DNS, který má zabránit zónovým přenosům mimo danou síť. Nemohu se ubránit pocitu, že TCP více potíží způsobí než vyřeší.

Řada problémů je způsobena novinkami. Například s nástupem IPv6 vedle objemu přenášených dat narůstá i počet dotazů, protože některé systémy při snaze najít adresu k danému jménu rovnou generují dva DNS dotazy – jeden pro IPv4 záznam typu A, druhý pro IPv6 záznam AAAA. Paul Mockapetris, autor DNS, kvůli tomu ostře kritizoval Windows Vista (a trochu si zapřeháněl). Duane Wessels jako možné řešení navrhuje vyvinout nový typ dotazu, který by se současně dotazoval na oba typy adresních záznamů.

Také internacionalizace (IDN) si vysloužila „ťafku“ kvůli nejednoznačnosti a možnosti zmást uživatele podstrčením podobného znaku z vhodné znakové sady, kterou začali využívat rhybháři.

Ve zvláštní pozici se ocitlo DNSSEC, které střídavě vystupuje na obou stranách barikády – jednou jako řešení problémů (především s falšováním a změnami odpovědí), jindy jako jejich zdroj. Duane Wessels především kritizuje jeho pomalý postup (v tom rozhodně není sám) a chybějící řešení pro některé detaily. Zároveň doporučuje vytrvat a nevzdávat se. V této souvislosti nelze nezmínit, že věčný provokatér Randy Bush nedávno poukázal na jisté společné znaky DNSSEC, IPv6 a války v Iráku.

V oblasti implementací působí krajně depresivně statistika, že více než 3/4 dotazů přicházejících na kořenové servery je zbytečných – opakují se, ptají se na neexistující domény nejvyšší úrovně (např. local) nebo přicházejí z adres, na něž se nedá odpovědět. Svým způsobem je to logické, protože příčetné dotazy pravděpodobně využijí dílčí informace z lokálních vyrovnávacích pamětí (například v nich nejspíš budou autoritativní servery pro korektní doménu nejvyšší úrovně), a ke kořenovým serverům proto nejspíš vůbec nedojdou.

Za pozornost stojí pragmatická poznámka, že na spoustě míst se používají lokální adresy podle RFC 1918, ale skoro nikde pro ně nebývá udržováno reverzní DNS. Duane Wessels doporučuje správcům lokálních sítí se polepšit, aby reverzní dotazy na soukromé adresy neprotékaly do horních pater doménové hierarchie. Upozorňuje také na kvanta DNS dotazů, které způsobuje automatické doplňování domén, a to jak na straně DNS klienta, tak na straně aplikace (typickým příkladem domýšlivého programu je WWW klient). A evergreenem pochopitelně jsou různé nekonzistence v obsahu doménových souborů – špatné delegace, chybějící SOA záznamy a podobně.

Pokud se týká doporučení, jak se některým z popisovaných problémů vyhýbat, několikrát se v prezentaci opakuje:

1. Používat aktuální verze programů.
2. Chránit je před zneužitím vhodnou konfigurací, například použitím přístupových seznamů (praktický návod pro BIND najdete v našem starším článku).
3. Kontrolovat obsah svých domén vhodnými nástroji (tipy na ně přináší článek o neplechách v DNS).