Jak diagnostikujeme a řešíme problémy se síťovými připojeními - díl III. - DNS

1. Do třetice... (naposledy)

V předchozím díle jsme se naučili, jak funguje směrování paketů a řekli jsme si, jak lze diagnostikovat a vyřešit případné problémy. V tomto posledním díle se podíváme na (relativně časté) potíže se servery DNS

2. What the... aneb Co to vlastně je? A odkud se to vzalo?

Co je DNS? Znamená to Domain Name System a v praxi se jedná o systém, jakým se tzv. překládá jmenná internetová adresa na IP adresu (a obráceně). K čemu je to dobré? Hned si to vysvětlíme. Kdysi, v dávných dobách, kdy Internet nebyl ještě ani Internetem, ale Arpanetem, se počet připojených počítačů zvětšil takovým tempem a na takové množství, že se pomalu přestalo dařit udržovat v aplikacích a systémech seznamy IP adres počítačů se kterými bylo nutno komunikovat.

2.1 Soubory hosts

Jako přechodné řešení bylo přijato použití souborů hosts, první, takřka "nulté" verze jmenného systému. Prakticky se jednalo o přiřazení "lidských" jmen jednotlivým adresám. Nevýhodou tohoto řešení ovšem bylo, že se jednalo o striktně lokální řešení, tedy každý počítač měl vlastní soubor hosts. Udržovat tedy takové seznamy bylo jen o trochu jednodušší, než zadávat do aplikací přímo IP adresy. Navíc vždy hrozilo, že tyto soubory nebudou totožné na všech navzájem komunikujících počítačích, a tedy že komunikace selže díky triviální chybě - že zdrojový počítač jednoduše nenajde správný cílový počítač. Nicméně hosts soubory přežily dodnes, protože umožňují "doladění" překladu jmen lokálně na konkrétním počítači.
Zde je ukázka klasického hosts souboru z Windows XP:

# Copyright (c) 1993-1999 Microsoft Corp.
#
# Toto je ukázka souboru HOSTS používaného službou Microsoft TCP/IP for Windows.
#
# Soubor obsahuje mapování adres IP na názvy hostitelů. Každá položka
# by měla být na jednom řádku. Adresa IP by měla být umístěna 
# v prvním sloupci a měla by být následována odpovídajícím názvem hostitele.
# Adresa IP a název hostitele by měly být odděleny nejméně jednou
# mezerou.
#
# Komentáře (jako například tento) lze vkládat na jednotlivé řádky
# nebo za název hostitele, komentář je určen znakem '#'.
#
# Příklad:
#
#      102.54.94.97     rhino.acme.com          # zdrojový server
#       38.25.63.10     x.acme.com              # hostitel klientů x

127.0.0.1       localhost

2.2 DNS - logická evoluce

Z výše uvedeného je jasné, že soubory hosts nebyly považovány za ideální řešení. Tehdejší vývojáře napadla geniálně prostá myšlenka - sjednotit tyto hosts soubory na jednom počítači a přes síťovou službu je poskytnout všem ostatním počítačům. Tím se jednoduše eliminuje nutnost duplikace stejných hosts souborů. Tak vznikl systém DNS.
S ohledem na univerzálnost byl systém navržen hierarchicky, tedy existuje několik tzv. root (též kořenových - v doménovém zápise se jedná o prostou tečku - ".") doménových serverů, které se označují písmeny a jsou rozmístěny po celém světě, které spravují domény jednotlivých tzv. Top Level Domén (TLD) - tedy např. domény .COM, .NET, .ORG (dále EDU, MIL) nebo národní domény (.CZ, .SK, .EU, nebo .UK). Každá z těchto TLD má své DNS servery které jsou známy kořenovým serverům, a které spravují tzv. domény druhého řádu, tedy např. DNS server domény .NET spravuje záznamy pro tuto doménu, např. doménu 2. řádu PORADNA (a "ví" kde je DNS server pro tuto doménu 2. řádu). Následně tento server pro doménu PORADNA je serverem, který spravuje domény 3. řádu a hostitele platné pro tuto doménu, tedy např. hostitele pc.poradna.net - je zde vidět striktní hierarchie ukládání záznamů.
Samotné použití DNS se sestává z dotazování jednotlivých serverů, a to opět hierarchicky. Uživatel se ptá svého DNS serveru, který, pokud nezná odpověď, se ptá svého nadřazeného serveru až do doby, než nenajde cílový název domény nebo nenarazí na kořenový server - v takovém případě pak dochází k "sestupování" do dané doménové struktury, dokud není nalezen záznam odpovídajícího požadovaného hostitele.

