Vytváření a konfigurace zón DNS. Co je reverzní zóna v DNS. Co je PTR záznam?

V tomto materiálu se podíváme na konfiguraci jmenovaného programu při organizaci doménového serveru, jehož hostitelé jsou distribuováni ve dvou fyzických sítích IP třídy C (v notaci CIDR x.x.x.x/24). Hlavní pozornost bude věnována „reverzním“ zónám, protože „Přímá“ zóna se v tomto případě výrazně neliší od zóny uvažované při popisu malé podnikové domény.

Situace uvažovaná v tomto případě je typická pro organizace, které mají více než jednu síť třídy C, kde je nutné nasadit podnikovou doménu. Přesněji řečeno, nemluvíme jen o sítích třídy C.

Předpokládejme, že fondy adres, které jsou přiděleny organizaci a jejím divizím, nejsou jediným adresním prostorem, ale řezem několika bloků adres. Navíc jsou tyto bloky ořezány tak, aby adresy vypadaly jako z různých oblastí, pokud vezmeme v úvahu adresní prostor z hlediska zápisu CIDR x.x.x.x/24. Například:

192.168.0.0/24 a 192.168.10.0/24

Z hlediska popisu korespondence mezi doménovým jménem a IP adresou v „přímé“ zóně zde nejsou žádné problémy:

$ORIGIN en.
test IN SOA ns.test.ru. hostmaster.test.ru (
233 3600 300 9999999 3600)
;
IN NS ns.test.ru.
V NS ns.privider.ru.
V A 192.168.10.1
IN MX 10 mail.test.ru.
IN MX 20 mail.provider.ru.
;
ns IN A 192.168.10.1
pošta IN A 192.168.0.1
www IN A 192.168.10.2
ftp IN A 192.168.0.2

Příklad ukazuje, že záznamy adres lze v popisu zóny dokonale „namíchat“. Přímou zónu lze tedy definovat na libovolné sadě sad adres, které lze libovolně rozptýlit po celém adresním prostoru.

Samozřejmě jsou adresy, do kterých by se nemělo zasahovat. Například by se neměly směšovat směrovatelné a nesměrovatelné adresy. Ve skutečnosti v příkladu používáme přesně to druhé (více informací o nesměrovatelných adresách viz RFC 1918).

Pokud požadujete IP adresu z internetu pomocí názvu domény a jako odpověď obdržíte adresu z nesměrovatelného fondu, není jasné, co s tím dělat. I když se sami nacházíte v nesměrovatelné síti, adresa přijatá zvenčí ze stejné sítě s největší pravděpodobností není adresa, kterou hledáte.

Ve skutečnosti může stejný server doménových jmen podporovat směrovatelné i nesměrovatelné shody, ale pro snazší prezentaci je lepší tento případ ponechat pro samostatnou analýzu v jiném materiálu.

A tak v „přímé“ zóně můžeme „zasahovat“ adresy, ale jak můžeme zachovat reverzní shody? V případě „reverzních“ zón totiž máme co do činění také s doménovými jmény, i když jsou tvořeny inverzí IP adres. Oddělovač v hierarchii názvů domén je znak ".", proto budou hranice bajtů v adrese odpovídat hranicím vnoření domény.

Řešení je jednoduché – vytvořte dvě reverzní zóny 0.168.192.in-addr.arpa a 10.168.192.in-addr.arpa. Bude to vypadat nějak takto:

3600 $ TTL

10 V SOA ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600)
IN NS ns.test.ru.
V NS ns.privider.ru.
1 V PTR ns.test.ru.
2 V PTR www.test.ru.

A pro 0.168.192.in-addr.arpa. respektive:

3600 $ TTL
$ORIGIN 168.192.in-addr.arpa.
0 IN SOA ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600)
IN NS ns.test.ru.
V NS ns.privider.ru.
1 V PTR ns.test.ru.
2 V PTR www.test.ru.

Na hlavním serveru musí být deklarovány dvě "reverzní" zóny. V BIND 4.x by to v souboru named.boot vypadalo nějak takto:

adresář /etc/namedb
primární test.ru test.ru
primární localhost localhost
primární 127.in-addr.arpa localhost.rev
primární 10.168.192.in-addr.arpa 10.168.192.in-addr.arpa
primární 0.168.192.in-addr.arpa 0.168.192.in-addr.arpa
xfrnets 192.168.20.1 a 255.255.255.255
cache. pojmenovaný.kořen
možnosti no-recursion no-fetch-glue fake-iquery

Ve skutečnosti je z hlediska kontextu tohoto materiálu důležité, že mezi řídicími směrnicemi jsou dvě primární směrnice pro odpovídající reverzní zóny.

Zde je pouze vhodné upřesnit, že v tomto případě je adresa 192.168.20.1 adresou podřízeného serveru, který má povoleno kopírovat zónu. Účel zbývajících řídicích direktiv je podrobně popsán v části „Malá firemní doména v doméně ru Popis „dopředných“ zón.

Pokud jde o soubor named.conf pro verze BIND 8.xa 9.x, jeho obsah bude vypadat nějak takto:

možnosti (
adresář "/etc/namedb";
allow-query(any;);
rekurze ne;
fake-iquery ano;
č. aportovacího lepidla;
use-id-pool ano;
};
//Nápověda pro kořenový server
zóna "." ( zadejte nápovědu; soubor "named.root"; );
// Forward Loopback
zóna "localhost" (
typový mistr;
soubor "localhost";
};
// Reverse Loopback
zóna "0.0.127.in-addr.arpa" (
typový mistr;
soubor "localhosr.rev";
};
// Firemní doména
zóna "test.ru" (
typový mistr;
soubor "test.ru";

};

zóna "0.168.192.in-addr.arpa" (
typový mistr;
soubor "0.168.192.in-addr.arpa";
povolit přenos ( 192.168.20.1; );
};
// Reverzní firemní doména
zóna "10.168.192.in-addr.arpa" (
typový mistr;
soubor "10.168.192.in-addr.arpa";
povolit přenos ( 192.168.20.1; );
};

Tento popis také obsahuje dvě direktivy pro reverzní zóny, na které jsou mapována jména. Popis je poněkud delší než u BIND 4.x kvůli jinému formátu konfiguračního souboru, ale jeho podstata je stejná.

Zde je třeba poznamenat, že se objevuje několik reverzních zón, například pro sítě jako x.x.x.x/23. Celý problém spočívá v tom, že fond adres, například 192.168.0.0.23, kombinuje dva sousední bloky 192.168.0.0/24 a 192.168.1.0/24. Proto budou existovat dvě odpovídající reverzní zóny: 0.168.192.in-addr.arpa a 1.168.192.in-addr.arpa. Standardním způsobem je lze kombinovat pouze na úrovni 168.192.in-addr.arpa, nikoli však nižší.

Z výše uvedeného vyplývá, že vlastník zóny 168.192.in-addr.arpa musí delegovat odpovědnost za správu dvou reverzních zón na svého klienta, pokud je nechce spravovat sám.

Podobné poznámky platí pro fondy adres x.x.x.x/16 a fondy adres x.x.x.x.8, tzn. sítě tříd B a A. Prostor doménových jmen reverzní zóny byl vytvořen s přihlédnutím ke staré klasifikaci adres v době, kdy ještě nebyla notace CIDR široce používána.

RFC 1519 podrobně popisuje mapování adresního prostoru CIDR na „supernet“ sítí třídy C, tzn. pooly adres, které jsou tvořeny podsítěmi sítí třídy B a A Poskytovatel musí v tomto případě delegovat odpovídající reverzní zóny na klienty a ti jim poskytují podporu podobným způsobem jako v diskutovaném případě 192.168.0.0/23. výše.

