IPv6 samozřejmě umožňuje takzvanou stavovou konfiguraci prostřednictvím DHCPv6, u ní ale zpravidla správce sítě musí pro jednotlivé počítače cosi konfigurovat. Ten pravý bezobslužný ráj zajišťuje bezstavová konfigurace, jejímž základem je objevování sousedů (Neighbor Discovery, ND).
Jeho prostřednictvím počítač získá svou adresu, masku sítě i adresy implicitních směrovačů pro odesílání datagramů za hranice podsítě. Chybí v něm ale informace o místním DNS serveru, na nějž se má počítač obracet s DNS dotazy. Tato informace je nicméně velmi podstatná, protože život v síti bez DNS je jen těžko představitelný.
Značná pozornost se proto věnuje již několik let návrhu mechanismů pro automatickou konfiguraci adresy lokálního DNS serveru. Názory však dosud nejsou jednotné a ve hře je několik variant. Nedávno vyšlo informativní RFC 4339 shrnující navržené mechanismy a hodnotící jejich klady a zápory. Podívejme se, co je k mání.
Rozšíření objevování sousedů
Jestliže základem bezstavové automatické konfigurace je objevování sousedů, jedním z přirozených kandidátů je doplnit do něj chybějící informaci o místním DNS serveru. Návrh draft-jeong-dnsop-ipv6-dns-discovery (aktuálně ve verzi 8) proto navrhuje umožnit v ohlášení směrovače (Router Advertisement) novou volbu RDNSS, která by obsahovala adresy DNS serverů, které mají počítače používat.
Předností tohoto přístupu je, že počítače dostávají „vše v jednom“ – prostřednictvím jediné služby dostanou kompletní podklady pro konfiguraci. Jelikož objevování sousedů pracuje s dobou platnosti jednotlivých informací, lze zároveň dynamicky reagovat na případné změny. Navíc se jedná o nadstavbu známé služby, s níž jsou praktické zkušenosti a ví se, co od ní očekávat.
Na druhé straně objevování sousedů bývá typicky implementováno v jádře operačního systému. Jeho změna tedy vyžaduje zásah do jádra. I samotná změna již zavedené a fungující služby je sama o sobě potenciálním zdrojem problémů.
Bezstavové DHCP
DHCP samozřejmě dokáže poskytnout adresy DNS serverů. Pokud správce nechce použít DHCP ke kompletnímu nastavení komunikačních parametrů, může sáhnout po takzvaném bezstavovém DHCP definovaném v RFC 3736. Je koncipováno jako doplněk k bezstavové autokonfiguraci, tedy k objevování sousedů.
Počítač si základní síťové parametry (adresy a implicitní brány) opatří bezstavovou konfigurací a na bezstavové DHCP se obrátí pro ostatní informace, jež v objevování sousedů chybí. To samozřejmě podstatným způsobem zjednodušuje správu DHCP serverů, které v principu mohou běžet i na směrovačích (někteří výrobci již bezstavové DHCP podporují).
DHCP je dobře známá technologie, která navíc podporuje jak dobu platnosti poskytovaných informací, tak princip rekonfigurace na žádost serveru. Umožňuje tedy dynamické změny informací. Významnou předností zde je, že veškerá konfigurace může pocházet z jednoho zdroje, z jedné datové základny. V případě potřeby lze konfiguraci poskytovat individuálně, „na míru“ jednotlivým zařízením. Navíc je vše již popsáno v RFC, není třeba vyvíjet či rozšiřovat stávající mechanismy. DHCP definuje také mechanismy pro své rozšiřování, které umožňují později doplňovat další konfigurační informace.
Nevýhody bezstavového DHCP jsou spíše marginální. Vyžaduje přenos několika málo zpráv, což může být nevýhodou v prostředí velmi chudém na přenosovou kapacitu či extrémně náročném na rychlost automatické konfigurace. Vyřízení DHCP dialogu přece jen stojí špetku času.
Dobře známá výběrová adresa
Se zajímavou myšlenkou přišel Masataka Ohta. Navrhl využít pro DNS výběrové (anycast) adresy, které zaručí, že dotaz bude doručen vždy nejbližšímu serveru hlásícímu se k dané adrese. Doporučuje zavést tři konstantní výběrové adresy pro místní DNS servery, které by se používaly vždy a všude. Byly by předkonfigurovány v DNS klientech a nic by se na nich nemuselo měnit.
DNS server by vhodným směrovacím protokolem ohlásil svou přítomnost a směrovače by mu na základě toho předávaly DNS dotazy z blízkého okolí. Aby se situace zjednodušila, v návrhu se požaduje, aby na každé lince byl nanejvýš jeden server s danou výběrovou adresou, a aby tedy doručování paketů na ni směřujících bylo vždy jednoznačné. Redundance se dosáhne tak, že při neúspěchu se klient obrátí na další z dobře známých adres.
Tato koncepce má řadu zajímavých vlastností. Nic se nepřenáší, takže není třeba definovat žádné protokoly ani datové formáty, navíc je konfigurace zařízena okamžitě. Pokud daný zákazník nemá vlastní DNS server, může snadno využívat DNS server svého poskytovatele – jednoduše bude nejbližší.
Vyžaduje ovšem, aby DNS servery aktivně vstoupily do směrovacího procesu, a s největší pravděpodobností budou nutné i konfigurační úpravy na směrovačích (povolení individuálních směrovacích záznamů, jejich filtrování, aby se nešířily mimo instituci a podobně). Za nedostatek lze považovat i skutečnost, že návrh draft-ohta-preconfigured-dns pochází z února 2004 a od té doby nebyl aktualizován.
Každá z navržených variant má rozhodně něco do sebe a teprve budoucnost ukáže, která se prosadí v nejširším měřítku, případně bude deklarována za jedinou podporovanou. Já osobně bych se lehce klonil k té prostřední. Především z toho důvodu, že umožňuje snadné potenciální budoucí rozšiřování o další informace, které možná za pár let budou považovány za stejně samozřejmé jako dnes DNS.
