Konfigurace a správa služeb DNS a DHCP

DHCP je zkratkou Dynamic Host Control Protokol. DHCP přiděluje klientským zařízením jako jsou počítače, tablety aj., v síti pomocí DHCP protokolů IP adresu, masku sítě, bránu a adresu DNS TLINK serveru. Přidělené údaje mají pouze omezenou dobu trvání a po určitém čase je třeba toto nastavení obnovit. Jedná se o tzv. zápůjčku.

Jako serverová služba umožňuje prostřednictvím nastavovat stanicím v síti sadu parametrů nutných pro komunikaci pomocí IP protokolu (TCP/IP). Dynamičnost zde znamená, že adresy a další informace distribuované serverem DHCP klientům nejsou přidělovány staticky, nastálo, ale jen na určitou stanovenou dobu. Po této době klient adresu vrátí, nebo obnoví (typicky po půli pronajaté doby). Umožňuje tedy ekonomicky hospodařit s adresním prostorem, zjednodušuje ho a centralizuje (přidávání nových stanic, hromadné změně parametrů, skrytí technických detailů před uživateli). Usnadňuje tak konfiguraci hlavně u větších sítí.

DHCP server může přidělovat IP adresu a maska sítě, implicitní bránu, DNS servery, jméno hostitele a domény, může hostitelům vnutit chování podle určitých norem, 'změnit' jeho MAC adresu, informovat ho o SMTP, POP, NTP a dalších serverech, zapnout, nebo vypnout IP forwarding (směrování v síti, určení cesty packetu), bezdiskovým stanicím určí cestu k bootovacímu obrazu, apod. V případě potřeby samozřejmě můžeme pomocí DHCP nastavit určité stroje staticky (rezervováním adresy). Typické je to například pro počítače poskytující určité služby: Web server, SMTP server, Router apod. Usnadňuje se tak nejen přístup k samotným službám, ale i vzdálená konfiguraci jednotlivých serverů.

Klienti komunikují na UDP portu 68, server naslouchá na UDP portu 67. Po připojení do sítě klient vyšle broadcastem DHCPDISCOVER paket. Na ten odpoví DHCP server paketem DHCPOFFER s nabídkou IP adresy. Klient si z nabídek vybere jednu IP adresu a o tu požádá paketem DHCPREQUEST. Server mu ji vzápětí potvrdí odpovědí DHCPACK. Jakmile klient obdrží DHCPACK, může už IP adresu a zbylá nastavení používat. Klient musí před uplynutím doby zapůjčení obnovit svou IP adresu. Pokud lhůta uplyne aniž by dostal nové potvrzení, klient musí IP adresu přestat používat.

DHCP server u každého klienta eviduje půjčenou IP adresu a čas, do kdy ji klient smí používat (doba zapůjčení - lease time). Poté co vyprší, smí server adresu přidělovat jiným klientům.

Hromadné rozeslání, které přijmou všechna zařízení v dané podsíti. Broadcast se nešíří mezi sítěmi a zastavuje se tedy u routeru, který broadcastové vysílání nepustí do sítí dalších.

Funguje jako 1 vysílatel (sender) / 1 příjemce (receiver)

• Individuální adresa identifikuje vždy jedno rozhraní v dané části sítě (dosahu) a datagramy směřující na ni budou doručeny právě tomuto jedinému rozhraní.
• Každý name server (NS) je dostupný jen v určité lokaci. Existuje v daný čas jen na jednom místě na internetu.
• Individuální adresy se dále dělí na adresy Globální, lokální linkové a unikátní lokální.

Funguje jako 1 vysílatel / N - příjemců

• Skupinová (multicastová) adresa určuje skupinu síťových rozhraní. Takto adresovaný datagram musí být doručen všem členům skupiny. Najdou využití například při internetovém vysílání televize či rádia (data nemusí být vysílána individuálně každému příjemci, ale jen jednou na skupinovou adresu všech příjemců daného kanálu).

Funguje jako 1 vysílatel / N - výběr příjemců ze skupiny

• Výběrové adresy představují velmi zajímavou, ale také komplikovanou kategorii adres. Označují skupinu rozhraní, datagram by ovšem měl být doručen jen jejímu nejbližšímu členovi. Nabízí se jejich využití pro rozložení zátěže a zvýšení robustnosti určité služby.
• Každý name server (NS) je dostupný odkudkoli. Existuje zároveň na více místech na internetu.
• V současnosti se výběrové adresy hojně používají pro kořenové DNS servery - jediná adresa je přiřazena i několika desítkám fyzických serverů a DNS dotaz je doručen vždy nejbližšímu z nich. To v praxi znamená, že každá výběrová adresa musí mít ve směrovacích tabulkách té části sítě, v níž existuje, svůj vlastní záznam. Tento požadavek velmi omezuje použitelnost výběrových adres v globálním měřítku, protože by zaplevelily globální směrovací tabulky.
• Výběrové adresy sdílejí prostor s individuálními. Nemají žádný svůj prefix ani předepsanou strukturu, platí pro ně stejná pravidla jako pro individuální adresy (unicast ) a ani od nich nejsou rozeznatelné. Odlišné zacházení s výběrovými adresami je dáno jen konfigurací zúčastněných strojů.

V porovnání se současným IP tedy zmizely oznamovací (broadcast) adresy. Jejich roli převzaly obecnější adresy skupinové. Jednotlivé druhy adres sloužící různým účelům jsou navzájem rozlišeny pomocí prefixů. Podle počáteční skupiny bitů v adrese poznáte, jakého druhu dotyčná adresa je. Zatím byl definován význam jen asi pro 15 % adresního prostoru, zbytek čeká na pozdější využití.

Jedná se o roli DHCP. Používá se v situaci, kdy existují dvě nebo více sítí oddělené směrovačem a jen jedna síť obsahuje DHCP server. V takovém případě správce na směrovači zapne Relay agenta a nastaví jej tak, aby všesměrové (broadcast) DHCP dotazy ze sítí bez DHCP přeposílal DHCP serveru. Agent k přeposílanému dotazu přidá číslo sítě a masku sítě, na které klienta zaslechl, aby DHCP server poznal, ze kterého adresního rozsahu má klientovi adresu přiřadit.

Relay Agent je nutný mezi sítěmi proto, že když se klient připojí do sítě, tak vyhledává DHCP server broadcastově vyslaným paketem. Broadcast se nešíří z jedné sítě do druhé a zastavuje se o router, takže pokud DHCP server není v dané sítí, klient ho nenajde. Relay Agent je schopný broadcastové vysílání zkonvertovat na Unicastové, které již routerem projde, a spojit tak klienta s DHCP serverem v jiné síti.

Protokol Bootstrap (BOOTP) je síťový protokol, který se používal v počítačových sítích pro nastavení parametrů pro stanice používající TCP/IP. BOOTP je definován v RFC 951 z roku 1985. V současné době je nahrazen protokolem DHCP.

Aby mohly stanice v lokální počítačové síti komunikovat pomocí rodiny protokolů TCP/IP, je na nich nutné nastavit několik základních parametrů (zpravidla IP adresa, maska sítě, brána a adresy DNS serverů). Z hlediska správy počítačové sítě není výhodné, aby tyto údaje byly uchovávány na pevných discích stanic, protože v případě jejich změny by je bylo nutné obcházet a ručně nastavení měnit. Proto se s výhodou používal protokol BOOTP, který všechny potřebné údaje přiděloval stanicím z centrální databáze dle potřeby.

BOOTP server uchovává ve své databázi seznam MAC adres síťových rozhraní stanic (síťové karty klientů). Na žádost stanic pak uložené údaje stanicím odesílá pomocí protokolu UDP.

Administrátor sítě vytváří konfigurační soubor, kde nastaví parametry pro všechny zařízení zapojené v lokální síti. Musí tedy udržovat databázi na BOOTP serveru a ručně do ní přidávat zařízení.

Startující stanice (BOOTP client - port 68) vytvoří dotaz „kdo jsem?„ a pomocí UDP ho odešle na IP adresu 255.255.255.255 (lokální broadcast - je odeslán na všechna zařízení v síti).

BOOTP server (port 67) po přijetí dotazu prohledá tabulku a najde-li v ní odpovídající MAC adresu tazatele, odešle mu z tabulky potřebná data pro nastavení síťové karty (IP adresu, masku podsítě, adresu DNS serveru, cestu k serveru a souboru, ze kterého má nabootovat operační systém, atd.). IP adresa přidělená zařízení je přidělená nastálo. To znamená, že každé zařízení v síti musí mít jeden profil na BOOTP serveru a zabírá pro sebe jednu konkrétní IP adresu, která nemůže být přidělená jinému zařízení v síti.

Přestože je BOOTP často považovaný za předchůdce DHCP, rozhodně nelze říci, že by byl BOOTP zcela nahrazen, protože má své opodstatnění i dnes. Hlavní využití i v dnešní době je u UNIXových systémů, protože klient může po připojení do sítě bootovat i bez lokálně uložených informací, s jakými parametry nastartovat systém. BOOTP totiž přiděluje jak adresy, tak i nastavení o místě s uloženými informacemi o bootu, které si klient stáhne pomocí protoholu TFTP a může tak nabootovat.

BOOTP: Určen pro konfiguraci pracovních stanic bez disků s omezenými možnostmi spuštění. Klienti nenavazují nové spojení ani neobnovují stávající konfiguraci se serverem s výjimkou restartování systému. Kvůli tomuto rozdílu oproti DHCP je BOOTP prakticky nepoužitelný v mnoha sítích, které počítají s vysokou fluktuací klientů, typicky například veřejné bezdrátové sítě.

DHCP: Pro konfiguraci často přemísťovaných síťových počítačů s místními pevnými disky a neomezenými možnostmi spouštění. Klienti obnovují přidělování zapůjčených adres ze serveru automatickým vstoupením do stavu nového navázání v daných časových intervalech. Proces probíhá na pozadí bez vědomí uživatele.

DHCP je nezávislý na použitém operačním systému (pokud OS DHCP podporuje) a celý je definován a upřesňován několika dokumenty RFC. Vychází z protokolu BOOTP, se kterým je zpětně kompatibilní a vylepšuje ho o mnoho nových a užitečných vlastností. Server DHCP můžeme být nasazen i pro klienty protokolu BOOTP, ovšem připravujeme se tím o mnoho výhod, například o zmiňovanou dynamičnost.

Protokol DHCP nebyl se svým předchůdcem BOOTP zpětně kompatibilní, což je pro internetové protokoly a vydávání RFC velmi nezvyklé. Protokol přinesl možnost „pronájmu IP adresy“. Vzhledem k modularitě BOOTP protokolu, ale bylo možné tuto vlastnost implementovat i do tohoto předchůdce.

Zpětně nekompatibilní protokol prosadila firma Microsoft, která pro systémy Windows 95 a novější implementovala jako standardní součást pouze podporu protokolu DHCP. Pro správce tak bylo tehdy nutné společně s novou verzí stolního systému Windows nakoupit a provozovat též serverovou edici Windows NT, protože podpora DHCP byla do stávajících BOOTP serverů (typicky provozovaných na unixových systémech) implementována až se zpožděním.

—-

Jak již zaznělo, tak možností přidělování IP adres je několik:

Ruční nastavení: V tomto případě správce sítě nevyužívá DHCP serveru a konfiguraci jednotlivých stanic zapisuje ručně do nastavení síťového adaptéru.

Statická alokace: DHCP server obsahuje seznam MAC adres a k nim příslušným IP adres. Pokud je žádající stanice v seznamu, dostane vždy přidělenu stejnou pevně definovanou IP adresu.

Dynamická alokace: Správce sítě na DHCP serveru vymezí rozsah adres, které budou přidělovány stanicím, které nejsou registrovány. Časové omezení pronájmu IP adresy dovoluje DHCP serveru již nepoužívané adresy přidělovat jiným stanicím. Registrace dříve pronajatých IP adres umožňuje DHCP serveru při příštím pronájmu přidělit stejnou IP adresu.

Zeroconf je zvláštním druhem konfigurace síťového rozhraní klientské stanice v případě, že v síti, ve které je klient připojen, není k dispozici žádný DHCP server nebo jiná služba zajišťující předání konfiguračních údajů o dané síti.