1. Albitz P., Lee K.. DNS a BIND. - Per. z angličtiny - Petrohrad: Symbol-Plus, 2002. - 696 s.
2. P. Mockapetris. RFC-1034. DOMÉNOVÁ JMÉNA - KONCEPCE A ZAŘÍZENÍ. ISI, 1987. (

Systém doménových jmen je základem moderního internetu. Lidé se nechtějí obtěžovat zapamatováním množiny čísel 63.245.217.105, ale chtějí, aby je počítač připojil k určenému uzlu pomocí názvu mozilla.org. To je to, co servery DNS dělají: překládají požadavky lidí do digitálního formátu, kterému rozumějí. V některých případech však může být vyžadována reverzní IP adresa → konverze jmen DNS. O takových jménech bude řeč níže.

k čemu to je?

Správně nakonfigurovaná adresa rDNS je naprosto nezbytná pro odesílání zpráv z vašeho vlastního firemního e-mailového serveru. Téměř všechny poštovní servery odmítnou zprávu na začátku relace, pokud adresa IP vašeho serveru nemá záznam v reverzní zóně DNS. Důvod selhání vzdáleného poštovního serveru bude s největší pravděpodobností označen následovně:
550-"IP adresa nemá žádný záznam PTR (adresa k názvu) v DNS, nebo když záznam PTR nemá odpovídající záznam A (název k adrese). Prosím zkontrolujte a opravte svůj DNS záznam."

nebo
550-Neexistuje žádný odpovídající PTR pro vaši IP adresu (IP-adresu), která je vyžadována 550. Promiňte, nashledanou.

nebo jen
550 Vaše IP nemá žádný záznam PTR

Číslo 550 je ve všech třech případech standardním kódem poštovního serveru SMTP a hlásí kritickou chybu, která nepřekonatelně brání další práci v rámci této poštovní relace. Je třeba říci, že obecně jsou všechny chyby řady 500 kritické a poté, co se objeví, není možné pokračovat v odesílání pošty. V textu je podrobněji vysvětlen důvod odmítnutí a uvádí se, že správce poštovního serveru příjemce jej nakonfiguroval tak, aby zkontroloval, zda má odesílající poštovní server záznam v reverzní zóně DNS (rDNS), a pokud není přítomen, příjemce server je povinen odmítnout odesílateli připojení (chyby řady SMTP-5XX).

Jak nastavit a používat?

Právo konfigurovat reverzní zónu DNS má pouze vlastník odpovídajícího bloku IP adres, kterému tato zóna odpovídá. Tímto vlastníkem je zpravidla poskytovatel, který vlastní svůj autonomní systém. Více o registraci vašeho autonomního systému (AS) a bloku IP adresy si můžete přečíst v tomto článku. Stručně řečeno, k registraci reverzní zóny DNS musí provozovatel bloku IP adres zaregistrovat objekt typu „doména“ ve svém osobním účtu na webu RIPE, uvést adresu serverů DNS, které budou zónu rDNS podporovat a nakonfigurujte na nich podporu pro zónu typu 3.2.1.in -addr.arpa. Ukazatel, záznam PTR, je zodpovědný za zdroje v reverzní zóně. Zde směřují požadavky na překlad IP adresy na název hostitele.

Pokud nejste šťastným vlastníkem autonomního systému, nastavení rDNS pro IP adresu nebo adresy poštovního serveru pro vás začíná a končí požadavkem na službu podpory poskytovatele nebo hostitele. V obou případech by měl být smysluplně uveden název IP adresy poštovního serveru a zejména firemního poštovního serveru.

Příklady dobrých jmen pro poštovní server:

mail.domena.ru
mta.domain.ru
mx.domain.ru

Příklady špatných jmen:

hostitel-192-168-0-1.domena.ru
zákazník192-168-0-1.domena.ru
vpn-dailup-xdsl-clients.domain.ru

a podobně. Taková jména budou s vysokou pravděpodobností filtrována jako přiřazená klientským počítačům, na které nelze nainstalovat poštovní server, a proto je z nich odesílán spam.

Můžete a měli byste úspěšně používat dotazy k obrácení zón DNS ihned po spuštění poštovního serveru. K tomu je potřeba provést pouze drobné softwarové úpravy. Na různých poštovních serverech se nastavení kontroly rDNS provádí odlišně:

takže pro poštovní server Postfix musíte tuto možnost povolit
odmítnout_neznámého_klienta

na jiném oblíbeném poštovním serveru Exim
ověřit = reverse_host_lookup

MS Exchange Server
V modulu snap-in serveru Exgange přejděte do části Servery, vyberte server v rozbaleném seznamu, vyberte položku Protokoly, poté protokol SMTP, v pravém okně vyberte server SMTP a klikněte pravým tlačítkem myši a vyberte ze seznamu Vlastnosti. Dále karta Doručování → Provádět zpětné vyhledávání DNS u příchozích zpráv

Nyní budou všechny zprávy z IP adres, které nemají reverzní DNS záznam (záznamy typu PTR), odmítnuty a tok spamu se výrazně sníží. Možná je to nejjednodušší, nejúčinnější a nejméně náročná na zdroje ze všech metod filtrování spamu: zpětná kontrola DNS odřízne drtivou většinu spamu odeslaného z infikovaných počítačů běžných uživatelů, kteří tvoří botnety spammerů.

Při opětovném publikování článku je vyžadována instalace aktivního indexovaného hypertextového odkazu na zdrojový web!

Rašíd Achilov

Vytváření DNS zón

Domain Name System je druh „nervového systému“ internetu. Díky ní se při psaní dostanete na stránky časopisu „Správce systému“ a ne jinam. Jak vytvořit, nakonfigurovat a spustit server DNS pro malou firmu?

Struktura DNS

V současné době je internet obrovskou sítí, která zahrnuje miliony uzlů rozmístěných po celém světě. Aby požadavek podaný z jednoho počítače dosáhl cíle umístěného na jiném počítači, musí být tento cíl nejprve specifikován. IP adresu můžete samozřejmě zadat přímo. Pokud ho znáte, samozřejmě. Zde je ale možné velmi snadno udělat chybu – informace o tom, kde se Vám požadovaná adresa již mohla změnit a v lepším případě se Vám zobrazí hláška, že adresa nebyla nalezena a v horším případě ocitnete se na webu, který nemá absolutně nic společného s tím, co bylo potřeba. Bude spolehlivější a snazší obrátit se na systém, který uchovává korespondenci mezi symbolickými názvy jako www.site a IP adresami, které jim v tuto chvíli odpovídají (v našem případě 217.144.98.99). DNS je takový systém. Protože na jeho úspěšném fungování závisí provoz celého internetu, funguje tento systém na principu distribuované databáze - existuje 13 „známých“ serverů, nazývaných také „kořenové“ servery, obsahující informace o serverech, obsahující informace o serverech atd. Jako dům, který postavil Jack.

Celá internetová síť, která je popsána zónou „.“ (tečka) se dělí na tzv. TLD (Top Level Domains), distribuované buď funkčně nebo geograficky. Existuje také termín primární doména - „primární doména“ nebo „doména první úrovně“, ale tento termín se používá mnohem méně často. Zeměpisná distribuce se provádí v souladu s normou ISO 3166, která stanoví dvou- a třípísmenné kódy pro všechny země světa. Přidělování podle funkčního základu se provádí podle potřeby pro vytvoření nové TLD. Zde je třeba poznamenat, že všechny záležitosti týkající se TLD jsou řešeny ICANN (Internet Corporation for Assigned Names and Numbers) a právě tento orgán rozhoduje o vytvoření nové TLD.

Samotné kořenové servery obsahují pouze odkazy na servery obsahující informace o zónách druhé úrovně, které zase obsahují informace o serverech obsahujících informace o zónách třetí úrovně atd. Ve většině případů hierarchie končí na třetí nebo čtvrté zóně. Ale ne proto, že by zde bylo nějaké omezení. Pamatovat si složitá jména není o nic jednodušší než IP adresy.

Proces vyhledávání informací, řekněme o webovém serveru www.granch.ru, tedy bude vypadat takto:

• Klient kontaktuje svůj DNS server, jehož adresu nastavil správce systému s požadavkem „Řekni mi adresu odpovídající názvu www.granch.ru“.
• DNS server zná adresy serverů, ze kterých má začít hledat, pokud požadovaná informace není uložena v jeho cache, a tak se obrátí na jeden z nich.
• Kořenový server mu pošle adresu serveru odpovědného za zone.ru
• Server DNS přistupuje k serveru zone.ru
• Server zone.ru mu pošle adresu serveru, který je zodpovědný za zónu zrnitosti v rámci jeho zóny.
• DNS server přistupuje k serveru zóny granch.ru.
• A nakonec mu server zóny granch.ru sdělí adresu odpovídající názvu www. V tomto případě to bude 81.1.252.58.

Tento proces je znázorněn na Obr. 1, kde čísla udávají pořadí požadavků.

Jak integrovat vaše informace do struktury DNS?

Než se připojíte k jakémukoli systému, musíte mít určitou představu o tom, kde a jak se připojit.

Kam to vložíme?

Různé servery jsou zodpovědné za různé TLD, a pokud je za geografické domény zodpovědný zpravidla jeden server (přesněji jedna organizace), pak obecně řečeno neomezený počet tzv. registrátorů, tedy společností, které mají uzavřeli zvláštní smlouvy, mohou být odpovědní za funkční domény s ICANN, že to budou oni, kdo registruje jména v určitých funkčních doménách. Je uveden stručný popis funkční domény a adresa jejího registrátora.

Je-li registrátorů více, uvádí se adresa hlavního z nich (například VeriSign pro doménu.com). Domény .gov a .mil jsou vyhrazeny výhradně pro americkou vládu a americké vojenské organizace a rezervace .gov je formalizována odpovídajícím RFC - RFC 2146. Kompletní seznam všech aktuálně existujících geografických TLD s uvedením registrátora domény a nezbytných kontaktních informací naleznete v. I když, řekněme, na zone.com si můžete vybrat z velkého seznamu, pak pro zones.ru a.su RUTSENTR neexistují žádné možnosti.

Zde je třeba poznamenat několik bodů. Zone.su ve skutečnosti patří k neexistujícímu státu Sovětský svaz, i když je nadále obsluhován a je otevřen pro registraci. Registrace je tam poměrně drahá – 100 dolarů za registraci nebo podporu ročně.

Neexistuje žádná priorita, kdy by jedna organizace nebo osoba měla při registraci domény přednost před jinou. Jeden americký obchodník, který se zabýval výrobou plastových oken, si zaregistroval doménu windows2000.com. Když se o totéž pokusil Microsoft, s překvapením zjistil, že jméno je již obsazeno a společnost za něj musela zaplatit vysokou částku. Existuje dokonce pojem „cybersquatting“ - proces registrace domén za účelem jejich následného prodeje. Na tom se rozhodl podílet i RUTSENTR a podle nových pravidel, která jsou zavedena 1. června 2006, se uvolněné domény dávají do „aukce doménových jmen“ a převádějí se na toho, kdo nabídne nejvyšší nabídku. Jména jsou držena v „aukci“ po dobu jednoho roku, pokud je během tohoto období nikdo neuplatní, je jméno uvolněno k bezplatné registraci.

Když byly vytvořeny výše uvedené TLD, TLD .xxx byla také plánována pro stránky s tematikou pro dospělé. ICANN tento návrh odmítl. Nedávno byl předložen k druhému hlasování a ICANN jej znovu odmítl. Ale objevil se TLD .tel, navržený pro současné použití na počítačích a mobilních zařízeních.

Existuje RFC 1480, který popisuje pravidla pro registraci jmen v doméně .us. Tato pravidla jsou extrémně těžkopádná a matoucí a vyžadují vytvoření jmen z 6-7 úrovní jako Hamilton.High.LA-Unified.K12.CA.US

Jak to vložíme?

Dříve bylo vše mnohem složitější. Pro registraci zone.com jsem musel vyplnit spoustu textových formulářů - s údaji o organizaci, s údaji o kontaktních osobách... Tyto formuláře se pak rozesílaly na speciální adresy, odkud přicházely odpovědi - přijaté či nepřijaté. Předem vytvořený soubor zóny byl poté testován a znovu byla odeslána zpráva e-mailem, která oznamovala, zda bylo testování úspěšné nebo ne.

Nyní je vše mnohem jednodušší. Network Solutions i RUTSENTR získaly webová rozhraní, s jejichž pomocí lze vše výše uvedené (samozřejmě kromě vytvoření zónového souboru) provést na pár kliknutí myší. Veškeré údaje lze kdykoli opravit, doplnit nebo smazat. Dříve bylo nutné uzavřít servisní smlouvu s RUCENTER, ale od 1. června 2006 jsou zavedena nová pravidla, podle kterých se stačí zaregistrovat na jejich webu. Zahraniční registrátoři si zpravidla vystačí s kreditními kartami, ale pokud doménu nelze z jakéhokoli důvodu zaregistrovat, peníze vrátí nejdříve po třech dnech.

Registrátor bude muset poskytnout IP adresu a masku podsítě serveru, na kterém bude spuštěn program serveru DNS a který bude obsahovat hlavní databázi, kterou vytvoříte a upravíte podle potřeby. Tento server se bude nazývat primární server (master server). Kromě toho budete muset zadat alespoň jednu IP adresu serveru obsahujícího záložní kopii databáze pro případ selhání primárního serveru. Takové servery se nazývají sekundární servery (slave servery). Abyste dlouze nepřemýšleli, kam sekundární DNS umístit, nabízí RUCENTER umístění na jejich stránky. Náklady na služby RUCENTER jsou 15 USD za rok za doménu v zones.ru, .net, .com, .org, 50 USD za doménu v zónách .biz, .info, 100 USD za doménu v zone.su a 5 USD za rok pro podporu sekundárního DNS v jakékoli zóně (včetně těch, které u nich nejsou registrovány).

Proč je požadavek na sekundární server DNS povinný? Protože stabilita DNS je nesmírně důležitá pro stabilitu internetu jako celku, osoba nebo organizace registrující doménu musí splňovat určité podmínky týkající se stability DNS:

• Tuto doménu musí obsluhovat alespoň dva servery.
• Tyto servery musí být dostupné alespoň 22 hodin denně.

Podle nových pravidel neexistují žádné požadavky na umístění serverů, ačkoli dříve bylo požadováno, aby byly umístěny v různých IP sítích.

www.krokodil.ru

Řekněme tedy, že chceme vytvořit web www.krokodil.ru (v době psaní tohoto článku byl zdarma), věnovaný chovu krokodýlů doma. Poskytovatelem je přiděleno vyhrazené linkové připojení, síť třídy C, konkrétně 212.20.5.0 – 212.20.5.255 (tento rozsah je aktuálně zdarma). Tento příklad je poněkud netypický pro současnou dobu s nedostatkem IP adres, ale byl vzat speciálně za účelem zvážení vytvoření reverzní zóny. Zvažována bude i možnost připojení přes síť 212.20.5.0/31. Vnitřní síť naší chovatelské kanceláře krokodýlů se skládá ze šesti počítačů a bude oddělena od internetového firewallu-proxy atd., na kterém běží FreeBSD. Co budeme potřebovat k realizaci našich plánů?

Nejprve si všimnu, že existují možnosti, které nevyžadují žádnou znalost DNS - vše je hostováno na webu poskytovatele, vše je obsluhováno poskytovatelem, máte k dispozici pouze webové rozhraní. Tato služba je velmi populární v zahraničí, ale v Rusku je velmi málo poptávaná. Jeho popis je nad rámec tohoto článku, takže ho nebudu zvažovat.

Nejprve budeme potřebovat program serveru DNS. K dnešnímu dni pouze jeden program implementuje požadovanou sadu funkcí. Jedná se o BIND DNS server distribuovaný ISC (Internet System Consortium Inc.), nezisková organizace, která vyvíjí BIND, DHCP, INN a NTP servery. Pokud ve vašem systému není, musíte si jej stáhnout a nainstalovat. FreeBSD se dodává s BIND 9.3.2, takže tento článek se zaměří na tuto verzi. Je třeba poznamenat, že pro verze BIND 8.x jsou následující popisy konfigurace zcela nevhodné, protože formát konfiguračních souborů BIND 8.x se zásadně liší od formátu konfiguračních souborů BIND 9.x.

Za druhé, budeme muset distribuovat IP adresy, které nám byly přiděleny, a přiřadit adresy interním počítačům. Vše je zde velmi jednoduché: nechť 212.20.5.1 je brána poskytovatele, 212.20.5.2 je adresa serveru UNIX, 10.87.1.0/24 je vnitřní podsíť, ve které se nacházejí pracovní stanice 1 až 6, 254 je adresa server interního rozhraní. Zbývající adresy budou rezervovány pro budoucí rozšíření.

Za třetí, budete potřebovat předem připravený soubor s popisem zóny, který bude definovat malý počet externích adres: krokodil.ru – kořenový server zóny, www.krokodil.ru, ftp.krokodil.ru, mail.krokodil.ru a ns.krokodil.ru . Název ns (nameserver) je již téměř tradiční název pro počítače, na kterých služba DNS běží, i když vám samozřejmě nikdo nebrání ho nazývat například jaws.krokodil.ru. Názvy budou také definovány pro počítače ve vnitřní síti, přístupné pouze zevnitř: zub1.krokodil.ru – zub6.krokodil.ru.

DNS záznamy

Existuje poměrně velké množství různých typů záznamů, které lze umístit do DNS. Rozsah tohoto článku nám umožňuje vzít v úvahu pouze ty nejdůležitější z nich pro úplné informace, měli byste se obrátit na příslušné RFC: RFC 1033 a RFC 1035 definují základní formáty záznamů, RFC 1122 – formát záznamu PTR, RFC 2782 –; záznamový formát SRV. Budeme uvažovat pouze ty záznamy, které jsou potřebné k vygenerování souborů zóny požadovaných pro registraci domény:

• Záznam SOA, který určuje začátek popisu zóny.
• Záznam NS, který definuje jmenné servery zóny.
• Záznam A, který mapuje IP adresu na jméno (přímý překlad).
• Záznam MX, který popisuje nastavení doručování pošty pro tento počítač.
• Záznam CNAME, který uvádí alternativní názvy.
• V popisu „reverzní“ zóny je použit záznam PTR, který specifikuje shodu mezi jménem a IP adresou (reverzní překlad).

Formát DNS záznamu je společný pro všechny typy záznamů:

[jméno] [třída]<тип> <данные>

• Jméno– jedná se o název objektu, se kterým jsou data spojena;
• ttl– životnost objektu;
• Třída– záznamová třída;
• typ– typ záznamu;
• data– data spojená s tímto objektem.

Název může nabývat libovolné hodnoty, v takovém případě je považován za název objektu. Pokud název končí tečkou, je považován za plně kvalifikovaný, jinak je název zóny nahrazen na konci názvu, který lze zadat dvěma způsoby:

• Zadáním názvu zóny v direktivě $ORIGIN, například:

$ORIGIN krokodil.ru

• Zadáním názvu zóny v direktivě zóny konfiguračního souboru BIND.

Speciální znak „@“ označuje název aktuální zóny. Všimněte si, že direktiva $ORIGIN přepíše direktivu zóny a trvá, dokud se neobjeví další direktiva $ORIGIN nebo do konce souboru. Dokud se neobjeví první direktiva $ORIGIN, je považována za nastavenou na hodnotu direktivy zóny v konfiguračním souboru BIND.

Pokud je zadán název, musí začínat na první pozici řádku.

TTL se obvykle vynechává a nastavuje globálně direktivou $TTL. Direktiva $TTL je pro BIND 9.x povinná a obvykle se nastavuje na samém začátku souboru. Datové pole této směrnice specifikuje životnost (v sekundách) prvku, během kterého může zůstat v mezipaměti a být považován za spolehlivý. V tomto příkladu jsou to dva dny (48 hodin).

172 800 $ TTL

Vstupní třídou může být jedna z následujících hodnot:

• V– záznam internetových zdrojů.
• CH– záznam zdrojů ChaosNet – síť pro ruského uživatele zcela neznámá, používaná na strojích Symbolics.
• H.S.– Záznam zdroje Hesiod – servisní protokol BIND.

Typ záznamu je jedním z výše uvedených typů.

Upozorňujeme, že pole name, ttl a class lze vynechat. V tomto případě se jako jejich hodnoty bere poslední definovaná hodnota (v tomto případě bude správnou definicí zadání @), a pokud hodnota nebyla nikde definována, pak pro pole třídy je výchozí hodnota „IN“ přijato, u ostatních polí vede k chybové zprávě.

Kromě položek může soubor zóny obsahovat příkazy. Existují celkem čtyři příkazy: $TTL, $ORIGIN, $INCLUDE a $GENERATE. Popis příkazu $GENERATE je uveden v dokumentaci k programu BIND, stejně jako v a, příkaz $INCLUDE funguje podle jeho pravopisu - obsahuje zadaný soubor v aktuálním souboru.

Poznámka: znak ";" (středník) je značka komentáře.

Záznam SOA

Tato položka definuje začátek zóny. Každá zóna musí začínat záznamem SOA. Objevení se další položky SOA automaticky ukončí první zónu a začne druhou. Formát záznamu SOA je uveden níže. Záznam SOA ve skutečnosti pojmenuje zónu a nastaví pro ni některé výchozí hodnoty.

2005122001; Sériové číslo

3600; Opakujte každou hodinu

172800); Minimálně 2 dny