Příklad: Uživatel v doméně poradna.net požaduje adresu hostitele www.seznam.cz (předpokládáme, že žádný server nemá požadované názvy v cache).

Nejprve je dotazován místní DNS server, který, protože neví, kde leží doména CZ, kontaktuje některý kořenový server, který mu sdělí adresu TLD serveru domény CZ, následně je dotazován tento server na doménu SEZNAM a obdrží adresu doménového serveru
seznamu. Poslední dotaz již směřuje přímo na DNS server seznamu a je dotazován na adresu hostitele "WWW", na což by měl odpovědět jeho IP adresou.

V následující kapitole se mírně dotkneme technického pozadí služby DNS, a to jak stručného popisu samotných záznamů, tak existujících serverů.

3. Technický pohled na DNS

V předchozí kapitole bylo nastíněno, jakým způsobem služba funguje, nyní si rozebereme vlastní způsob uložení nejdůležitějších záznamů a jejich fungování.

3.1 Záznamy DNS

Záznamy DNS se rozumí samotné informace o doménách a hostitelích. Logicky nejstarším typem záznamu je záznam typu A, který v sobě obsahuje překlad jmenné adresy na IP adresu. Logickým doplňkem tohoto záznamu je záznam PTR (PoinTeR), který má funkci přesně opačnou, tedy překládá IP adresu na jmenný tvar. Zde je třeba poznamenat, že pro jednu IP adresu může existovat několik A záznamů, ale vždy pouze jeden PTR záznam. Dalším významným, nicméně později uvedeným záznamem je záznam MX (Mail eXchanger), který je vázán na existující A záznam domény a určuje poštovní server (nebo servery), které pro danou doménu přijímají poštu. Mezi další záznamy se pak počítají mj. NS (záznamy o NameServerech - tj. ostatních DNS), CNAME (alternativní jméno k A záznamu), SOA (technické informace o doménové zóně), SRV (dostupné služby), AAAA (IPv6) nebo TXT (textové rozšiřující informace).

3.2 Nejznámější servery DNS

Z historického hlediska je zcela určitě nutno zmínit na prvním místě ISC BIND (Linux/Unix platforma), který se nachází již v deváté verzi a jehož historie je s vývojem DNS úzce spjata. Mezi mé oblíbené DNS servery se řadí rovněž velmi bezpečný server djbDNS (Linux/Unix) nebo MyDNS (opět Linux/Unix). Mezi dobré DNS servery se rovněž řadí DNS server obsažený ve Windows Server, samozřejmě v aktuální a opatchované verzi, což je ovšem podmínka, kterou by měly splňovat všechny DNS servery, nezávisle na platformě a vývojáři.

3.3 Funkce DNS serveru

Nyní se už dostáváme k funkcím, ve kterých může DNS server pracovat (přičemž jeden fyzický server může poskytovat jednu, několik, nebo všechny tyto funkce) . Prakticky se jedná o čtyři základní funkce:

- Primární DNS server - DNS je primárním serverem pro danou doménu, pokud je jeho adresa zanesena v hierarchicky nadřazeném DNS serveru jako adresa jmenného serveru dané domény. Na tomto serveru se spravují záznamy dané domény a je tzv. autoritativní, tedy jeho data mají nejvyšší a trvalou platnost. Existuje vždy jen jeden primární server pro danou doménu.

- Sekundární DNS server - tento server je opět definován v nadřazené struktuře, jeho funkcí je převzít úlohu primárního serveru v případě, že samotný primární server je mimo provoz. Sekundární server neumožňuje editaci a je možné definovat vícero sekundárních serverů s prioritou.

- Caching DNS server - jedná se o "pouhé" rozložení zátěže. Místo aby klienti neustále dotazovali primární servery po celém světě, zodpovídá tento server již jednou zodpovězené dotazy ze své cache (vyrovnávací paměti). Tímto tak značným způsobem urychluje funkci vyhledávání v DNS. Tento server poskytuje NEAUTORIZOVANÉ odpovědi a je potenciálním cílem útoků na DNS, o kterých byla řeč v úvodu, a které budou rozebrány ve samostatné kapitole.

- Forwarding DNS - toto je nejnižší možná varianta, která se zhusta vyskytuje v domácích "krabičkoidních" routerech. Jedná se defacto o DNS proxy, která veškeré dotazy na ni okamžitě přeposílá na jiné DNS servery (typicky servery ISP)