Klientská stanice si náhodně nastaví adresu a komunikuje přes ní. Je velmi nepravděpodobné, že by si dvě nebo více stanic náhodně vybralo stejnou adresu, ovšem i tak je ZEROCONF volen až jako podlední možnost. Ve větších sítích šance na stejně zvolenou adresu stoupá a již je potřeba DHCP serveru (nebo velmi časově náročné ruční konfigurace). U menších sítí, kde je sice šance zvolení stejné adresy minimální, je ale vhodnější použít statické IP.

Zeroconf adresa má u stanic s operačním systémem MS Windows spodobu:

169.254.xxx.xxx

Názorná ukázka možnosti ZEROCONF automatické konfigurace:

—-

Internet Protocol version 4 (IPv4) je první verze IP, která se masivně rozšířila. IPv4 je datově orientovaný protokol, který je používán v sítích s přepojováním paketů (např. Ethernet). Jde o protokol přepravující data bez záruky, tj. negarantuje doručení, zachování pořadí ani vyloučení duplicit. Zajištění těchto záruk je ponecháno na vyšší vrstvě, kterou představuje protokol TCP. IPv4 datagram nese pouze informaci o kontrolním součtu hlavičky datagramu se služebními údaji.

IPv4 poskytuje omezený adresní prostor. Teoreticky 2³² unikátních adres, což je zhruba 4 295 000 000 adres.

Adresa je definována jako 4 po sobě jdoucí oktety (4*8 = 32bitů) s maximální hodnotou 2^8 (0-255) v podobě zápisu d . d . d . d ⇒ 0.0.0.0 až 255.255.255.255.

Dne 3. února 2011 byly rozděleny poslední bloky adres protokolu IPv4, čímž došlo k jejich vyčerpání. Od té doby postupně probíhá přechod na protokol IPv6.

IPv6 je tedy nástupce protokolu IPv4. Hlavní změna, kterou přináší IPv6, je daleko větší adresní prostor, což umožňuje větší pružnost při přidělování adres. Je odstraněna potřeba použití překladu síťových adres (NAT), která byla zavedena kvůli vyčerpání adresního prostoru IPv4. Zjednodušuje otázku přidělování adres a přečíslování při změně poskytovatele připojení.

Cíle stanovené při tvorbě podoby IPv6:

• Dostatečně bohatý adresní prostor - pokud možno by už nikdy neměla nastat nouze o adresy
• Podpora služeb se zaručenou kvalitou
• Design odpovídající vysokorychlostním sítím
• Bezpečnostní mechanismy přímo v IP
• Podpora mobilních zařízení
• Automatická konfigurace
• Kooperace s IPv4 a co nejhladší přechod ze stávajícího protokolu na nový

Hlavním důvodem pro přechod na IPv6 byl původně nedostatek adres. Postupem času se hledala řešení i na bázi IPv4. Vzniklo beztřídní přidělování adres, mechanismy pro nahrazení celé lokální sítě jedinou adresou (NAT) díky tomu se zjistilo, že je možné ještě celkem dlouhou dobu vydržet s daným rozsahem. Také pro ostatní z výše uvedených cílů se začínají objevovat řešení v IPv4. S postupujícím časem se asi nejzávažnějším argumentem ve prospěch IPv6 stává podpora mobilních počítačů, která je zde vyřešena podstatně lépe, než v jeho předchůdci.

Na adresách se nešetřilo. Délka adresy vzrostla na čtyřnásobek původní hodnoty, tedy na 128 bitů. To znamená, že počet všech možných adres je 2^128 = 3,40*10^38 (340 sextiliónů). Na každého obyvatele planety připadá bezmála 30 tisíc síťových prefixů (každý síťový prefix nabízí 65 tisíc podsítí, z nichž každá umí rozlišit miliardy miliard koncových zařízení). Adres je tedy po všech stránkách dost a měly by vystačit opravdu dlouho.

Významným rozdílem proti IPv4 je, že zatímco v předchozím protokolu mívalo jedno síťové rozhraní obvykle jen jednu IPv4 adresu, ve světě IPv6 jich mívá celou řadu. Existuje dokonce výčet povinných adres, na nichž počítač či směrovač musí přijímat data.

Seznam povinných adres pro host (počítač):

• Lokální linková pro každé rozhraní
• Všechny individuální a výběrové, které mu byly přiděleny
• Lokální smyčka (loopback, ::1)
• Skupinové adresy pro všechny uzly (ff0x::1, kde x zastupuje odpovídající dosahy)
• Skupinová adresa pro vyzývaný uzel pro všechny přidělené individuální a výběrové adresy
• Všechny skupinové adresy, jejichž je členem

Seznam povinných adres pro směřovač (router):

všechny adresy povinné pro počítač a navíc výběrová adresa pro směrovače v podsíti pro každé rozhraní, kde funguje jako směrovač skupinové adresy pro všechny směrovače (ff0x::2, kde x zastupuje odpovídající dosahy)

Pro používání IPv6 není ze strany uživatele v moderních operačních systémech nutná žádná speciální příprava (tj. Windows Vista a novější, aktuální distribuce Linuxu atp.). V takovém případě je však nutné, aby správce lokální sítě (LAN) provedl příslušná nastavení aktivních prvků (routery) a aby IPv6 podporoval též poskytovatel internetového připojení (WAN síť - (například síť, která překračuje hranice města, regionu nebo státu)).

Existuje též možnost, kdy může uživatel navzdory nepřipravenosti sítě LAN a WAN přesto IPv6 používat (tzv. 6 to 4 = Connection of IPv6 Domains via IPv4 Clouds - Jedná se o automatický tunelovací mechanismus, který umožňuje připojit koncovou IPv6 síť k ostatním IPv6 sítím, přestože je sama připojena do světa po IPv4. Najde uplatnění například pokud chcete nasadit IPv6, ale váš poskytovatel Internetu podporuje jen IPv4.). Vinou vadných aplikací však může při aktivaci IPv6 dojít k nedostupnosti některých služeb.

Vzhledem k délce by bylo silně nepraktické převzít způsob zápisu z IPv4. V IPv6 se adresy zapisují kompaktněji v šestnáctkové soustavě a jednotlivé dvojice bajtů (čtveřice šestnáctkových číslic) se pro větší názornost oddělují dvojtečkami. Takže IPv6 adresa může vypadat třeba takto:

2001:0db8:7654:3210:fedc:ba98:7654:3210

Aby se zápis ještě o něco zkrátil, lze v jednotlivých čtveřicích vynechávat počáteční nuly. Pokud se vyskytne několik po sobě jdoucích nulových skupin, lze je nahradit dvojicí dvojteček. Ta se však v zápisu každé adresy smí objevit jen jednou, aby byl jednoznačný. Takže následující trojice zápisů je ekvivalentní:

ff01:0000:0000:0000:0000:0000:0000:0101\\ ff01:0:0:0:0:0:0:101\\ ff01::101

RFC 5952 zavedlo kanonický zápis, jehož cílem je snížit polymorfii adres. Podle něj aplikace sice na vstupu musí podporovat všechny možné tvary adresy, ale ve svých výstupech by měly používat jen kanonický zápis. ted je definován následujícími pravidly:

• šestnáctkové číslice se zapisují malými písmeny
• vynechání počátečních nul ve čtveřici je povinné
• konstrukce „::“ musí mít co největší efekt – musí pohltit všechny sousední nulové skupiny, musí být použita pro nejdelší takovou skupinu v adrese (pokud je jich více o stejné délce, použije se pro nejlevější) a nesmí se použít pro jednu nulovou skupinu

Poslední ze tří výše uvedených alternativ je v kanonickém tvaru.

Zápis adresy je v každém případě dost komplikovaný. Upřímně řečeno se neočekává, že by je uživatelé někdy psali. Pro ně jsou určena jména a adresy se vyřídí prostřednictvím DNS.

Prefixy se zapisují stejně jako v IPv4 adresa/délka, kde adresa určuje začátek adresy (její nevýznamné bity bývá zvykem vynulovat) a délka definuje, kolik bitů je významných. Například prefixu ff00::/8 vyhoví každá adresa, jež má v prvních osmi bitech samé jedničky.

Výběrové adresy nemají svůj vlastní prefix. Jsou zařazeny mezi globální individuální adresy, od nichž se liší pouze způsobem zpracování ve směrovacích algoritmech.

Následující prefixy nepředstavují oficiální kategorie adres. Jedná se o prefixy přidělené určitým mechanismům či technologiím:

Individuální adresa identifikuje vždy jedno rozhraní v dané části sítě (dosahu) a datagramy směřující na ni budou doručeny právě tomuto jedinému rozhraní. Drtivou většinu jejich adresního prostoru zabírají individuální globální adresy, jen několika prefixům byl přidělen speciální význam (jejich přehled uvádí tabulka na stránce Adresy). Jednotlivé kategorie jsou popsány v následujících sekcích.

Jedná se o nejběžnější typ, adresy používané a jednoznačné v globálním Internetu. Zatím byla v RFC 3587 definována jen část z nich (prefix 001 binárně). Definice podle daného RFC je velmi obecná, reálně mají tyto adresy následující strukturu:

Globální směrovací prefix (adresa sítě) je přidělován stejně jako v IPv4 řetězcem IANA–RIR–LIR. Zhruba řečeno počátečních 16 bitů určí IANA, dalších 16 bitů RIR a závěrečných 16 bitů LIR. Koncová síť by měla dostat k dispozici prefix délky 48. Správce sítě může použít dalších 16 bitů pro rozlišení podsítí a v každé z nich jsou jednotlivá rozhraní identifikována 64bitovými hodnotami (viz identifikátor rozhraní). Malým koncovým sítě může být přidělen i menší adresní prostor – prefix délky 56 nebo 64 bitů.

Tyto adresy jsou jednoznačné jen v rámci jedné linky (např. jednoho Ethernetu či jedné Wi-Fi buňky). Mají tvar fe80::identifikátor_rozhraní. Jejich hlavní předností je, že si je každý stroj může automaticky přidělit sám. Některé mechanismy IPv6 vyžadují, aby se pro lokální komunikaci po lince používaly právě tyto adresy – například je najdete ve směrovacích tabulkách.

Jelikož je adresa definována jen v rámci linky, musí být obvykle doplněna identifikátorem rozhraní, jehož prostřednictvím je daná linka připojena. Zapisuje se za adresu, oddělen znakem procento. Výsledný tvar vypadá například takto: fe80::224:d7ff:fe3d:5ad0%eth0.

Původně byly podobně jako linkové definovány i lokální místní adresy (site local) s prefixem fec0::/10. Jednalo se de facto o analogii lokálních IPv4 adres definovaných v RFC 1918. Trpěly však řadou problémů, proto je RFC 3879 zavrhlo. Později byly nahrazeny konceptem unikátních lokálních adres (ULA) zavedeným v RFC 4193.

Tyto adresy začínají prefixem fc00::/7. Za ním následuje jednobitový příznak L, zda byl prefix přiřazen lokálně (L=1) nebo jinak (L=0). V současnosti definované ULA jsou přiřazovány lokálně, proto začínají prefixem fd00::/8. Dalších 40 bitů obsahuje náhodně vygenerované číslo. Pro jeho vytvoření použijte generátor prefixů pro ULA, který vám zároveň umožní vytvořený prefix zaregistrovat. Zbytek kopíruje strukturu globálních adres - následuje 16bitový identifikátor podsítě a 64bitový identifikátor rozhraní.

Unikátní lokální adresy jsou lokální a jejich směrování v globálním Internetu je zakázáno, podobně jako pro lokální IPv4 adresy podle RFC 1918. Náhodné číslo v jejich prefixu nicméně minimalizuje pravděpodobnost, že adresy budou kolidovat s jiným místem (odtud slovo „unikátní“ v jejich názvu) a pokud by nedokonalostí filtru unikly do Internetu či jeho části, nemělo by to způsobit problémy.

Některé přechodové mechanismy potřebují vyjádřit v IPv6 adresy, které jsou ve skutečnosti IPv4 adresami. Slouží k tomu tzv. adresy s vloženým IPv4 (IPv4-embedded) podle RFC 6052. Mají obecný tvar:

//prefix// + //IPv4 adresa// + //přípona//

kde prefix přidělí lokální správce z místního adresního prostoru (např. pro tento účel vyčlení jednu z podsítí), nebo se použije dobře známý prefix 64:ff9b::/96. Při použití tohoto prefixu lze IPv4 adresu psát v obvyklém tvaru. Adresu 147.230.1.2 lze zapsat jako 64:ff9b::147.230.1.2 a nemusíte převádět IPv4 adresu do šestnáctkové soustavy (kanonický tvar téže adresy je 64:ff9b::93e6:102). RFC 6052 doporučuje nepoužívat přípony a volit prefixy délky 96 bitů. Podrobněji viz překlad adres.