Podívejme se na příklad. Znak @ v poli názvu znamená, že je nutné převzít název zóny dříve určený direktivou $ORIGIN. Třída záznamu je IN, typ záznamu je SOA. SOA je jediná položka, která má tak komplexní seznam parametrů.

Prvním parametrem je adresa hlavního jmenného serveru zóny. V tomto příkladu je to krokodil.ru. Druhým parametrem je emailová adresa osoby odpovědné za tuto zónu. Vezměte prosím na vědomí, že adresa je zapsána jako "uzivatelske_jmeno.domena" a ne "uzivatelske jmeno@domena".

Druhý parametr je seznam hodnot uzavřený v závorkách. Teoreticky je možné to zapsat do jednoho řádku, ale v praxi jsem to nikde neviděla forma zápisu uvedená v příkladu; Seznam se skládá z pěti prvků:

• Sériové číslo zóny. Toto nastavení hraje mimořádně důležitou roli při šíření aktualizace provedené na primárním serveru na všechny jeho sekundární servery. Musí existovat nějaký způsob, jak informovat sekundární server, že se data na primárním serveru změnila. Pokud byl primární server restartován, odešle DNS NOTIFY všem sekundárním serverům. Po obdržení tohoto upozornění si sekundární server vyžádá sériové číslo – pokud má primární server vyšší sériové číslo než sekundární server, sekundární server vydá příkaz k aktualizaci zóny. Kromě toho sekundární server provádí pravidelné kontroly sériového čísla za stejným účelem. Proto byste si měli zapamatovat jedno jednoduché pravidlo: pokud zónu opravíte, zvyšte sériové číslo! Běžnou praxí mezi správci DNS je vytvořit sériové číslo takto: RRRRMMDDv, kde:
  • YYYY, MM, DD– aktuální rok (4 číslice), měsíc a den
  • proti– zónová verze pro daný den. Pokud je za den provedeno několik změn, toto číslo se postupně zvyšuje o jednu.
