Současný Internet je veskrze postaven na bázi protokolové sady TCP/IP, která používá k jednoznačné identifikaci vzájemně komunikujících uzlů v síti IP adresu. Pro člověka jako uživatele je však snažší označovat počítače jménem a ne téměř nic neříkajícím 32 bitovým číslem nazývaným právě IP adresa (resp. 128 bitovým číslem, pokud uvažujeme protokol IPv6). Vznikl tedy systém DNS neboli Domain Name System, který nedokonalost lidského druhu elegantně obchází a který řeší i další, na první pohled ne zcela zřejmé, problémy související s překladem jmen na IP adresy a opačně.
První experimentální počítačová síť ARPANET vznikla koncem
šedesátých let jako výzkumný projekt pod záštitou amerického úřadu
DARPA (Defense Advanced Research Projects
Agency) a propojovala důležité výzkumné organizace Spojených Států.
V rámci tohoto projektu vznikla sada protokolů TCP/IP,
která se záhy stala uznávaným standardem, a znamenala skutečný průlom v
oblasti síťových technologií, neboť vedla ke vzniku dnešního
Internetu.
A jak s tím souvisí systém DNS? Ano, již v době sítě
ARPANET bylo zapotřebí překládat jména na IP adresy, jenže tehdy k
tomu stačil jediný soubor. Jmenoval se HOSTS.TXT (dnes mu na Unixech
odpovídá soubor /etc/hosts) a obsahoval tabulku hostitelů a
příslušných IP adres. Obsah souboru spravovala organizace SRI's
Network Information Center, která jej
distribuovala po síti a to z jediného počítače! Jmenoval se SRI-NIC.
A začaly vznikat problémy, na scénu totiž přišel TCP/IP a s ním i
masívní rozšíření sítí za hranice malinkatého ARPANETu (tehdy několik
stovek stanic). Zátěž na SRI-NIC tak začala být neúnosná a databázi
hostitelů bylo stále obtížnější udržet v konzistentním stavu
(duplicitní jména, rychlý růst sítě).
Pánové, jež se zasloužili o vznik ARPANETu, se však nevzdávali a pracovali
dál. Z jejich společného úsilí vzešel nový a lepší systém, který
řešil překlad jmen distribuovaně a ne centrálně jako v předešlém
případě. Podporoval lokální správu dat, což rozložilo zátěž po celé
síti a jména hostitelů byla uspořádána hierarchicky, což zamezilo
vzniku duplicitních jmen. Vznikl tak systém DNS.
Systém DNS je celosvětově distribuovanou databází uchovávající
záznamy o tom, která IP adresa patří ke kterému doménovému jménu, přitom IP adresa může mít doménových
jmen i více. O databázi se starají programy zvané jmenné
servery, které data z datábaze poskytují klientům, tzv.
resolverům.
Jmenný prostor všech domén je uspořádán
do hierarchické struktury podobné struktuře souborového systému
na UNIXu. Databázi si lze představit jako strom s
kořenovým uzlem, tzv. kořenová doména, která obsahuje všechny domény,
na vrcholu, kde každý uzel má přiděleno nějaké jméno, tzv. doménu.
Doménové jméno uzlu je seznam všech domén ležících
na cestě mezi výchozím uzlem a uzlem kořenovým zapsaných zprava doleva
v tečkové notaci. Doménové jméno tedy odráží příslušnost uzlu do
určité domény, subdomény atd.
|
Doména je skupina jmen, které spolu logicky souvisejí např. tak, že mají společnou geografickou polohu, společnou přislušnost k nějaké organizaci nebo vytvářejí jistou síť. Domény lze dále členit na menší celky, tzv. subdomény.
V některých případech požadujeme po systému DNS tzv. zpětný překlad tzn. překlad IP adresy na reverzní doménu (doménové jméno). Pro tyto účely byla definována doména in-addr.arpa (v případě protokolu IPv6 ip6.arpa), která má subdomény 0 až 255. Domény jsou tvořeny IP adresami psanými v opačném pořadí. Např. síť 196.168.192.0/24 patří do domény 192.168.196.in-addr.arpa.
Doménové jméno vznikne spojením příslušných řetězců (domén) vzájemně
oddělených tečkou, kde první řetězec je jméno počítače, druhý jméno
domény, do níž počítač náleží atd. Takové jméno se pak čte zprava doleva. Celé
jméno může být maximálně 255 znaků dlouhé, řetězec 63 znaků a může
obsahovat pouze číslice, písmena a pomlčky (pomlčky nesmí být na
začátku ani na konci řetězce). Např. uzel se jménem
aisa.fi.muni.cz. je počítač se jménem aisa ležící v subdoméně fi
subdomény muni domény cz kořenové domény (.). Poslední
tečka na konci se uvádí z důvodu jednoznačného určení jména a
představuje kořenovou doménu (může se téměř vždy vynechat). Takové
doménové jméno se pak nazývá plně kvalifikované (FQDN, Fully
Qualified Domain Name).
V kořenové doméně jsou definovány tzv. generické domény (TLD,
Top Level Domains), např. org, com, edu, net,
arpa, a dále dvouznakové domény jednotlivých států, např. cz pro
Českou republiku.
Správa domény může být z hlediska jejího rozsahu velice náročná. Jelikož systém DNS člení domény na menší celky, tzv. subdomény, je možné pověřit správou subdomény jiného správce. Hovoříme o tzv. delegaci domény. Zóna je pak část prostoru jmen domény, kterou obhospodařuje konkrétní správce. Je tedy tvořena doménou nebo její částí.
Resolver je část systému, která dokáže nalézt IP adresu k
příslušnému jménu a naopak. Je většinou implementován jako
soubor knihovních funkcí, který se slinkuje s aplikací požadující tyto
služby. Aplikace pak volá příslušné procedury, jako jsou
např. gethostbyname(3) nebo gethostbyaddr(3), resolver zformuluje a pošle
jmennému serveru dotaz a čeká na konečnou odpověď, kterou pak předá aplikaci.
Pozn.: Knihovna resolveru je součástí standardní knihovny
jazyka C.
Jmenný server je právě zmiňovaný správce, který dohlíží na data definující příslušnou zónu a zajišťuje překlad jmen počítačů na IP adresy a naopak na žádost resolveru nebo jiného jmenného serveru.
Podle uložení dat rozlišujeme následující typy jmenných serverů:
Resolver je klientem systému DNS a zastupuje aplikaci požadující
služby DNS. Resolver tak zformuluje dotaz, pošle jej místnímu jmennému serveru
a očekává jeho odpověď. Zná-li náš server na příslušný dotaz odpověď
(odpověď hledá ve svých autoritativních datech nebo v neautoritativních
datech, které si uložil do vyrovnávací paměti z předchozích dotazů),
zašle ji nazpět. Pokud ji nezná, kontaktuje další servery, přitom vždy
začíná kořenovým jmenným serverem. Uvažujme např. dotaz na jméno
aisa.fi.muni.cz. Kořenový jmenný server zjistí, že správou domény cz
pověřil jiný server, pošle tedy našemu serveru IP adresu tohoto
serveru. Náš server se obrátí na server domény cz a ten pošle adresu
serveru domény muni.cz. Proces iterace pokračuje tak dlouho, dokud
náš server nedostane IP adresu stroje aisa.fi.muni.cz (za předpokladu, že
příslušné jmenné servery jsou funkční). Získané informace náš server ukládá do
vyrovnávací paměti pro případ, že by se dotazy mohly opakovat.
Protokol DNS je aplikační protokol využívající k transportu dat protokol UDP a TCP. K jednodušším dotazům, jako je překlad adres, se používá UDP. Pro odpovědi se používá UDP, ale pouze pokud je odpověď kratší než 512B. V opačném případě se použije pro přenos TCP. Protokol TCP se také používá pro přenos zón mezi primárním a sekundárním jmenným serverem. Jmenný server naslouchá dotazům na portu 53 (UDP i TCP).
Autoritativní data zóny jsou uloženy v databázi ve formě
tzv. zdrojových záznamů (RR, Resource Records). Každý
záznam má přidělen typ, který popisuje druh dat v záznamu, a dále třídu, která
vyjadřuje adresovací schéma sítě např. IP adresám odpovídá třída IN,
adresám sítí Hesiod třída HS. Záznamy RR se přenáší sítí protokolem
DNS a používají se v konfiguračních souborech systému DNS.
Mezi základní typy záznamů RR patří:
| Typ | Význam |
| SOA (Start Of Authority) | Každá zóna obsahuje právě jeden záznam SOA, viz Záznam SOA |
| A (A host address) | 32 bitová IP adresa, viz Záznam A |
| NS (Authoritative name server) | Jméno autoritativního serveru pro zónu, viz Záznam NS |
| CNAME (Canonical name for an alias) | Alias pro doménové jméno, viz Záznam CNAME |
| PTR (Domain name pointer) | Doménové jméno pro reverzní překlad, viz Záznam PTR |
| MX (Mail exchange) | Priorita a doménové jméno poštovního serveru, viz Záznam MX |
| HINFO (Host information) | Popis hardwaru a softwaru, viz Záznam HINFO a TXT |
| TXT (Text string) | Textový popis, viz Záznam HINFO a TXT |
BIND neboli Berkeley Internet Name
Domain je referenční implementací DNS serveru na Unixu, který vznikl
jako studentský projekt na Kalifornské univerzitě. Dnes je jeho vývoj
sponzorován různými organizacemi, zejména pak Internet Software Consorcium, a je portován i
na jiné operační systémy.
Součástí BINDu je:
DJBDNS (D.J.Bernstein Domain Name System) je sada DNS nástrojů, která zahrnuje:
Dents patří mezi novější implementace systému DNS. Jelikož je projekt ve stadiu alfa testování, nedoporučuje se nasazovat na produkční systémy.
Veškerá konfigurace uvedená v této části se bude týkat BINDu verze 8.x a vyšší, tzn. že se budeme konkrétně zabývat obsahem souboru /etc/named.conf. Pokusíme se nastavit knihovnu resolveru a jmenný server realizovaný programem named, probereme záludnosti zónových souborů, řekneme si něco o bezpečnosti DNS a nakonec poznáme pár užitečných nástrojů, které nám správu DNS systému určitě v mnohých ohledech ulehčí.
Základní instalace BINDu je celkem přímočará. Po stažení a rozbalení balíku vystačíme s klasickým trojhmatem:
Nastavení resolveru, který se dodává na Linuxu jako součást
standardní knihovny jazyka C GNU Libc verze 2, se opírá o konfigurační
soubor /etc/nsswitch.conf (ve starších verzích Linuxu se používal
soubor /etc/host.conf). Tento soubor resolveru říká, které služby a v
jakém pořadí má používat.
Nakonfigurujeme-li knihovnu resolveru tak,
aby k překladu jmen používala systém DNS, je ještě nutné uvést seznam
dostupných jmenných serverů do souboru /etc/resolv.conf.
Chceme-li, aby např. resolver dal přednost vyhledání adresy v databázi hostitelů /etc/hosts před systémem DNS, stačí do souboru /etc/nsswitch.conf vložit řádek:
V souboru /etc/resolv.conf lze resolveru určit, na které jmenné
servery se mají dotazy zasílat, a dále lze specifikovat jedno nebo více
místních doménových jmen.
Běh a činnost programu named lze ovlivnit konfiguračním souborem /etc/named.conf, pokud přepínačem -c neuvedeme soubor jiný (původní verze 4.x používala soubor /etc/named.boot). Při startu si program přečte obsah souboru a načte odpovídající databáze DNS z disku do vyrovnávací paměti.
Soubor /etc/named.conf obsahuje příkazy, které určují globální
chování jmenného serveru a dále definují umístění a typ zónových souborů.
Mezi základní příkazy patří:
| Příkaz | Význam |
| acl | Definuje seznam IP adres pro řízení přístupu, viz Řízení přístupu |
| include | Vkládá soubor |
| logging | Definuje události, které se mají zaznamenávat |
| options | Globální nastavení serveru |
| zone | Definice zóny |
options {
directory "/var/named"; //pracovní adresář
pid-file "named.pid";
};
zone "." {
type hint;
file "root.hints";
};
// každý jmenný server je autoritou pro
reverzní doménu 0.0.127.in-addr.arpa, tj. i chaching-only server je
primárním pro tuto doménu!!!
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.zone";
};
options {
directory "/var/named"; //pracovní adresář
pid-file "named.pid";
recursion no; // bez rekurzivních dotazů
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.zone";
};
// jmenný server je primární pro zónu xyz.cz
zone "xyz.cz" {
type master;
notify yes;
file "xyz.cz.zone";
};
// jmenný server je sekundární pro zónu abc.cz
zone "abc.cz" {
type slave;
masters { 194.149.105.18; };
file "abc.cz.zone";
};
Databáze DNS jsou na primárním jmenném serveru uloženy v zónových
souborech, které si server při startu nahraje do paměti.
Zónové soubory mohou obsahovat následující typy data:
Záznam typu SOA určuje autoritativní jmenný server pro zónu, je
vždy právě jeden a to na počátku souboru.
Příklad záznamu pro server zóny xyz.cz:
@ IN SOA ns.xyz.cz. hostmaster.xyz.cz. (
1 ; Serial
8H ; Refresh after 8 hours
2H ; Retry after 2 hours
1W ; Expire after 1 week
1D) ; Minimum TTL of 1 day
Záznam A přiřazuje doménovému jménu IP adresu.
Příklad záznamu typu A:
xyz.cz. IN SOA ns.xyz.cz. hostmaster.xyz.cz. (
...
www IN A 172.17.14.1
server.xyz.cz. IN A 10.1.1.3
...
Záznam CNAME definuje synonyma doménových jmen.
Příklad záznamu CNAME:
xyz.cz. IN SOA ns.xyz.cz. hostmaster.xyz.cz. (
...
mail IN A 192.1.1.2
www IN CNAME mail.xyz.cz.
...
Záznam NS definuje autoritativní jmenný server pro doménu.
Záznam NS je vždy ve dvou databázích:
xyz.cz. IN SOA ns.xyz.cz. hostmaster.xyz.cz. (
...
IN NS ns.xyz.cz.
abc IN NS ns.abc.xyz.cz.
ns.abc IN A 11.2.2.2.
...
Záznam PTR slouží k překladu IP adresy na doménové jméno (reverzní
překlad).
Příklad záznamu PTR:
xyz.cz. IN SOA ns.xyz.cz. hostmaster.xyz.cz. (
...
3.1.1.10.in-addr.arpa. IN PTR server.xyz.cz.
...
Záznam MX specifikuje jméno poštovního serveru. K tomuto jménu se
ještě dodává číselná priorita serveru. Nejdříve se zkouší odeslat
poštu na server s nejvyšší prioritou. Pokud se odeslání nezdaří,
zkouší se další server atd.
Příklad záznamu MX:
xyz.cz. IN SOA ns.xyz.cz. hostmaster.xyz.cz. (
...
IN MX 20 mail1.xyz.cz
IN MX 10 mail.xyz.cz
...
Bez uvedení záznamu MX by poštovní adresa uživatele vypadala
jinak než jsme zvyklí:
BIND od verze 8.x poskytuje prostředky pro omezení přístupu k DNS službám (příkaz acl v souboru /etc/named.conf). Ve verzi 9.x byly navíc ještě přidány tzv. pohledy (views, příkaz view v souboru /etc/named.conf), které umožňují nastavit jmenný server tak, že na stejný dotaz odpovídá různě podle toho, kdo se dotazuje.
Jedním ze způsobů, jak jmenný server zabezpečit, je spouštět
program named bez oprávnění superuživatele a změnit mu kořenový
adresář. Tento postup pak omezí, při zneužití nějaké bezpečnostní chyby
serveru, přístup pouze na vyhrazený kořenový adresář.
Jak tedy spustit chrootovaný BIND?
Po spuštění nakonfigurovaného jmenného serveru je vhodné si
ověřit, zda-li server pracuje tak, jak má. Z těchto důvodů je součástí BINDu
spousta užitečných nástrojů pro administraci a ladění DNS systému.
Pozn.: Každý z těchto programů má příslušnou manovou stránku,
pro další informace proto stačí zadat příkaz man jméno_programu.
Program named lze ovládat rovněž signály (programem kill), které zvládnou téměř totéž co
programy ndc a rndc.
| Signál | Význam |
| SIGHUP | Server znovu načte data z disku |
| SIGINT | Vypíše všechna data z paměti do souboru (/tmpnamed_dump.db) |
| SIGTERM | Ukončí server |