Starší specifikace (RFC 4291) zavedly IPv4-mapované adresy (IPv4-mapped) s prefixem 0:0:0:0:0:ffff::/96, za nímž následovala IPv4 adresa, a ještě starší IPv4-kompatibilní adresy (IPv4-compatible) s 96 nulovými bity a následující IPv4 adresou. Oba tyto formáty jsou v současnosti zastaralé, byly nahrazeny výše zmíněnými adresami s vloženým IPv4.

IPv6 adresa tak má podobu:

xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

Při kombinaci s IPv4 má podobu:

(x:x:x:x:x:x:d.d.d.d)_IPv6 = 128bit vs. (d.d.d.d)_IPv4 = 32bit

Nebo také jako:

fna8:cd03:85ef:1201:e015:ffff:192.168.10.13

Přepočet z IPv4 na IPv6 spočívá v převodu z dekadické soustavy na hexadecimální. Použijeme-li např. adresu 192.168.10.13, musíme každý jednotlivý oktet oddělený čárkou vydělit 16 a zapsat číslem v 16tkové soustavě.

• 192 / 16 = 12 a zbytek 0.
• Číslo 12 je v 16tkové soustavě označeno písmenem „c“ a 0 jako „0“, proto zapíšeme oktet 192 jako „c0“.
• 168 / 16 = 10 a zbytek je 8.
• Číslo 10 je v 16tkové soustavě jako písmeno „a“ a 8 jako číslo „8“, proto zapíšeme oktet 168 jako „a8“.
• 10 / 16 = 0 a zbytek 10.
• Číslo 0 je v 16tkové soustavě „0“ a číslo 10 jako „a“, proto zapíšeme oktet 10 jako „0a“.
• 13 / 16 = 0 a zbytek 13
• Číslo 0 je v 16tkové soustavě jako „0“ a číslo 13 jako „d“, proto zapíšeme oktet 13 jako „0d“
• Výsledný převod IPv4 192.168.10.13 zapíšeme jako „c0a8:0a0d“

Při pohledu na výsledek je zřejmé, že je IPv6 opravdu 4násobně větší než IPv4, které při pohledu na výsledek zabírá právě 1/4 celkové délky adresy IPv6. Pro převod adres bez zbytečného počítání, lze využít i online nástroj UltraTools https://www.ultratools.com/tools/ipv4toipv6.

Ve světě IPv6 je značná pozornost věnována tomu, abyste pokud možno nemuseli nic konfigurovat. Po připojení počítače do sítě se vše samo nastaví a vše bude samo fungovat.

Ke kýženému cíli byly navrženy hned dvě cesty: Stavová a bez-stavová automatická konfigurace. Stavová odrůda není nic nového, jedná se o konfiguraci prostřednictvím DHCPv6. Počítač rozešle dotaz a DHCP server mu v odpovědi sdělí vše, co by o zdejší síti měl vědět. Takhle to dnes funguje zcela běžně v řadě sítí.

Kreativní novinkou je konfigurace bez-stavová, která nevyžaduje žádné servery. Jejím základním pilířem je takzvané objevování sousedů (neighbor discovery). Základní myšlenka je celkem prostá. Každý směrovač v určitých intervalech rozesílá do sítí, k nimž je připojen, takzvané ohlášení směrovače. V něm jsou obsaženy základní informace, především prefixy adres dané sítě a zda on sám může sloužit pro předávání paketů ven (jako implicitní směrovač, default gateway).

Instalace DHCP serveru na Windows Server 2012 R2 probíhá úplně stejně jako instalace jakékoliv jiné služby, kterou potřebujeme přidat. Instalace tak probíhá jako přidání role přes Správce serveru.

Ačkoliv máme možnost konfigurovat různé DNS a WINS servery už během po-instalační konfiguraci DHCP serveru , naší službu DHCP serveru je možné instalovat a provozovat i bez těchto služeb instalovaných na stejném serveru.

Pro správnou funkčnost DHCP serveru je nutné, aby byl síťový adaptér serveru nastaven na pevnou IP adresu!! To platí pro nastavení IPv4 a IPv6.

Po instalaci serveru máme možnost několik typů nastavení, které si následně ukážeme. Jedná se o:

• Nastavení oboru (Scope) IPv4
• Fond adres (Exclusion Ranges)
• Zapůjčení adresy (Lease adress)
• Rezervace (Reservations)
• Možnosti oboru (Scope Options)
• Zásady (Policies)
• Filtry (Filters)
• Nastavení oboru (Scope) IPv6

Rychlá konfigurace DHCP

RychlakonfiguraceDHCP.webm

Podrobná konfigurace včetně vysvětlení jednotlivých funkcí

PodrobnakonfiguraceDHCPserveru.webm

Jako první si zkontrolujeme, že máme na serveru nastavené statické IP adresy. To platí pro IPv4 i IPv6.

ipv4Nakonfigurujeme IPv4. Zvolíme si adresu, v našem případě 192.168.1.1 a masku sítě 255.255.255.0.

Zde si nastavíme IPv6 adresu. Může být libovolná. My si zvolíme adresu 2001:db7::1. (prefixy jsou popsané výše, prefix by měl být jiné, než budeme přidávat hostům, nebo by měla být adresa serveru vyloučena z rozsahu přidělovaných adres)

Nyní si otevřeme modul Správce serveru.

V pravé horní části si klikneme na „Správa“ a vybereme „Přidat role a funkce“.

V průvodci přejdeme na krok s názvem „Typ instalace“ (vidíme v levém postranním menu) a vybereme „Instalace na základě rolí nebo na základě funkcí.

Vybereme náš server, na který chceme roli instalovat.

Vybereme „Server DHCP“

Otevře se nám další dialogové okno, které nás upozorní na požadavek přidání dalších funkcí, aby byl server DHCP plně funkční. Zde nic neměním a potvrdíme „Přidat funkce“.

V další části nás průvodce vyzve k přidání dalších funkcí. My jsme funkce nutné pro fungování DHCP serveru již potvrdili a proto přejdeme dál.

Nyní nás instalace role upozorní na nutné konfigurace pro správné fungování DHCP serveru. Především je třeba nastavit statickou IP adresu serveru v nastavení síťového adaptéru. To platí pro IPv4, ale i IPv6! Dále je vhodné předem si rozvrhnout jaké podsítě, obory a jak velké nebo vyloučení adres z oborů použijeme v naší síti.

V následujícím kroku se zobrazí rekapitulace požadované instalace role. Zde zaškrtneme políčko „V případě potřeby cílový server automaticky restartovat“. Potvrdíme volbu v dalším okně. Spustíme instalaci.

Po dokončení instalace, která byla úspěšná, klikneme na odkaz v textu „Dokončit konfiguraci služby DHCP“.

Nyní nastavíme pro DHCP server skupiny, které budou mít přístup k této službě. Od tohoto kroku se liší konfigurace služby DHCP podle toho zda je server umístěn v ActiveDirectory (AD) a nebo není. Rozdíl je pouze ve volbě přístupových údajů a zápisu skupin, které mohou využít služby DHCP.

Jestliže je server umístěn v AD, služba DHCP serveru se autorizuje účtem, kterého zvolíme jako správcem této služby. Po dokončení se skupiny automaticky přidají do AD.

Nyní máme hotovo.

Můžeme konfigurovat součásti služby DHCP serveru. Ve Správci serveru si klikneme na „Nástroje“ a vybereme „DHCP“.

Zobrazí se nám okno se správou služby DHCP serveru.

Nastavením oboru neboli v originálním znění scope, nastavujeme DHCP serveru rozsahy a podmínky přidělování adres pro klientské stanice využívající naší službu DHCP. Jakmile nastavíme alespoň jeden obor, otevře se nám další možnost práce s tímto vytvořeným oborem:

• Rozsah IP adres, do kterého budou zahrnuty nebo z kterého budou vyloučeny adresy pro nabídky zapůjčení služby DHCP.
• Maska podsítě, která určuje podsíť pro danou IP adresu.
• Název oboru.
• Hodnoty doby trvání zapůjčení přiřazení klientům DHCP, kteří přijímají dynamicky přidělované IP adresy.
• Všechny možnosti oboru DHCP konfigurované pro přiřazení klientům DHCP, například server DNS, IP adresa směrovače a adresa serveru WINS (Windows Internet Name Service).
• Rezervace, které se volitelně používají k zajištění toho, aby klient DHCP obdržel vždy stejnou IP adresu.

Před konfigurací oboru si dobře promyslete kolik a jaká zařízení budete v tomto oboru provozovat. Podle toho si rozvrhněte rozsah IP adres. Jaké adresy následně vyloučíte, aby vám je DHCP server nepřiřadil pro klientské stanice. Rozmyslete si jakou IP adresu pro váš obor zvolíte. Jaké DNS servery využijte pro překlad adres a jakou výchozí bránu nastavíte.

TIP:Využijte rozumně celou šíři rozsahu oboru. Pro vyloučení z oboru zvolte jednoduché IP adresy, které využijte například pro servery, zálohovací zařízení, tiskárny atp. Např. od čísla 10 do 30.

Pravým tlačítkem klikněte na ikonku serveru IPv4. Zvolte „Nový obor“. Zobrazí se vám průvodce vytvořením nového oboru

Otevře se úvodní dialog.

Zadejte název vašeho nového oboru. Název je povinný, ale komentář je nepovinný.

Na této stránce vyberte rozsah IP adres, které bude DHCP přidělovat.

Dále máte možnost přidat rozsah adres, které chce vyloučit z nového oboru, proto, aby je DHCP server automaticky nepřidělil klientům. Toto nastavení lze provést i později.

Nyní zvolte dobu, po kterou bude IP adresa zapůjčena klientské stanici. V případě rozsahu pro návštěvy a často frekventované výměny klientských stanic, ponechte dobu co nejkratší. Naopak, víte-li, že máte v síti stálé klientské stanice, které jsou v podstatě stále připojeny do vaší privátní sítě, můžete ponechat dobu velmi dlouhou.

V další části se nás průvodce zeptá, zda chceme nakonfigurovat možnosti oboru. Tuto volbu zvolte v případě, kdy chcete pro váš nový bor nastavit například DNS servery, WINS servery, výchozí bránu, časový server aj. Pokud zvolíme ano, průvodce bude pokračovat dále, pokud zvolíme ne, konfigurace bude hotová a ukončí se. My zvolíme ano.

Zde nastavíme IP adresy směrovačů.

Zde nastavíme, aby klienti používali náš DNS server a naši nadřazenou doménu.

WINS (Windows Internet Name Service).

V tomto kroku nás průvodce vyzve k aktivaci oboru.

Pro dokončení klikneme dokončit.

Zde vidíme možnosti tohoto oboru, dostaneme se k nim dále.

Tato volba nám slouží k definici rozsahů, které budou vyloučeny ze zvoleného oboru, ve kterém se nacházíme. Vyloučení znamená, že rozsah, který zadáme nebude službou DHCP nikdy přidělen klientským stanicím a bude tak přeskočen.

Využití najdeme především v sítích, ve kterých se vyskytují zařízení jako servery, zálohovací zařízení, tiskárny, IP telefony aj. O kterých potřebujeme mít jasný přehled v adresaci.

Klikněte pravým tlačítkem na „Fond adres“ a zvolte položku „Nový rozsah vyloučení“.

V dialogovém okně vyplňte vámi zvolený rozsah, který chcete vyloučit a stiskněte „přidat“.

Rozsah se automaticky přidá a je zobrazen v seznamu fondu adres.

V této položce máme zobrazen seznam všech klientů, které obdrželi z našeho DHCP serveru nastavení sítě. Při kliknutí na zvoleného klienta v seznamu máme volbu:

• Přidat do filtru (Povolit / Odepřít)
• Přidat do rezervace
• Odstranit

Přidáním do filtru povolit nebo odepřít, nastavíme klientské stanice možnost povolit nebo odepřít komunikaci ve zvoleném oboru.

Přidáním do rezervace, učiníme rezervaci IP adresy pro konkrétní klientskou stanici a tato IP adresa nebude nikdy zapůjčena jiné stanici než této.