K takové praxi vás samozřejmě nikdo nebude nutit. Například DNS servery ve Windows jej nedodržují, ale jednoduše očíslují 1, 2, 3 atd.
• Hodnota periody aktualizace, po které musí podřízený server kontaktovat master a zkontrolovat, zda se sériové číslo zóny nezměnilo. Pokud se sériové číslo změnilo, podřízený server stáhne nová data. V tomto příkladu 10800 sekund (3 hodiny).
• Doba, po které se podřízený server pokusí kontaktovat master, pokud selže pokus o získání nového sériového čísla. V tomto příkladu 3600 sekund (jedna hodina).
• Doba, po kterou budou podřízené servery obsluhovat požadavky pro danou zónu v případě dlouhé nepřítomnosti hlavního serveru. Systém musí fungovat i v případě, že hlavní server nepracuje delší dobu, proto je hodnota tohoto parametru nastavena na 1 728 000 sekund (20 dní).
• Doba ukládání do mezipaměti záporné odpovědi. V tomto příkladu 172 800 sekund (2 dny).

Vstup NS

Tato položka uvádí názvy serverů, které zónu podporují, tj. vede její základnu. Zde by měly být uvedeny názvy primárních a všech sekundárních serverů. Obvykle tato položka bezprostředně následuje po položce SOA. Do datového pole se zadává jedna hodnota – název nebo IP adresa serveru zóny DNS, bez ohledu na to, zda se jedná o master nebo slave. Všechna zde uvedená jména musí být plně kvalifikovaná, to znamená končit tečkou!

V NS ns.krokodil.ru.

V NS ns4.nic.ru.

V uvedeném příkladu nejprve popíšeme hlavní server naší zóny ns.krokodil.ru a poté podřízený server - uzel RU CENTER ns4.nic.ru.

Záznam A

Záznam typu A je hlavním obsahem souborů v přímé konverzní zóně nebo jednoduše „přímé“ zóně, to znamená, že udává název počítače podle jeho adresy. Je sestaven pro každý počítač. Pro snadnější čitelnost jsou tyto záznamy obvykle seskupeny ve vzestupném pořadí IP adres a jsou také seskupeny se záznamy MX odpovídajícími dané IP adrese, i když to samozřejmě není vyžadováno. Do pole jméno se zadává jméno přiřazené k IP adrese, do datového pole IP adresa, ke které je jméno přiřazeno. Pokud má adresa další jména, název přiřazený k adrese záznamem A se nazývá primární název.

zub1 V A 10.87.1.1

zub2 V A 10.87.1.2

zub3 V A 10.87.1.3

zub4 V A 10.87.1.4

zub5 V A 10.87.1.5

zub6 V A 10.87.1.6

Tento příklad popisuje přidělování IP adres počítačům ve vnitřní síti, která má adresu 10.87.1.0/24. U počítačů v interní síti zpravidla není potřeba vytvářet žádné další záznamy, snad s výjimkou CNAME.

záznam CNAME

Záznam CNAME je volitelná funkce DNS. Umožňuje vám přiřadit více než jedno jméno k jedné IP adrese. Do pole jméno se zadává dodatečné jméno přiřazené k IP adrese, do datového pole - hlavní jméno dříve přiřazené záznamem typu A, nebo jiné dodatečné jméno přiřazené záznamem CNAME. V tomto případě se jméno v datovém poli záznamu nazývá kanonický (odtud název záznamu - Canonical Name). Jedné IP adrese lze přiřadit neomezený počet dalších jmen prostřednictvím záznamů CNAME, ale jiné typy záznamů musí používat název přiřazený záznamem A, nikoli záznamem CNAME. Níže je uveden příklad správného a nesprávného přiřazení dalších jmen.

Právo:

ns IN A 10.87.1.1

jméno1 IN CNAME ns

IN MX 10 ns

Špatně:

ns IN A 10.87.1.254

jméno1 IN CNAME ns

Název IN MX 101

Záznamy CNAME na sebe mohou ukazovat, maximálně však sedm úrovní, osmá musí být záznam směřující na jméno přiřazené záznamem typu A V literatuře existuje doporučení používat více záznamů typu A namísto přiřazování více další jména k adrese. V této souvislosti můžeme říci, že tento bod je zmíněn v RFC 2219 ve smyslu „neexistují žádná absolutní doporučení v této věci, každý se musí rozhodnout sám, co je pro něj nejlepší“. Správa více záznamů CNAME je snazší, manipulace s více záznamy A je snazší, protože dochází k menšímu počtu přesměrování.

Záznam MX

Záznam MX je druhým hlavním prvkem souboru zóny. Tento záznam znamená "Mail eXchanger" a je určen k označení IP adres nebo názvů počítačů, které přijímají poštu pro uzel popsaný v poli názvu. Toto pole může být prázdné, může se jednat o plně nebo částečně kvalifikovaný název. Pokud je pole názvu prázdné nebo je zadáno neúplně kvalifikované jméno, pak je název doplněn direktivou $ORIGIN. Generování MX záznamů ve složitých případech, kdy je nakonfigurována poměrně velká zóna s rozsáhlým schématem příjmu pošty, je velmi netriviální úkol, který je úzce provázán s prací programů, které pro doručování pošty používají protokol SMTP, takže zvažte pouze nejjednodušší případ - veškerá pošta je přijímána serverem UNIX. Do datového pole se zadávají dvě hodnoty - priorita a název nebo IP adresa počítače, který přijímá poštu odeslanou na tento počítač. K jedné IP adrese může být obecně přidružen neomezený počet záznamů MX a všechny by měly mít různé priority. Pošta je směrována podle priority – poštovní agent třídí záznamy podle rostoucí priority a pokouší se doručovat poštu tímto způsobem. Předpokládejme, že jsme se s administrátorem uzlu behemot.ru dohodli, že můžeme jeho server použít jako tranzitní uzel, který bude přijímat naši poštu za účelem následného doručení jejím příjemcům po obnovení spojení. Pak bude popis serveru krokodil.ru vypadat takto:

krokodil.ru. V A 212.20.5.2

IN MX 10 krokodil.ru.

IN MX 50 behemot.ru.

www IN CNAME krokodil.ru.

mail IN CNAME krokodil.ru.

ftp IN CNAME krokodil.ru.

Toto je komplexní příklad a okamžitě ukazuje použití záznamů MX, A a CNAME. Tady jsme:

• Jméno krokodil.ru přiřazujeme k adrese 212.20.5.2.
• Označujeme, že pošta odeslaná na adresy jako [e-mail chráněný], přijme (v tomto pořadí):
• server krokodil.ru;
• server behemot.ru.
• Definujeme další názvy www.krokodil.ru, mail.krokodil.ru a ftp.krokodil.ru. Vezměte prosím na vědomí, že všechna jména na pravé straně jsou plně kvalifikovaná, to znamená, že končí tečkou. Pokud tak neučiníte, bude na konec názvu automaticky nahrazena hodnota aktuální direktivy $ORIGIN. V tomto případě by to vedlo ke vzniku jmen jako www.krokodil.ru.krokodil.ru.

Záznam PTR

Jedná se o velmi zvláštní typ záznamu. V našem příkladu jsme „speciálně“ vzali celou podsíť, abychom zvážili případ „normální“ práce se záznamy PTR. O kauze se sítí 212.20.5.0/31 bude řeč o něco později.

Záznam PTR je určen k provádění zpětného překladu jmen na IP adresy. Takové převody jsou velmi široce používány v různých programech, které poskytují přístup k určitým síťovým zdrojům: kontrolují shodu dopředných a zpětných převodů, a pokud záznam PTR nesouhlasí nebo chybí, mohou odepřít přístup. Zóna obsahující záznamy PTR se nazývá zóna zpětného překladu nebo jednoduše zóna „reverzní“.

Záznamy PTR nemají žádný vztah k záznamům A, MX, CNAME a dalším záznamům, které popisují přímou konverzi. To bylo provedeno záměrně za účelem použití stejné sady softwarových modulů pro obě transformace. Zde však čelíme následujícímu typu složitosti – plně kvalifikovanému názvu domény ve tvaru www.krokodil.ru. „zvyšuje rozměr“ zleva doprava (to znamená, že uzly se zvětšují, když se pohybujete textem názvu zleva doprava) a IP adresa 212.20.5.2 je zprava doleva. Pro sjednocení programových modulů byla přijata následující konvence: všechny IP adresy jsou názvy obsažené ve speciální TLD in-addr.arpa. "Zóny" v této doméně jsou podsítě a název zóny je zapsán jako IP adresa čtená pozpátku. „Název“ naší reverzní zóny bude tedy 5.20.212.in-addr.arpa pro reverzní zónu obsahující popis vnější sítě a 1.87.10.in-addr.arpa pro reverzní zónu obsahující popis vnitřní síť.

