Prvotní kořeny lze najít již v dobách ARPAnetu. V počítačových sítích jsou počítače typicky rozpoznatelné dle IP adresy, popřípadě MAC adresy, ale tu budeme pro naše potřeby ignorovat. Máme-li před sebou nějakou počítačovou síť, řekněme s 20 počítači, přičemž každý počítač má přidělenu nějakou IP adresu, existuje reálná šance, že administrátor si bude topologii sítě nějakým způsobem pamatovat, toto tvrzení již ale zcela určitě nebude platit pro uživatele dané sítě.
Vzniká tedy myšlenka o pojmenovávání počítačů nějakými znakovými řetězci, které bychom dokázali na úrovni opračního systému převádět na IP adresy, a to nejlépe tak, aby o tom uživatel mnoho nemusel vědět.
Vzniká myšlenka souboru hosts (na UNIX-like systémech se obvykle nachází v adresáři /etc). V takovém souboru jsou uvedeny na jednom řádku IP adresa a k ní příslušná jména, resp. doménová jména daného počítače.
Doménová jména je termín, kterým označujeme názvy počítačů, uvedené např. v souboru hosts. Takové doménové jméno by mělo jednoznačně reprezentovat daný počítač (hovoříme o tzv. plně kvalifikovaném doménovém jménu). Obvykle se skládá z uzlů (v ukázce níže je to např. smb, organizace nebo cz) a oddělovače (tečka). Doménová jména představují stromovou strukturu. Počet teček v doménovém jméně označuje řád domény. Např. doména cz je doména prvého řádu, organizace.cz je doména druhého řádu, atd.
Jednoduchý soubor /etc/hosts může vypadat napříkad takto:
127.0.0.1 localhost
192.168.1.1 zeus.organizace.cz nfs.organizace.cz smb.organizace.cz
192.168.1.2 hera.organizace.cz backup.organizace.cz
...
Pozn: doménová jména nfs.organizace.cz a smb.organizace.cz by v dobách ARPAnetu nejspíše nikdo nechápal ;).
Pozn2: doménová jména v plně kvalifikovaném tvaru by se správně měla ukončovat tečkou, aby bylo patrné, že za ně již nepatří žádné doplnění, např. erigona.fi.muni.cz.
Takový soubor /etc/hosts bylo již jen potřeba rozkopírovávat na všechny počítače v sítí a bylo vyhráno. Nevýhoda takového systému je nejspíše zřejmá - je nutné distribuovat soubor hosts na všechny počítače v síti.
Z tohoto důvodu byl p. Paulem Mockapetrisem v roce 1983 definován pojem Domain Name System (tento člověk mimo jiné definoval i pojem doménová jména), konkrétně se tak stalo v RFC 882 a 883.
Princip DNS je jednoduchý, pro každý uzel (pokud se nejedná o koncový počítač) bude existovat vlastní DNS server, který bude obsahovat informace o IP adresách všech uzlů, které se nachází přímo pod tímto uzlem (na vrchu by tedy stála doména cz, která by obsahovala informace o umístění serverů pro doménu organizace.cz, atd.) - tento princip se tedy drží stromové struktury doménových jmen. Do specifikace byly přidány i další informace, které by měl DNS server uchovávat (např. seznam doménových serverů pro danou doménu, seznam emailových serverů pro danou doménu, emailovou adresu správce dané domény, aj.).
Princip stromové struktury dává administrátorům jednotlivých domén poměrně velikou flexibilitu, protože změny, které provedou v konfiguraci své domény, se automaticky projeví ve vyšších úrovních a není tedy třeba nic konfigurovat vícekrát. Postupem času se standardizovaly i situace, kdy jeden DNS server uchovává informace o více doménách.
Ještě bych rád zmínil, jakým způsobem probíhá dohledávání IP adresy počítače, v případě, že na DNS server dorazí požadavek. V principu mohou nastat 3 situace:
V rámci DNS protokolu je definováno několik typů záznamů, které servery udržují
Samotné DNS servery je možné rozdělit do tří skupin:
Klientu DNS serveru se říká resolver. Na UNIX-like systémech se k jeho konfiguraci používá soubor /etc/resolv.conf. V tomto souboru jsou uloženy informace ve formě 1 záznam na řádek, kde jeden záznam obsahuje typicky text typu nameserver IPadresa, nebo domain doména, nebo search doména. Řádek s textem nameserver určuje doménový server, který se má použít pro dohledání IP adresy k doménovému jméno, těchto řádků zde může být typicky více, maximálně však 3. Řádek s textem domain obsahuje název domény (používá se zde plně kvalifikované jméno), ke které je připojen daný počítač. Pokud je pro vyhledání IP adresy zadána pouze část plně kvalifikovaného doménového jména (např. smb, nebo nfs), je tento text automaticky připojen k takovému doménovému jménu. Řádek s textem search funguje obdobně, jen umožňuje zvolit více domén na dohledání (jsou odděleny mezerou).
V dnešní době se jako dns server majoritně využívá software s názvem BIND. Tento software existuje již poměrně dlouhou dobu a je tedy velmi stabilní a bezpečný, nicméně mnoho správců počítačových systémů vidí problém v tom, že tento server implicitně běží s oprávněním uživatele root, došlo-li by tedy k prolomení této služby, mohlo by dojít k ohrožení serveru. Na adrese http://www.linuxsecurity.com/docs/LDP/Chroot-BIND-HOWTO.html je velmi pěkně popsáno, jak lze docílit pomocí nástroje chroot, aby se nebylo možné v případě prolomení ochrany BINDu, dostat jinam, než do předem definovaného adresáře a napáchat tedy minimální škodu. Nebudu zde opisovat většinu článku a proto jen uvedu základní myšlenku, kterou docilujeme pomocí chroot.
Naším cílem je vytvoření pseudosystému, který se pro všechny aplikace, které nad ním budou spuštěné, bude tvářit, jakoby se jednalo o kořenový adresář nějakého souborového systému, kde má uživatel, jež spustil danou aplikaci, práva uživatele root. Dosahujeme toho tím, že vytvoříme nějaký adrešář ve kterém vytvoříme standardní UNIX-like adresářovou strukturu kořenového adresáře (adresář /dev, /var, /etc, ...). Do tohoto adresáře rozbalíme aplikaci, kterou budeme chtít uzamknout v takovém prostředí a pak už jen stačí pustit chroot a jako parametr mu dát cestu k našemu pseudokořenu a cestu k spouštěcímu souboru aplikace.
Nastavení BIND serveru probíhá pomocí souboru /etc/named.conf. Minimální soubor pro naši doménu organizace.cz by mohl vypadat například takto:
options {
allow-query { any; };
//forward first;
//forwarders {
// IPADRESADNS;
//};
};
zone "organizace.cz" {
type master;
notify no;
file "/etc/named/organizace.cz";
};
zone "1.168.192.in-addr.arpa" {
type master;
notify no;
file "/etc/named/1.168.192.in-addr.arpa";
};
Takovým souborem nakonfigurujeme DNS server, aby přijímal požadavky ode všech počítačů. 3 řádky zakomentované pomocí dvou lomítek, řeší forwardování neznámých požadavků na jiné jmenné servery. Vytvořili jsme zónu pro doménu organizace.cz a také reverzní zónu 1.168.192.in-addr.arpa. Rozdíl mezi těmito dvěma typy zón je ten, že organizace.cz bude mapovat doménová jména na IP adresy, zóna 1.168.192.in-addr.arpa bude dělat opačnou práci (používáme termín reverzní zóna). Pro obě zóny je nastaven BIND jako primární DNS server a také jsme parametrem notify no ustanovili, že pokud by naše doména měla nějaké sekundární DNS servery, nebudeme je informovat o změnách v konfiguraci. Také má každá zóna uveden konfigurační soubor, na něž se podívámě podrobnějí v následujícím textu.
Nejprve tedy k organizace.cz:
$TTL 3D
@ IN SOA ns1.organizace.cz. root.organizace.cz. (
200800001 ; seriové čislo
8H ; za jak dlouho se má sek. DNS server ptát na změny
2H ; jak dlouho ma sek. DNS server počkat, než pošle znovu dotaz na prim. DNS server, který mu neodpovídá
4W ; pokud sek. DNS server nedostane odpověď od prim. DNS serveru do této doby, přestane se prohlašovat za autoritativní server domény
3D) ; na jakou minimální dobu by měly být záznamy cachovány
NS ns1.organizace.cz. ; určení DNS serveru
; NS ns2.organizace.cz případný druhý server
; MX 10 mx1.organizace.cz - určuje emailový server
organizace.cz A 192.168.1.1
zeus A 192.168.1.1
ns1 A 192.168.1.1
hera A 192.168.1.2
nfs CNAME zeus
smb CNAME zeus
backup CNAME hera
Tato zóna popisuje doménu organizace.cz. Hodnota TTL udává, jak dlouho bude aktivní tato konfigurace, po uplynutí této doby, je sekundární server povinen si znovu vyžádat konfiguraci. Dle seriového čísla je možné poznat, že došlo ke změně konfigurace, dojde-li sekundárnímu serveru konfigurace domény, která má stejné ser. číslo, jako konfigurace, kterou právě používá, není povinen konfiguraci nijak měnit, je tedy důležité při každé změně konfigurace navýšit tuto hodnotu. V tomto případě jsem zakomentoval pomocí středníku řádek, definující e-mailový server, v původním hosts souboru jej neuvádím, ale v konfiguraci domény je to poměrně důležitý paremtr, proto bych jej rád popsal. Číslo, umístěné mezi MX a doménovým jménem emailového serveru je priorita, čím je číslo niší, tím má emailový server prioritu vyšší. Lze zadat více emailových serverů pomocí více řádků definujících MX záznam, jen je potřeba rozvrhnout priority, nemělo by dojít k tomu, že 2 emailové servery mají stejnou. Důležité také je, že NS záznam se musí odkazovat na doménové jméno, které je definováno jako A záznam, nikoliv jako CNAME.
Nyní přistoupíme k 1.168.192.in-addr.arpa
$TTL 3D
@ IN SOA ns1.organizace.cz. root.organizace.cz. (
200800001
8H
2H
4W
3D)
NS ns1.organizace.cz
1 zeus
2 hera
Soubor s reverzními záznamy je velmi podobný souboru s jmennými záznamy. Neuvádí se zde emailový server a neuvádí se žádné CNAME záznamy, pouze A záznamy.
Na závěr bych rád doporučil některé aplikace, které lze použít na otestování vámi vytvořených domén