Při odstranění ze seznamu, odebereme klientské stanici zapůjčenou konfiguraci a IP adresu z našeho DHCP serveru a klient si zažádá o nové nastavení. Tuto možnost využijeme v případě, že potřebujeme odstranit klientskou stanici, která již není aktivní, ale doba výpůjčky ještě nevypršela. Tímto uvolníme další IP adresu pro jiné klienty.

Rezervaci adres provádíme v případě, že potřebujeme aby daná klientská stanice dostala vždy stejnou IP adresu, kterou ji nastavíme. Rezervovaná adresa bude vyčleněna z dostupných adres rozsahu a DHCP ji vždy přidělí pouze zvolené klientské stanici. Rezervaci provádíme na základě fyzické (MAC) adresy klientské stanice.

Po nastavení rezervace klientské stanici, máme možnost upravovat další nastavení. Například změnit výchozí bránu, DNS servery aj.

Vytvoření rezervace

Nejjednodušší způsob vytvoření rezervace je založit rezervaci ze seznamu zapůjčených adres. Nepotřebujeme tak získat informaci o fyzické (MAC) adrese klientské stanici, pro kterou požadujeme vytvoření rezervace.

V případě vytvoření nové rezervace, bez využití seznamu zapůjčených adres (stanice ještě neexistuje v seznamu), je třeba znát fyzickou (MAC) adresu síťového rozhraní klientské stanice, pro kterou vyžadujeme rezervaci. Informaci můžeme získat prostřednictvím příkazu IPCONFIG /ALL .

Pravým tlačítkem klikněte na „Rezervace“ a zvolte položku „Nová rezervace“

V dialogovém okně vyplňte název rezervace, požadovanou IP adresu a fyzickou (MAC) adresu klientské stanice, pro kterou vytváříte rezervaci.

Konfigurace rezervace

• Zobrazte si seznam všech rezervací ve zvoleném oboru.
• Vyberte si konkrétní klientskou stanici ze seznamu, která má provedenou rezervaci.
• Zvolte „Konfigurovat možnosti“ a poté vyberte možnost, kterou chcete upravit

Možnosti oboru jsou shodným nástrojem jako Možnosti serveru. Možnosti serveru jsou však nadřazeným prvkem a tak konfigurace provedená v možnostech serveru, která není upravena v konkrétním oboru, platí pro všechny obory zároveň.

U této položky máme možnost editace různých parametrů pro DNS a WINS servery, výchozí brány aj., které budou využity a předány síťovým rozhraní klientských stanic, které kontaktují službu DHCP serveru.

Zásady fungují jako pravidla pro hromadnou konfiguraci klientských stanic, které jsou již členy služby DHCP serveru a nebo se konfigurace automaticky provede pro stanici novou, která server DHCP kontaktuje a splní nastavená kritéria.

Zásady se provádí hierarchicky, tzn. že zásada, která je umístěna jako první (nejvýše v seznamu), se provede jako první, splní-li klientská stanice nastavená kritéria.

Kritéria zásad lze různě kombinovat díky zvoleným operátorům A (And) NEBO (Or). Pro definici kritéria se nejčastěji využívá fyzická (MAC) adresa klientských stanic/e nebo FQDN . Lze však využít i typ operačního systému tzv. „třída dodavatelů“ aj.

TIP: Potřebuji-li nastavit pro všechny VoIP telefony, které jsou od stejného výrobce, jinou výchozí bránu, než pro stolní počítače ve stejném oboru, mohu využít počáteční prefix MAC adresy, která je pro každého výrobce unikátní. Za tento prefix vložím zástupný znak * a zásada tak platí pro všechny zařízení tohoto výrobce.

Konfigurace zásady:

• Nyní zvolíme rozsah IP adres, který bude stanicím při splnění podmínek zásady přiřazen. Pozor, nelze zvolit rozsah, který byl z oboru vyloučen.
  
• V další části průvodce máme možnost nastavit například výchozí bránu, DNS a WINS servery, klientským stanicím, které podmínky zásady splňují.
• V souhrnu vidíme výčet všech podmínek a upravené možnosti. Potvrdíme „Dokončit“.

Pravým tlačítkem klikneme na „Zásady“ a zvolíme položku „Nová zásada…“, otevře se nám průvodce pro vytvoření nové zásady.

Vytvoříme název pro novou zásadu. Název je povinný, ale komentář nemusí být vyplněn.

V další části vytvoříme podmínku, pro kterou bude zásada platit. V dolní části je možnost volby operátora v případě, že kritérií zásady je více. Zvolíme přidat.

Otevře se další dialogové okno pro vytvoření podmínky. Jako kritérium zvolíme „Adresa MAC“. Do pole „Hodnota:“ vložíme MAC adresu klientské stanice, pro kterou bude zásada platit. MAC adresu zjistíme například příkazem ipconfig /all v příkazovém řádku. Screenshot s fyzickou adresou je na konci této sekce. V případě využití zásady pro více klientských stanic, které mají shodný prefix MAC adresy, můžeme využít pouze prefix a za něj nebo před něj vložit zástupný znak *. Přidáme hodnotu a potvrdíme „OK“.

Máme-li nastavené všechny podmínky zásady, potvrdíme „Další“.

Nyní zvolíme rozsah IP adres, který bude stanicím při splnění podmínek zásady přiřazen. Pozor, nelze zvolit rozsah, který byl z oboru vyloučen.

V další části průvodce máme možnost nastavit například výchozí bránu, DNS a WINS servery, klientským stanicím, které podmínky zásady splňují.

V souhrnu vidíme výčet všech podmínek a upravené možnosti. Potvrdíme „Dokončit“.

Nastavení filtrů slouží k odepření nebo povolení DHCP služby klientským stanicím. V případě, že se některá klientská stanice ocitne ve filtru „Odepřít“, budou této stanici odebrány konfigurační údaje DHCP serveru a sužby s touto stanicí nebude již nadále komunikovat.

Konfigurace filtrů

U filtrů můžeme konfigurovat buď povolení nebo odepření klientské stanice. Pravidlo pro nastavení filtru se vytváří pouze na základě MAC adresy klientské stanice.

Nastavení oboru IPv6 je téměř shodný s nastavením oboru IPv4. Možnosti konfigurace oboru IPv6, jsou v DHCP serveru omezenější než u oboru IPv4.

Zvolíme si položku serveru IPv6 a pravým tlačítkem klikneme na ikonku. Vybereme položku „Nový obor“. Otevře se nám průvodce vytvořením nového oboru.

Úkáže se okno průvodce.

Zadáme libovolný název a popis.

V další části průvodce zadáme předponu našeho oboru IPv6. My využijeme adresu 2001:db7::

Nastavíme dobu zápůjčky adres.

Zvolíme, zda chceme obor aktivovat

V této položce máme zobrazen seznam všech klientů, které obdrželi z našeho DHCP serveru nastavení sítě. Stejné jako u IPv4.

U této položky máme možnost editace různých parametrů pro DNS apod.

Smysl rezervace je stejný jako v případě IPv4. Avšak u IPv6 je třeba zadat rozdílné informace.

Klikneme pravým tlačítkem na rezervace a zvolíme „Nová rezervace“.

Na rozdíl od fyzické (MAC) adresy síťového rozhraní klienta, musíme zadat DUID (DHCP Unique Identifier) a IAID (Interface Association Identifier), které zjistíme pomocí příkazu IPCONFIG /ALL.

Zadáme údaje a klikneme na „Přidat“

Rezervace je hotová.

U DHCPv6 máme možnost vyloučit některé adresy z adresního rozsahu.

Pravým tlačítkem klikneme na „Vyloučení“ a zvolíme „Nový rozsah vyloučení“.

Zadáme rozsah adres, které chceme vyloučit. Pokud chceme jen jednu adresu, zadáme ji do počáteční IPv6 adresa.

Vyloučení je hotové.

DHCP server si při běhu ukládá data do databáze ve složce Windows\System32\dhcp, nejdůležitějšími soubory ve složce jsou dhcp.mdb – primární databáze DHCP serveru, j50.log – log transakcí pro případ potřeby obnovení nedokončených transakcí po pádu serveru a Tmp.edb – pracovní soubor serveru. Server je automaticky zálohován každých 60 minut do složky Windows\System32\dhcp\backup.

Vynucení zálohy lze zařídit kliknutím pravým tlačítkem na server a vybráním položky Zálohování.

Správce má možnost nastavit si cestu k záloze. Výchozím nastavením je složka backup, ale je možné zálohovat například na externí úložiště.

Cesty k primární i záložní složce je možné změnit po kliknutí pravým tlačítkem na server – Vlastnosti

Obnovení provádíme opačným postupem, kliknutím pravým tlačítkem na server – Obnovení a vybereme složku se zálohou serveru.

Server provede změny až po restartování (není možné změnit zásadní parametry za běhu).

Po kliknutí pravým tlačítkem na typ adres, které chceme spravovat – Vlastnosti, se otevře nové okno.

Hned první položkou je aktualizace statistických údajů, ve výchozím stavu není povolena, to znamená, že jejich aktualizace je provedena jen při spuštění DHCP manažera, případně po kliknutí pravým na vybraný typ adres – Aktualizovat. Můžeme si nastavit, po jaké době se budou údaje aktualizovat v případě, že zůstane okno konzole otevřené.

Tyto údaje si můžeme zobrazit po kliknutí pravým tlačítkem – Zobrazit statistické údaje, najdeme zde informace o čase spuštění serveru, době provozu, statistice přidělování adres a jejich využití.

Další položkou ve vlastnostech typu adresy je protokolování auditu DHCP, ve výchozím stavu povolená volba, jednou denně vytvoří záznam o používání serveru. Uložená data si můžeme zobrazit ve Windows\System32\dhcp, soubory DhcpSrvLog-* a DhCpV6SrvLog-*

V souboru tvoří jeden záznam jeden řádek, oddělovačem je čárka, údaje jsou zde uloženy ve formátu ID, Datum, Čas, Popis, IP adresa, Název hostitele, MAC adresa.

Jak přidat klienta do povolených, případně vyloučených adres, jsme si již ukázali, po jeho přidání do seznamu ale není toto pravidlo aktivní.

Musíme povolit alespoň jednu položku, jde o hromadné spouštění pravidla. Můžeme si ručně přidat 20 zařízení do blokování a potom tento filtr jedním kliknutím aktivujeme a deaktivujeme.

V záložce Upřesnit můžeme nastavit, kolikrát se má server před zapůjčením adresy pokusit o ping adresy určené k zapůjčení aby došlo k vyloučení možnosti dynamického přidělení adresy, kterou si jiný klient sám nastavil staticky. V dnešní době je výchozí hodnotou 0, protože tento problém nastával před Windows 2000, novější klienti sami automaticky ověřují dostupnost adresy, kterou jim server nabízí, ještě před přijetím.

Pod položkou Změna vazeb připojení serverů můžeme nastavit, na kterých síťových kartách serveru bude spuštěn DHCP server. Jeden server může například na dvou kartách přidělovat nezávisle na sobě různé rozsahy, nebo ten samý.

Karta se v nabídce nezobrazí, pokud nemá nakonfigurovanou pevnou IP adresu.

Klientem DHCP je jakékoliv zařízení, které podporuje protokol DHCP a dokáže tak se serverem DHCP komunikovat. Na řadě zařízení si lze zvolit zda chceme obdržet nastavení síťového rozhraní pomocí DHCP nebo ručně viz. kapitola: Možnosti přidělování IP adres .

Pro zjištění kompletní konfigurace síťových rozhraní na klientovi s operačním systémem Windows, stačí otevřít příkazový řádek (Command Line) a zadat příkaz IPCONFIG /ALL. Pomocí toho příkazu můžeme zjistit nastavení:

• Název klientské stanice
• Fyzickou (MAC) adresu síťového rozhraní
• Přidělenou IP adresu
• Masku podsítě
• Výchozí bránu (Gateway)
• Server DHCP
• Server DNS

Výstup by měl vypadat dle následujícího obrázku (červeně je označena oblast, která nás jako správce zajímá nejvíce):

Jestliže jsme provedli na DHCP serveru nebo přímo u klientského zařízení nastavení síťových rozhraní a potřebujeme, aby se nám změna projevila okamžitě, lze využít příkaz IPCONFIG /RELEASE, který zahodí všechna nastavení adaptérů u klientské stanice. A příkazem IPCONFIG /RENEW opět vyhledá a získá nové aktuální informace o nastavení.