Stejně jako pro použití názvu domény si jej musíte zaregistrovat, pro použití zpětného překladu musíte zaregistrovat reverzní „zónu“ u koordinátora reverzní zóny. Na rozdíl od přímých konverzních zón je zde pouze jeden koordinátor a registrace u něj je zdarma. Registraci reverzních zón zajišťuje RIPE NCC. Veškeré informace o registraci zpětné zóny jsou uvedeny v.

Proč potřebujete registrovat reverzní zónu? Server nejvyšší úrovně v zóně in-addr.arpa musí vědět, že aby mohl provést požadavek na zpětný překlad, musí kontaktovat ten a ten server, v tomto případě náš 212.20.5.2. Reverzní zónu vnitřní podsítě samozřejmě není potřeba nikde registrovat.

Samotný záznam PTR vypadá velmi jednoduše – do pole jména se zadává poslední část IP adresy a do datového pole se zadává plně kvalifikovaný název přímého překladu. Upozorňuji na poslední věc - jméno zadané do datového pole musí být plně kvalifikované, jelikož záznamy PTR samy definují vztah mezi IP adresou a jménem, ​​nemohou odnikud obdržet informaci o tom, ve které zóně je neúplně kvalifikovaný přímý překlad jméno by mělo být přiřazeno .

$ORIGIN 1.87.10.in-addr.arpa

1 V PTR zub1.krokodil.ru.

2 V PTR zub2.krokodil.ru.

3 V PTR zub3.krokodil.ru.

4 V PTR zub4.krokodil.ru.

5 V PTR zub5.krokodil.ru.

6 V PTR zub6.krokodil.ru.

Ve výše uvedeném příkladu jsme zadali zpětnou konverzi pro počítače ve vnitřní síti. Pro server napíšeme jeden řádek (ve skutečném příkladu není třeba uvádět direktivy $ORIGIN, jsou uvedeny pouze proto, aby bylo jasné, o jakou zónu mluvíme):

$ORIGIN 5.20.212.in-addr.arpa

2 V PTR krokodil.ru

Zde je třeba poznamenat, že záznamy CNAME se nepoužívají k určení vícenásobných zpětných shod, takže při dotazu „jaké jméno odpovídá adrese 212.20.5.2“ bude výsledkem vždy krokodil.ru, bez ohledu na počet aliasů pro něj nastavených.

Jak se to bude lišit, když poskytovatel přidělí blok 212.20.5.0/31 místo úplné podsítě? Z pohledu generování všech záznamů kromě PTR nic. Postup vytvoření přímé zóny a její registrace nezávisí na počtu adres, zejména proto, že ve většině případů není potřeba mnoho adres. Z hlediska záznamů PTR je však rozdíl. Směrem ke zjednodušení. Nebo možná ne, záleží na poskytovateli. A spočívá v tom, že záznamy:

gate.krokodil.ru. V A 212.20.5.1

krokodil.ru. V A 212.20.5.2

budou na vašem serveru a spravujete je vy, ale položky:

1 V PTR gate.krokodil.ru.

2 V PTR krokodil.ru.

musí být tvořen poskytovatelem, protože možnost zaregistrovat si reverzní zónu a spravovat ji sami je poskytována pouze v případě, že máte síť alespoň třídy C. To na jedné straně usnadňuje práci - nemáte potřeba se registrovat u RIPE, ale na druhou stranu to komplikuje změny v pojmenování serveru je nutné pokaždé kontaktovat poskytovatele.

Struktura souboru

Samotnému BINDu je samozřejmě jedno, v jakém pořadí jsou záznamy nebo jak jsou naformátovány. To je důležité pouze pro ty, kteří budou zónu udržovat, zejména pokud v ní budou často prováděny změny. Zde popíšu rozdělení zón podle souborů, jak se používá v zónách, které spravuji. Samozřejmě to není jediná možná objednávka a možná ani nejlepší. Ale funguje to.

Vnější a vnitřní zóny

BIND 8.x měl jednu extrémně zásadní nevýhodu – neumožňoval rozlišovat výstup informací v závislosti na jakýchkoli faktorech – bylo nutné buď ukázat, co je zbytečné, nebo skrýt, co bylo potřeba. Externí klienti absolutně nepotřebují vědět o přítomnosti počítačů ve vnitřní síti, ale protože neexistoval způsob, jak tyto informace oddělit, mohl každý počítač vytvořit strukturu vnitřní sítě pomocí dotazů DNS. BIND 9.x nemá tuto nevýhodu – umožňuje vám distribuovat požadavky napříč „pohledy“ pomocí seznamů řízení přístupu (ACL). Pohledy mohou mít libovolná jména, obvykle vytvářejí vnitřní pohled, který je spokojený s klienty v interní podsíti, a externí pohled, kterému vyhovují všichni ostatní. Pamatujte, že se jedná o stejnou zónu, jen je zobrazena jinak – soubory externí zóny zpravidla obsahují pouze informace, které externí klienti potřebují – o externím serveru, o cestách doručování pošty atd. a soubory interní zóny odrážejí celou topologii sítě. Pokud je navíc doprovázena reverzní zóna, pak je nutné stejným způsobem rozdělit informace o adresách zpětné konverze do souborů.

Vraťme se tedy k našemu příkladu.

Struktura souboru bude následující. Máme přímou zónu krokodil.ru a reverzní zónu 5.20.212.in-addr.arpa. Kromě toho musí být přítomna zóna reverzní zóny 0.0.127.in-addr.arpa, aby byl zajištěn správný zpětný překlad localhost 127.0.0.1. Tato zóna je potřebná k tomu, aby se BIND nepokoušel dotazovat kořenové servery na sebe sama, což se stane, když 127.0.0.1 ukazuje na „localhost“. Záznam přímého převodu 127.0.0.1 localhost.krokodil.ru bude zapsán do souboru přímého převodu vnitřní zóny. Aby nebyla síť zatížena přenosem zbytečných dat, používají se různé SOA záznamy pro vnější a vnitřní zóny - záznamy ve vnějších zónách se mění velmi zřídka a ve vnitřních poměrně často. Proto máme následující soubory:

• localhost.rev– soubor zóny reverzní konverze 0.0.127.in-addr.arpa. Tento soubor existuje pouze pro interní reprezentaci.
• zóna212.rev– soubor zóny reverzní konverze 5.20.212.in-addr.arpa.
• zóna10.rev– soubor interní inverzní zóny 1.87.10.in-addr.arpa.
• direct-krokodil-ru.int– interní soubor zóny přímé konverze krokodil.ru.
• direct-krokodil-ru.ext– externí soubor přímé konverzní zóny krokodil.ru.
• krokodil-ru-int.soa– soubor se záznamy SOA a NS pro vnitřní zóny.
• krokodil-ru-ext.soa– soubor se záznamy SOA a NS pro externí zóny.

Přes obsáhlý seznam jsou soubory poměrně krátké, proto jsou zde uvedeny v plném znění, s výjimkou komentářů.

Udělejme jednu poznámku ohledně názvu localhost. RFC 1912 konkrétně zmiňuje soubory nastavení pro rozlišení na 127.0.0.1 a localhost. V našem příkladu zóna localhost vyhovuje RFC 1912, i když v reálném životě je docela možné se setkat s rozlišením názvu 127.0.0.1 localhost.domain.tld a odpovídajícím zpětným rozlišením.

soubor Localhost.rev. Používá jeden záznam SOA spolu s vnitřní inverzní zónou:

$INCLUDE /etc/namedb/krokodil-ru-int.soa

1 V PTR localhost.

Soubor zone212.rev:

1 V PTR gate.krokodil.ru.

2 V PTR krokodil.ru.

Soubor zone10.rev:

$INCLUDE /etc/namedb/krokodil-ru-int.soa

1 V PTR zub1.krokodil.ru.

2 V PTR zub2.krokodil.ru.

3 V PTR zub3.krokodil.ru.

4 V PTR zub4.krokodil.ru.

5 V PTR zub5.krokodil.ru.

6 V PTR zub6.krokodil.ru.

Soubor direct-krokodil-ru.int:

$INCLUDE /etc/namedb/krokodil-ru-int.soa

krokodil.ru. V A 10.87.1.254

IN MX 10 krokodil.ru.

www IN CNAME krokodil.ru.

mail IN CNAME krokodil.ru.

proxy IN CNAME krokodil.ru.

ftp IN CNAME krokodil.ru.

ns IN CNAME krokodil.ru.

localhost. V A 127.0.0.1

zub1 V A 10.87.1.1

zub2 V A 10.87.1.2

zub3 V A 10.87.1.3

zub4 V A 10.87.1.4

zub5 V A 10.87.1.5

zub6 V A 10.87.1.6

Soubor direct-krokodil-ru.ext:

$INCLUDE /etc/namedb/krokodil-ru-ext.soa

krokodil.ru. V A 212.20.5.2

IN MX 10 krokodil.ru.

IN MX 50 behemot.ru.

www IN CNAME krokodil.ru.

mail IN CNAME krokodil.ru.

ftp IN CNAME krokodil.ru.

brána V A 212.20.5.1

Soubor krokodil-ru-int.soa:

@ IN SOA krokodil.ru. hostmaster.krokodil.ru. (

2006051202; Sériové číslo

10800; Aktualizujte každé 3 hodiny

3600; Opakujte každou hodinu

1728000; Platnost vyprší každých 20 dní

172800); Minimálně 2 dny

NA NS krokodil.ru.

Soubor krokodil-ru-ext.soa:

172 800 $ TTL

@ IN SOA korkodil.ru. hostmaster.krokodil.ru. (

2005122001; Sériové číslo

10800; Aktualizujte každé 3 hodiny

3600; Opakujte každou hodinu

1728000; Platnost vyprší každých 20 dní

172800); Minimálně 2 dny

NA NS krokodil.ru.

V NS ns4.nic.ru.

Závěr

Jak vytvořit, nakonfigurovat a spustit server DNS pro malou firmu? Ve skutečnosti to není tak obtížné, jak se zpočátku zdá - stačí projít touto cestou jednou, další akce proběhnou „automaticky“.

Aplikace

Domény nejvyšší úrovně