3.4 Nástroje pro vyhledávání v DNS

Kromě samotného systému můžete dotazovat DNS servery i přímo, pomocí nástrojů, které jsou součástí systému. Součástí všech Windows je příkaz nslookup, který je možno nalézt i v Linuxech, tam je ale již vytlačován nástrojem dig, který se dá lépe používat např. v skriptech.

4. Diagnostikujeme problémy

Nyní nadešel čas, kdy si povíme něco blíže o diagnostice problémů s DNS. Pokud již máte ověřeno (viz předchozí díly), že vaše připojení a směrování je v pořádku, je nutno ověřit ještě možné problémy s DNS. Pro jednoduchost budeme používat nástroj nslookup, kderý se dá najít nebo nainstalovat prakticky ve všech soudobých systémech.

4.1 Kontrola funkčního DNS

Jak již bylo řečeno, možný problém v případě, že síť i směrování funguje a prohlížeč přesto nefunguje, lze hledat v nefunkčním nebo nedostatečně fungujícím DNS serveru. Ověření funkce můžeme provést následujícím způsobem:

Spustíme nslookup (buď přímo z příkazového řádku, nebo v případě Windows můžeme i z nabídky Start pomocí položky "Spustit" a zadáme příkaz zde. Přivítá nás prompt (všimněte si špatně kódované češtiny, toto je bohužel vlastní Windows verzím, fungují ve špatném kódování):

Věchozˇ server:   mygateway1.ar7
Address:  10.0.0.138

>

Co lze z tohoto výpisu zjistit? Dvě informace: náš výchozí server má adresu 10.0.0.138 a je funkční, protože nslookup se s ním bez problémů spojil. Pokud vám nslookup po spuštění vyhodí jakoukouliv chybu, jedná se o nějaký zásadnější problém. Typickým problémem může být např. pomalá odezva DNS serverů ISP (což je vlastní např. serverům české Telefónicy O2), nebo dokonce nulová odpověď - v takovém případě DNS server nefunguje vůbec a tím pádem jste našli chybu prakticky okamžitě.

Nyní přikročíme k otestování základní funkce:

Věchozˇ server:   mygateway1.ar7
Address:  10.0.0.138

> set type=a
> www.seznam.cz
Server:  mygateway1.ar7
Address:  10.0.0.138

Neautorizovan  odpovŘÔ:
N zev:   www.seznam.cz
Address:  77.75.72.3

>

Přepnuli jsme dotazy na záznamy typu A a zeptali se DNS serveru na IP adresu serveru www.seznam.cz. Jak je patrno, vše funguje. V případě, že se místo odpovědi objeví něco podobného:

> www.seznam.cz
Server:  mygateway1.ar7
Address:  10.0.0.138

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** ¬asově limit po§adavku pro mygateway1.ar7 vyprçel.
>

- pak se jedná o poruchu a je třeba problém řešit (viz následující kapitola)

4.2 Možné způsoby řešení problémů

Pokud nefunguje základní překlad existujících adres (typicky seznam.cz apod.), můžete zkusit v případě, že používáte forwarder v routeru (jako je uvedeno výše) přepnout pomocí direktivy server ip_adresa na server ISP (IP adresy DNS serverů ISP bývají většinou součástí technických dokumentů předávaných při zřízení připojení) a pokusit se znova o vyhledání IP adresy. Pokud to zafunguje, je chyba ve vašem routeru a je třeba jej minimálně restartovat (doporučuji podívat se na internetu, zda neexistuje novější firmware pro váš router řešící tento problém). V případě, že ani server ISP nereaguje, je třeba ověřit, že jsou průchodné porty 53/TCP a 53/UDP přes vaše firewally (jak lokální na PC, tak firewall na routeru). Jestliže ani po této kontrole není vyhledání úspěšné, je nejspíše problém na straně DNS serveru ISP. V takové situaci máte už jen dvě možnosti, můžete je ale realizovat naráz. Měli byste zavolat svému ISP a uvědomit jej o problémech s jeho DNS a zároveň můžete na svém routeru (pokud to umožňuje) nastavit jiný server DNS. Tuto možnost popíšeme v kapitole 5.

5. Řešení problému s (děravým) DNS serverem u ISP

Mnoho současných caching serverů ISP je v žalostném stavu, jsou přetížené a neaktualizované. Zde je možno otestovat DNS server na aktuální velkou chybu: www.dns-oarc.net. Pokud se vám u kteréhokoliv serveru objeví hlášení "POOR", jste zranitelní! (více v následující kapitolce). Pokud jsme se dobrali zjištění, že server u vašeho poskytovatele není funkční, nebo že je děravý, máte možnost přejít jinam. Lehce se to řekne, ale už hůře udělá. Bohužel, z bezpečnostních ohledů poskytují ISP své caching servery pouze pro své zákazníky, není tedy možno využívat DNS server jiného ISP, než toho, kterého používáte. Naštěstí zde existuje jedno "globální" řešení, které je možno použít nezávisle na tom jak a přes koho jste připojeni. Jedná se o OpenDNS. Není to řešení ideální, neboť jako protiváhu DNS serverů zdarma je používáno tzv. wildcardů, tj. pokaždé když zadáte v prohlížeči neexistující adresu, zobrazí se vám reklama. Taktéž je známo, že OpenDNS přesměrovává Google na své servery, což je daleko horší, nicméně s ohledem na potenciální problémy vašeho ISP (viz další kapitola) se jedná o problém řádově menší. Samotné přenastavení proveďte buď ve vašem routeru (pokud to umožňuje, což by měl) nastavením IP adres 208.67.222.222 a 208.67.220.220 v položkách DNS serverů u WAN rozhraní. Pokud toto váš router neumožňuje (a standardně přijímá pouze DNS adresy z DHCP), můžete si tyto adresy nastavit v políčkách DNS serverů u vašeho síťového připojení v počítači (vypněte přiřazení DNS serverů z DHCP a zadejte tyto dvě adresy). Pro mnoho routerů, jakož i pro operační systémy jsou podrobné návody zde: start

Nastavení můžete po uložení a restartu otestovat novým dotazem podle návodu v kap. 4.1, případně otestovat děravost testem uvedeným v této kapitole. Vše by mělo být od této chvíle funkční, a vy byste se měli být schopni dostat se na internet.

6. Současná bezpečnostní hrozba týkající se systémů DNS

Nedávno byl veřejně publikován způsob včetně ukázkového kódu, jak zneužít caching DNS server k útoku Man in the Middle. V podstatě se jedná o vynucení serveru načíst DNS informace o útočníkově DNS zóně, ve které je ukryt specifický kód, kterým se "otráví" (tj. záměrně poškodí) cache DNS serveru tak, že začne poskytovat nekorektní překlady pro doménu na kterou útočník útočí. V praxi tedy útočníkovi stačí požádat caching server o načtení své "útočné" domény (např. hax0r.net), která pozmění data (IP adresu daného serveru) pro doménu na kterou útočí (např. internetbanking.com) a která jsou dále poskytovaná ostatním uživatelům. V konečném důsledku pak stačí, aby na IP adrese, na kterou nyní ukazuje upravený záznam www.internetbanking.com, běžela upravená kopie téhož webu, která bude odchytávat hesla a následně jen uživateli sdělí, že heslo není platné (nebo v lepším případě vystaví spojení na původní server s tím, že budou logovány veškeré úkony a transakce). Jak je vidět, jedná se o velmi nebezpečnou záležitost. Obrana proti tomuto je dvojí: používat pouze bezpečné DNS servery a pokud možno zabezpečenou komunikaci pomocí SSL, ideálně podepsanou certifikátem vydaným spolehlivou certifikační autoritou - samozřejmě je nutno sledovat, zda certifikát je stále tentýž a zda se "náhodou" nezměnil. Výše popsaný útok je znám již hodně dlouhou dobu. Jeho nebezpečnost byla velmi nízká, díky tomu, že k útoku bylo potřeba se "trefit" do DNS serveru. Nicméně právě poslední bezpečnostní hrozba kombinuje tento útok s jinými dvěma bezpečnostními děrami, a to malé náhodnosti zdrojových portů DNS serveru a malé náhodnosti transakčních ID. V kombinaci je to již velmi nebezpečná záležitost, a proto se doporučuje, v případě, že používáte takto nezabezpečený server, upgradovat tento server, nebo přejít na jiný.

7. Závěr

Doufám, že tato série článků pomohla nebo pomůže těm, kdo řeší problémy s připojením k síti. V posledním díle jsem se také snažil upozornit na aktuální bezpečnostní problém, a způsob, jak jej alespoň částečně vyřešit. Nad dalšími články na shledanou...

Předešlé díly:

Diagnostika a řešení problémů s routingem (II.)
Diagnostika a řešení problémů s TCP/IP stackem (I.)