Pokud chceme změnu na IPv6 tak použijeme obdobné příkazy IPCONFIG /RELEASE6 a IPCONFIG /RENEW6. Pokud se adresa z DHCP nenačte, je dobré zakázat a povolit síťový adaptér a nebo restartovat klienta. —- ==== DNS ==== DNS, zkratka pro Domain Name Systém, je hierarchický systém doménových jmen. Jeho hlavním úkolem a příčinou vzniku jsou překlady doménových jmen na IP adresy uzlů sítě a zpět. Později přibral další funkce (např. pro elektronickou poštu či IP telefonii) a slouží dnes de facto jako distribuovaná databáze síťových informací. DNS byl vytvořen pro potřeby internetu, má prakticky neomezenou kapacitu. Hlavní prvky DNS jsou DNS server(y), DNS klient(i) a DNS protokol. Systém DNS umožňuje efektivně udržovat decentralizované databáze a rozkládat tak zátěž. Tato hierarchická decentralizovaná databáze obsahuje doménová jména (uspořádány ve stromové struktuře), DNS zóny a jejich kopie (servery s daty) a data v podobě záznamů různých typů. Neříká nic o fyzické poloze - 2 stroje mohou být ve stejné doméně, ale mohou být na opačném konci světa. === DOMÉNOVÝ SYSTÉM === Doménová jména jsou rozdělena na domény jednotlivých úrovní. Jednotlivé úrovně se oddělují tečkou a zapisují se zleva doprava od nejnižší k nejvyšší. == Úrovně domén == Nejvýše stojí kořenová doména (root). Ta se označuje tečkou na konci adresy. Za kořenovou doménou stojí doména 1. úrovně. Ta se nazývá také Top Level Domain, TLD. Tyto domény se dále dělí, jak bude uvedeno podrobněji níže. Za doménou 1. úrovně (někdy též I. řádu) stojí doména 2. úrovně. V adrese ahoj.cz by byla doména 2. řádu slovo „ahoj“. Tato doména reprezentuje nejčastěji adresu na internetu. Doména 3. úrovně neboli subdoména je rozšíření doménového názvu o další úroveň. Může být např. ve tvaru vesele.ahoj.cz, kde „vesele„ je název domény III. řádu. Subdomény je možné vytvářet u domén II. řádu. Za domény III. řádu se již neplatí správci domény. Před doménou třetího řádu může být ještě čtvrtá, pátá,… doména. V každé doméně jsou name servery (DNS servery). Name server zná jména všech počítačů ve své doméně a zná adresu name serveru v nadřazené doméně. Příklad:
server1.pedf.cuni.cz * server1 = počítač, doména 4. úrovně * pedf = Pedagogická fakulta, doména 3. úrovně * cuni = Univerzita Karlova, doména 2. úrovně * cz = Česká republika, TLD Počítač SERVER1 zná adresu name serveru v doméně CUNI a CUNI zná adresu domény CZ. Naopak CUNI zná jména všech počítačů ve své doméně. Každý registr domén má svou organizaci či osobu, která je jeho správcem a určuje pravidla pro registraci doménových jmen pro subdomény. Doménu CZ spravuje organizace CZ.NIC. Doménový strom a popis jednotlivých úrovní je vidět na tomto obrázku. Postupné přidávání úrovní do domén a vznik doménových jmen zobrazuje tento obrázek. Pojem FQDN = Fully Qualified Domain Name. Jedná se o označení pro plně specifikované doménové jméno počítače. Příklad: jméno počítače (FQDN) - pedf.cuni.cz. * . = Root Domaincz = tato část se nazývá TLD - Top Level Domain - doména první úrovněcuni = tato část je doménou druhé úrovně (2nd level domain)pedf = tato část je konkrétním jménem počítače (3rd level domain)

Doména I. řádu

Tato doména může být buď tematická (com pro komerci, edu pro vzdělávací instituce atd.) nebo státní. Pro Českou republiku je to .CZ, pro Polsko je to .PL, pro Německo .DE, atd.

Domény I. řádu se dělí:

Národní TLD (country-code TLD, ccTLD) sdružující domény jednoho státu. Jejich název je dvoupísmenný, až na výjimky odpovídající kódu země (dle ISO 3166-1), např. cz pro Českou republiku. Pravidla pro přidělování národní domény určuje příslušný správce. Mnoho zemí přiděluje svoji národní doménu všem zájemcům, bez ohledu na jejich státní příslušnost (mezi nimi ČR). Jiné státy povolují registraci národní domény pouze svým občanům a národním podnikům (např. Slovenská republika - sk).

Generické TLD (generic TLD, gTLD) sdružující obecné domény (např. org pro neziskové organizace), nespojené s jedním konkrétním státem (až na výjimku TLD .mil a .gov, které jsou z historických důvodů vyhrazeny pro vojenské, resp. vládní počítačové sítě v USA). Tyto domény se ještě dále dělí. Bude uvedeno pouze několik příkladů:

• neomezené (jejich využití není nijak omezeno) - com, info…
• vymezené (mohou být použity pouze pro daný účel) - biz (obchodní společnosti), int (mezinárodní nevládnoucí organizace)…
• exkluzivní (pouze subjekty v USA) - edu (vzdělávací instituce), gov (vláda)…
• infrastrukturní (využívané pro mechanismy internetu) - arpa (používá ji systém DNS pro zpětný překlad IP adres na doménové jméno)

Prostor doménových jmen tvoří strom s jedním kořenem. Každý uzel tohoto stromu obsahuje informace o části jména (doméně), které je mu přiděleno a odkazy na své podřízené domény. Kořenem stromu je tzv. kořenová doména, která se zapisuje jako samotná tečka. Pod ní se v hierarchii nacházejí tzv. domény nejvyšší úrovně.

Kořenový zónový soubor popisuje, kde se nacházejí autoritativní servery (viz níže) pro domény nejvyšší úrovně. Tento kořenový zónový soubor je relativně velmi malý a často se nemění - operátoři root serverů ho pouze zpřístupňují, samotný soubor je vytvářen a měněn organizací IANA.

Pojem root server (kořenový server) je všeobecně používán pro 13 kořenových jmenných serverů. Root servery se nacházejí ve 34 zemích světa, na více než 80 místech.

Tento obrázek není zcela přesný. Zjednodušeně je však možné si na něm vysvětlit princip fungování vyhledávání uzlu dle jména.

• Uživatel zadá do vyhledavače doménové jméno webové stránky, kterou chce zobrazit. V tomto případě je to jméno www.nic.cz.
• Lokální server nezná překlad této adresy na IP adresu, proto pošle dotaz na nějaký ze svých nadřazených serverů. Na obrázku e znázorněno zaslání dotazu přímo na root server, ve skutečnosti by se lokální server pravděpodobně nejdříve zeptal serveru poskytovatele nternetu pro daný počítač a postupně by postupoval s dotazy nahoru, až k root serveru (pokud by nikdo překlad neznal).
• Nakonec se lokální server skutečně zeptá některého z kořenových serverů. Ten odpověď nezná, ale ví, kam je delegována doména cz. Pošle tedy seznam jmenných serverů pro doménu cz.
• Lokální DNS použije informaci od kořenového serveru a zeptá se jednoho z těchto serverů na jméno www.nic.cz.
• Server opět odpověď nezná, ale jelikož obsahuje informaci o všech subdoménách cz, pošle nazpět informaci o tom, který další server obsahuje doménu nic.cz.
• Lokální server postupuje dále a zeptá se jednoho ze serverů, které poskytují doménu nic.cz, na jméno www.nic.cz.
• Dotázaný server obsahuje informaci o všech subdoménách nic.cz. Doménu www.nic.cz zná a pošle zpět odpověď, jménu www.nic.cz odpovídá IP adresa 217.31.201.43.
• Poté se tento překlad uloží do CACHE ISP serveru. Když budeme k webu přistupovat znovu, načte se odtud.

Tento princip velmi jasně a srozumitelně ukazují následující tři videa:

Systém názvů domén (DNS) rozděluje informace o doménách do zón. V zónách jsou uloženy informace o názvech jedné nebo několika domén DNS. Zóna je autoritativním zdrojem informací o všech názvech domén DNS, které jsou začleněny do této zóny.

Zóna se spouští jako databáze. Pokud jsou pod doménu použitou k vytvoření zóny přidány další domény, mohou být tyto domény součástí téže zóny nebo patřit k jiné zóně. Je-li přidána subdoména, může být:

• spravována a obsažena jako součást původních záznamů zóny,
• delegována do jiné zóny vytvořené pro podporu subdomény.

Následující obrázek znázorňuje doménu microsoft.com, která obsahuje názvy domén společnosti Microsoft. Při prvním vytvoření domény microsoft.com na jednom serveru je tato doména nakonfigurována jako jediná zóna pro všechny obory názvů DNS společnosti Microsoft. Pokud však doména microsoft.com používá subdomény, jsou tyto subdomény začleněny do této zóny nebo delegovány do jiné zóny.

Na tomto obrázku obsahuje doména example.microsoft.com novou subdoménu example.microsoft.com, která je delegována mimo zónu microsoft.com a je spravována ve své vlastní zóně. Zóna microsoft.com však musí obsahovat několik záznamů poskytujících informace o delegování. Ty odkazují na servery DNS, jež jsou autoritativní pro delegovanou subdoménu example.microsoft.com. Jinak řečeno, zóna obsahuje pouze informace o Microsoft.com a odkazy na name servery subdomén.

Pokud zóna microsoft.com nepoužívá delegování pro subdoménu, zůstávají veškerá data pro tuto subdoménu součástí zóny microsoft.com. Například subdoména dev.microsoft.com není delegována mimo, ale je spravována v rámci zóny microsoft.com.

Výhoda tohoto uspořádání spočívá v možnosti zónu rozdělit a správu její části svěřit někomu dalšímu. Nově vzniklá zóna se tak stane autoritativní (nezvratná) pro přidělený jmenný prostor. Právě možnost delegování pravomocí a distribuovaná správa tvoří klíčové vlastnosti DNS, které jsou velmi podstatné pro jeho úspěch. Ve vyšších patrech doménové hierarchie platí, že zóna typicky obsahuje jednu doménu. Koncové zóny přidělené organizacím připojeným k Internetu pak někdy obsahují několik domén - například doména kdesi.cz a její poddomény vyroba.kdesi.cz, marketing.kdesi.cz a obchod.kdesi.cz mohou být obsaženy v jedné zóně a obhospodařovány stejným serverem.

Na tomto videu můžete vidět vysvětlení DNS zón pomocí hezkého přirovnání k hierarchii ve firmě.

Tyto zóny obsahují informace pro převod jmenné doménové adresy na IP adresu. Klienti obvykle provádějí právě toto vyhledávání.

Služba DNS rovněž zajišťuje proces zpětného vyhledávání, který klientům umožňuje při dotazu na název použít známou adresu IP a podle této adresy vyhledat název počítače. Zpětné vyhledávání má formu otázky, kterou lze interpretovat například jako: „Chci znát název DNS počítače, který používá adresu IP 192.168.1.20.“

Služba DNS původně nebyla navržena k podpoře tohoto typu dotazu. Problémem při podpoře procesu zpětného vyhledávání je rozdíl v tom, jak obor názvů DNS řadí a indexuje názvy, a jak jsou přidělovány adresy IP. DNS adresy jsou totiž psány zleva doprava od nejkonkrétnějších k nejobecnějším informacím, naopak IP adresy začínají obecnými informacemi (adresa IP sítě) a až v jejich pravé části se objevují informace konkrétní (adresa IP hostitele). Pokud by jedinou metodou zodpovězení předchozí otázky bylo hledat ve všech doménách v oboru názvů DNS, zpětný dotaz by trval příliš dlouho a vyžádal by si příliš náročné zpracovávání, takže by nebyl užitečný.

K vyřešení tohoto problému byla ve standardech služby DNS definována a rezervována v oboru názvů DNS sítě Internet zvláštní doména, in-addr.arpa (inverse addresses in the arpanet), která zajišťuje praktický a spolehlivý způsob zpracování zpětných dotazů. Pro vytvoření zpětného názvu jsou v rámci domény in-addr.arpa vytvořeny subdomény, které používají zpětné řazení zápisu desítkových čísel adres IP s tečkou jako oddělovačem.

Z důvodu odlišného zápisu IP adres oproti DNS jmenným adresám musí být při vytváření struktury domény in-addr.arpa pořadí oktetů adres IP obrácené. Adresy IP stromu in-addr.arpa služby DNS mohou být přidělovány společnostem tak, jak jsou jim přidělovány specifické či omezené sady adres IP v rámci tříd adres definovaných v síti Internet.