Zpočátku, podle RFC 920, seznam funkčních TLD zahrnoval pouze .com, .gov, .mil, .edu, .org, které reprezentovaly komerční, vládní, vojenské, vzdělávací a neziskové organizace. Následně se tento seznam poněkud rozšířil - v roce 1985 přibyl TLD .net zastupující organizace poskytující síťové služby a v roce 1988 TLD .int zastupující mezinárodní organizace. V letech 2001-2002 byly do tohoto seznamu přidány pro ruského uživatele prakticky neznámé TLD .aero, .biz, .cat, .coop, .jobs, .mobi, .museum, .name, .pro a .travel. Podrobnější informace jsou uvedeny v. Geografické domény jsou distribuovány jednou provždy. I když to neznamená, že si u něj nemůžete zaregistrovat svou doménu. Mnoho geografických domén, které se shodou okolností shodují se „známými“ zkratkami, jsou mimořádně atraktivní. Například .md (Moldavsko) je velmi atraktivní pro zdravotnické instituce a obyvatele Marylandu v USA; .tv (Tuvalu) – pro webové stránky související s televizí; .tm (Turkmenistán) se shoduje s pravopisem zkratky „Trade Mark“ a .nu (Niue – existuje taková ostrovní kolonie) – pro stránky v „nahém“ stylu.

http://www.ripe.net.

http://www.ripe.net/rs/reverse/rdns-project/index.html.

Nemeth E, Snyder G, Seabass S, Hayne TR. UNIX: Příručka správce systému. Pro profesionály/trans. z angličtiny – Petrohrad: Petr; K.: BHV Publishing Group, 2002 – 928 s.: ill.

Kriket Liu, Paul Albitz, DNS a BIND, třetí vydání, 1998 (O'Reilly, ISBN 1-56592-512-2).

Přímý pohled potřebné k překladu doménových jmen na IP adresy, zpětné vyhledávání– překládat IP adresy na názvy domén.

Každý segment sítě musí mít zónu zpětného vyhledávání. Konkrétně, pokud máte podsítě 192.168.10.0, 192.168.11.0 a 192.168.12.0, měli byste mít tři zóny zpětného vyhledávání.

Standardní název zóny zpětného vyhledávání se skládá z ID sítě v opačném pořadí a přípony in-addr.arpa. Zóny zpětného vyhledávání z předchozího příkladu by se nazývaly 10.168.192. in-addr.arpa, 11.168.192.in-addr.arpa a 12.168.192.in-addr.arpa. Záznamy zón zpětného a dopředného vyhledávání musí být synchronizovány. Pokud se synchronizace v doméně nezdaří, může selhat autentizace.

Chcete-li vytvořit zónu zpětného vyhledávání, postupujte takto:

1. Otevřete konzoli Správce DNS a připojte se k požadovanému serveru.

2. Klepněte pravým tlačítkem myši na položku serveru a vyberte příkaz Vytvořte novou zónu (New Zone). Otevře se Průvodce novou zónou. Klikněte Další.

3. Pokud nastavujete primární server s integrovanou službou Active Directory, vyberte přepínač Primární zóna a ujistěte se, že je zaškrtávací políčko zaškrtnuté . Pokud nechcete integrovat DNS do Active Directory, vyberte přepínač Primární zóna a zrušte zaškrtnutí políčka Uložte zónu ve službě Active Directory. Klikněte Další.

4. Pokud konfigurujete zónu zpětného vyhledávání pro sekundární server, vyberte přepínač Sekundární zóna a klikněte Další.

5. Pokud integrujete zónu se službou Active Directory, vyberte jednu z následujících strategií replikace:

Pro všechny servery DNS v této doménové struktuře (To znamená všechny servery DNS v této doménové struktuře) Jedná se o rozsáhlou replikační strategii. Pamatujte, že doménová struktura Active Directory zahrnuje všechny stromy domén, které sdílejí data adresáře s aktuální doménou.

Pro všechny servery DNS v této doméně (To znamená všechny servery DNS v této doméně) Tuto strategii vyberte, chcete-li replikovat informace DNS v rámci aktuální domény a jejích podřízených domén.

Pro všechny řadiče domény v této doméně (To jsou všechny řadiče domény v této doméně) Tuto strategii vyberte, pokud chcete replikovat informace DNS do všech řadičů domény v aktuální doméně a jejích podřízených doménách. Ačkoli tato strategie umožňuje širší replikaci informací DNS v rámci domény, ne každý řadič domény je serverem DNS (není nutné konfigurovat každý řadič domény jako server DNS).

6. Nastavte spínač Zóna zpětného vyhledávání. Klikněte Další.

7. Určete, pro které adresy chcete vytvořit zónu zpětného vyhledávání (IPv4 nebo IPv6) a klikněte Další. Proveďte jednu z následujících akcí:

Pokud nastavujete pro IPv4, zadejte ID sítě pro zónu zpětného vyhledávání. Hodnoty, které zadáte, určují výchozí název zóny zpětného vyhledávání. Klikněte Další.

Pokud nastavujete pro IPv6, zadejte předponu sítě pro zónu zpětného vyhledávání. Názvy zón se generují automaticky na základě zadaných hodnot. V závislosti na zadaném prefixu můžete vytvořit až osm zón. Klikněte Další.

8. Pokud konfigurujete primární nebo sekundární server, který není integrován se službou Active Directory, zadejte název souboru zóny. Výchozí název souboru pro databázi zóny DNS by již měl být zadán. Nechte jej beze změny nebo zadejte nový název. Klikněte Další.

9. Vyberte, zda chcete povolit dynamické aktualizace. Máte tři možnosti:

Povolit pouze zabezpečené dynamické aktualizace Pokud je vaše zóna integrovaná se službou Active Directory, můžete pomocí seznamů ACL omezit, kteří klienti mohou provádět dynamické aktualizace. Pokud vyberete tento přepínač, mohou záznamy prostředků dynamicky aktualizovat pouze klienti s ověřenými účty počítačů a schválenými seznamy ACL.

Povolit nezabezpečené i zabezpečené dynamické aktualizace Výběrem tohoto přepínače umožníte libovolnému klientovi aktualizovat své záznamy prostředků v DNS, když dojde ke změnám.

Nepovolovat dynamické aktualizace Tento přepínač zakáže dynamické aktualizace DNS. Mělo by se používat pouze v případě, že zóna není integrována se službou Active Directory.

Po instalaci zón zpětného vyhledávání se musíte ujistit, že delegování je pro danou zónu zpracováno správně. Kontaktujte své IT oddělení nebo ISP a ověřte registrace zóny v nadřazené doméně.

Historické pozadí: Systém doménových jmen byl vyvinut v roce 1983 Paulem Mockapetrisem. Zároveň bylo provedeno první úspěšné testování DNS, které se později stalo jednou ze základních součástí internetu. S DNS je možné implementovat škálovatelný, distribuovaný mechanismus, který mapuje hierarchické názvy webů na číselné IP adresy.

V roce 1983 Paul Mokapetris pracoval jako výzkumný pracovník v Institutu informačních věd. ISI), která je součástí University of Southern California School of Engineering ( USC). Jeho nadřízený Jon Postel navrhl, aby Paul přišel s novým mechanismem, který by navázal spojení mezi názvy počítačů a internetovými adresami, a nahradil tak současný centralizovaný adresář názvů hostitelů a adres spravovaný kalifornskou společností SRI International.

„Všichni pochopili, že staré schéma nemůže fungovat věčně,“ vzpomíná Mockapetris. „Růst internetu se připojoval k síti, která vznikla na základě projektu ARPANET iniciovaného společností. Pentagon."

Řešení Mockapetris, DNS, byla distribuovaná databáze, která umožňovala organizacím, které se připojily k internetu, získat svou doménu.

„Jakmile se organizace připojí k síti, mohla používat tolik počítačů, kolik chtěla, a sama jim přiřazovat jména,“ zdůraznil Mockapetris. Názvy domén pro společnosti obdržely koncovku .com, univerzity - .edu a tak dále.

DNS byl původně navržen tak, aby podporoval 50 milionů záznamů a mohl být bezpečně rozšířen na několik stovek milionů záznamů. Mockapetris odhaduje, že nyní existuje asi 1 miliarda jmen DNS, včetně téměř 20 milionů veřejných jmen. Zbytek patří systémům umístěným za firewally. Jejich jména běžní uživatelé internetu neznají.

Nový systém byl zaváděn postupně v průběhu několika let. V této době řada výzkumníků experimentovala s jeho schopnostmi a Mokapetris studoval ISI servis a udržování stabilního provozu „kořenového serveru“ postaveného na sálových počítačích Digital Equipment. Kopie hostitelských tabulek byly uchovávány na každém počítači připojeném k internetu přibližně do roku 1986. Poté začal masivní přechod na používání DNS.

Potřeba mapovat názvy hostitelů sítě na adresy IP

Počítače a další síťová zařízení používají IP adresy k vzájemnému odesílání paketů přes síť. Pro uživatele (člověka) je však mnohem jednodušší a pohodlnější zapamatovat si některá symbolická jména uzlů sítě než čtyři nesmyslná čísla. Pokud však lidé hodlají ve svých interakcích se síťovými prostředky používat spíše názvy hostitelů než adresy IP, pak musí existovat mechanismus, který mapuje názvy hostitelů na jejich adresy IP.

Existují dva takové mechanismy – soubor lokálních hostitelů pro každý počítač a centralizovaná hierarchická jmenná služba DNS.

Použití souboru Local Hosts a DNS k rozlišení názvů hostitelů v síti

V počáteční fázi rozvoje sítě, kdy byl počet uzlů v každé síti malý, stačilo na každém počítači uložit a udržovat aktuální stav jednoduchého textového souboru, který obsahoval seznam síťových uzlů dané sítě. Seznam je strukturován velmi jednoduše - každý řádek textového souboru obsahuje dvojici "IP adresa - název hostitele sítě". V systémech řady Windows je tento soubor umístěn ve složce %system root%\system32\drivers\etc (kde %system root% označuje složku, ve které je nainstalován operační systém). Ihned po instalaci systému Windows se vytvoří soubor hosts s jednou položkou 127.0.0.1 localhost.

