facebook LinkedIN LinkedIN - follow
IT SYSTEMS 4/2012 , ITSM (ITIL) - Řízení IT

Výkonnější DNS pomocí anycastu



Ignum DNS (Domain Name Service) je jedna z nejdůležitějších služeb internetu, která přímo ovlivňuje zážitek uživatelů z prohlížení webových prezentací, zejména pak rychlost prvního načtení webových stránek. Abychom se vyhnuli dlouhému čekání na otevření požadované internetové adresy, nebo i přímo výpadkům DNS, lze jeho výkon posílit pomocí anycastu.


Výpadky DNS mívají tragické následky, protože se při nich z pohledu uživatelů – potenciálních zákazníků – zdá, že webové prezentace či jiné služby zkrátka nefungují. DNS je citlivé i z bezpečnostního hlediska. Úspěšný útok na DNS umožňuje přesměrovat tok informací a podstrčit uživateli malware nebo podvodné stránky místo e-shopu či webu internetového bankovnictví.
DNS slouží především k překladu doménových jmen (např. www.ignum.cz) na IP adresy (v tomto případě 62.109.128.30). K tomu DNS používá hierarchickou strukturu a tabulky záznamů, takzvané zóny. Záznamy mohou být několika typů, nejznámější typy záznamů jsou SOA, A, AAAA, NS a MX, CNAME. Záznamům se také říká resouce record (zkráceně RR).

Jak pracuje DNS?

DNS funguje ve zkratce tak, že prakticky všichni uživatelé internetu mají nastaveny ve svém operačním systému IP adresy jednoho nebo více DNS serverů, které chtějí používat jako rekurzivní DNS servery (rekurzory). Operační systém klienta vygeneruje DNS dotaz pokaždé, když uživatel do webového prohlížeče zadá novou adresu nebo když při zobrazování webové stránky narazí prohlížeč na obrázek, který se nachází na jiném serveru apod. Úkolem rekurzorů je přijímat DNS dotazy od klientů, nacházet odpovědi a vracet je klientům zpět. Najít odpověď lze buď rychle s použitím vlastní cache, nebo pomaleji, rekurzivním dotazem. Cache si rekurzory budují z dotazů, na které v minulosti odpověděli na základě rekurze a ke každému záznamu v cache si zaznamenávají dobu platnosti.
DNS rekurze je sled na sebe navazujících dotazů do hierarchie autoritativních DNS serverů. Autoritativní server je druhý typ DNS serveru vedle DNS rekurzoru a je součástí DNS hierarchie (nebo DNS stromu). Každý autoritativní server poskytuje na vyžádání DNS dotazem jednu nebo více DNS zón v její celé, úplné a aktuální podobě. Autoritativní servery mohou být buď master, nebo slave, podle toho, jestli administrátoři (či držitelé domén) přímo nastavují na server do konfigurace celý obsah zóny, nebo jestli se celá zóna stahuje z master serveru a drží se pak jako platná a aktivní záloha. DNS hierarchie je tvořena delegacemi mezi zónami a servery, které jsou pro ně autoritativní.
Delegace je svého druhu přenesení autority nad jmenným podprostorem na jiný server a tvoří se DNS záznamem NS. Například DNS jméno www.ignum.cz. se skládá z počátku (DNS rootu) a tečky (na konci). Autoritativní servery pro kořenovou zónu obsahují v kořenové zóně delegaci pro zónu cz. (tu spravuje organizace CZ.NIC). Autoritativní servery pro zónu cz. obsahují v zóně cz. delegaci pro zónu ignum.cz. a tyto servery pak obsahují DNS záznam typu A, který ke jménu „www“ přiřazuje IP adresu 62.109.128.30.
Poznámka: Tečka na konci DNS jména se v mnoha technicky přesně vymezených případech nemusí psát, a tak DNS jména zdomácněla bez teček představujících DNS root. Fungují však i se specifikací rootu, tedy s tečkou na konci a je v jistých situacích bezpečnější uvádět je s tečkou. V rámci konfigurace DNS je to někdy dokonce nutnost.

Obr. 1: Hierarchie DNS
Obr. 1: Hierarchie DNS


DNS rekurze je časově náročná, přestože autoritativní servery odpovídají rychle – v řádu jednotek až desítek milisekund. Rekurze komplikovanějšího jména však může znamenat například pět dotazů a k času odezvy serverů se přidává ještě síťová latence, která může představovat i stovky milisekund, pokud se data přenáší přes různé kontinenty. Doba, jakou konečný klient musí čekat na DNS odpověď od svého rekurzoru, tak může snadno překročit sekundu. Navíc v případě výpadku některého autoritativního serveru v řetězci nebo ztracení DNS dotazu či odpovědi při přenosu dochází k čekání na timeout před opakováním dotazu nebo kontaktováním záložního DNS serveru. To může představovat další sekundy čekání.
Autoritativní servery doménových registrátorů v českém prostředí běžně odpovídají na stovky až tisíce DNS dotazů z celého světa každou sekundu. Není divu, když velcí doménoví registrátoři mívají ve správě stovky tisíc zón, které na jejich autoritativní servery delegovali jejich zákazníci. Péče věnovaná autoritativním DNS serverům je tedy velmi opodstatněná jednak pro jejich klíčovou roli, pro potenciální katastrofální dopady na business continuity v případě jejich výpadku a také z důvodu výkonu a robustnosti pro případ DoS útoků, které se DNS serverům rozhodně nevyhýbají.

