Analýza DNS programem dig
Program dig je nástroj pro ruční kladení otázek DNS serverům. Může dobře posloužit pro zjištění chyb, ale i k prostému nahlédnutí „pod pokličku“ DNS. V distribuci Fedora a Red Hat Enterprise Linux ho najdete v balíčku bind-utils. Program dig je nástupcem programu nslookup (který není již dále vyvíjen a nejsou v něm ani opravovány známé chyby).
Tučně psaný text v příkladech vkládá uživatel, výzva systému (shell) je zde vidět jako znak dolar ($). Ostatní text je výstup programu tak, jak ho uživatel mohl vidět.
Převod jména na IP adresu
Při převodu jména na IP adresu zadáme požadované DNS jméno programu dig jako parametr:
$ dig ftp.abdita.cz
; <<>> DiG 9.2.1 <<>> ftp.abdita.cz
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18216
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 2
;; QUESTION SECTION:
;ftp.abdita.cz. IN A
;; ANSWER SECTION:
ftp.abdita.cz. 86400 IN CNAME neptun.abdita.cz.
neptun.abdita.cz. 86400 IN A 195.113.159.1
;; AUTHORITY SECTION:
abdita.cz. 86400 IN NS neptun.abdita.cz.
abdita.cz. 86400 IN NS semiramis.asabdita.cz.
abdita.cz. 86400 IN NS ns.ces.net.
;; ADDITIONAL SECTION:
ns.ces.net. 82485 IN A 195.113.144.233
semiramis.asabdita.cz. 83745 IN A 195.113.167.1
;; Query time: 2 msec
;; SERVER: 195.113.159.1#53(195.113.159.1)
;; WHEN: Thu Oct 10 14:43:16 2002
;; MSG SIZE rcvd: 167
V příkladu je vidět, že odpověď byla autoritativní (tj. pochází od primárního nebo od sekundárního serveru domény, na kterou se ptáme). Autoritativní odpověď je indikována příznakem (flag) aa na 5. řádku výstupu. To znamená, že DNS server má danou informaci uvedenou v definici domény na svém pevném disku. Pokud bychom se ptali na jiné jméno, server by poskytl neautoritativní odpověď, protože informaci získá někde jinde. Neautoritativní odpovědi jsou uchovávány v cache (v paměti) DNS serveru, který odpověď získal. Informace je uložena v cache jen tak dlouho, jak to dovolí správce dané domény. Zbývající čas je pak uveden před klíčovým slovem IN (zde je z důvodu autoritativní odpovědi trvale hodnota 86400).
Dále výstup obsahuje sekci s odpovědí (ANSWER SECTION). Z výstupu je vidět, že ftp.abdita.cz není vlastní jméno počítače, ale že je to je přezdívka (CNAME). Tato přezdívka ukazuje na reálné jméno počítače (zde neptun.abdita.cz). Na dalším řádku je pak uveden A záznam pro tento počítač (tj. jeho IP adresa).
Sekce AUTHORITY SECTION ukazuje seznam DNS serverů, které jsou autoritativní pro tuto doménu (tj. jeden z nich bude zřejmě primární a ostatní budou sekundární). Sekundární i primární DNS servery poskytují rovnocenné odpovědi a z hlediska uživatele mezi nimi není rozdíl. Z hlediska jejich správce je primární server nositelem databáze (dělají se zde tedy změny v definici domény) a sekundární servery jsou záložní. Sekundární servery si kopírují definici domény z primárního DNS serveru automaticky pomocí příkazu AXFR (jak bude uvedeno dále).
Poslední sekcí výstupu je ADDITIONAL SECTION. Zde jsou uvedeny upřesňující informace, zde konkrétně IP adresy DNS serverů. Můžete si povšimnout, že zbývající doba trvanlivosti informace uložené v cache DNS serveru je nižší. Při opakování dotazu je pak vidět, jak dále klesá.
Hodnoty FLAG:
- QR – příznak, zda se jedná o zprávu s dotazem či odpovědí
- OPCODE – označení typu dotazu
- AA (Authoritative Answer) – pokud je tento příznak nastaven, znamená to, že server, který nám odpověď poslal, je autoritativní pro název, na který se ptáme. Jinak řečeno to znamená, že data v části answer nepochází z cache a ani z rekurzivního dotazu, ale jedná se o aktuální data přímo ze zónového souboru a odpověď nebyla zprostředkována žádným cachovacím DNS serverem.
- TC (Truncation) – příznak signalizující zkrácení odpovědi, která je delší než 512 bytů a nemohla být celá poslána v jednom UDP paketu
- RD (Recursion Desired) – tento příznak nastaví tazatel v případě, že si od serveru přeje podle potřeby provést rekurzivní zpracování dotazu. Server může rekurzivní dotaz odmítnout, ale v odpovědi posílá stejné nastavení tohoto příznaku.
- RA (Recursion Available) – tento příznak nastaví server v případě, že tazateli nabízí rekurzivní dotazy. Pokud server tuto službu tazateli umožňuje, posílá příznak RA ve všech odpovědí jako oznámení o dostupných možnostech, nejedná se pouze o reakci na příznak RD v dotazu.
Převod IP adresy na jméno
Pro zpětný převod je potřeba použít parametr -x. Tento parametr zajistí automatický přepis IP adresy do reverzního zápisu v doméně in-addr.arpa. Všimněte si, že odpověď už není autoritativní (chybí příznak aa, který byl vidět v předchozím příkladu).
$ dig -x 147.230.16.8
; <<>> DiG 9.2.1 <<>> -x 147.230.16.8
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14640
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;8.16.230.147.in-addr.arpa. IN PTR
;; ANSWER SECTION:
8.16.230.147.in-addr.arpa. 86400 IN PTR obelix.tul.cz.
;; AUTHORITY SECTION:
230.147.in-addr.arpa. 86400 IN NS ns.ces.net.
230.147.in-addr.arpa. 86400 IN NS bubo.tul.cz.
;; ADDITIONAL SECTION:
ns.ces.net. 79871 IN A 195.113.144.233
bubo.tul.cz. 86229 IN A 147.230.16.1
;; Query time: 5 msec
;; SERVER: 195.113.159.1#53(195.113.159.1)
;; WHEN: Thu Oct 10 15:26:50 2002
;; MSG SIZE rcvd: 147
Zjištění MX záznamů
MX záznamy slouží pro směrování elektronické pošty. Obsahují číslo, které slouží k určení priority. Čím nižší, tím má příslušný záznam vyšší prioritu a naopak. Při doručování pošty je z elektronické adresy vzata část za zavináčem a nejprve se ji program doručující poštu (MTA – Mail Transfer Agent) pokusí přeložit na IP adresu (nejstarší varianta směrování pošty). Pokud to nelze nebo daná IP adresa není schopna poštu přijmout, zkouší se pošta doručit na MX záznamy nižší prioritou.
Následující výpis je zkrácen tak, aby obsahoval jen vlastní odpověď.
$ dig abdita.cz mx
…
;; ANSWER SECTION:
abdita.cz. 86400 IN MX 20 ns.blucina.net.
abdita.cz. 86400 IN MX 40 rs.cesnet.cz.
abdita.cz. 86400 IN MX 10 ns.abdita.cz.
Zjištění NS, SOA a případně dalších záznamů
Podobně jako u MX záznamů lze požádat i o další záznamy v DNS, například NS (seznam DNS serverů), SOA (Start Of Authority, resp. definiční část domény se sériovým číslem a předepsanými implicitními intervaly) a podobně:
$ dig abdita.cz ns
…
;; ANSWER SECTION:
abdita.cz. 86400 IN NS ns.ces.net.
abdita.cz. 86400 IN NS neptun.abdita.cz.
abdita.cz. 86400 IN NS semiramis.xserver.cz.
$ dig abdita.cz soa
…
;; ANSWER SECTION:
abdita.cz. 86400 IN SOA ns.abdita.cz. hostmaster.abdita.cz. 2004081800 28800 7200 1814400 86400
SOA záznam obsahuje postupně tyto údaje:
- jméno primárního NS serveru (nemá funkční význam, takže tam může být v podstatě cokoliv, zde ns.abdita.cz)
- elektronickou adresu správce domény, přičemž znak zavináč je nahrazen tečkou (zde hostmaster@abdita.cz)
- serial – sériové číslo zónového souboru, podle kterého sekundární NS servery usuzují, zda je potřeba přenést novější zónový soubor z primárního NS serveru, obvykle je to datum plus sériové číslo, ale v podstatě musí být při každé změně číslo pouze zvětšeno (zde 2004081800)
- refresh – doba, za kterou by sekundární server měl zkontrolovat, zda primár neobsahuje novější informace (zde 28800 vteřin, tj. 8 hodin)
- retry – po jaké době by měl sekundární server opakovat pokus o stažení zóny v případě neúspěchu (zde 7200 vteřin, tj. 2 hodiny)
- expire – po jakou dobu je oprávněn poskytovat sekundár autoritativní odpovědi bez toho, aby se mu podařilo spojit s primárním NS serverem (zde 1814400 vteřin, tj. 4 týdny)
- minimum TTL – implicitní trvanlivost záznamů v cache, přičemž pro každý záznam je možné v zónovém souboru uvést specifickou hodnotu (zde 86400 vteřin, tj. 1 den)
Přenos zóny (AXFR)
Pokud je přenos zóny povolen, lze o něj požádat primární nebo sekundární DNS server domény. Z toho vyplývá, že nejprve zjistíme NS servery domény a pak se jich pokusíme zeptat. Z výpisu NS serverů nepoznáme, který server je primární a který sekundární, nicméně oba poskytují autoritativní odpovědi (označené flagem aa). S jistou rezervou lze brát jako nápovědu jméno serveru uvedené v SOA záznamu domény, protože na toto místo většinou administrátor domény píše právě název primárního NS serveru.
$ dig abdita.cz ns
$ dig @neptun.abdita.cz abdita.cz axfr
; <<>> DiG 9.2.2 <<>> @neptun.abdita.cz abdita.cz axfr
;; global options: printcmd
abdita.cz. 86400 IN SOA neptun.abdita.cz. hostmaster.abdita.cz. 2004081800 28800 7200 1814400 86400
abdita.cz. 86400 IN NS ns.ces.net.
abdita.cz. 86400 IN NS neptun.abdita.cz.
abdita.cz. 86400 IN NS semiramis.xserver.cz.
abdita.cz. 86400 IN MX 10 opteron.abdita.cz.
abdita.cz. 86400 IN MX 20 neptun.abdita.cz.
abdita.cz. 86400 IN MX 30 semiramis.xserver.cz.
abdita.cz. 86400 IN MX 40 rs.cesnet.cz.
abdita.cz. 86400 IN A 195.113.159.10
pluto.abdita.cz. 86400 IN A 195.113.159.169
…
Kontroly DNS
Kontrola správnosti NS záznamů
Domény jsou organizovány jako stromová struktura shora dolů. Zakládáme-li tedy doménu, musíme u nadřízené domény požádat o definici včetně příslušných NS serverů. Protože jsou NS servery uvedené i ve vlastním zónovém souboru domény (jak je vidět v předchozím výpisu), vzniká zde prostor pro nekonzistence. Ve správném případě by tedy měl být seznam NS serverů nadřízené domény shodný se seznamem NS serverů uvedeným v příslušné doméně. Pokud bychom chtěli provést kontrolu pro doménu abdita.cz, vypadal by postup zhruba takto:
$ dig cz ns
…
;; ANSWER SECTION:
cz. 18000 IN NS ns.tld.cz.
cz. 18000 IN NS ns.ripe.net.
cz. 18000 IN NS ns2.nic.fr.
cz. 18000 IN NS nss.tld.cz.
cz. 18000 IN NS sunic.sunet.se.
cz. 18000 IN NS ns-ext.vix.com.
$ dig @ns.tld.cz. abdita.cz ns
…
;; AUTHORITY SECTION:
abdita.cz. 18000 IN NS neptun.abdita.cz.
abdita.cz. 18000 IN NS semiramis.asabdita.cz.
abdita.cz. 18000 IN NS ns.ces.net.
$ dig @neptun.abdita.cz. abdita.cz ns
…
;; ANSWER SECTION:
abdita.cz. 86400 IN NS semiramis.xserver.cz.
abdita.cz. 86400 IN NS ns.ces.net.
abdita.cz. 86400 IN NS neptun.abdita.cz.
Jak je vidět, záznamy jsou v pořádku. Současně bychom měli zkontrolovat, zda všechny uvedené NS servery poskytují autoritativní odpovědi (tj. jestli na nich jsou skutečně umístěny zónové soubory, resp. jestli jsou opravdu buď primárním nebo sekundárním serverem dané domény).
Kontrola DNS záznamů
Při běžném postupu můžeme přeskočit kontrolu toplevel domény a přikročit přímo ke zjištění NS serverů domény abdita.cz (viz dále). Pokud je něco špatně, neměli bychom vynechat ani tento první krok. Zjistíme si tedy, jaký server je zřejmě dané toplevel zóně primární (zde česká doména .cz):
$ dig cz. soa
…
;; ANSWER SECTION:
cz. 780 IN SOA a.ns.nic.cz. hostmaster.nic.cz. 1255876469 900 300 604800 900
Zde je vidět, že primárním serverem toplevel domény cz je zřejmě a.ns.nic.cz.. Mohli bychom se také zeptat na běžné NS servery zóny cz, protože správně by všechny měly obsahovat stejné informace:
$ dig cz. ns
…
;; ANSWER SECTION:
cz. 11334 IN NS C.NS.NIC.cz.
cz. 11334 IN NS D.NS.NIC.cz.
cz. 11334 IN NS E.NS.NIC.cz.
cz. 11334 IN NS B.NS.NIC.cz.
cz. 11334 IN NS F.NS.NIC.cz.
cz. 11334 IN NS A.NS.NIC.cz.
Z výše uvedeného výpisu je zřejmé, že jeden z uvedených NS serverů je primární a zbylé sekundární. Z vnějšku je není možné rozlišit (maximálně pomocí informativní položky v SOA záznamu) a všechny poskytují autoritativní odpovědi. Dále zjistíme NS servery dané domény (mohli bychom použít i přímý dotaz na zvolený NS server, například dig @a.ns.nic.cz. abdita.cz ns a porovnat pak jednotlivé odpovědi):
$ dig abdita.cz ns
…
;; ANSWER SECTION:
abdita.cz. 18000 IN NS neptun.abdita.cz.
abdita.cz. 18000 IN NS semiramis.asabdita.cz.
abdita.cz. 18000 IN NS ns.ces.net.
Jeden z uvedených serverů je primární, ostatní jsou sekundární. Sekundární servery si periodicky synchronizují obsah zóny podle primárního NS serveru. Může se tedy stát, že sekundární servery budou obsahovat starší informace, což by mělo být zřejmé podle sériového čísla uvedeného v SOA záznamu domény. V ideální případě musí být sériová čísla stejná. Pokud nejsou, je nutné vyčkat až proběhne synchronizace sekundárních serverů s primárním serverem. Při výpisu SOA záznamu je možné orientačně zjistit, který server je označen za primární, avšak je nutné si uvědomit, že tato informace má pouze informativní charakter (důležitá je vlastní konfigurace DNS serveru, kterou z vnějšku však nelze zjistit). Zjistíme tedy SOA záznam domény abdita.cz:
$ dig abdita.cz soa
…
;; ANSWER SECTION:
abdita.cz. 86400 IN SOA neptun.abdita.cz. hostmaster.abdita.cz. 2009076006 28800 7200 1814400 86400
Ve výše uvedeném výstupu je zřejmé, že sériové číslo zóny abdita.cz je 2009076006 (zde ve formě datumu a dvojciferného rozlišení). Primárním serverem je zřejmě neptun.abdita.cz (avšak tato informace nemusí být pravdivá, jak bylo uvedeno výše). Pomocí konkrétních dotazů můžeme zjistit stav jednotlivých serverů (jejich SOA záznamy), protože pokud je záznam již v cache lokálního serveru, nebude po celou dobu své platnosti aktualizován. Níže jsou uvedeny tři dotazy na všechny tři NS servery domény abdita.cz:
$ dig @neptun.abdita.cz abdita.cz soa
$ dig @semiramis.asabdita.cz abdita.cz soa
$ dig @ns.ces.net abdita.cz soa
Podle stavu SOA záznamů jednotlivých DNS serverů si můžeme vytvořit představu o aktuálním stavu jejich konzistence. Pak lze kontrolovat jednotlivé záznamy, zkusit přenést celou zónu a podobně:
$ dig @neptun.abdita.cz. www.abdita.cz
…
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 2
…
;; ANSWER SECTION:
www.abdita.cz. 86400 IN CNAME opteron.abdita.cz.
opteron.abdita.cz. 86400 IN A 195.113.159.18
Výše uvedený výstup je autoritativní (nepochází z cache), což indikuje flag aa ve výstupu (anglicky authoritative answer). Pokud bychom se zeptali lokálního DNS serveru (je dán konfigurací počítače, na kterém pracujeme), získáme pravděpodobně odpověď z cache, přičemž lze získat i informaci o tom, jak dlouho bude ještě záznam v cache platný:
$ dig www.abdita.cz
…
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1
…
;; ANSWER SECTION:
www.abdita.cz. 85422 IN CNAME opteron.abdita.cz.
opteron.abdita.cz. 76004 IN A 195.113.159.18
Ve výše uvedeném výpisu je zřejmé, že jde o výpis z cache (chybí flag aa). Záznam CNAME pak bude platný ještě 85422 vteřin (necelý 1 den) a záznam A pak ještě 76004 vteřin (asi 21 hodin).
Kontrola reverzního záznamu
Ke každému A záznamu by měl být v pořádku příslušný reverzní záznam, který by měl odpovídat stejnému jménu, jako má A záznam. Zkusíme tedy převést výše zjištěnou IP adresu 195.113.159.18 na jméno:
$ dig -x 195.13.15.18
…
;; ANSWER SECTION:
18.15.13.195.in-addr.arpa. 86400 IN PTR opteron.abdita.cz.
Odkazy:
http://www.dns-info.cz/dns/index.html