Jak sítě rostou, je stále obtížnější udržovat informace v souboru hostitelů aktuální a přesné. Chcete-li to provést, musíte neustále aktualizovat obsah tohoto souboru na všech uzlech sítě. Navíc je to tak jednoduché technologie neumožňuje uspořádat jmenný prostor do žádné struktury. Proto byla potřeba centralizovaná databáze jmen, která by umožňovala převod jmen na IP adresy bez nich skladování odpovídající seznam na každém počítači. Takovým základem byl DNS (Domain Name System), systém pojmenování domén, který zahájil masový provoz v roce 1987.

Všimněte si, že s příchodem služby DNS vůbec nezmizela relevance použití hostitelského souboru, v některých případech se použití tohoto souboru ukazuje jako velmi efektivní.

Služba DNS: jmenný prostor, domény

DNS je hierarchická databáze, který mapuje názvy síťových uzlů a jejich síťových služeb na IP adresy uzlů. Obsah této databáze je na jedné straně distribuován na velkém počtu serverů služeb DNS a na druhé straně je centrálně spravován. V jádru hierarchická struktura databáze DNS je doménový jmenný prostor, jehož hlavní strukturní jednotkou je doména, která sdružuje síťové uzly (hostitele) a také subdomény. Proces hledání názvu hostitele sítě v databázi DNS a přiřazování tohoto názvu k IP adrese se nazývá „překlad názvu hostitele v oboru názvů DNS“.

Služba DNS se skládá ze tří hlavních součástí:

Jmenný prostor DNS a odpovídající záznamy prostředků (RR, záznam prostředku)- toto je samotná distribuovaná databáze DNS;

DNS jmenné servery- počítače, které ukládají databázi DNS a na které reagují žádosti DNS klienti;

DNS klienti (DNS klienti, DNS resolvery)-počítače, které odesílají dotazy na servery DNS za účelem získání záznamů o prostředcích.

Jmenný prostor.

Jmenný prostor DNS je hierarchická stromová struktura začínající u kořene, která nemá žádné jméno a je označena tečkou ".". Návrh jmenného prostoru DNS lze nejlépe ilustrovat na příkladu internetu ( rýže. 4.8).

Rýže. 4.8.

Pro domény 1. úrovně existují 3 kategorie názvů:

ARPA- speciální jméno používané pro reverzní překlad DNS (z IP adresy na celé jméno hostitele);

Obecná jména 1. úrovně- 16 (aktuálně) jmen, jejichž účel je uveden v tabulka 4.4;

Dvoupísmenné názvy zemí- jména pro domény registrované v odpovídajících zemích (například ru - pro Rusko, ua - pro Ukrajinu, uk - pro Velkou Británii atd.).

Tabulka 4.4.
Název domény	Účel
	Letecké komunity
	Společnosti (bez odkazu na zemi)
	Komerční organizace, především ve Spojených státech (například doména microsoft.com pro společnost Microsoft Corporation)
	Družstva
	Vzdělávací instituce v USA
	Americké vládní agentury
	Doména pro organizace poskytující jakékoli informace spotřebitelům
	mezinárodní organizace (například doména nato.int pro NATO)
	Americká vojenská oddělení
	Globální doména pro jednotlivce
	Doména pro poskytovatele internetu a další organizace, které spravují strukturu internetu
	Neziskové a nevládní organizace především v USA
	Doména pro profesní sdružení (lékaři, právníci, účetní atd.)
	Personální agentury
	Cestovní kanceláře

Chcete-li přímo mapovat jmenný prostor na prostor IP adres, použijte tzv. záznamy o zdrojích (RR, resource record). Každý server DNS obsahuje záznamy prostředků pro tu část jmenného prostoru, za kterou je zodpovědný ( autoritativní). tabulka 4.5 obsahuje popis nejčastěji používaných typů záznamů zdrojů.

Tabulka 4.5.
Typ záznamu zdroje	Funkce nahrávání	Popis použití
	Adresa hostitele Adresa hostitele nebo uzlu	Mapuje název hostitele na adresu IP (například pro doménu microsoft.com na hostitele s názvem www.microsoft.com IP adresa je mapována pomocí následující položky: www A 207.46.199.60)
	Kanonický název (alias)	Mapuje jedno jméno na druhé
	Mail Exchanger Výměna pošty	Řídí směrování poštovních zpráv pro protokol SMTP
	Jmenný server Jmenný server	Odkazuje na servery DNS odpovědné za konkrétní doménu a její subdomény
	Ukazatel	Používá se ke zpětnému překladu IP adres na názvy hostitelů v doméně in-addr.arpa
	Start of Authority Spuštění vstupu do zóny	Používá se k určení primárního serveru pro danou zónu a popisu vlastností zóny
	Ukazatel lokátoru služeb na službu	Používá se k vyhledání serverů se specifickými službami (například řadiče domény Active Directory nebo servery globálního katalogu)

Plně kvalifikovaný název domény (FQDN) se skládá z několika názvů, nazývaných štítky, oddělených tečkou. Štítek zcela vlevo odkazuje přímo na uzel, zbývající štítky jsou seznamem domén od domény první úrovně po doménu, ve které se uzel nachází (tento seznam je zobrazen zprava doleva).

DNS jmenné servery.

Názvové servery DNS (nebo servery DNS) jsou počítače, které ukládají ty části databáze jmenného prostoru DNS, za které jsou tyto servery odpovědné, a spouštějí software, který zpracovává požadavky na překlad názvů klientů DNS a poskytuje odpovědi na přijaté požadavky.

DNS klienti.

Klient DNS je jakýkoli síťový uzel, který kontaktoval server DNS, aby přeložil název hostitele na adresu IP nebo naopak adresu IP na název hostitele.

Služba DNS: Domény a zóny

Jak bylo uvedeno výše, každý server DNS je zodpovědný za obsluhu určité části jmenného prostoru DNS. Informace o doméně uložené v databázi serveru DNS jsou organizovány do speciálních jednotek nazývaných zóny. Zóna je základní jednotkou replikace dat mezi servery DNS. Každá zóna obsahuje určitý počet záznamů prostředků pro odpovídající doménu a případně její subdomény.

Systémy řady Windows Server podporují následující typy zón:

Standardní primární- hlavní kopie standardní zóny; Pouze v této instanci zóny lze provést jakékoli změny, které se poté replikují na servery, které ukládají další zóny;

Standardní sekundární- kopie hlavní zóny, dostupná v režimu pouze pro čtení, navržená pro zvýšení odolnosti proti chybám a rozložení zátěže mezi servery odpovědné za konkrétní zónu; Proces replikace změn záznamů zóny se nazývá „přenos zóny“ ( zónový převod

) (informace ve standardních zónách jsou uloženy v textových souborech, soubory se vytvářejí ve složce "%system root%\system32\dns", název souboru je obvykle tvořen z názvu zóny s přidáním přípony souboru " .dns"; termín "standardní" se používá pouze v systémech rodiny Windows);- všechny informace o zóně jsou uloženy jako jediná položka v databázi Active Directory (tyto typy zón mohou existovat pouze na serverech Windows, které jsou řadiči domény Active Directory; v integrovaných zónách lze přísněji kontrolovat přístupová práva k zónám; změny zónové vstupy mezi různými instancemi integrované zóny nejsou vytvářeny podle technologií přenos zóny službou DNS a replikačními mechanismy služby Active Directory);

Zóna pahýlu (pahýl;

Pouze Windows 2003) je speciální typ zóny, která pro danou část jmenného prostoru DNS obsahuje holou minimální sadu záznamů prostředků (počáteční záznam zóny SOA, seznam jmenných serverů odpovědných za tuto zónu a několik A záznamy pro odkazy na jmenné servery pro danou zónu). Podívejme se jako příklad na vztah mezi pojmy doména a zóna. Pojďme analyzovat informace uvedené na.

rýže. 4.9

Rýže. 4.9. V tomto příkladu začíná jmenný prostor DNS doménou microsoft.com , který obsahuje 3 subdomény:, sales.microsoft.com it.microsoft.com A edu.microsoft.com skladování(domény na obrázku jsou označeny malými vodorovnými ovály). Doména je čistě logický pojem, který se týká pouze distribuce jmen. Koncept domény nemá nic společného s technologií informace o doména. Zóna

- jedná se o způsob prezentace informací o doméně a jejích subdoménách v úložišti těch DNS serverů, které jsou zodpovědné za danou doménu a subdomény. V této situaci, pokud je pro úložiště vybrána standardní zónová technologie, lze umístění informací o doméně implementovat následovně: V tomto příkladu začíná jmenný prostor DNS doménou záznamy související s doménou A A

, jsou uloženy v jedné zóně v souboru "microsoft.com.dns" (na obrázku je zóna označena velkým nakloněným oválem); , který obsahuje 3 subdomény: záznamy související s doménou sales.microsoft.com správa domény

delegované na jiné servery DNS, byly pro tyto domény na jiných serverech vytvořeny odpovídající soubory „sales.microsoft.com.dns“ a „it.microsoft.com.dns“ (tyto zóny jsou označeny velkými svislými ovály).

Delegování kontroly je přenesením odpovědnosti za část jmenného prostoru na jiné servery DNS.

Zóny dopředného a zpětného vyhledávání Zóny diskutované v předchozím příkladu jsou dopředné vyhledávací zóny

. Tyto zóny se používají k překladu názvů hostitelů na adresy IP. Nejčastěji používané typy záznamů jsou A, CNAME, SRV. Zóny zpětného vyhledávání ( zón), hlavním typem záznamu v „reverzních“ zónách je PTR. K vyřešení tohoto problému byla vytvořena speciální doména s názvem in-addr.arpa. Pro každou IP síť v takové doméně jsou vytvořeny odpovídající subdomény vytvořené z identifikátoru sítě zapsaného v opačném pořadí. Záznamy v takové zóně budou odpovídat ID hostitele úplnému názvu FQDN tohoto hostitele. Například pro síť IP 192.168.0.0/24 musíte vytvořit zónu s názvem „0.168.192.in-addr.arpa“. Pro uzel s IP adresou 192.168.0.10 a názvem host.company.ru musí být v této zóně vytvořen záznam „10 PTR host.company.ru“.