Posílení výkonu pomocí BGP anycastu

Základní mechanismus škálování DNS je už zmíněné cachování. Pokud nestačí, je třeba zařídit rozklad zátěže na více fyzických serverů. Nabízí se buď postavit cluster s loadbalancerem nebo využití technologie BGP anycast. Pointa BGP anycastu spočívá v tom, že se využije vlastností protokolu BGP (Border Gateway Protocol), což je dominantní externí směrovací protokol v Internetu, který používají ISP k vzájemnému propojení. Vyčlení se ASN (číslo autonomního systému) a IP prefix a tento prefix se oznamuje do protokolu BGP pod vyčleněným ASN z mnoha DNS serverů umístěných v různých lokalitách ve světě. Jedna nebo více IP adres z tohoto prefixu slouží jako adresa pro DNS server.
Protokol BGP preferuje vždy nejkratší cestu k cíli a proto servery tvořící DNS anycast cloud na sebe „lákají“ DNS dotazy ze svého síťového (a tedy i geografického) okolí. Pak už jen stačí mít mechanismus na správu a udržování aktuálních zón na všech serverech DNS anycast cloudu a je zajištěno jednak podstatné snížení síťové latence a obrovská škálovatelnost, ale i výborná robustnost DNS anycast cloudu. V případě výpadku jednoho z DNS anycast serverů nebo sítě ISP, kde je server zapojen, totiž dojde pouze k přesměrování cest k IP adrese, která představuje DNS server na jiné anycast servery. Ty jsou od klientů možná trochu vzdálenější, ale službu poskytují stejnou. Celé přesměrování proběhne v řádu sekund od výpadku DNS anycast nodu a je plně automatické, stejně jako přesměrování nazpět, po tom co se problém vyřeší. Situaci ilustruje zjednodušený obrázek, kde je znázorněno na pěti autonomních systémech a dvou serverech, jak se BGP zachová po výpadku DNS nodu 1 – všechny cesty budou přesměrovány na DNS node 2 (čárkovaně).

Obr. 2: Rekonvergence BGP po výpadku uzlu 1
Obr. 2: Rekonvergence BGP po výpadku uzlu 1


Aby byl DNS anycast účinný, je třeba pečlivě volit umístění DNS anycast nodů a systém průběžně rozšiřovat. V zásadě nemá smysl umístit více DNS anycast nodů do jednoho města do různých datacenter, s výjimkou případu, kdy je cílem jen a pouze zálohovat provoz. Optimální je umísťovat servery primárně na různé kontinenty do míst, kde je největší koncentrace IT infrastruktury. Například v rámci USA je vhodné rozlišovat východní a západní pobřeží a sever a jih. V Evropě je důležité pokrýt místa s největší koncentrací zákazníků, což je pro české firmy přirozeně ČR a Slovensko. Dále jsou z obecných lokací s velkou koncentrací IT zajímavé Frankfurt nad Mohanem, Amsterodam či Londýn. Samozřejmě je nejlepší variantou nasadit několik DNS anycast nodů a na základě analýzy geografického rozložení dotazů na tyto servery pak plánovat rozšiřování do míst, odkud pochází nejvíc dotazů přesahujících stanovenou hranici síťové latence, kterou lze považovat za rozumnou – například RTT do 100 ms.

Anycast v praxi

Anycast není pouze teoretickým nástrojem pro zvýšení rychlosti a spolehlivosti pohybu na internetu, ale v praxi hojně využívanou technologií. Sdružení CZ.NIC, správce národní domény CZ, má své anycastové servery umístěné v Praze, Frankfurtu a San Franciscu. Tyto servery obsluhují požadavky po IPv4 i IPv6. Z českých poskytovatelů internetového připojení provozuje anycast zatím pouze společnost Ignum s anycastovými servery v lokalitách Praha, Bratislava a Curych ve Švýcarsku.
Anycasting je však obecný mechanismus, který lze použít i pro jiné služby než DNS. Nesmí však jít o služby, které závisí na dlouho trvajících TCP spojeních, neboť změny cest na jiný server anycast cloudu by vedly automaticky k přerušování a timeoutování spojení. Právě tyto změny můžou nastávat celkem často, bez vědomí provozovatele anycast cloudu i bez možnosti jejich výskyt ovlivnit či omezit. Anycasting je tedy přirozeně nejvhodnější na čistě UDP služby.

Tomáš Hlaváček
Autor působí jako senior administrátor ve společnosti Ignum.

Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.