Pokud dotazovaný zpětný název nelze ze serveru DNS zodpovědět, lze k lokalizaci serveru DNS oprávněného pro zpětnou vyhledávací zónu a obsahujícího dotazovaný název použít normální překlad DNS (rekurze nebo iterace). V tomto smyslu je proces překladu názvů používaný v zpětném vyhledávání stejný jako dopředné vyhledávání.

Podle uložení dat rozlišujeme následující typy name serverů:

Autoritativní name server

Udržuje data o své zóně v databázích na disku. Jeho data pro příslušnou zónu se považují za nezvratná (autoritativní). Zná definitivní odpověď na DNS dotaz. Neposkytuje pouze uložené odpovědi, které byly získané jiným name serverem, tudíž pouze vrací odpovědi na dotazy o doménových jménech, které jsou nainstalovány v jeho konfiguračním systému. Existují dva typy autoritativního name serveru:

Primární name server (master server)

Udržuje data o své zóně v databázích na disku. Pouze na primárním name serveru má smysl editovat tyto databáze. Je to tedy ten server, na němž data vznikají. Každá doména má právě jeden primární server.

Sekundární name server (slave server)

Kopíruje databáze v pravidelných časových intervalech z primárního name serveru. Každý „slave server„ dostane update master serveru přes speciální automatický aktualizační mechanismus DNS protokolu. Tyto databáze nemá smysl na sekundárním name serveru editovat, neboť budou při dalším kopírování přepsány. Slouží zejména jako záloha pro případ výpadku primárního serveru a taktéž pro rozkládání zátěže u frekventovaných domén. Každá doména musí mít alespoň jeden sekundární server. Doporučuje se však využívat minimálně 2 slave servery a 1 master server na každé doméně.

Caching only server

Není pro žádnou doménu ani primárním ani sekundárním name serverem (není žádnou autoritou). Avšak využívá obecné vlastnosti name serveru, tj. procházející data ukládá ve své paměti. Tato data se označují jako neautoritativní. Slouží tedy jako vyrovnávací paměť pro snížení zátěže celého systému. Uchovává si odpovědi a poskytuje je při opakování dotazů, dokud nevyprší jejich životnost. Každý server je caching server, ale slovy caching only zdůrazňujeme, že pro žádnou zónu není ani primárním ani sekundárním name serverem.

Root name server

Name server obsluhující root doménu. Každý root name server je primárním serverem, což jej odlišuje od ostatních name serverů.

Typy root serverů:

• A - VeriSign Global Registry Services
• B - University of Southern California - Information Sciences Institute
• C - Cogent Communications
• D - University of Maryland
• E - NASA Ames Research Center
• F - Internet Systems Consortium, Inc.
• G - U.S. DOD Network Information Center
• H - U.S. Army Research Lab
• I - Autonomica/NORDUnet
• J - VeriSign Global Registry Services
• K - RIPE NCC
• L - ICANN
• M - WIDE Project

Tyto root servery lze editovat ve vlastnostech serveru v záložce Odkazy na kořenové servery

Jeden name server může být pro nějakou zónu primárním serverem, pro jiné sekundárním serverem.

Z hlediska klienta není žádný rozdíl mezi primárním a sekundárním name serverem. Oba jsou stejně důležité, jsou pro danou zónu autority. Klient nemusí ani vědět, který server pro zónu je primární a který sekundární. Naproti tomu caching server není autoritou, tj. nedokáže-li provést překlad, pak kontaktuje autoritativní server pro danou zónu.

Autoritativní data pocházejí z databází na disku. Je zde pouze jedna výjimka. Pro správnou činnost name serveru musí name server znát root name servery. Pro ty však není autoritou, přesto každý name server má na disku databázi informací o root serverech, kterou ale zavádí příkazem cache do sekundární paměti (není k nim autorita).

Ještě existují dva další typy serverů: forwarding a slave servery. Tato vlastnost serveru nesouvisí s tím, zda jsou primární nebo sekundární servery pro nějakou zónu, ale souvisí se způsobem jejich překladu.

Je-li podniková síť připojena k Internetu pomalou linkou, pak místní name server zatěžuje linku svými překlady. V takovém případě je výhodné si name server konfigurovat jako forwarding server. Forwarding server vezme požadavek od klienta a předá jej forwarderovi na rychlé síti jako rekurzivní dotaz. Forwarder je server v Internetu, který je připojen rychlejšími linkami. Dotaz rekurzivně vyřeší a pošle našemu forwarding serveru konečný výsledek. Jako forwarder je praktické použít name server poskytovatele Internetu.

Forwarding server čeká na odpověď od forwardera. Nedočká-li se odpovědi v daném časovém intervalu, pak kontaktuje root name servery a pokouší se sám vyřešit překlad.

Nemá-li forwarding server kontaktovat root name servery, ale pouze čekat na odpověď od forwardera, pak je nutné označit takový server jako slave server. Tyto servery se používají v uzavřených podnikových sítích (za firewallem), kde není možný kontakt s root name servery. Slave server pak kontaktuje forwardera, který je součástí firewallu.

Na obrázku vidíme schéma fungování forwarding a slave serveru.

Pozn.: V tomto dělení se vyskytuje název „slave server“ pro dva různé typy serverů. Jednak je to jiný název pro sekundární name server, dále se používá ve vztahu k forwarding serveru. Nejedná se o chybu, tento název serveru je skutečně používán ve dvou různých významech.

Obsah zóny (domény či několika domén) je uložen v tzv. zónovém souboru, někdy též nazývaném databázový soubor. Skládá se z jednotlivých záznamů (přesný název zní zdrojové záznamy, Resource Records, RR) obsahujících dílčí informace.

Informace distribuované pomocí DNS jsou tedy uloženy v paměti DNS serverů ve tvaru zdrojových vět (RR). Name server naplňuje svou paměť několika způsoby. Autoritativní data načte ze souborů na disku, nebo je získá pomocí dotazu zone transfer z paměti jiného serveru. Neautoritativní data získává postupně z paměti jiných serverů, tak jak vyřizuje jednotlivé DNS dotazy.

Zónový soubor se dá vyexportovat pomocí příkazu v příkazové řádce:
dnscmd /zoneexport [název zóny] [název souboru].dns

V případě, že DNS klient (resolver) potřebuje získat informace z DNS, pak požaduje po name serveru věty RR podle zadaných požadavků. Klient může např. požadovat po serveru věty RR typu A, které obsahují IP adresy pro dané doménové jméno, apod.

Jednotlivá pole vět RR obsahují:

• NAME - Doménové jméno.
• TYPE - Typ věty.
• CLASS - Třída věty, rodina protokolů, k níž se záznam vztahuje. DNS lze teoreticky používat i pro jiné síťové architektury, v praxi však třída vždy bývá IN, což znamená Internet.
• TTL - Time to live. 32 bitové číslo, udávající dobu, po kterou může být tento RR udržován v cache server jako platný (obvyklá doba je 86400 sekund, což je 24 hodin). Po vypršení této doby musí být věta považována za neplatnou. Hodnota 0 zabraňuje neautoritativním serverům uložit RR větu do cache. Je to tedy číslo, které omezuje dobu platnosti dat nebo počet průchodů paketů skrz aktivní prvky počítačové sítě. Položku TTL využívá ke své činnosti program traceroute.
• RDLENGTH - 16 bitové číslo specifikující délku pole RDATA.
• RDATA - Vlastní data ve tvaru řetězce proměnné délky. Formát tohoto pole závisí na typu a třídě RR.

Na následujícím obrázku je zobrazena struktura RR včetně struktury některých typů těchto záznamů.

Věty SOA (Start Of Authority)

Každý zónový soubor musí začínat záznamem typu SOA. Tento speciální záznam se musí v každém zónovém souboru vyskytovat právě jednou. Jedná se o jakousi hlavičku, která obsahuje následující informace:

• jméno domény - většinou se píše znak @, který značí kořen domény, který je definován v /etc/named.conf
• MNAME - název primárního DNS serveru pro danou zónu
• RNAME - kontakt na správce zónového souboru - uvádí se e-mailová adresa, ve které je zavináč nahrazen za tečku (protože znak zavináče má v DNS speciální význam)
• SERIAL - sériové číslo zóny - číselný údaj, který udávající verzi zónového souboru; při změně v záznamech se číslo navýší a sekundární DNS servery si při porovnání s číslem, které mají uložené u sebe, zjistí, že došlo ke změně a že je třeba data aktualizovat
• REFRESH - počet sekund, po jejichž uplynutí od poslední kontroly či načtení zóny z primárního DNS provede sekundární server kontrolu sériového čísla
• RETRY - po zahájení zjišťování sériového čísla z předchozího bodu opakuje požadavek na primární DNS server po uplynutí RETRY sekund, pokud se předchozí požadavek nezdařil (pokud server neodpověděl)
• EXPIRE - pokud se nedaří stáhnout sériové číslo z primárního DNS a od posledního úspěšného pokusu uplynulo EXPIRE vteřin, je zóna považována za neplatnou a sekundární DNS server by ji měl vyřadit ze svých záznamů (zapomenout ji)
• MINIMUM TTL - jak dlouho mohou neautoritativní servery udržovat daný záznam ve vyrovnávací paměti

Všechny tyto položky jsou znázorněny na následujícím příkladu záznamu SOA. Na prvním řádku se vyskytuje jméno domény, nahrazené @, dále MNAME a RNAME. Dále jsou uvedeny data ve stejném pořadí, v jakém byla popsána výše.

Příklad zónového souboru

DNS je nutné přidat jako novou roli (pokud máte nainstalované AD, tak DNS také. AD je na DNS jsou závislé). Pokud jsme tuto roli ještě nepřidali, přidáme ji takto:

Správa - Přidat role a funkce - u Rolí serveru zaškrtneme Server DNS a nainstalujeme vše s ním spojené.

Zkontrolujeme, zda máme vyplněnou adresu DNS. Pro kontrolu otevřeme Síťová připojení (jedna z cest: Místní disk - kliknutí na adresu Sítě Ethernet). V Síťovém připojení si přes kliknutí na Ethernet pravým tlačítkem otevřeme jeho vlastnosti. Zde si otevřeme vlastnosti Protokolu IP verze 4 a poté 6.
Vyplníme následovně:

Stejná adresa DNS by se nám měla zobrazit, zadáme-li do příkazového řádku příkaz ipconfig /all.

Tento příkaz je zkratkou tří slov - internet protocol configuration, do češtiny by bylo možné ho přeložit jako nastavení internetového protokolu. Tento příkaz vypisuje údaje o různých síťových kartách a zařízeních.

Po této kontrole můžeme otevřít samotný DNS Manager, se kterým budeme později pracovat. Na prvním obrázku vidíme cestu k DNS Manageru, na druhém již otevřený DNS Manager.

Otevřel se nám Správce DNS

Nyní si nakonfigurujeme DNS. Klikneme na SERVER pravým tlačítkem a vybereme volbu „Konfigurovat server DNS“.

Otevře se nám průvodce konfigurací.

V případě, že chceme nastavit Caching-only server, vybereme poslední možnost Konfigurovat pouze kořenové odkazy. Žádné zóny pak nekonfigurujeme.

Nyní máme na výběr jaké zóny chceme konfigurovat. My si vybereme obě zóny.

Nyní si vytvoříme zóny dopředného vyhledávání

V okně vybíráme typ zóny - vytvoříme zónu primární.
Primární a sekundární zóny byly podrobně popsány v předchozích kapitolách.

Kromě těchto zón nám průvodce ještě nabízí typ Zóna se zakázaným inzerováním. Ta uchovává pouze odkazy na autoritativní DNS servery domény. Jedná se o kopii zóny, která obsahuje pouze NS, SOA a A záznamy.

Pokud server DNS hostuje zónu se zakázaným inzerováním, je tento server pouze zdrojem informací o autoritativních názvových serverech pro tuto zónu. Zóna na tomto serveru musí být získána z jiného serveru DNS, který tuto zónu hostuje. Tento server DNS musí mít síťový přístup ke vzdálenému serveru DNS, aby mohl kopírovat informace o autoritativním názvovém serveru této zóny.

Jakmile server DNS načte zónu se zakázaným inzerováním (například widgets.tailspintoys.com), dotáže se hlavních serverů, které se mohou nacházet jinde, na potřebné záznamy o prostředcích autoritativních serverů pro zónu widgets.tailspintoys.com. Seznam hlavních serverů může obsahovat jeden nebo několik serverů a může se kdykoli změnit.