Algoritmy pro iterativní a rekurzivní DNS dotazy

Vše žádosti, odeslané klientem DNS na server DNS za účelem překladu názvů, se dělí na dva typy:

iterativní dotazy (klient odešle DNS server žádost, která vyžaduje, abyste poskytli nejlepší odpověď bez kontaktování jiných serverů DNS);

rekurzivní dotazy (klient odešle dotaz na DNS server, ve kterém požaduje konečnou odpověď, i když DNS server musí posílat dotazy na jiné DNS servery; dotazy zaslané v tomto případě na jiné DNS servery budou iterativní).

Běžní klienti DNS (jako jsou uživatelské pracovní stanice) obvykle odesílají rekurzivní dotazy.

Podívejme se na příklady interakce klienta DNS a serveru DNS při zpracování iterativních a rekurzivních dotazů.

Řekněme, že uživatel spustil program Internet Browser a zadal adresu do adresního řádku http://www.microsoft.com. Než může prohlížeč navázat HTTP relaci s webem, musí klientský počítač určit IP adresu webového serveru. K tomu slouží klientská část protokolu TCP/IP pracovní stanice uživatele (tzv řešitel) nejprve prohledá svou místní mezipaměť dříve vyřešených jmen ve snaze najít tam jméno www.microsoft.com. Pokud se jméno nenajde, odešle klient požadavek na server DNS uvedený v konfiguraci TCP/IP tohoto počítače (nazvěme tento server DNS "místní server DNS"), pro rozlišení jmen www.microsoft.com na IP adresu tohoto uzlu. DNS server pak požadavek zpracuje v závislosti na typu požadavku.

Možnost 1 (iterativní dotaz).

Pokud klient odeslal na server iterativní požadavek (nezapomeňte, že klienti obvykle posílají rekurzivní požadavky), je požadavek zpracován podle následujícího schématu:

V tomto příkladu začíná jmenný prostor DNS doménou;

pokud je taková zóna nalezena, hledá se v ní záznam pro uzel www; pokud je záznam nalezen, výsledek hledání je okamžitě vrácen klientovi;

www.microsoft.com ve své mezipaměti dříve vyřešených dotazů DNS;

pokud je hledané jméno v mezipaměti, pak je výsledek hledání vrácen klientovi; pokud lokální DNS server nenajde požadovaný záznam ve své databázi, je klientovi zaslána IP adresa jednoho z kořenových DNS serverů;

klient získá IP adresu kořenového serveru a zopakuje mu požadavek na rozlišení názvu www.microsoft.com;

kořenový server ve své databázi neobsahuje zónu „microsoft.com“, ale zná servery DNS odpovědné za zónu „com“ a kořenový server odešle klientovi IP adresu jednoho ze serverů odpovědných za tuto zónu ;

klient obdrží IP adresu serveru odpovědného za zónu "com" a odešle mu požadavek na rozlišení názvu www.microsoft.com;

server zodpovědný za zónu com ve své databázi zóny neobsahuje V tomto příkladu začíná jmenný prostor DNS doménou, ale zná servery DNS odpovědné za zónu V tomto příkladu začíná jmenný prostor DNS doménou a tento server DNS odešle klientovi IP adresu jednoho ze serverů odpovědných za zónu V tomto příkladu začíná jmenný prostor DNS doménou;

klient obdrží IP adresu serveru odpovědného za zónu V tomto příkladu začíná jmenný prostor DNS doménou a odešle mu požadavek na rozlišení názvu www.microsoft.com;

server odpovědný za zónu V tomto příkladu začíná jmenný prostor DNS doménou, obdrží tento požadavek, najde ve své databázi IP adresu www uzlu umístěného v zóně V tomto příkladu začíná jmenný prostor DNS doménou a odešle výsledek klientovi;

klient získá IP adresu, kterou hledá, uloží vyřešený požadavek do své lokální mezipaměti a předá IP adresu webové stránky internetovému prohlížeči (prohlížeč poté komunikuje s webem přes HTTP).

Možnost 2 ( rekurzivní dotaz).

Pokud klient odeslal na server rekurzivní dotaz, pak je požadavek zpracován podle následujícího schématu:

Místní server DNS nejprve prohledává zóny, za které je za zónu zodpovědný V tomto příkladu začíná jmenný prostor DNS doménou;

pokud je taková zóna nalezena, hledá se v ní záznam pro uzel www; www.microsoft.com pokud je záznam nalezen, výsledek hledání je okamžitě vrácen klientovi;

jinak místní server DNS vyhledá požadovaný název www.microsoft.com ve své mezipaměti dříve vyřešených dotazů DNS; pokud je hledané jméno v mezipaměti, pak je výsledek hledání vrácen klientovi;

Pokud místní server DNS nenalezne požadovaný záznam ve své databázi, místní server DNS sám provede řadu iterativních dotazů k překladu názvu.

a klientovi se odešle buď nalezená IP adresa, nebo chybová zpráva.

Implementace služby DNS v systémech rodiny Windows Server

Hlavním rysem služby DNS v systémech řady Windows Server je, že služba DNS byla navržena tak, aby podporovala adresářovou službu Active Directory. Pro provedení této funkce musí být splněny dvě podmínky:

Windows Server DNS splňuje obě podmínky a adresářové služby Active Directory lze implementovat pouze na serverech se systémem Windows Server.

Podívejme se na několik jednoduchých příkladů správy služby DNS:

instalace služby DNS;

vytvoření hlavní a další přímé pozorovací plochy;

vytvoření zóny zpětného vyhledávání;

provádění dynamické registrace uzlů v zóně.

síť se skládá ze dvou serverů Windows 2003;

operační systém - časově omezená 120denní ruská verze Windows 2003 Server Enterprise Edition;

první server je nainstalován na PC s procesorem Intel Pentium-4 3GHz a 512 MB RAM, název serveru - DC1, IP adresa - 192.168.0.1/24;

druhý server běží jako virtuální systém využívající Microsoft VirtualPC 2004, název serveru -DC2, IP adresa - 192.168.0.2/24;

název domény v prostoru DNS a odpovídající název v adresářové službě Active Directory - world.ru (síť je zcela izolována od ostatních sítí, takže v tomto příkladu si autoři mohli vybrat název domény svobodně; v reálné situaci konkrétní vzdělávací instituci, musí učitel tuto informaci opravit).

Podrobná doporučení pro organizaci sítě pro studium tohoto kurzu (jak pod vedením učitele v organizované skupině, tak při samostatném studiu) jsou uvedena v pokynech pro provádění laboratorních cvičení na konci příručky.

Instalace služby DNS

Instalace služby DNS (stejně jako dalších součástí systému) je poměrně jednoduchá pomocí Průvodce instalací součástí systému Windows:

OTEVŘENO Ovládací panel.

Vyberte položku "Přidat nebo odebrat programy".

Klepněte na tlačítko "Instalace součástí systému Windows".

Vybrat "síťové služby"- tlačítko "dodatečně"(v žádném případě nezrušte zaškrtnutí jména "síťové služby").

Zkontrolujte službu DNS.

Rýže. 4.10.

Pokud vás systém požádá o zadání cesty k systémové distribuci, zadejte cestu ke složce s distribucí.

Proveďme tuto akci na obou serverech.

Vytvoření primární zóny dopředného pohledu.

Na serveru DC1 vytvoříme standardní hlavní zónu s názvem world.ru.

Otevřeme konzoli DNS.

Vyberme sekci "Dopředné pohledové zóny".

Spusťte průvodce vytvořením zóny (typ zóny - "Základní", dynamické aktualizace - povolit, ostatní parametry - výchozí).

Zadáme název zóny - world.ru.

Povolme přenos této zóny na jakýkoli server DNS (konzole DNS - zone world.ru - Vlastnosti- Záložka "Přenosy zón"- Zkontrolujte "Povolit převody" it.microsoft.com "Na jakýkoli server").

Vytvoření další zóny výhledu vpřed.

Na serveru DC2 vytvoříme standardní další zónu s názvem world.ru.

Otevřeme konzoli DNS.

Vyberme sekci "Dopředné pohledové zóny"

"Další", IP adresa hlavního serveru (ze kterého bude zóna zkopírována) je adresa serveru DC1, ostatní parametry jsou výchozí)

Zadáme název zóny - world.ru.

Zkontrolujeme vzhled zóny v konzole DNS.

Konfigurace hostitelů pro provádění dynamické registrace DNS.

K dokončení tohoto úkolu je třeba provést řadu akcí jak na serveru DNS, tak v nastavení klienta DNS.

DNS server.

Vytvořte příslušnou zónu.

Povolit dynamické aktualizace.

Už jsme to udělali.

DNS klient.

V nastavení protokolu TCP/IP zadejte adresu preferovaného serveru DNS - serveru, na kterém jsou povoleny dynamické aktualizace (v našem příkladu server DC1).

V úplném názvu počítače uveďte příslušnou příponu DNS (v našem příkladu - world.ru). Za tohle - - "Můj počítač""Vlastnosti" - Záložka"Název počítače" - Tlačítko"Název počítače" "dodatečně""Přeměna" - zadejte název domény world.ru do prázdného textového pole - tlačítko"OK"

(3krát)).

Rýže. 4.11. Poté vás systém vyzve k restartování počítače. Po restartu DNS serveru v zóně world.ru se pro naše servery automaticky vytvoří záznamy typu A ().

rýže. 4.12

Rýže. 4.12..

Otevřeme konzoli DNS.

Vyberme sekci Vytvoření zóny zpětného vyhledávání.

"Zóny zpětného vyhledávání" "Základní" Spusťte průvodce vytvořením zóny (vyberte: typ zóny -

, dynamické aktualizace - povolit, ostatní parametry - výchozí) V terénu"Síťový kód (ID)"

Zadáme parametry ID sítě - 192.168.0.

Spusťte příkaz, který přinutí klienta zaregistrovat se na DNS server - ipconfig /registerdns. Naše servery se zaregistrují reverzní zóna DNS ():