Nyní se podíváme na problémy, se kterými se můžete setkat při připojení vašeho linuxového počítače k síti, jež využívá protokol TCP/IP. Vyřešíme problémy týkající se IP adres, názvů hostitelů a některé problémy směrování. Základy, které získáte v této kapitole, se vám budou hodit při konfigurování linuxového počítače. Další kapitoly se budou zabývat nástroji, které k tomu budete potřebovat.
Aby se vyřešila rozmanitost zařízení, která mohou být používána v síťovém prostředí, definuje protokol TCP/IP abstraktní rozhraní, přes které je přistupováno k hardwaru. Toto rozhraní nabízí množinu operací, která je stejná pro všechny typy hardwaru a zabezpečuje posílání a přijímání paketů.
Každé periferní zařízení, které chcete použít v síti, musí mít v jádru operačního systému příslušné rozhraní. Například v Linuxu se rozhraní Ethernet nazývají eth0 a eth1 a rozhraní SLIP pak sl0, sl1 atd. Tyto názvy rozhraní se používají při konfiguraci, když chcete v jádru systému pojmenovat konkrétní fyzické zařízení. Jinde nemají žádný význam.
Aby bylo rozhraní použitelné v sítích na bázi TCP/IP, musí mu být přiřazena IP adresa, která slouží jako identifikace při komunikaci se zbytkem světa. Tato adresa je odlišná od názvu rozhraní, o kterém jsme mluvili výše; pokud bychom rozhraní přirovnali ke dveřím, pak adresa odpovídala štítku, který je na nich připevněn.
Samozřejmě lze nastavovat i další parametry; jedním z nich je maximální velikost datagramů, které mohou být zpracovány danou částí hardwaru. Tento parametr se také nazývá maximální přenosová jednotka (Maximal Transfer Unit), neboli MTU. Další atributy budou představeny později.
Již v předchozí kapitole jsme se zmínili o tom, že adresy, kterým rozumí síťový protokol IP, jsou 32 bitová čísla. Každému počítači musí být vzhledem k síťovému prostředí přiděleno jedinečné číslo. Pokud provozujete lokální síť, která s ostatními sítěmi nekomunikuje na bázi protokolu TCP/IP, můžete tato čísla přidělit podle vlastního uvážení. Nicméně systémům připojeným k Internetu jsou čísla přidělována centrálně, konkrétně síťovým informačním centrem (Network Information Center), zkráceně NIC.
IP adresy jsou pro přehlednost rozděleny do čtyř 8bitových čísel, kterým říkáme oktety. Například adresa quark.physics.groucho.edu má IP adresu 0x954C0C04, která je zapsána jako 149.76.12.4. Tomuto formátu se také někdy říká tečková notace.
Dalším důvodem této symboliky je rozdělení IP adres na číslo sítě, které je obsaženo v levých dvou oktetech, a na číslo hostitele, které je zapsáno v pravých dvou oktetech. Když požádáte centrum NIC o přidělení IP adres, nebude vám přidělena adresa pro každého hostitele, kterého hodláte používat. Místo toho obdržíte jediné číslo sítě a pak na základě vlastního uvážení můžete přidělovat hostitelům ve vaší síti všechny IP adresy v rámci získaného rozsahu IP adres.
V závislosti na velikosti sítě je nutné mít i různě velkou část hostitele. Protože mají různí uživatelé různé nároky na velikost sítí, existuje několik tříd sítí, které definují různá rozdělení IP adres.
| Třída A | Třída A obsahuje sítě od 1.0.0.0 do 127.0.0.0. Číslo sítě je obsaženo v prvním oktetu. Takto je k dispozici 24bitová část hostitele, která umožňuje až 1,6 milionů hostitelů. |
| Třída B | Třída B obsahuje sítě od 128.0.0.0 do 191.255.0.0; číslo sítě je obsaženo v prvních dvou oktetech. To umožňuje 16 320 sítí, z nichž každá může mít až 65 024 hostitelů. |
| Třída C | Třída C zahrnuje sítě od 192.0.0.0 do 223.255.255.0, kde číslo sítě je obsaženo v prvních třech oktetech. To umožňuje vytvořit téměř 2 miliony sítí s až 254-mi hostiteli. |
| Třída D, E a F | Adresy, které spadají do intervalu od 224.0.0.0 do 254.0.0.0, jsou buť experimentální, nebo jsou rezervovány pro budoucí použití. Nespecifikují žádnou síť. |
Vrátíme-li se zpět k příkladu z minulé kapitoly, zjistíme, že adresa 149.76.12.4, což je adresa quark, spadá do třídy sítí B 149.76.0.0 a odkazuje na hostitele 12.4.
Ve výše uvedeném seznamu jste si možná všimli, že v každém oktetu nebyly v příslušné části hostitele povoleny všechny hodnoty. To proto, že hostitelé, jejichž čísla oktetů jsou rovna 0 nebo 255, jsou rezervováni pro speciální účely. Adresa, ve které jsou všechny bity hostitelské části nulové, odkazuje na síť a adresa, v níž jsou všechny bity hostitelské části rovny jedné, se nazývá vysílací adresa (broadcast address). Vysílací adresa současně odkazuje na všechny hostitele v konkrétní síti. Tedy adresa 149.76.255.255 není koréktní hostitelská adresa, ale odkazuje na všechny hostitele v síti 149.76.0.0.
Dále existují ještě dvě rezervované síťové adresy, a to 0.0.0.0 a 127.0.0.0. První z nich se nazývá implicitní směr (default route), druhá se nazývá zpětnovazebná adresa (loopback address).
Implicitní směr souvisí se způsobem směrování IP datagramů, které budeme probírat dále. síť 127.0.0.0 je rezervována pro místní IP dopravu k vašim hostitelům. Adresa 127.0.0.1 je obvykle přiřazena speciálnímu rozhraní na vašem hostiteli, které se někdy také nazývá zpětnovazebné rozhraní (loopback interface) a chová se jako uzavřený obvod. Každý IP paket předaný protokolem TCP nebo UDP je vrácen zpět, jakoby právě přišel z nějaké sítě. To umožňuje vyvíjet a testovat síťový software, aniž byste používali "skutečnou" síť. Další užitečnou aplikací je případ, kdy chcete použít síťový software na samostatném hostiteli. Není to zase tak neobvyklé, jak by se mohlo zdát; například mnoho systémů UUCP nemá vůbec žádné IP propojení, ale přesto chtějí provozovat systém news INN. Aby systém INN správně fungoval pod Linuxem, vyžaduje zpětnovazebné rozhraní.
Když teď víte, jak se vytváří IP adresy, bude vás asi zajímat, jak se s jejich pomocí v Ethernetu adresují různí hostitelé. Protokol Ethernet identifikuje hostitele číslem složeným ze šesti oktetů, které nemá nic společného s IP adresou.
Proto potřebujeme mechanismus, jenž ethernetovým adresám přiřadí IP adresy. Tento mechanismus se nazývá protokol pro rozlišování adres (Address Resolution Protocol), zkráceně ARP, ktrý není omezen pouze na Ethernet, ale používá se i u jiných typů sítí, příkladem je ham-radio. Idea protokolu ARP je stejná jako když hledáte pana X. Představte si tlačenici asi 150-ti lidí, kteří budou chodit pořád dokola, volat jeho jméno a spoléhat na to, že jim v případě, že je přítomen, odpoví.
Když chce ARP najít ethernetovou adresu odpovídající příslušné IP adrese, použije tzv. "vysílání" (broadcasting), při kterém je datagram současně adresován na všechny stanice v síti.
Vyslaný datagram, který odešle protokol ARP, obsahuje dotaz na příslušnou IP adresu. Každý hostitel, který přijímá, ji porovná se svou vlastní IP adresou a pokud souhlasí, vrátí dotazujícímu se hostiteli odpověi pomocí protokolu ARP. Nyní může dotazující se hostitel vytáhnout z odpovědi ethernetovou adresu zasilatele.
Možná se ptáte, jak hostitelé vědí, na kterém z miliard světových Ethernetů lze požadovaného hostitele nalézt a proč to má být zrovna Ethernet? Všechny tyto otázky souvisí se směrováním, tedy nalezením fyzického místa hostitele v síti. To bude předmětem dalšího výkladu.
Podívejme se nyní na protokol ARP. Když hostitel získá ethernetovou adresu, uloží ji do vyrovnávací paměti protokolu ARP, takže když bude dotyčnému hostiteli posílat zpět nějaký datagram, nemusí se na ni znovu dotazovat. Tuto informaci by však nebylo rozumné uchovávat příliš dlouho; ethernetová karta vzdáleného hostitele může být například z důvodu technických problémů vyměněna, čímž by byla data protokolu ARP neplatná. Abychom si vynutili další dotazy na IP adresu, dochází po určité době k mazání vstupů z vyrovnávací paměti protokolu ARP.
Někdy je také nutné nalézt IP adresu, která odpovídá určité ethernetové adrese. To je případ, kdy se bezdiskový počítač pokouší zavádět operační systém ze síťového serveru. V lokálních sítích je to docela běžná situace. Bezdiskový klient však o sobě nemůže poskytnout skoro žádné informace - kromě své ethernetové adresy. Jediné co může udělat je poslat spouštěcímu serveru zprávu se žádostí o sdělení jeho IP adresy. Pro tento účel existuje další protokol, který se nazývá Protokol pro zpětné rozlišení adres (Reverse Adress Resolution Protocol), zkráceně RARP. Společně s protokolem BOOTP slouží k definování procedury zavádění operačního systému bezdiskových klientů v síti.
Když někomu píšete dopis, uvedete obvykle na obálce kompletní adresu, která obsahuje název země, stát, kraj, PSČ atd. Poté co ho vhodíte do poštovní schránky, ho pošta doručí na cílové místo: pošle ho do vyznačené země, zde ho národní pošta odešle do příslušného kraje atd. Výhoda tohoto hierarchického schématu je poměrně zřejmá: Ať už pošlete dopis kamkoliv, bude vždy místní poštmistr zhruba vědět směr, kterým má dopis poslat dál, a přitom se nemusí starat o to, po jaké trase poputuje dopis v rámci cílové země.
Sítě IP jsou strukturovány obdobným způsobem. Celý Internet se skládá z mnoha sítí, kterým říkáme autonomní systémy (autonomous systems). Každý takovýto systém provádí veškeré směrování v rámci svých členských hostitelů, takže se úkol doručení datagramu zredukuje na hledání cesty k síti cílového hostitele. To znamená, že jakmile datagram zachytí libovolný hostitel v cílové síti, bude další proces prováděn výhradně touto sítí.
Tato struktura vyplývá z rozdělení IP adres na část hostitelskou a část síťovou, viz výše uvedený popis. Cílová síť je implicitně odvozena ze síťové části IP adresy. Proto by se hostitelé, kteří mají identická síťová IP čísla, měli nacházet ve stejné síti, což platí i obráceně.
Obdobné schéma má smysl i uvnitř sítě, protože vlastní síť se může skládat ze stovek menších sítí, kde jsou nejmenšími jednotkami fyzické sítě, například Ethernety. Protokol IP umožňuje rozdělit sít IP na několik podsítí.
Podsíť na sebe přebírá (od sítě IP, které je součástí) odpovědnost za doručení datagramů pro daný rozsah IP adres. K její identifikaci slouží síťová část IP adresy, jako tomu bylo u tříd A, B nebo C. Nyní je však síťová část rozšířena tak, aby obsahovala i některé bity z hostitelské části. Počet bitů, které jsou interpretovány jako číslo podsítě, udává tzv. maska podsítě (subnet mask) neboli síťová maska (netmask). Jedná se také o 32bitové číslo, které určuje bitovou masku části sítě IP adresy.
Příkladem takové sítě je ýkolní síť Groucho Marx University. Má síťové číslo třídy B 149.76.0.0, a proto je její síťová maska 255.255.0.0.
Vnitřně je ýkolní síť GMU složena z několika menších sítí, které tvoří například lokální sítě různých kateder. Takže rozsah IP adres je rozložen na 254 podsítí, od adresy 149.76.1.0 po adresu 149.76.254.0. Například katedra teoretické fyziky má přidělenu adresu 149.76.12.0.
Páteří školní sítě je v pravém slova smyslu síť s adresou 149.76.1.0. Tyto podsítě sdílí stejné číslo sítě IP, zatímco třetí oktet slouží k jejich rozlišení. Používají tedy masku podsítě 255.255.255.0.
Obrázek 2.1 ukazuje rozdílnou interpretaci čísla 149.76.12.4, což je adresa quark. Je-li v prvním případě považována adresa za adresu běžné sítě třídy B, pak ve druhém případě je považována za adresu podsítě.
Je dobré vědět, že vytváření podsítí slouží pouze k vnitřnímu dělení sítě. Podsítě jsou generovány vlastníkem sítě (nebo jejími správci). Sítě jsou často vytvářeny kvůli hranicím, například fyzickým (mezi dvěma Ethernety), administrativním (mezi dvěma katedrami) nebo geografickým, a pravomocemi nad těmito podsítěmi je pověřena nějaká kontaktní osoba. Tato struktura však odráží pouze vnitřní chování sítě a pro okolní svět je neviditelná.
Vytváření podsítí nemá jen organizační výhody, je často přirozeným důsledkem hranic hardwaru. "Výhled" hostitele dané fyzické sítě, jako například Ethernetu, je velmi omezující: jedinými hostiteli, se kterými lze komunikovat přímo, jsou hostitelé v dané síti. Ke všem ostatním hostitelům může být přistupováno jen s pomocí tzv. bran. Brána je hostitel, který je současně spojen se dvěma nebo více fyzickými sítěmi a který je nastaven pro přenášení paketů mezi nimi.
Aby protokol IP poznal, zda se hostitel nachází v příslušné lokální fyzické síti, musí různé fyzické sítě náležet k odlišným sítím IP. Například síťové číslo 149.76.4.0 je rezervováno pro hostitele lokální sítě katedry matematiky. Když se posílá datagram na adresu quark, síťový software na serveru erdos okamžitě z IP adresy 149.76.12.4 pozná, že cílový hostitel je připojen k jiné fyzické síti, a proto je dosažitelný pouze pomocí brány (implicitní bránou je sophus).
Vlastní brána sophus je propojena se dvěma rozdílnými podsítěmi: s katedrou matematiky a s páteří školní sítě. Ke každé z nich přistupuje za pomoci různých rozhraní eth0, resp. fddi0.
Jakou adresu mu ale přidělíme? Máme mu dát adresu podsítě 149.76.1.0 nebo 149.76.4.0 ?
Odpověi zní: obě. Při komunikaci s hostitelem v lokální síti katedry matematiky by měla brána sophus použít IP adresu 149.76.4.1 a při komunikaci s hostitelem v páteřní síti by měla použít adresu 149.76.1.4.
Bráně je tedy přidělena jedna IP adresa pro každou síť s níž je spojena. Tyto adresy - společně s odpovídajícími síťovými maskami - jsou spojeny s rozhraním, ke kterému přistupuje podsíť. Mapování rozhraní a adres v rámci brány sophus by tedy mělo vypadat následovně:
| Rozhraní | Adresa | síťová maska |
| Eth0 | 149.76.4.1 | 255.255.255.0 |
| Fddi0 | 149.76.1.4 | 255.255.255.0 |
| Lo | 127.0.0.1 | 255.0.0.0 |
Poslední řádek popisuje zpětnovazebné rozhraní lo, které bylo popsáno výše.
Obrázek 2.2 ukazuje část síťové topologie na Groucho Marx University (GMU). Hostitelé, kteří jsou v daném okamžiku ve dvou podsítích, jsou zobrazeni s oběma adresami.
Jemnou odlišnost mezi přidělením adresy hostiteli nebo jeho rozhraní je možné ignorovat. Na hostitele, kteří se nachází v jedné síti, například hostitel erdos, se budete většinou odkazovat pomocí IP adresy, i když třeba tato adresa odpovídá ethernetovému rozhraní. Tento rozdíl je ale důležitý pouze v případě, kdy se odkazujete na bránu.
Nyní se zaměříme na způsob, jakým protokol IP vybírá bránu, kterou použije k doručení datagramu do vzdálené sítě.
Ukázali jsme si, že u datagramu pro server quark zkontroluje hostitel erdos cílovou adresu, načež zjistí, že se nenachází v lokální síti. Proto ho pošle na implicitní bránu sophus, která je postavena před stejný úkol. Brána sophus pozná, že hostitel quark není na žádné ze sítí, s nimiž je přímo spojena, takže musí najít další bránu, na kterou by datagram poslala. Správnou volbou by byla brána niels, což je brána katedry fyziky. Proto potřebuje brána sophus příslušné informace, aby mohla přiřadit cílovou síť vhodné bráně.
Směrovací informace, které protokol IP pro tento účel používá, jsou tvořeny tabulkou, jež přiřazuje jednotlivé sítě branám, s nimiž jsou spojeny. Tabulka musí být doplněna o data typu zachyš-vše (catch all) (pro implicitní směr); je to brána sdružená se sítí 0.0.0.0. Všechny pakety pro neznámou síť jsou poslány implicitním směrem. Pro bránu sophus by mohla tabulka vypadat následovně.
| síť | Brána | Rozhraní |
| 149.76.1.0 | - | fddi0 |
| 149.76.2.0 | 149.76.1.2 | fddi0 |
| 149.76.3.0 | 149.76.1.3 | fddi0 |
| 149.76.4.0 | - | eth0 |
| 149.76.5.0 | 149.76.1.5 | fddi0 |
| - - - | ||
| 0.0.0.0 | 149.76.1.2 | fddi0 |
V sloupci brána je symbol "-" proto, že se směruje do sítě, s níž je brána sophus přímo spojena, tudíž není žádná brána vyžadována.
Směrovací tabulky mohou být vytvářeny různým způsobem. U malých sítí LAN je většinou nejefektivnější vytvořit je ručně a při procesu zavádění je naplnit IP adresami pomocí příkazu route (viz. kapitola 5). V rozsáhlejších sítích jsou vytvářeny a přizpůsobovány v čase spuštění pomocí směrovacích démonů; démoni běží na centrálních hostitelích sítě a vyměňují si směrovací informace, čímž určí "optimálníi. směrování mezi členskými sítěmi.
V závislosti na velikosti sítě budou použity různé směrovací protokoly. Ke směrování uvnitř autonomních systémů (jako je ýkolní síť Groucho Marx) budou použity vnitřní směrovací protokoly. Nejvýznamnijším z nich je protokol RIP, což je směrovací informační protokol (Routing Information Protocol), který je implementován do BSD-démona routed. Ke směrování mezi autonomními systémy by měly být použity externí směrovací protokoly, jako je například EGP (vnější bránový protokol (External Gateway Protocol)) nebo BGP (hraniční bránový protokol (Border Gateway Protocol)); tyto protokoly (stejně tak i RIP) byly implementovány do démona gated.
Dynamické směrování založené na protokolu RIP vybírá nejlepší směrování k cílovému hostiteli nebo síti na základě počtu "skoků" (hops), to znamená počtu bran, kterými musí datagram projít, než dosáhne cíle. Čím kratší je směr, tím rychlejší je RIP. Velmi dlouhé směry s 16-ti nebo více skoky jsou považovány za nepoužitelné a jsou zrušeny.
Chcete-li použít protokol RIP na vnitřní správu směrovacích informací ve vaší místní síti, musíte mít na všech hostitelích spuštěn program gated. Při procesu zavádění zkontroluje program gated všechna aktivní síťová rozhraní. Pokud existuje více než jedno aktivní rozhraní (nepočítaje zpětnovazebné rozhraní), bude předpokládat, že hostitelé posílají pakety mezi několika sítěmi a bude aktivně vyměňovat a vysílat směrovací informace. V opačném případě bude jen pasivně přijímat všechny aktualizace z protokolu RIP a aktualizovat místní směrovací tabulku.
Při vysílání informace z místní směrovací tabulky vypočte program gated délku směrování z tzv. metrické hodnoty, která je ve směrovací tabulce součástí dat jednotlivých položek. Tato metrická hodnota je při konfiguraci směrování nastavena systémovým správcem a měla by odrážet aktuální váhu použití daného směru. Proto by měla být metrická hodnota směrování k podsíti, se kterou je hostitel přímo propojen, vždy rovna nule, zatímco směr procházející dvěma bránami by měl mít metrickou hodnotu rovnu dvěma. S těmito metrickými hodnotami si však nemusíte dělat starosti, pokud nebudete používat protokol RIP nebo program gated.
Protokol IP obsahuje doprovodný protokol, o kterém jsme se zatím nezmínili. Jedná se o tzv. internetový protokol na řízení zpráv (Internet Control Message Protocol) (ICMP), který využívá síťový kód jádra operačního systému k předávání chybových zpráv ostatním hostitelům apod. Předpokládejme například, že jste znovu na hostiteli erdos a chcete se za pomoci telnetu připojit na port 12 345 serveru quark, ale na tomto portu neexistuje žádný odposlech.
Pokud dorazí na tomto portu na server quark první paket, síťová hladina to pozná a okamžitě vrátí za pomoci protokolu ICMP hostiteli erdos zprávu, v níž bude uvedeno "Port je nedostupný" (Port Unreachable).
Protokol ICMP rozumí poměrně velkému počtu zpráv, z nichž mnohé počítají s chybovými stavy. Mezi nimi existuje jedna velice zajímavá zpráva "Přesměrování zprávy" (Redirect message). Generuje je směrovací modul v případě, že zjistí, že ho již jako bránu používá jiný hostitel, i když ve skutečnosti existuje i mnohem kratší cesta. Například po restartu systému může být směrovací tabulka brány sophus neúplná, obsahujíc směrování na síť katedry matematiky, na páteř FDDI a implicitní směr na centrální bránu Groucho Computing Center (gcc1). Proto bude každý paket pro server quark poslán na bránu gcc1 místo aby byl poslán přímo na bránu niels, což je brána katedry fyziky. Při přijetí takového datagramu si brána gcc1 všimne, že jde o špatnou volbu, pošle paket na bránu niels a zároveň vrátí bráně sophus pomocí protokolu ICMP zprávu o přesměrování, která bude obsahovat výhodnijší cestu.
Teď to vypadá, že jde o velmi chytrý způsob, jak se vyhnout manuálnímu nastavování všech směrů s výjimkou těch nejzákladnějších. Ale ne vždy je dobré spoléhat na dynamická směrovací schémata, jako jsou protokoly RIP nebo ICMP se zprávou o přesměrování. Zpráva o přesměrování u protokolu ICMP nebo protokol RIP nabízí jen malou, případně nulovou kontrolu toho, zda je směrovací informace skutečně autentická. Takto mohou zlomyslní uživatelé přerušit dopravu v celé síti nebo případně provést i něco horšího. Proto existují určité verze linuxového síťového kódu, které zacházejí se zprávami o přesměrování, jež ovlivňují směrování sítí, jakoby šlo jen o zprávy o přesměrování hostitelů.
Jak jsme řekli, je adresování v sítích na bázi protokolu TCP/IP prováděno prostřednictvím 32 bitových čísel. Pokud byste si však chtěli zapamatovat o něco více, strávili byste nad nimi poměrně hodně času. Proto se hostitelé označují "běžnýmiš. názvy, jako je hostitel gauss nebo hostitel strange. Povinností aplikace je, aby naýla IP adresu odpovídající danému názvu.
Tento proces se označuje jako rozlišení názvu hostitele.
Aplikace, která chce najít IP adresu příslušného názvu hostitele, nemusí obsahovat vlastní rutiny pro hledání hostitelů a jejich IP adres. Místo toho se spoléhá na skupinu funkcí z knihoven, které tuto operaci provádějí transparentně. Funkce se nazývají gethostbyname(3) a gethostbyaddr(3). Obvykle jsou tyto funkce společně s mnoha dalšími příbuznými procedurami seskupeny v oddělené knihovně, v tzv. knihovně resolveru; v Linuxu jsou součástí standardní knihovny libc. Z toho důvodu se tato sbírka funkcí označuje jako tzv. "resolver" U malých sítí, jako je Ethernet, nebo dokonce jeho části, je správa tabulek s názvy hostitelů společně s jejich adresami příliš složitá. Tato informace je obvykle uchovávána v souboru s názvem /etc/hosts. Při přidávání nebo odebírání hostitele nebo opětovném přidělování adresy stačí na všech hostitelích aktualizovat soubor hosts. Tento proces se komplikuje u sítí, které jsou složeny z většího počtu počítačů.
Jedním z řešení tohoto problému je systém NIS, síťový informační systém (Network Information System) vyvinutý firmou Sun Microsystems, hovorově se mu také říká YP, nebo-li Žluté stránky (Yellow Pages). Systém NIS ukládá soubor hosts (a další informace) do databáze na hlavním hostiteli, odkud ho mohou klienti dle potřeby získat. Přesto je tento přístup vhodný pouze pro středně velké sítě, jako jsou sítě LAN, protože vyžaduje centrální správu celé databáze hosts a její distribuci na všechny servery.
V Internetu byly adresy zprvu uchovávány v jediné databázi nazvané HOSTS.TXT. Tento soubor byl spravován síťovým informačním centrem (NIC) a všechny zúčastněné systémy si ho musely stáhnout a nainstalovat. Jak síť rostla, objevilo se v souvislosti s tímto schématem několik problémů. Kromě administrativního přetížení, které bylo způsobeno pravidelnou instalací souboru HOSTS.TXT, se příliš zvětýovalo i zatížení serverů, které ho distribuovaly.
Mnohem horší ale bylo, že všechny názvy musely být registrovány v centru NIC. To proto, aby se některý název neobjevil dvakrát.
Proto došlo v roce 1984 k adaptaci nového schématu pro rozlišování názvů. Byl jím tzv. Doménový jmenný systém (Domain Name System). Systém DNS byl navržen Paulem Mockapetrisem a oba tyto problémy řeší současně.
Systém DNS organizuje názvy hostitelů do hierarchie domén. Doména je skupina systémů, mezi nimiž je nějaký vztah - bui proto, že tvoří vlastní síť (například všechny univerzitní počítače nebo všichni hostitelé v síti BITNET), nebo proto, že všechny patří určité organizaci (jako je například vláda Spojených států), nebo zkrátka tvoří geografické celky. Například univerzity jsou seskupeny do domény edu, každá univerzita nebo vysoké učení používá svoji subdoménu, pod kterou jsou sloučeni její hostitelé. Groucho Marx University má přidělenu doménu groucho.edu a síť LAN katedry matematiky má přidělenu subdoménu maths.groucho.edu. Hostitelé v síti katedry by měli tento název domény připojen ke svému názvu hostitele; takže hostitel erdos bude známý jako hostitel erdos.maths.groucho.edu. Tato symbolika je označována jako plně kvalifikovaný název domény (fully qualified domain name), nebo zkráceně FQDN, a jednoznačně identifikuje tohoto hostitele po celém světě.
Obrázek 2.3 ukazuje část prostoru s názvy domén. Vstup u kořene tohoto stromu, který je označen malou tečkou, je poměrně výstižně nazván kořenovou doménou (root domain) a obklopuje všechny další domény. Aby se naznačilo, že název hostitele je plně kvalifikovaným názvem domény a nikoliv relativním názvem nějaké (implicitní) místní domény, píše se někdy s postfixovou tečkou. Ta udává, že název poslední části představuje kořenovou doménu.
V závislosti na jejím umístění v hierarchii názvů může být doména nazvána doménou nejvyšší úrovně, druhé úrovně nebo třetí úrovně. Více úrovní rozdělení sice je možných, ale vyskytují se jen řídce. Následuje několik domén nejvyšší úrovně, s nimiž se můžete často setkat:
| edu | Vzdělávací instituce (většinou v USA), jako jsou univerzity atd. |
| com | Komerční organizace, společnosti. |
| org | Nekomerční organizace. Často jsou v této doméně soukromé sítě typu UUCP. |
| net | Brány a další administrativní hostitelé na síti. |
| mil | Vojenské instituce Spojených států amerických. |
| gov | Vládní instituce Spojených států amerických. |
| uucp | Oficiálně byly do této domény přesunuty názvy všech systémů, které byly dříve používány jako názvy UUCP bez domén. |
Z technického hlediska patří první čtyři domény k části Internetu Spojených států amerických, ale i v těchto doménách můžete nalézt neamerické systémy. To platí zejména pro doménu net. Avšak domény mil a gov jsou používány výhradně Spojenými státy americkými.
Obecně platí, že každá země mimo území USA používá vlastní doménu nejvyšší úrovně, která je tvořena dvoupísmenným kódem země dle definice standardu ISO-3166. Například Finsko používá doménu fi, doména fr je přidělena Francii, doména de Německu, doména au patří Austrálie atd. Pod touto doménou nejvyšší úrovně může centrum NIC každé země libovolným způsobem organizovat názvy hostitelů. Například Austrálie má doménu druhé úrovně podobnou mezinárodním doménám nejvyšší úrovně, a sice com.au, edu.au atd. Ostatní země, jako je Německo, tuto speciální úroveň nepožívají, ale využívají raději delší názvy, které odkazují přímo na organizace, jež mají zvláštní doménu. Například není nic výjimečného setkat se s hostitelem, jehož název je například ftp.informatik.uni-erlangen.de. Zřejmě to nijak neovlivňuje německou výkonnost.
U těchto národních domén samozřejmě nemusí platit, že hostitel pod příslušnou doménou skutečně leží v dané zemi; pouze to signalizuje, že hostitel byl registrován centrem NIC dané země. Švédský výrobce může mít filiálku v Austrálii a přesto bude mít všechny své hostitele registrovány pod doménou nejvyšší úrovně se. Organizováním názvů do hierarchie názvů domén se tedy elegantně vyřeší problém jedinečnosti názvů; v systému DNS musí být název hostitele jedinečný pouze uvnitř vlastní domény, protože ta mu dává název odlišný od ostatních hostitelů po celém světě. Kromě toho jsou plně kvalifikované názvy poměrně lehce zapamatovatelné. Pak je velmi vhodné rozdělit rozsáhlou doménu na několik subdomén.
Ale systém DNS toho umí ještě mnohem více: umožňuje pověřit správou subdomény její správce. Například správci v instituci Groucho Computing Center mohou vytvořit subdoménu pro každý ústav. Již jsme se setkali se subdoménami maths a physics. Pokud se bude zdát správcům síť katedry fyziky pro správu zvenčí příliš rozsáhlá a chaotická (konec konců fyzici jsou známí jako neovladatelná skupina lidí), mohou jednoduše předat řízení nad doménou physics.groucho.edu správcům této sítě. Ti potom mohou používat libovolné názvy hostitelů a přidělovat jim IP-adresy své sítě, aniž by do toho zvenčí někdo zasahoval.
Na konci řetězce je prostor s názvy rozdělen na zóny (zones), z nichž každá je směrována na doménu. Všimněte si jemné odlišnosti mezi zónou a doménou: doména groucho.edu obsahuje všechny hostitele instituce Groucho Marx University, zatímco zóna groucho.edu obsahuje pouze hostitele, které přímo spravuje centrum Computing Center, například hostitele z katedry matematiky. Hostitelé z katedry fyziky patří do odlišné zóny, konkrétně physics.groucho.edu. Na obrázku 2.3 je začátek zóny označen malým kolečkem napravo od názvu domény.
Na první pohled se může zdát, že u všech těchto rozsáhlých domén a zón je provedení rozlišení názvu nesmírně komplikované. Konec konců, neřídí-li názvy, které jsou přidělovány daným hostitelům, žádná centrální správa, jak je má potom aplikace na nižší úrovni uhodnout?
Nyní přichází na řadu bezelstná vlastnost DNS. Chcete-li nalézt IP-adresu serveru erdos, pak vám DNS odpoví, že se máte jít zeptat lidí, kteří ho spravují, a oni vám ji řeknou.
Systém DNS je de facto obrovskou distribuovanou databází. Je implementován za pomoci takzvaných jmenných serverů (name servers), které dodávají informace o dané doméně nebo o dané skupině domén. U každé zóny existují nejméně dva a nejvýše několik jmenných serverů, které uchovávají všechny závažné informace o hostitelích v příslušné zóně. Pokud chcete získat IP-adresu serveru erdos, pak se stačí spojit s jmenným serverem zóny groucho.edu, který vám následně vrátí požadovaná data.
Možná si myslíte, že se o tom mnohem snadněji mluví, ale hůře se to provádí. Takže, jak mám vědět, jak se spojit s jmenným serverem na Groucho Marx University? V případě, že váš počítač není vybaven nástrojem pro analýzu adres, provede to systém DNS za něj. Když chce vaše aplikace vyhledat informace o serveru erdos, spojí se s místním jmenným serverem, který aplikuje na dané informace tzv. iterační dotaz. Začne zasláním dotazu jmennému serveru v kořenové doméně, kde se zeptá na adresu erdos.maths.groucho.edu. Kořenový jmenný server pozná, že tento název nepatří do jeho správní zóny, ale patří do zóny pod doménou edu.
Takže vám sdělí, že se máte spojit s jmenným serverem zóny edu, kde získáte více informací. Ke své odpovědi dále přibalí i seznam všech jmenných serverů domény edu společně s jejich adresami. Potom bude váš místní jmenný server pokračovat a pošle dotaz na některý z nich, například na a.isi.edu. Podobným způsobem jako u kořenového jmenného serveru se server a.isi.edu dozví, že lidé z groucho.edu mají svou vlastní zónu a odkáže vás na její vlastní servery. Místní jmenný server bude pokračovat v dotazu na server erdos na jednom z těchto serverů, který konečně zpozná, že daný server patří do jeho zóny, a vrátí jeho odpovídající IP-adresu.
Teď to možná vypadá, že kvůli vyhledání jedné mizerné IP-adresy bylo zapotřebí provést spoustu operací, ale ve skutečnosti je to v porovnání s množstvím dat, které by musely být přeneseny, kdyby se stále pracovalo se souborem HOSTS.TXT, minimum. Stále však existuje prostor, jak toto schéma vylepšit.
Aby zkrátil dobu odpovědi při dalších dotazech, uchovává jmenný server získané informace ve své místní vyrovnávací paměti (cache). Takže když chce příště někdo z vaší lokální sítě vyhledat adresu hostitele v doméně groucho.edu, nemusí jmenný server znovu absolvovat celý výše popsaný proces, ale přímo se spojí s jmenným serverem pro doménu groucho.edu.
Samozřejmě, že server nebude tyto informace uchovávat donekonečna, ale po určité době je smaže. Tato doba platnosti se nazývá čas přežití (time to live), zkráceně TTL. V databázi DNS přiděluje každé položce TTL správce, který je zodpovědný za danou zónu.
Jmenné servery, které uchovávají všechny informace o hostitelích příslušné zóny, se nazývají autoritativními jmennými servery (authoritative) dané zóny a někdy jsou také označovány jako hlavní jmenné servery (master name servers). Jakýkoliv dotaz na hostitele uvnitř této zóny nakonec stejně skončí až u těchto hlavních jmenných serverů.
Aby byl zachován spojitý obraz zóny, musí být její hlavní servery poměrně dobře synchronizovány. Toho dosáhneme tak, že jednoho ze serverů označíme jako primární (primary). Ten bude načítat informace o své zóně z datových souborů a ostatní servery budou označeny jako sekundární (secondary) a budou v pravidelných intervalech přenášet data z primárního serveru.
Jedním z důvodů, proč bychom měli mít několik jmenných serverů, je rozložení pracovní zátěže, dalším důvodem je pak redundance. Když přestane některý z jmenných serverů správně pracovat, například když spadne nebo ztratí síťové spojení, přejdou všechny dotazy na ostatní servery. Samozřejmě vás toto schéma neochrání před chybami serveru, jejichž důsledkem budou ýpatné odpovědi na všechny požadavky systému DNS, například z důvodu softwarových chyb ve vlastním programu serveru. Samozřejmě můžete chtít provozovat i takový jmenný server, který nebude správcem žádné domény.
Přesto však je tento typ serveru důležitý, protože je stále schopen provádět DNS dotazy pro aplikace, které jsou spuštěny v lokální síti, a dále může ukládat informace do vyrovnávací paměti. Proto se tento typ serveru nazývá server pouze pro cachování (caching-only server).
Ukázali jsme si, že systém DNS nejenom určuje IP-adresy hostitelů, ale také vyměňuje informace mezi jmennými servery. Ve skutečnosti může databáze DNS obsahovat celý svazek různých typů záznamů.
V databázi DNS se jednotlivým informacím říká zdrojový záznam (resource record), zkráceně RR. Každý záznam má přidělený typ, který popisuje druh dat, jež reprezentuje a třídu, určující typ sítě, na kterou se bude záznam vztahovat. Třída uspokojuje potřeby různých adresních schémat, jako jsou IP-adresy (třída IN) nebo adresy sítí Hesiod (používaných v MIT) a některé další. Vzorovým typem zdrojového záznamu je záznam A, který sdružuje plně kvalifikované názvy domény s IP-adresou. Samozřejmě, že hostitel může mít více než jeden název. Nicméně jeden z těchto názvů musí být označen jako oficiální, neboli kanonický název hostitele (canonical host name) a ostatní jsou chápány jako přezdívky oficiálního názvu. Rozdíl spočívá v tom, že kanonický název hostitele je takový, se kterým je sdružen záznam typu A, zatímco ostatní názvy mají pouze záznam typu CNAME, který odkazuje na kanonický název hostitele.
Nebudeme zde procházet všechny typy záznamů, to si schováme do příýtí kapitoly. Nyní vám raději poskytneme krátký příklad. Obrázek 2.4 ukazuje část databázové domény, kterou mají načtenu jmenné servery zóny physics.groucho.edu.
;
; Autoritativní informace o doméně physics.groucho.edu
@ IN SOA {
niels.physics.groucho.edu.
hostmaster.niels.physics.groucho.edu.
1034 ; serial no
360000 ; refresh
3600 ; retry
3600000 ; expire
3600 ; default ttl
}
;
; Jmenné servery
IN NS niels
IN NS gauss.maths.groucho.edu.
gauss.maths.groucho.edu. IN A 149.76.4.23
;
; Teoretická fyzika (podsíť 12)
niels IN A 149.76.12.1
IN A 149.76.1.12
nameserver IN CNAME niels
otto IN A 149.76.12.2
quark IN A 149.76.12.4
down IN A 149.76.12.5
strange IN A 149.76.12.6
...
; Collider Lab. (podsíť 14)
boson IN A 149.76.14.1
muon IN A 149.76.14.7
bogon IN A 149.76.14.12
...
Kromě záznamů typů A a CNAME můžete v horní části souboru vidět speciální záznam, který je roztažen na několika řádcích. Je to zdrojový záznam SOA, což označuje začátek správy (Start of Authority), kde jsou umístěny všeobecné informace o zóně, kterou daný server spravuje. Je v něm například obsažen implicitní čas přežití pro všechny záznamy.
Všimněte si, že všechny názvy v ukázkovém souboru, které nekončí tečkou, by měly být interpretovány vzhledem k doméně groucho.edu. Speciální název "@" použitý v záznamu typu SOA odkazuje na vlastní název domény.
Řekli jsme si, že jmenné servery domény groucho.edu musí nějakým způsobem vědět o zóně physics, aby mohly odkazovat dotazy na její jmenné servery. Toho se obvykle dosáhne pomocí dvojice záznamů: záznam typu NS, který poskytne FQDN název serveru, a záznam typu A, který tomuto názvu přidruží adresu. Protože právě tyto záznamy drží jmenný prostor pohromadě, označují se často jako tzv. tmelící záznamy (glue records). Jsou jedinými případy záznamů, kde rodičovská zóna skutečně uchovává informace o hostitelích podřazené zóny. Na obrázku 2.5 ukazují tmelící záznamy na jmenné servery physics.groucho.edu.
;
; Data zóny groucho.edu.
@ IN SOA {
vax12.gcc.groucho.edu.
hostmaster.vax12.gcc.groucho.edu.
233 ; serial no
360000 ; refresh
3600 ; retry
3600000 ; expire
3600 ; default ttl
}
....
;
; Tmelící záznamy pro doménu physics.groucho.edu
physics IN NS niels.physics.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physics IN A 149.76.12.1
gauss.maths IN A 149.76.4.23
...
Kromě vyhledávání IP-adresy, která náleží hostiteli, je někdy žádoucí vyhledat také název kanonického hostitele, který odpovídá příslušné adrese. Tento proces se označuje jako tzv. zpětné mapování (reverse mapping) a některé síťové služby ho používají k ověřování identity klienta. Pokud se používá jediný soubor hosts, pak si zpětné vyhledávání vyžádá vyhledání souboru hostitele, který vlastní požadovanou IP-adresu. U DNS samozřejmě nepřipadá v úvahu úplné prohledání jmenného prostoru. Místo toho byla vytvořena speciální doména in-addr.arpa, která obsahuje všechny IP-adresy všech hostitelů v převrácené tečkové notaci. Například IP-adrese 149.76.12.4 odpovídá název 4.12.76.149.in-addr.arpa. Záznam typu PTR je takový záznam, který tyto názvy sdružuje s názvy svých kanonických hostitelů.
Vytvoření správní zóny obvykle znamená, že její správci mají plnou kontrolu nad způsobem, jakým jsou adresy přiřazovány k názvům. Protože většinou obsluhují jednu nebo více sítí nebo podsítí IP, existuje mezi DNS-zónami a IP-sítěmi jedno či více mapování. Například katedra fyziky obsahuje podsítě 149.76.8.0, 149.76.12.0 a 149.76.14.0.
V důsledku toho musí být nové zóny v doméně in-addr.arpa vytvářeny společně se zónou physics a musí být postoupeny síťovým správcům kateder: 8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa a 14.76.149.in-addr.arpa. Jinak by instalace nového hostitele v Collider Lab vyžadovala, aby se správci spojili se svou nadřazenou doménou, kde se nová adresa zapíše do souboru zóny in-addr.arpa.
Na obrázku 2.6 je zobrazena databáze zóny pro podsíť 12. Odpovídající tmelící záznamy v databázi jejich rodičovské zóny vidíte na obrázku 2.7.
;
; doména 12.76.149.in-addr.arpa.
@ IN SOA {
niels.physics.groucho.edu.
hostmaster.niels.physics.groucho.edu.
233 360000 3600 3600000 3600
}
2 IN PTR otto.physics.groucho.edu.
4 IN PTR quark.physics.groucho.edu.
5 IN PTR down.physics.groucho.edu.
6 IN PTR strange.physics.groucho.edu.
V důsledku toho mohou být zóny vytvářeny pouze jako nadmnožiny sítí IP-a co je ještě krutější, musí mít síťové masky na hranicích bajtu. Všechny podsítě v Groucho Marx University mají síťovou masku 255.255.255.0, takže lze pro každou podsíť vytvořit zónu in-addr.arpa.
Pokud by však existovala síťová maska 255.255.255.128, nebylo by možné vytvořit zónu pro podsíť 149.76.12.128, protože by neexistoval žádný způsob, jak sdělit systému DNS, že doména 12.76.149.in-addr.arpa byla rozdělena na dvě zóny se samostatnou správou a s názvy hostitelů od 1 do 127, resp. od 128 do 255.
;
; the 76.149.in-addr.arpa domain.
@ IN SOA {
vax12.gcc.groucho.edu.
hostmaster.vax12.gcc.groucho.edu.
233 360000 3600 3600000 3600
}
...
; podsíť 4: Katedra matematiky
1.4 IN PTR sophus.maths.groucho.edu.
17.4 IN PTR erdos.maths.groucho.edu.
23.4 IN PTR gauss.maths.groucho.edu.
...
; podsíť 12: Katedra fyziky
12 IN NS niels.physics.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physics.groucho.edu. IN A 149.76.12.1
gauss.maths.groucho.edu. IN A 149.76.4.23
...