Zóny se zakázaným inzerováním lze použít k následujícím účelům:

• Udržování aktuálních informací o delegované zóně: Při pravidelné aktualizaci zóny se zakázaným inzerováním o jednu z jejích podřízených zón bude server DNS, který hostuje nadřazenou zónu i zónu se zakázaným inzerováním, udržovat aktuální seznam autoritativních serverů DNS pro podřízenou zónu.
• Vylepšený překlad názvů: Zóny se zakázaným inzerováním umožňují, aby server DNS prováděl rekurzi pomocí seznamu názvových serverů zóny se zakázaným inzerováním, takže není nutné posílat dotazy na obor názvů DNS internetovému nebo internímu kořenovému serveru.
• Zjednodušení správy DNS: Při použití zón se zakázaným inzerováním v infrastruktuře DNS lze seznam autoritativních serverů DNS pro zónu distribuovat bez použití sekundárních zón. Zóny se zakázaným inzerováním však neslouží ke stejnému účelu jako sekundární zóny a nelze je použít jako alternativu pro zvýšení redundance a rozložení zatížení.

Toto nastavení lze později změnit kliknutím na Vlastnosti u vybrané zóny, v záložce Obecné, sekce Typ tlačítkem Změnit…

Pod výběrem typ zóny se ještě zobrazí možnost uložit do AD. Bude-li zaškrtnuta, databáze zón bude uložena v Active Directory databázi. Díky tomu se zjednodušuje administrace, zvyšuje bezpečnost a umožňuje automatické replikace. Můžeme toto pole nechat zaškrtnuté.

V dalším okně budeme vybírat obor replikace služeb zóny AD. Vybereme druhou možnost „Na všechny servery DNS běžících na řadičích domény v této doméně: pedf.cuni.cz„.

• • Na všechny servery běžící na řadičích domény v této doménové struktuře

  • - Tato možnost slouží k replikaci dat zóny do oddílu ForestDNSZones. Proto poskytuje nejširší rozsah replikace.
  • • Na všechny servery DNS běžící na řadičích domény v této doméně - Tato možnost slouží k replikaci dat zóny do oddílu DomainDNSZone.
  • • Na všechny řadiče domén v této doméně - Replikuje data zóny na všechny řadiče domény v rámci domény Active Directory.

  Toto nastavení lze později změnit kliknutím na Vlastnosti u vybrané zóny, v záložce Obecné, sekce Replikace tlačítkem Změnit…

Nyní si zónu pojmenujeme. Název je možné zvolit libovolný, v tomto postupu je zóna pojmenovaná test.cz.

Zobrazí se okno s možnostmi dynamické aktualizace. Povolíme pouze zabezpečené dynamické aktualizace, vybereme tedy první možnost.

Dynamická aktualizace umožňuje klientským počítačům DNS registrovat a dynamicky aktualizovat záznamy o prostředcích na serveru DNS, kdykoli proběhnou změny. To snižuje potřebu ruční správy záznamů zón, zejména u klientů, kteří se často stěhují nebo mění místo a získávají adresu IP pomocí služby DHCP.

Nyní vytvoříme zónu zpětného vyhledávání.

Je to stejné jako z zóny dopředného vyhledávání.

Opět stejné jako u zóny dopředného vyhledávání.Vybereme druhou volbu.

Nyní si vybíráme, pro který typ adres chceme zónu vytvořit. My si vybereme IPv4, IPv6 vytvoříme později.

Nyní zadáme název zóny zpětného vyhledávání. Bude se skládat z prvních třech čísel IP adresy. V tomto příkladě vytváříme zpětnou zónu pro test.cz, zadaná IP adresa tedy bude 192.168.1. Ve formulářovém okénku v dolní části se bude automaticky vyplňovat obrácené pořadí těchto čísel.

Zobrazí se okno s možnostmi dynamické aktualizace. Stejně jako u dopředných zón povolíme pouze zabezpečené dynamické aktualizace, vybereme tedy první možnost.

Nyní zadáme servery pro předávání. 8.8.8.8 je DNS googlu.

Tyto servery umožnují nastavit pro určité adresy přístup přímo na určitý server. Odpadá tedy výše popsané vyhledávání přes uzle, jak bylo popsáno výše. Tím pádem je vyhledávání těchto adres mnohem rychlejší. Dále se dají servery pro podmíněné předávání použít pro přístup na servery, které jsou jiným způsobem nepřístupné. Díky tomu jsou tyto servery chráněny.

Například server DNS lze například konfigurovat tak, že bude předávat všechny přijaté dotazy na názvy zakončené příponou prakticke.priklad.com na adresu IP určeného serveru DNS nebo na adresy IP více serverů DNS.

Určíte-li server DNS jako server pro předávání, učiníte jej zodpovědným za zpracování externích přenosů. Tím se sníží ohrožení serverů DNS z Internetu. Server pro předávání vytváří velkou mezipaměť externích informací DNS, protože řeší všechny externí dotazy DNS v síti. Během krátké doby řeší server pro předávání pomocí těchto dat uložených v mezipaměti mnoho externích dotazů DNS. Snižují se tak internetové přenosy přes síť a zkracuje se doba odezvy pro klienty DNS.

Server DNS, který je nakonfigurován tak, aby používal server pro předávání, se chová jinak než server DNS, který tak nakonfigurován není. Chová se takto:

• Pokud server DNS obdrží dotaz, pokusí se ho vyřešit pomocí zón, jejichž je hostitelem, a pomocí své vyrovnávací paměti.
• Nemůže-li server DNS vyřešit dotaz pomocí lokálních dat, předá dotaz serveru DNS, který je určen jako server pro předávání.
• Nejsou-li servery pro předávání k dispozici, pokusí se server DNS vyřešit dotaz pomocí svých odkazů na kořenové servery.

Server DNS při předání dotazu serveru pro předávání pošle tomuto serveru rekurzivní dotaz. Je to jiné než při standardním překladu názvů (překladu názvů, který nezahrnuje server pro předávání), kdy server DNS odešle jinému serveru DNS iterační dotaz.

Nyní se zobrazí přehled všech nastavení, která jsme zvolili. Posledním kliknutím vytvoříme zóny.

Nyní si vytvoříme zónu zpětného vyhledávání pro IPv6.

Ve správci DNS klikneme pravým tlačítkem na „Zóny zpětného vyhledávání“ a Vytvoříme novou zónu.

Nyní si vybíráme, pro který typ adres chceme zónu vytvořit. IPv4 už máme, tak si vytvoříme IPv6.

Nyní zadáme prefix IPv6 pro které chceme zónu vytvořit. Musíme ho zadat i s délkou.

Zobrazí se okno s možnostmi dynamické aktualizace. Stejně jako u dopředných zón povolíme pouze zabezpečené dynamické aktualizace, vybereme tedy první možnost.

Nyní se zobrazí přehled všech nastavení, která jsme zvolili. Posledním kliknutím vytvoříme zónu.

Nyní můžeme v naší zóně test.cz vytvořit první záznam, konkrétně hostitele, takzvaný A záznam.

Pro jeho vytvoření rozklikneme zónu test.cz Pravým tlačítkem klikneme do pole zóny a vybereme možnost „Nový hostitel (A nebo AAAA)…“

Hostitel A a AAA

Objeví se okno „Nový hostitel“, do kterého vepíšeme název hostitele.
Hostitel A = hostitel pro IPv4
Hostitel AAA = hostitel pro IPv6

• Zde je jako název vybrána „stanice„. Zároveň je automaticky vyplněno FQDN, kam se k názvu hostitele přidá název zóny a tečka na konci, root.
• Vyplníme IP adresu tohoto hostitele.
• Zaškrtneme pole „Vytvořit přidružený záznam o ukazateli (PTR)“, neboli záznam umožňující zpětný překlad IP adresy na doménové jméno.

V předchozích kapitolách bylo uvedeno, že doménová adresa může mít svůj alias zvaný CNAME. Tento alias je velmi snadné vytvořit.

Začneme stejně, jako když jsme vytvářeli nového hostitele. Pravým tlačítkem klikneme buď na název zóny v levé liště, nebo do pole otevřené zóny. Objeví se nám nabídka, z které vybereme možnost „Nový alias (CNAME)…„

Otevře se nám podobné okno, jaké vidíme během vytváření hostitele.

• Do první kolonky uvedeme název aliasu, na tomto příkladu je uveden název „serv“
• Kolonka FQDN se stejně jako během vytváření hostitele vyplní sama.
• Poté je nutné vybrat, jakému hostiteli alias přiřadíme.
  • U poslední kolonky klikneme tedy na tlačítko „Procházet„.
  • Vybereme nás Server
  • Zóny dopředného vyhledávání
  • Klikneme na naší doménu test.cz
  • Zde je vybrán hostitel „server“

Nslookup.exe je nástroj příkazového řádku pro testování a odstraňování problémů se servery DNS, je to nejčastěji používaný program v souvislosti s DNS. Je instalován spolu s protokolem TCP/IP prostřednictvím Ovládacích panelů.

Nástroj Nslookup.exe lze používat ve dvou režimech: interaktivním a neinteraktivním. Neinteraktivní režim se hodí pouze v případě, že potřebujete vrátit jednotlivé údaje. Jeho syntaxe je:

nslookup [-parametr] [název hostitele] [server]

My budeme pro testování našich záznamů používat interaktivní režim tohoto programu. Přejdeme na klienta a do příkazového řádku zadáme příkaz nslookup a potvrdíme ho Entrem. Po tomto příkazu se zobrazí výchozí DNS server a jeho IP adresa.

Po prvním zadání tohoto příkazu již můžeme testovat výše vytvořené záznamy (pokud příkaz vypisuje Server: Unknown, restartujeme server). Na screenshotu vidíte testování 3 doménových adres - server.test.cz, pcklient.cuni.cz (klientský pc) a google.com. Po zadání a potvrzení každé z těchto adres vypíše nslookup server, na kterém doména běží společně s jeho IP adresou. V dalších řádcích se objeví doménové jméno zadané domény a její překlad na IP adresu.

DNS Manager nabízí ještě další možnost spuštění nástroje nslookup. Po kliknutí pravým tlačítkem na náš server se objeví nabídka a v ní právě možnost otevření nslookup. Otevře se nám okno, které funguje stejně jako příkazový řádek po zadání příkazu nslookup.

Jak již bylo výše řečeno, sekundární zóny slouží především k zálohování primárních zón a snížení zátěže na síti. Ukážeme si tedy vytvoření i tohoto typu zóny dopředného vyhledávání.

POZOR - Sekundární zóna lze vytvořit jedině na druhém serveru (fyzickém nebo virtuálním, ale nikoli na stejné stanici)

Nejprve je nutné vhodně upravit nastavení primární zóny, kterou bude naše nová sekundární zóna zálohovat. Na tomto příkladu budeme zálohovat zónu test.cz. Otevřeme okno jejích vlastností (pravé tlačítko na název zóny - Vlastnosti) a zobrazíme si záložku „Přenosy zón„. Zde povolíme přenosy zón na libovolný server, aby bylo možné vytvořit zálohu. Své nastavení potvrdíme.

Nyní vytvoříme sekundární zónu. Otevřeme průvodce vytvoření nové zóny (pravé tlačítko na Zóny dopředného vyhledávání - Nová zóna).

Vybereme možnost „Sekundární zóna“. Dále zadáme název nové zóny

V dalším okně zadáme IP adresu nebo název zóny, kterou chceme kopírovat. V našem případě můžeme zadat buď test.cz nebo 192.168.1.

Dokončíme tvorbu zóny tak, jak bylo uvedeno u vytváření primární zóny.

Protokol událostí serveru DNS, který obsahuje záznamy o chybách, výstrahách a dalších událostech na serveru DNS. V DND Manageru vypadá takto:

Někdy se může stát, že je třeba změnit IP adresu serveru. V jednodušší formě stačí změnit záznam v A a AAAA hostiteli. Vzhledem ale k tomu, že informace o serveru se čerpají ze zónového souboru, je třeba je ujistit, že provedené změny byly aplikovány kontrolou souboru případně příkazem nslookup.

Pro změnu adresy serveru rozklikneme Zóny dopředného vyhledávání. Vybereme patřičnou zónu, klepneme na ni pravým tlačítkem a vybereme Vlastnosti

Přejdeme na záložku Názvové servery a upravíme patřičný záznam

V případě, že máme server s více síťovými kartami, můžeme nastavit, aby DNS server naslouchal adresám pouze jedné (nebo i více) z nich. Toto nastavení může případně zvýšit zabezpečení.

Ve Správci DNS klikneme na Server pravým tlačítkem a vybereme Vlastnosti.

Na záložce Rozhraní můžeme vybrat Naslouchání buď Na všech IP adresách nebo Pouze na následujících. Vybereme námi požadovanou možnost a popřípadě upravíme IP adresy, kterým má server naslouchat.

DNS server si ukládá do databáze záznamy o adresách, aby je mohl rychleji překládat. Taková databáze se může rychle zvětšovat. Kvůli povaze dns záznamů se často mění IP adresy i jména a záznamy jsou brzy neaktuální. Proto se na serveru může nastavit doba stárnutí a uklízení záznamů. Windows server umožňuje nastavit pro záznamy 2 druhy intervalů:

• Minimální interval mezi aktualizacemi
  • Doba mezi poslední aktualizací časového razítka záznamu a okamžikem, kdy může být časové razítko znovu aktualizováno.
• Interval aktualizace
  • Doba mezi okamžiem, kdy může být časové razítko nejdříve aktulizováno, a okamžikem, kdy může být záznam uklizen.

Ve Správci DNS serveru klikneme na náš Serverm pravým tlačítkem a vybereme Nastavit možnosti stárnutí a úklidu pro všechny zóny…

V otevřeném okně zaškrtneme políčko Uklidit zastaralé záznamy o prostředcích (funkce není zapnutá ve výchozím nastavení) a pak provedeme patřičné změny.

V případě, že potřebujeme upravit chování zóny při získávání IP adresy, máme 2 možnost:

• Upravit zónový soubor
• Klikneme pravým tlačítkem na Vlasnotni dané zóny a přepneme na záložku Záznam Start of Authority (SOA). Poté provedene potřebné úpravy.

DNS klient je klientová komponenta, která zjišťuje a ukládá jména DNS domén. Jakmile DNS klient přijme žádost o zařazení DNS jména, které není obsaženo v jeho CACHE, tak vyšle požadavek danému DNS serveru o IP adresu daného jména. Jakmile DNS klient přijme vyžádanou adresu, uloží ji spolu se jménem do své CACHE, aby ji měl připravenou pro budoucí použití, aniž by musel opět zasílat požadavek DNS serveru. Všechny počítače, které využívají DNS ke zjišťování doménových jmen (včetně DNS serveru a doménového kontroloru), používají pro tyto případy DNS klienta.

Ukážeme si několik příkladů příkazů příkazového řádku, které může klient v souvislosti s DNS využít.

• Spusťte příkazový řádek.
• Zadejte: ipconfig /flushdns

ARP (Address Resolution Protocol) se v počítačových sítích s IP protokolem používá k získání ethernetové MAC adresy sousedního stroje z jeho IP adresy. Používá se v situaci, kdy je třeba odeslat IP datagram na adresu ležící ve stejné podsíti jako odesilatel. Data se tedy mají poslat přímo adresátovi, u něhož však odesilatel zná pouze IP adresu. Pro odeslání prostřednictvím např. Ethernetu ale potřebuje znát cílovou ethernetovou adresu.

Proto vysílající odešle ARP dotaz (ARP request) obsahující hledanou IP adresu a údaje o sobě (vlastní IP adresu a MAC adresu). Tento dotaz se posílá linkovým broadcastem - na MAC adresu identifikující všechny účastníky dané lokální sítě (v případě Ethernetu na ff:ff:ff:ff:ff:ff). ARP dotaz nepřekročí hranice dané podsítě, ale všechna k ní připojená zařízení dotaz obdrží a jako optimalizační krok si zapíší údaje o jeho odesilateli (IP adresu a odpovídající MAC adresu) do své ARP cache. Vlastník hledané IP adresy pak odešle tazateli ARP odpověď (ARP reply) obsahující vlastní IP adresu a MAC adresu. Tu si tazatel zapíše do ARP cache a může odeslat datagram.

Informace o MAC adresách odpovídajících jednotlivým IP adresám se ukládají do ARP cache, kde jsou uloženy do vypršení své platnosti. Není tedy třeba hledat MAC adresu před odesláním každého datagramu, jednou získaná informace se využívá opakovaně. V řadě operačních systémů (Linux, Windows) lze obsah ARP cache zobrazit a ovlivňovat příkazem arp.

Princip fungování protokolu ARP je znázorněn na následujícím obrázku.

Alternativou pro počítač bez ARP protokolu je používat tabulku přiřazení MAC adres IP adresám definovanou jiným způsobem, například pevně konfigurovanou. Tento přístup se používá především v prostředí se zvýšenými nároky na bezpečnost, protože v ARP se dá podvádět. Místo skutečného vlastníka hledané IP adresy může odpovědět někdo jiný a stáhnout tak k sobě data pro něj neurčená.

arp -a - zobrazí IP adresu a MAC adresu určeného počítače

Příkaz ping je základní diagnostický prvek, kterým můžeme otestovat funkčnost v TCP/IP sítích. V případě potíží s připojením můžete pomocí příkazu ping zkontrolovat dostupnost cílové adresy IP a zaznamenat dosažený výsledek. Příkaz ping zobrazí informace, zda počítač na cílové adrese odpověděl a jak dlouhá doba uplynula mezi vysláním dotazu a přijetím odpovědi. Dojde-li při pokusu o přenos dotazu k chybě, příkaz ping zobrazí chybovou zprávu.

Základní syntaxe tohoto příkazu vypadá tak, že do příkazového řádku zadáme příkaz ping [jmenná nebo ip adresa]

Využití příkazu ping si ukážeme na dvou příkladech. Na prvním vyzkoušíme námi vytvořeného hostitele server.test.cz.

Stejné výsledky bychom měli získat také v případě, že zadáme alias tohoto hostitele, tedy serv.test.cz.

V této části wiki byly představeny (popř. připomenuty) čtyři příkazy příkazového řádku. Na tomto místě ve stručnosti popíšeme jejich funkce.

• ipconfig - vypisuje údaje o různých síťových kartách a zařízeních
• nslookup - testování a odstraňování problémů se servery DNS
• arp - získání ethernetové MAC adresy sousedního stroje z jeho IP adresy
• ping - kontrola dostupnosti cílové adresy IP

Tento soubor je pokládat za předchůdce DNS. Je to textový dokument, ve kterém je možné ručně přepsat IP adresy i názvy domén. Počítač tento soubor kontroluje jako první, až poté využívá DNS.

Tento soubor je možné prakticky využít, chceme-li používat internet ještě před nastavením DNS. Dále je možné ho použít při správě malého množství počítačů, u kterých DNS nastavit nechceme.

Soubor hosts snadno najdeme v každém počítači. Stačí do vyhledavače zadat „hosts„ a dokument najdeme. Na tomto screenshotu vidíme jeho podobu.

Zde uvádíme zdroje, ze kterých jsme čerpali informace pro vytvoření těchto wiki stránek o DHCP a DNS. Není-li to z názvů zdrojů jasné, uvádíme pod nimi také popis toho, co v nich najdete.

HESTER, Matthew. Microsoft windows server 2012 administration instant reference. Indianapolis, IN: John Wiley, 2013. ISBN 978-1-118-56188-1.

BIJEČEK, Richard. DNS, DHCP [online]. [cit. 2015-04-17]. Dostupné z: http://www.cs.vsb.cz/navrat/vyuka/sws/prednasky/pred07.pdf.

• základní informace o DNS, infrastruktura DNS, domény, DNS komunikace, DNS záznamy
• DNS zóny, dynamická aktualizace, příkazy
• informace o DHCP

CALETKA, Ondřej. DNS pro začátečníky [online]. c2012 [cit. 2015-04-18]. Dostupné z: http://www.linuxalt.cz/files/stazeni/2012/2012-11-03-LA-105-06-Ondrej_Caletka-DNS_pro_zacatecniky.pdf.

• základní informace o DNS, zóny DNS, RR, zónový soubor, typy záznamů

MICHÁLEK, Viktor. DNS - Domain Name System [online]. [cit. 2015-04-20]. Dostupné z: http://www.fi.muni.cz/~kas/p090/referaty/2011-jaro/ut/dns.html.

• historie a struktura DNS, typy DNS serverů, průběh dotazu, typy DNS záznamů

ŠUMSKÝ, David. DNS [online]. [cit. 2015-04-20]. Dostupné z: http://www.fi.muni.cz/~kas/p090/referaty/2003-jaro/skupina12/dns.html.

• základní informace o DNS, historie, doménový systém, zóny, typy serverů, zdrojové záznamy

Co dělat, když mi nejde internet? 3. díl | Dostupnost UPC [online]. c2013 [cit. 2015-04-17]. Dostupné z: http://www.dostupnyinternet.cz/blog/co-delat-kdyz-mi-nejde-internet-3-dil/.

• popis příkazu ipconfig

Diagnostika sítě - příkaz Ping [online]. [cit. 2015-04-21]. Dostupné z: http://it.cestuji.info/ping.php.

Doména nejvyššího řádu - Wikipedie [online]. c2014 [cit. 2015-04-16]. Dostupné z: http://cs.wikipedia.org/wiki/Dom%C3%A9na_nejvy%C5%A1%C5%A1%C3%ADho_%C5%99%C3%A1du.

K čemu vlastní doménu, když mám… [online]. c2015 [cit. 2015-04-13]. Dostupné z: http://www.nic.cz/files/enum/img/CZ.NIC_DNS_edukacni_letak.pdf.

• IP adresa, domény a jejich úrovně, jak funguje DNS

Použití příkazu ping [online]. c2015 [cit. 2015-04-21]. Dostupné z: https://technet.microsoft.com/cs-cz/library/cc737478(v=ws.10).aspx.

Používání nástroje NSlookup.exe [online]. c2015 [cit. 2015-04-20]. Dostupné z: https://support.microsoft.com/cs-cz/kb/200525/cs.

Program nslookup [online]. [cit. 2015-04-20]. Dostupné z: http://zam.opf.slu.cz/botlik/CD-1x/14.html.

Protokol ARP (Address Resolution Protocol) [online]. c2015 [cit. 2015-04-21]. Dostupné z: https://technet.microsoft.com/cs-cz/library/cc758357(v=ws.10).aspx.

Věty Resource Records - Root-server.cz [online]. [cit. 2015-04-17]. Dostupné z: http://www.root-server.cz/vety-rr.html.

Individuální adresy (unicast). In: Ipv6 [online]. 2005 [cit. 2016-04-27]. Dostupné z: https://www.ipv6.cz/Individu%C3%A1ln%C3%AD_adresy_%28unicast%29

Povinné adresy. In: Ipv6 [online]. 2005 [cit. 2016-04-27]. Dostupné z: https://www.ipv6.cz/Povinn%C3%A9_adresy

Adresy. In: Ipv6 [online]. 2005 [cit. 2016-04-27]. Dostupné z: https://www.ipv6.cz/Adresy

Coje IPv6. In: Ipv6 [online]. 2005 [cit. 2016-04-27]. Dostupné z: https://www.ipv6.cz/Co_je_IPv6

Pro upřesnění praktických postupů při práci s DHCP a DNS zde najdete několik tutoriálů. Pro snadnější práci je u každého uveden jeho stručný obsah, u těch delších také časy, ve kterých najdete potřebné informace.

První tutoriál je namluven v angličtině a věnuje se konfiguraci DHCP.

Obdobnou problematikou, tedy instalaci a konfiguraci DNS, popisuje tento anglický tutoriál. Ukazuje nastavení pevné IP adresy a adresy DNS serveru. V DNS Manageru popisuje vytvoření zóny dopředného a zpětného vyhledávání, tvorbu hostitele a ukazatele. Vše poté testuje pomocí příkazu nslookup.

Poslední anglický tutoriál se kromě praxe věnuje více teorii DNS. Na začátku je popsáno, co je DNS a k čemu slouží. Dále seznamuje uživatele s DNS Managerem (7:30), ukazuje možnosti jeho obnovy a čištění a globální události. Na závěr (13:03) se věnuje zónám dopředného vyhledávání a tvorbě hostitele. Ty jsou následovně testovány pomocí příkazu ping. Tento tutoriál je poněkud rozvleklý, ale výborně srozumitelný.