A DNS a Domain Name System, azaz a „Domain Name System” rövidítése. Ez egy olyan rendszer, amelyben a szerverek összes domain neve egy bizonyos hierarchia szerint van elosztva. Nézzük meg, mire valók a DNS-kiszolgálók, hogyan kell beállítani őket Windows 7-en, mit kell tenni, ha a szerver nem válaszol, és hogyan lehet javítani az esetleges hibákat.
A DNS-kiszolgáló információkat tárol a tartományokról. Mire való? A helyzet az, hogy a számítógép nem érti a mieinket betűjelölések hálózati erőforrások. Itt például a yandex.ru. Mi weboldal címnek hívjuk, számítógépen pedig csak karakterkészlet. De a számítógép tökéletesen megérti az IP-címeket és azok elérését. Az IP-címek négy, nyolc karakterből álló számként vannak ábrázolva binárisan. Például 00100010.11110000.00100000.11111110. A kényelem kedvéért a bináris IP-címek azonos decimális számokként (255.103.0.68) vannak írva.
Tehát egy IP-címmel rendelkező számítógép azonnal hozzáférhet az erőforráshoz, de nehéz lenne megjegyezni a négyjegyű címeket. Ezért speciális szervereket találtak ki, amelyek az erőforrás minden IP-címéhez a megfelelő szimbolikus megjelölést tárolták. Így amikor webhelycímet ír be keresési karakterlánc böngészőben az adatok elküldésre kerülnek a DNS-kiszolgálónak, amely egyezést keres az adatbázisával. Ezután a DNS elküldi a helyes IP-címet a számítógépnek, majd a böngésző közvetlenül hozzáfér a hálózati erőforráshoz.
Amikor beállítja a DNS-t a számítógépen, a hálózati kapcsolat a DNS-kiszolgálón keresztül megy keresztül, amely lehetővé teszi a számítógép vírusok elleni védelmét, a szülői felügyelet beállítását, bizonyos webhelyek blokkolását és még sok mást.
A „Vezérlőpulton” megtudhatja, hogy a DNS-kiszolgáló engedélyezve van-e a számítógépén, és megtudhatja annak címét.
Természetesen az internetszolgáltatónak is van saját DNS-kiszolgálója, a kapcsolat alapértelmezés szerint ezen a szerveren keresztül történik. De a szabványos szerverek nem mindig a legjobb választás: Lehet, hogy nagyon lassan, vagy egyáltalán nem működnek. Nagyon gyakran az operátorok DNS-kiszolgálói nem tudnak megbirkózni a terheléssel és a „zuhanással”. Emiatt lehetetlen elérni az Internetet.
Ezen túlmenően, a szabványos DNS-szerverek csak az IP-címek meghatározására és karakteressé alakítására szolgálnak, de nincs szűrési funkciójuk. A nagyvállalatok harmadik féltől származó DNS-kiszolgálói (például Yandex.DNS) nem rendelkeznek ezekkel a hiányosságokkal. Szervereik mindig különböző helyeken találhatók, és a kapcsolat a legközelebbi helyen megy keresztül. Ennek eredményeként megnő az oldalbetöltési sebesség.
Szűrő funkcióval rendelkeznek, és szülői felügyeleti funkciót valósítanak meg. Ha vannak gyerekei, akkor legjobb lehetőség- a kétes és nem gyermekközönségnek szánt oldalak elérhetetlenné válnak számukra.
Beépített vírusirtójuk és feketelistájuk van a webhelyekről. Így a csaló és a rosszindulatú programokat tartalmazó oldalak blokkolva lesznek, és Ön nem fogja véletlenül elkapni a vírust.
A harmadik féltől származó DNS-kiszolgálók lehetővé teszik a webhely blokkolásának megkerülését. Kicsit abszurdnak hangzik, mert azt mondtuk, hogy a DNS-kiszolgálókat úgy tervezték, hogy blokkolják a nem kívánt erőforrásokat. A tény azonban az, hogy az internetszolgáltatók kénytelenek megtiltani a hozzáférést a Roskomnadzor által tiltott webhelyekhez a DNS-kiszolgálókon. A Goggle, a Yandex és mások független DNS-kiszolgálóinak erre egyáltalán nincs szükségük, így a különféle torrentkövetők, közösségi médiaés más oldalak is látogathatóak lesznek.
Itt konfigurálhatja a DNS-kiszolgálók elérésének sorrendjét. A tapasztalatlan felhasználóknak el kell magyarázni, hogy nincs olyan szerver, amely az összes létező internetcímet tárolná. Túl sok webhely van most, ezért sok a DNS-kiszolgáló. És ha a megadott cím nem található az egyik DNS-kiszolgálón, a számítógép a következőre kapcsol. Tehát a Windows rendszerben beállíthatja a DNS-kiszolgálók elérésének sorrendjét.
Beállíthatja a DNS-utótagokat. Ha ezt nem tudja, akkor nincs szüksége ezekre a beállításokra. A DNS-utótagokat nagyon nehéz megérteni, és fontosabbak maguknak a szolgáltatóknak. Általánosságban elmondható, hogy az összes URL-cím aldomainekre van felosztva. Például szerver.domain.com. Tehát a com az első szintű domain, a domain a második, a szerver a harmadik. Elméletileg a domain.com és a server.domain.com teljesen különböző erőforrások, eltérő IP-címekkel és eltérő tartalommal. A server.domain.com azonban továbbra is a domain.com-on belül van, ami viszont a com-on belül van. A DNS-utótag a szerver elérésekor domain.com. Annak ellenére, hogy az IP-címek eltérőek, a szerver csak a domain.com webhelyen található. A Windows rendszerben testreszabhatja az utótagok hozzárendelését, ami bizonyos előnyökkel jár belső hálózatok. Ami az internetet illeti, a DNS-kiszolgálók készítői már mindent automatikusan beállítottak, ami szükséges.
Mi a teendő, ha a „Számítógép beállításai helyesek, de az eszköz vagy az erőforrás (DNS-kiszolgáló) nem válaszol” hibaüzenet jelenik meg, amikor megpróbálok elérni egy webhelyet? Lehetséges, hogy a DNS szolgáltatás valamilyen okból le van tiltva a számítógépen. Lehetséges, hogy az Ön által használt DNS-kiszolgáló leállt.
Ha a DNS-kiszolgáló nem, vagy hibásan oldja fel a neveket, annak két lehetséges oka lehet:
A DHCP szerver automatikusan konfigurálja a hálózati beállításokat. Ezek a szerverek segítenek otthoni hálózat hogy ne kelljen minden csatlakoztatott számítógépet külön konfigurálni. A DHCP függetlenül írja elő a hálózati paramétereket a csatlakoztatott eszköz számára (beleértve a gazdagép IP-címét, az átjáró IP-címét és a DNS-kiszolgálót).
A DHCP és a DNS különböző dolgok. A DNS egyszerűen feldolgozza a kérést szimbolikus címként, és továbbítja a megfelelő IP-címet. A DHCP sokkal összetettebb és intelligensebb rendszer: hálózatba rendezi az eszközöket, egymástól függetlenül osztja ki az IP-címeket és azok sorrendjét, hálózati ökoszisztémát hoz létre.
Tehát rájöttünk, hogy a DNS-kiszolgálókat úgy tervezték, hogy továbbítsák a kért erőforrás IP-címét. A harmadik féltől származó DNS-kiszolgálók lehetővé teszik az internet felgyorsítását (a szabványos szolgáltatói szerverekkel ellentétben), megvédik a kapcsolatot a vírusoktól és csalóktól, és lehetővé teszik a szülői felügyeletet. A DNS-kiszolgáló beállítása nem nehéz, és a legtöbb probléma megoldható egy másik DNS-kiszolgálóra váltással.
Ebben a cikkben leírom, hogyan emelheti fel DNS szerver bérelt VDS/VPS-en a BIND csomag használatával.
Az okok, amelyek miatt szükségünk van saját DNS-szerverünkre, nagyon sokfélék lehetnek, de a legtöbb esetben ez csak megkönnyíti a több domainnel való munkát. És el kell ismerned, jó látni a névszervereidet a Whois szolgáltatásban.
Szeretném felhívni a figyelmet arra a tényre, hogy ebben a példában azt vizsgáljuk, hogyan lehet mindkét NS-t egyre emelni virtuális szerver. A legtöbb esetben két NS-re van szükség egy domain regisztrálásához, mivel nem minden regisztrátor engedélyezi a regisztrációt egy rekorddal vagy egyáltalán nem.
Azt is elmondom, hogy a megbízható működés érdekében érdemes elgondolkodni azon, hogy DNS-szervereinket különböző virtuális szervereken, lehetőleg különböző adatközpontokban helyezzük el. Ez lehetővé teszi, hogy webhelye késedelem nélkül tovább működjön, ha valamelyik szerver leáll.
Annak érdekében, hogy egyértelművé tegyük, hogyan történik a telepítés, vegyünk fiktív kiindulási adatokat:
DNS-kiszolgáló → 91.197.130.49 (ns1.mydomain.com)
→ 91.197.130.63 (ns2.mydomain.com)
Zóna --> mydomain.com
A virtuális szerverre telepített operációs rendszer - CentOS5.5
Először is magát a BIND csomagot kell telepítenünk a szerverre, és ehhez kapcsolódnunk kell a VDS-ünkhöz.
Két lehetőség közül választhat, attól függően, hogy melyik operációs rendszert használja a személyi számítógépén.
BAN BEN linux rendszerek minden nagyon egyszerű. A főpanelen a Helyek - Kapcsolódás a szerverhez .. fülre kell lépni, a Szolgáltatás típusánál kiválasztani az SSH kapcsolatot, megadni a szervered címét, bejelentkezésed, kattintani a "csatlakozás" gombra. A megjelenő ablakban adja meg jelszavát, és ... már a terminálban van operációs rendszer a VDS.
Ha Windowst használsz, azt tanácsolom, hogy töltsd le a PuTTY programot. A program ingyenes és korlátozás nélkül terjeszthető. Letöltheti és megtanulhatja, hogyan kell használni.
Tehát eljutottunk a VDS terminálhoz. telepíteni legújabb verzió BIND csomagot, be kell írnia a következő parancsot:
Yum install bind
Nyomja meg az "Enter" gombot, és várjon sikeres teljesítés telepítés.
Utunk következő lépése a zóna adatainak létrehozása.
A helyesért DNS beállítások A BIND alatt az adatok több fájlra vannak felosztva. Az egyik a gazdagépnevek címekhez való leképezését tartalmazza, a többi - a címek nevekre való visszarendelését. A cím-név keresések továbbítási leképezések, a név-cím keresések pedig fordított leképezések.
A következő fájlokat fogjuk használni:
1. A gazdagépnevek címekké alakításához szükséges adatokat tartalmazó fájl. A zónánk neve így fog kinézni: db.mydomain.com.
2. A címek gazdagépnevekké alakításához szükséges adatokat tartalmazó fájl. A neve így néz ki: db.addr, ahol az addr a leendő DNS-szerverünk külső IP-címe, az utolsó számjegyek és a hálózati maszk nélkül. Mert ezt a példát a fájl neve lesz
db.91.197.130.
3. Zone fájlok db.cache és db 127.0.0. Ezek a fájlok szükségesek a DNS megfelelő működéséhez.
4. Az összes zóna adatfájl összekapcsolásához szükséges telepítőfájl (konfigurációs fájl). A BIND 8-as és 9-es verziójában a fájl általában /etc/named.conf.
Folytassuk közvetlenül a fájlok létrehozásával.
Kezdjük a konfigurációs fájllal. Létrehozásához írja be a parancsot a VDS terminálba
Vi /etc/named.conf
A konfigurációs fájl sorokat tartalmaz, amelyek meghatározzák a zóna adatfájlokat tartalmazó könyvtárat.
A telepítőfájlok általában tartalmaznak egy karakterláncot, amely megadja a zóna adatfájlok helyének könyvtárát. Ezek a sorok így fognak kinézni:
Lehetőségek (
"/var/named/" könyvtár;
};
Az alábbiakban az egyes használandó zónaadatfájlok leírása található. A sor a zóna szóval kezdődik, amit követ Domain névés az osztály neve (in az internet osztály.) A BIND 8-ban és 9-ben az internet osztály alapértelmezés szerint be van állítva, így nem kell osztályt megadni hozzá. A fő típus azt jelzi, hogy a DNS-kiszolgálónk lesz az elsődleges. Az utolsó mező a zóna adatfájl nevét tartalmazza.
Zóna "mydomain.com" IN (
gépíró;
fájl "db.mydomain.com";
};
Adott sor A konfigurációs fájl a gyökérmutató fájl olvasását utasítja:
zóna "." (
típusú tipp;
fájl "db.cache";
};
Ez a fájl nem tartalmaz gyorsítótár-adatokat, csak a gyökér DNS-kiszolgálókra vonatkozó mutatókat (tippeket), amelyekről az alábbiakban lesz szó.
Általában a konfigurációs fájl így fog kinézni:
Lehetőségek (
"/var/named/" könyvtár;
dump-file "/var/run/named_dump.bd";
Statistics-file "/var/run/named.stats";
};
Zóna "mydomain.com" IN (
gépíró;
fájl "db.mydomain.com";
};
Zóna "130.197.91.IN-ADDR.ARPA." BAN BEN(
gépíró;
fájl "db.91.197.130.";
};
Zóna "0.0.127.IN-ADDR.ARPA." BAN BEN (
gépíró;
fájl "db.127.0.0";
};
zóna "." (
típusú tipp;
fájl "db.cache";
};
Most nézzük meg, hogyan hozhat létre adatfájlokat a mydomain.com., 91.197.130.0, 127.0.0 és a gyorsítótár számára. Általánosságban elmondható, hogy a db.127.0.0 és db.cache fájlok automatikusan jönnek létre, így nem szükséges leírni őket.
Lépjen be a terminálba
Vi /var/named/db.mydomain.com.
Most kezdjük el a fájl szerkesztését.
Már az elején be kell állítania a TTL élettartamának standard értékét. A DNS-szerver a kérésekre válaszul elküldi a megadott TTL értéket, ami lehetővé teszi, hogy más névszerverek gyorsítótárazzák a kapott adatokat a megadott időtartamra. Ha az adatok ritkán változnak, akkor indokolt a frissítési intervallumot néhány napra, de legfeljebb egy hétre beállítani. Ha az adatok gyakran változnak, akkor az intervallumot beállíthatja egy órára, de lehetőleg nem kevesebbre, mivel a rövidebb időközök miatt nagy mennyiségű DNS-forgalom generálódik.
Egy szabványos érték megadásához a $TTL direktívát kell használni. Ebben a példában vegyünk 3 órát (3h) standard értéknek. Az első sor így fog kinézni:
Most meg kell adnia a SOA rekordot. Minden zóna adatfájlban kell lennie. Ez azt mutatja, hogy a DNS-szerverünk a legmegbízhatóbb információforrás ebben a zónában.
Fontos tudni! Egy zónaadatfájlnak csak egy SOA rekordja lehet.
A példa SOA rekordja a következő lenne:
mydomain.com. A SOA-ban ns1.mydomain.com. admin.mydomain.com. (
1; Sorozatszám
3 óra; Frissítés 3 óra múlva
1 óra; 1 óra múlva próbálkozzon újra
1w; 1 hét után lejár
1 óra); Negatív TTL 1 óra múlva
Első helyen a leendő NS domain zónáját jelöljük, a tartomány végére mindenképpen tegyünk pontot. Hogy miért történik ez, egy kicsit később elmondom. Ezt követi a hálózati osztály, ezt már fentebb írtuk, nem kell megadni. A SOA a rekord típusát jelzi. ns1.mydomain.com. a mydomain.com zóna elsődleges DNS-kiszolgálójának címe. És admin.mydomain.com. - a domain zóna tulajdonosának levelezési címe. A zárójelek segítségével több sort is megadhat egy bejegyzéshez. A bennük található alábbi értékek ebben a példában nem igazán szükségesek, főként másodlagos szerverek használják őket, de röviden leírom, mit jelentenek.
A sorszám a zónán belüli összes adatra vonatkozik, és jelzi a frissítések számát. Amikor egy másodlagos DNS-kiszolgáló csatlakozik egy elsődlegeshez, először ellenőrzi a sorszámot. Ha az elsődlegesek száma nagyobb, akkor a másodlagos szerver frissíti az adatait.
A következő négy mező különböző időintervallumokat határoz meg, és ne felejtse el, hogy az alapértelmezett értékek másodpercben vannak megadva.
Frissítés
A frissítési időköz utasítja a másodlagos DNS-kiszolgálót, hogy milyen gyakran ellenőrizze, hogy a zóna információi naprakészek-e. A példában beállított 3 óra nagyon nagy terhelést jelent az elsődleges szerveren, ezért ha ritkán frissíti a másodlagos szerver zónafájljait, érdemes legalább 24 órára állítani az intervallumot.
Próbálja újra
Ha a másodlagos kiszolgáló nem tud csatlakozni az elsődlegeshez (amely valószínűleg már nem fut), akkor az ezen érték által meghatározott rendszeres időközönként újra próbálkozik.
Rosszallás
Ha a másodlagos DNS-kiszolgáló nem tud csatlakozni az elsődlegeshez a megadott időtartamon belül, akkor a rajta lévő adatok elavulnak. Az elavult adatzónák azt jelzik, hogy az információ már nem releváns, és nem szabad többé felhasználni. Érdemes a frissítési intervallumnál jóval nagyobb lejárati értékeket beállítani (egy héttől egy hónapig), különben elavulnak, még mielőtt idejük lenne frissíteni.
Negatív TTL
A TTL ideje élni. Ez az érték a DNS-kiszolgálóktól érkező összes negatív válaszra vonatkozik, amely mérvadó a zónában.
A következő rekordokat NS rekordoknak nevezzük, és minden adatfájlhoz hozzáadódnak.
Mivel a domainek helyes regisztrációjához és támogatásához legalább két NS rekord szükséges, ezt így írjuk:
mydomain.com. IN NS ns1.mydomain.com.
mydomain.com. IN NS ns2.mydomain.com.
Feljegyzéseink azt mutatják, hogy állítólag két különböző DNS-kiszolgáló tartozik a DNS-zónánkhoz. Az NS-rekordok megfelelő működéséhez meg kell adnia azokat az IP-címeket, amelyekre a szerverek telepítve vannak. Ez az A rekordokkal történik:
ns1.mydomain.com. IN A 91.197.130.49
ns2.mydomain.com. IN A 91.197.130.63
db.mydomain.com fájl. kész, folytassuk a következő fájl létrehozásával. Írja be a terminálba:
vi /var/named/chroot/var/named/db.91.197.130.
És szerkesztjük az adatokat, mint az előző fájlban.
Először TTL és SOA rekordot regisztrálunk.
$TTL 3H
130.197.91 IN SOA ns1.mydomain.com admin.mydomain.com (
1
3H
1H
1W
1H)
Space IN NS ns1.mydomain.com.
space IN NS ns2.mydomain.com.
És most megadjuk a PTR rekordokat - ezek az IP-címeknek megfelelő nevek megjelenítésére szolgálnak. Ebben a példában a bejegyzések így néznek ki:
49.130.197.91 PTR ns1.mydomain.com.
63.130.197.91 PTR ns2.mydomain.com.
Itt a fájlunk és kész.
Itt az ideje, hogy beszéljünk a rekord rövidítésekről, amelyek segítségével gyorsabban szerkesztheti a zónaadatfájlokat.
Térjünk vissza a miénkhez konfigurációs fájl. A zóna direktíva mezője határozza meg a tartománynevet. Ez a név az alapértelmezett utótag (eredet) a zónaadatfájlokban található összes információhoz. Az alapértelmezett utótag minden olyan név végére kerül, amelyek nem végződnek ponttal (Ne feledje, azt mondtam, hogy ne felejtsen el pontot tenni a nevek végére). Mivel minden fájl felelős a saját zónájáért, az alapértelmezett utótagok minden fájlban eltérőek.
A rövidítések ezen elve alapján a kódot a következőképpen egyszerűsítheti:
A sor helyett: „ns1.mydomain.com. A 91.197.130.49"-ben megadhatja ezt a sort:
Ns1 IN A 91.197.130.49
A „49.130.197.91 PTR ns1.mydomain.com” bejegyzés. így írható:
49 PTR ns1.mydomain.com.
Ha a domain név megegyezik az alapértelmezett utótaggal, akkor "@"-ként is megadható. Általában egy ilyen rekordot használnak a SOA rekordokban. Például:
@ IN SOA ns1.mydomain.com. admin.mydomain.com. (
1
3 óra
1 óra
1w
1 óra)
Továbbá, ha a bejegyzések (az első sor helyétől kezdődően) szóközökből vagy tabulátor karakterből állnak, a rendszer az előző bejegyzés nevét automatikusan behelyettesíti. Ez a funkció akkor használható, ha több bejegyzést hoz létre azonos névhez:
130.197.91 IN NS ns1.mydomain.com.
Ez a rövidítés alkotáskor is használható különféle típusok bejegyzések egy névhez.
Most nézzük meg, hogyan fognak kinézni a zónaadatállományaink a fent leírt redukciós szabályokkal.
db.mydomain.com fájl.
$TTL 3H
@ IN SOA ns1.mydomain.com. admin.mydomain.com. (
1
3 óra
1 óra
1w
1 óra)
"space" IN NS ns2.mydomain.com.
Ns1 IN A 91.197.130.49
ns2 IN A 91.197.130.63
db.91.197.130 fájl.
$TTL 3H
@ IN SOA ns1.mydomain.com admin.mydomain.com (
1
3H
1H
1W
1H)
"space" IN NS ns1.mydomain.com.
"space" IN NS ns2.mydomain.com.
49 PTR ns1.mydomain.com.
63 PTR ns2.mydomain.com.
Gratulálunk! Befejeztük DNS-kiszolgálónk beállítását két NS-rekorddal.
A szerver indításához és leállításához használja a következő parancsokat a terminálban:
/etc/init.d/named start
/etc/init.d/named stop
/etc/init.d/named újraindítás
Van egy nagyon hasznos program a szerverek tesztelésére - az nslookup.
Címkék: DNS, BIND, NS rekordok, zóna adatfájlok.
A DNS-kiszolgálót úgy tervezték, hogy a webhely(ek) tartományneveit IP-címekre fordítsa és fordítva. Ez a fő feladatuk.
Domain Name System vagy Domain Name System (DNS) felismerő rendszerként jött létre, melynek segítségével egy domain név forrást keres az interneten. Inkább a tartomány keresi az erőforrás IP-címét, és ez keresi és nyitja meg a szükséges internetes erőforrást.
Támogatott elágazó DNS rendszer hierarchikus struktúra DNS szerverek. A keresési hivatkozást a következő lekérdezési lánccal lehet demonstrálni:
A böngésző sorban a következő bejegyzés található: http://www.domain.com → Domain ellenőrzése a DNS-rendszerben → A DNS-rendszer tartományonként keresi a domain.ru webhely IP-címét ↔ IP: XX.XXX.XXX .XX → A webhely tartalma megnyílik. A séma leegyszerűsített, de teljes mértékben feltárja a DNS-kiszolgálók célját.
Mivel a tartománynév-felismerést minden olyan internetes erőforráshoz használják, amelynek saját tartománya van, ezért minden tartományt DNS-kiszolgálókhoz kell kötni, vagy egyébként bármely tartományhoz DNS-kiszolgálókat kell konfigurálnia. Vizsgáljuk meg részletesen a DNS-kiszolgálók konfigurálására szolgáló összes létező módszert.
Minden domain név regisztrátor rendelkezik egy domain-összerendelési szolgáltatással a regisztrátor DNS-kiszolgálóihoz. Ez a szolgáltatás ingyenes. Ha használja, akkor a regisztrátornak meg kell adnia a DNS-szervereinek nevét, amelyeket minden olyan tárhelyen regisztrálnia kell, ahol a domainjét tárolja. A DNS-kiszolgálók nevei a tartományrekordokban, a "Record type - NS servers" (Rekord típusa - NS szerverek) sorban vannak regisztrálva. Legalább két DNS-kiszolgálónak kell lennie.
Ha megosztott tárhelyet bérel, az internetszolgáltatónak meg kell adnia a DNS-kiszolgálóik címét is. Megtekintheti őket a tárhely adminisztrációs paneljén, vagy kérdezheti meg a támogatási szolgáltatót. Ha ilyen DNS-szerver beállítást választott, akkor egy tartomány hosztolásakor adjon meg egy „DNS-kiszolgálók használata” elemet, és írja be magukat a DNS-kiszolgáló címét a névregiszternél a „DNS delegálás” vagy „DNS-zónakezelés” mezőbe. típusú fület.
Ha nem tárhelyet, hanem virtuális dedikált szervert (VDS / VPS) bérel, akkor létrehozhatja saját DNS-kiszolgálóit. Ehhez vásároljon egy második dedikált IP-címet a szerver számára. Minden IP-címnek saját DNS-kiszolgálója van.
Ha két dedikált IP-címe és egy tartománya van a VDS/VPS-kiszolgálón, két tartománynév-kiszolgálót (DNS) hozhat létre. Megmutatom, hogyan kell ezt megtenni az ISP-kezelő szerver vezérlőpultjának példáján.
Nyissa meg a "Domain nevek" lapot;
Válassza ki a kiválasztott domaint DNS létrehozása szerverek. Kattintson duplán a domainre, vagy kattintson a "Hozzászólások" gombra;
A megnyíló „Rekordok” lapon egymás után négy új tartományrekordot kell létrehoznia:
1.Hozza létre az első aldomaint az első NS-kiszolgálóhoz, megadva az első IP-címet;
2. Hozzon létre egy második aldomaint a második NS-kiszolgálóhoz, megadva a második IP-címet;
class="eliadunit">
3. Hozzon létre egy rekordot az NS szerver első címével;
4. Hozzon létre egy rekordot az NS szerver második címével.
Minden. Létrehozta saját NS (DNS) szervereit, amelyek a dedikált VDS/VPS szerver bármely tartományához kapcsolhatók.
Egy másik. A DNS-kiszolgálók létrehozásakor használt tartományhoz regisztrálja a létrehozott DNS-kiszolgálókat a névregisztrátornál, egyúttal megadja a szerver IP-címét. Nézd a képet.
Ha van saját dedikált IP-címe, amely lehetséges a VDS / VPS szerveren, vagy ha IP-címet vásárol a tárhelyen, akkor a tartományt közvetlenül az erőforrás IP-címéhez kötheti. Ehhez a névregiszter rendelkezik egy speciális űrlappal. Ezen az űrlapon három bejegyzést kell létrehoznia. : , [@] és [*], írja be az A-t, és minden bejegyzés a dedikált IP-címét jelzi. Figyelem, IP-t kell kiválasztani. A megosztott tárhely IP-címe nem alkalmas domain összekapcsolására.
A DNS-kiszolgálók konfigurálásának módjait a tartomány harmadik féltől származó DNS-kiszolgálókhoz való kapcsolásával fejezem be. Vannak DNS-kiszolgálók az interneten, amelyeket függetlennek neveznek. Rajtuk ingyenesen vagy térítés ellenében összekapcsolhatja domainjét a DNS-címükkel. Miért történik ez? Feltehetően a kapcsolatok felgyorsítására, a DNS megbízhatóságának növelésére, az erőforrás biztonságának növelésére. Mindenki megtalálja a maga előnyeit a DNS-kiszolgálók ilyen konfigurálásában. A független DNS-kiszolgálók közül a legnépszerűbb a Yandex.
Ezek mind a DNS-kiszolgálók konfigurálásának módjai, amelyekről beszélni akartam. Igen, elfelejtettem. Ingoda, az oldal átvitelekor helyzet alakul ki, az oldal átkerül, és a DNS szerverek megmaradnak a régi tárhelyről. Az oldal működni fog, de nem helyes. Az erőforrás DNS-kiszolgálójának megkereséséhez számos online szolgáltatás létezik. Például, cy-pr.com/tools/dns. A munka elemi. Adja meg domainjét az űrlapon, és a szolgáltatás megjeleníti az összes DNS-kiszolgálóját és tartományrekordját.
Szeretné gyorsan próbára tenni tudását rendszergazda? Kérd meg tőle a Google nyilvános DNS-ének IP-címét. Bármely magát tisztelő rendszergazda a következőt válaszolja: "8.8.8.8", a haladó pedig hozzáadja a "... és 8.8.4.4"-et.
Mi történtDNS?
A DNS a Domain Name System rövidítése. Lefordítva tartománynévrendszerként, olyan rendszer, amely megegyezik egy gazdagép tartománynevével és IP-címével. Tehát a gazdagép nevének ismeretében megkaphatja a címét és fordítva. Mire való? Világháló Az internetet úgy alakították ki, hogy minden eszköznek (számítógép, telefon, táblagép, útválasztó) saját egyedi címe legyen (valójában a címek megismételhetők, ha beszélgetünk a különböző HELYI hálózatokról, de ebben a cikkben arról beszélünk globális hálózatés nem megyünk bele a NAT, PAT és útválasztás részleteibe), és ehhez az eszközhöz csak a hálózaton található címének ismeretében férhet hozzá. Miközben az interneten dolgozunk, naponta több tucat webhelyhez érünk el. Nehéz lenne megjegyezni az összes címüket, például számok és pontok sorozatából, melyiket könnyebb megjegyezni: 77.222.61.238 vagy integrus.compumur.ru? Természetesen a második. A domain névrendszer pedig megjegyzi az Ön címét.
A DNS minden számítógépen, minden hálózaton és minden szolgáltatón megtalálható, ráadásul van hierarchikus nézetés abban az esetben, ha a tartománynévrendszer nem tudja meghatározni a kért erőforrás címét a tartománynévből, akkor továbbítja a kérést egy upstream DNS-kiszolgálónak. A lekérdezés akár a 13 "világ legfontosabb" gyökér DNS-kiszolgálójának egyikére is elküldhető.
A szerver különféle funkciókat lát el, működhet globális katalógusként, fájlinformációkat tárolhat, dolgozhat adatbázisokkal, dolgozhat egyszerre több felhasználóval. A kiszolgáló céljától függően szerepek vannak telepítve rá - egy speciális programkészlet, amely lehetővé teszi a szerver számára a szükséges funkciók elvégzését.
Szerepkör telepítéseDNS szerverek? Telepítjük tovább Windows Server 2012R2.
A DNS-kiszolgáló szerepkör leggyakrabban egy tartományvezérlővel van telepítve. De ha közben Aktív beállítások Könyvtár, törölte a „DNS-kiszolgáló” négyzet bejelölését, vagy egyszerűen nincs szükség AD-re, akkor csak a DNS-kiszolgálót kell telepítenie. Ehhez lépjen a szerverkezelőbe, és kattintson a "Szerepek és szolgáltatások hozzáadása" gombra.
Megnyílik a Szerepkörök és szolgáltatások hozzáadása varázsló ablak. Olvassa el a varázsló bevezető szövegét, majd kattintson a Tovább gombra. 
Győződjön meg arról, hogy a Szerepkörök és szolgáltatások telepítése lehetőség van kiválasztva, majd kattintson a Tovább gombra. 
Válasszon ki egy kiszolgálót a kiszolgálókészletből. A mi esetünkben csak egy szerver van, több is lehet. 
Válassza ki a DNS-kiszolgáló szerepét. 
Ha a szükséges elemet pipával bejelöli, megjelenik a „Szerepek és szolgáltatások hozzáadása varázsló” ablak. Ezek az összetevők szükségesek a telepített szerepkör kezeléséhez. Ha egy másik szerverről kívánja adminisztrálni a DNS-kiszolgálót, akkor kihagyhatja ezen összetevők hozzáadását. 
Visszatérve a DNS-kiszolgáló jelölőnégyzetet tartalmazó ablakhoz, kattintson a Tovább gombra, majd ismét a Tovább és a Tovább gombra, amíg a Telepítés gomb aktívvá nem válik. 
Kattintson a "Telepítés" gombra. 
A telepítés megkezdődik. 
A telepítés befejezése után (a telepítés kevesebb, mint 5 percig tart) a következő üzenet jelenik meg: "A telepítés befejeződött a YourServerName-n". Kattintson a "Bezárás" gombra. Most egy új "DNS" sor jelenik meg a Kiszolgálófelügyeleti panelen, valamint a Start menüben. Ha erre a sorra kattint, elindul a "DNS Manager".
Ez így néz ki.
Tovább Ebben a pillanatban Nincs zóna konfigurálva a DNS-kiszolgálón. Az ilyen szervert gyorsítótárazó szervernek nevezzük. A zónák a névtér azon részei, amelyekért a szerver felelős. A továbbítási keresési zónák magukban foglalják a név IP-címmé történő fordítását. Ezzel szemben a fordított keresési zóna az IP-címet egy névhez rendeli hozzá.
Hozzunk létre egy előre keresési zónát, és készítsük el egyszerű beállítás.
Ehhez kattintson a gombra Jobb klikk kattintson a "Forward Lookup Zones"-re, majd az "New Zone"-ra.
Megnyílik az "Új zóna varázsló" ablak, kattintson a "Tovább" gombra. Megnyílik a zónatípus kiválasztási ablak. Ha nincs másik DNS-kiszolgálója, válassza az "Elsődleges zóna" és a "Következő" lehetőséget. 
A következő ablakban meg kell adnia a zóna nevét. Javasoljuk, hogy használja a domainjét. Esetünkben a név a következő lenne: . Kattintson a "Tovább" gombra. 
A következő ablakban válassza ki a dinamikus frissítés típusát. Javasoljuk, hogy engedélyezze a dinamikus frissítéseket, de csak akkor, ha a DNS-t kizárólag az Ön által használt rendszer fogja használni helyi hálózat. Ellenkező esetben ez az elem biztonsági kockázatokat rejthet magában, amelyekre az Új zóna varázsló figyelmezteti. 
Kattintson a "Tovább" és a "Befejezés" gombra. A forward lookup zóna sikeresen létrejött, végezzük el az egyszerű beállítását. A böngészési zóna konfigurálása DNS-rekordok zónához való hozzáadásával történik. A DNS-rekordoknak többféle típusa van. Fontolja meg a fő típusokat:
Hozzunk létre egy A-rekordot az új előrekeresési zónánkhoz. Ehhez kattintson a jobb gombbal a zónára, és válassza ki a megfelelő elemet. helyi menü, ahogy a képen is látszik. 
A megnyílt ablakban" Új csomópont» Adja meg a gazdagép nevét, például GateWay és annak IP-címét, például 192.168.0.1. Kattintson a Csomópont hozzáadása gombra. 
Kész! A bejegyzés sikeresen létrehozva!
Ebben a cikkben megpróbáltuk a legérthetőbb nyelven elmagyarázni egy egyszerű, mély informatikai ismeretekkel nem rendelkező embernek, hogy mi az a DNS, hogyan kell telepíteni a DNS-kiszolgáló szerepkört a Windows Server 2012 rendszeren, megismerkedtünk a fő rekordtípusokkal és képekben bemutattuk. hogyan készülnek ezek a feljegyzések. És ha a fentiek mindegyike nehéznek tűnt számodra, akkor szakembereink kevesebb, mint egy óra alatt felállítanak egy szervert.
Folytatva a webhelyépítés témáját, beszéljünk egy olyan fontos szempontról, mint a domain névrendszer - DNS - működése. A kezdeti elhelyezéssel, valamint a helyek különböző szerverek és tárhelyek közötti átvitelével kapcsolatos számos probléma a DNS-zóna konfigurációjával és helyével kapcsolatos. A domain névrendszer működésének megértése megkönnyíti a saját domainek és a kapcsolódó webhelyek és egyéb szolgáltatások kezelését.
Mi az a domain név? Sokak számára ez a webhely címének szinonimája, például www.site. Ha beírja ezt a címet, szilárdan meg van győződve arról, hogy erre az oldalra fog eljutni, és nem máshová. Ugyanakkor a domain név nemcsak webhelyet, hanem szervert is jelenthet Email, rövid üzenetküldés vagy egyéb internetes és hálózati szolgáltatás. A tartománynevek tartomány zónákban szerepelnek, amelyek hierarchikus sorrendben helyezkednek el egymáson belül.
Általánosságban elmondható, hogy a domain egy szimbolikus név, amely egyedileg címez egy autonóm névteret az interneten. És nem csak megszólítani, hanem lehetővé tenni bármely ügyfél számára, hogy gyorsan megtalálja a kívánt csomópontot anélkül, hogy a legcsekélyebb fogalma is lenne a helyéről. Túlzás nélkül elmondható, hogy a DNS-rendszer a modern internet alapja abban a formában, ahogyan azt mindannyian ismerjük és megszoktuk.
A DNS-rendszer globális és szigorú hierarchiával rendelkezik. Tekintsük a következő diagramot:
A hierarchia legfelső szintje a ponttal jelölt gyökértartomány, amely információkat tartalmaz az első szintű tartományokról, pl. hu, com, org stb. A gyökérzóna munkáját 13 gyökérszerver biztosítja a világ minden táján, és folyamatosan replikálják egymás között az adataikat. Valójában több gyökérszerver is létezik, de a protokollszolgáltatások csak 13 legfelső szintű csomópont megadását teszik lehetővé, így a rendszer méretezhetőségét és hibatűrését az egyes gyökérszerverek tükrei biztosítják.
Az első szintű domainek ismerősek számunkra domain zónák nemzeti és nemzetközi szervezetek is kezelhetik, és saját felhasználási feltételekkel rendelkeznek. Minden egyes első szintű tartomány zóna lehetővé teszi korlátlan számú másodszintű tartomány elhelyezését, amelyek webhelycímként minden internetfelhasználó számára ismerősek.
A második szintű tartományok viszont egyben tartományzónák is, és lehetővé teszik harmadik szintű tartományok elhelyezését, amelyekben, mint egy fészkelő babánál, negyedik, ötödik stb. szinteket. A különböző zónákban elhelyezkedő csomópontok egyedi azonosítása érdekében a koncepció teljesen minősített domain név (FQDN, Teljesen minősített domain név), amely tartalmazza a DNS-hierarchiában lévő összes szülőtartománynevet. Például webhelyünk esetében az FQDN a következő lenne: weboldal.Így van, pontra végződve, ami a gyökérzónát jelöli.
Ez nagyon fontos pont. A mindennapi használatban a zárópont elvetése megszokott, de a DNS rekordokban az utolsó pont hiánya azt jelzi, hogy az adott domain név az aktuális tartományzónához tartozik, pl. A DNS-kiszolgáló egy ilyen névhez hozzáadja a saját tartományzónáját és az összes magasabb zónát a gyökérig.
Például a szerverünkön a zónában weboldal hozzáadunk egy CNAME rekordot, amely rá fog mutatni harmadik fél szerver, mondjuk, Yandex mail. A helyes bejegyzésnek így kell kinéznie:
MailIN CNAMEdomain.mail.yandex.net.
BAN BEN ez az eset A mail nem FQDN, és ki lesz töltve mail.site., ha elfelejtünk egy pontot tenni a Yandex domain név végére, akkor ez a név szintén nem lesz FQDN, és a teljes domain névre kell kitölteni. A következő hibás bejegyzés:
Levelezés: CNAME domain.mail.yandex.net
Tapasztalatlan szemmel nehéz észrevenni a különbséget, de a Yandex mail webes felülete helyett ez a design egy nem létező címre küld minket: domain.mail.yandex.net.site.
Még egy pillanat. A tartományi zónák minden rekordját a zóna adminisztrátorai készítik a saját DNS-kiszolgálóikon. Hogyan válnak ezek a rekordok ismertté a DNS-rendszer számára? Végül is nem értesítjük az upstream DNS-kiszolgálókat, ha bármilyen rekordot megváltoztattunk.
Bármely DNS-zóna csak a tagjairól és a gyermekzónákról tartalmaz rekordokat. Az alsó zóna csomópontjaira vonatkozó információkat a saját szerverein tárolják. Ezt delegálásnak nevezik, és lehetővé teszi a gyökérkiszolgálók terhelésének csökkentését, és a szükséges autonómiát biztosítva a gyermektartományi zónák tulajdonosainak.
Tehát mondjuk vásárolt egy domaint example.org, utána delegálnia kell, pl. adja meg a névszervereket (DNS-kiszolgálókat), amelyek a fájlzóna rekordjait tartalmazzák. Ezek lehetnek saját szerverei és nyilvános szolgáltatásai, például a Yandex DNS.
Ebben az esetben a tartományi zónában org bejegyzés kerül hozzáadásra:
Példa IN NS dns1.yandex.net.
Ez azt jelzi, hogy a zóna összes rekordja a szerveren található dns1.yandex.net. A szabályok szerint minden tartományzónának legalább két NS-kiszolgálóval kell rendelkeznie, amelyek különböző alhálózatokon helyezkednek el. A gyakorlatban gyakran megboldogulnak egy szerverrel, két különböző tartományból származó IP-címet szerezve neki.
Most pedig nézzük meg, hogyan történik a keresett DNS-rekord, és miért teszi lehetővé a szerverén készült rekord a látogatók számára, hogy a világ bármely pontjáról eljuthassanak webhelyére.
Tegyük fel, hogy egy felhasználó meg akar látogatni egy népszerű Yandex Market-forrást, és beírja címsor a webhely nevének megfelelő böngészőben, és nyomja meg az Enter gombot. Az oldal tartalmának a felhasználó számára történő megjelenítéséhez a böngészőnek kérést kell küldenie az oldalt kiszolgáló webszervernek, ehhez pedig ismernie kell annak IP címét. Ezért a böngésző felveszi a kapcsolatot a DNS-klienssel, hogy megtudja, melyik cím felel meg a felhasználó által megadott tartománynévnek.
A DNS-kliens viszont ellenőrzi a bejegyzéseket a hosts fájlban, majd a helyi gyorsítótárban, és nem találja ott a szükséges bejegyzéseket, továbbítja a kérést a hálózati beállítások DNS szerver. Ez valószínűleg egy helyi DNS-gyorsítótárazó proxy, például a dnsmasq vagy a vállalat helyi DNS-kiszolgálója. Ezek a megoldások általában nem a globális DNS rendszer teljes értékű szerverei, és nem is szerepelnek benne, csak a helyi zónát szolgálják ki és gyorsítótárazza a DNS kéréseket, így az ilyen kérés, ha az adatok nincsenek a gyorsítótárban, átkerül a magasabb szintre. DNS-kiszolgáló, általában a szolgáltató szervere.
A kérés beérkezésekor a szolgáltató szervere ellenőrzi a saját bejegyzéseit, majd a saját gyorsítótárát, és ha az eredményt megtalálja, azt jelenti a kliensnek, ellenkező esetben a szervernek a rekurzió- keresés a globális DNS rendszerben. A folyamat mechanizmusának jobb megértése érdekében elkészítettük a következő diagramot:
Tehát az ügyfél DNS-kérést küld a szolgáltató szerverének, hogy megtudja a tartomány címét market.yandex.ru, a szolgáltató szervere nem rendelkezik ilyen információval, ezért az egyik gyökérszerverre hivatkozik, kérést továbbítva neki. A gyökérszerver szintén nem rendelkezik a szükséges rekordokkal, de azt válaszolja, hogy ismeri a zónáért felelős szervert hu - a.dns.ripn.net. Ezzel a névvel együtt a gyökérszerver azonnal jelenteni tudja az IP-címét (és a legtöbb esetben meg is teszi), de ezt nem teheti meg, ha nem rendelkezik ilyen információval. Ebben az esetben, mielőtt kapcsolatba lépne ezzel a szerverrel, egy másikat kell végrehajtania. egy rekurzív lekérdezés, csak a nevének meghatározásához.
Miután megtudta a ru zónáért felelős szerver címét, a szolgáltató szervere elküldi a kérést, de adott szerver szintén nem rendelkezik a szükséges bejegyzésekkel, de megmondja, mi a zóna yandex válaszol a szerver ns1.yandex.ruÉs Szükségszerűen adja meg a címét. Ellenkező esetben a rekurzió nem fejezhető be, mivel a zóna yandex a zónában lévő szerver válaszol yandex. Ehhez a szülő zónában a zónát kiszolgáló névszerverekről szóló NS rekord mellett egy "linkelt" A-rekord, amely lehetővé teszi egy ilyen szerver címének megtudását.
Végül egy kérés elküldésével a zónát kiszolgáló szervernek yandex, a szolgáltató szervere megkapja a kívánt tartomány címét és jelenti azt a kliensnek. Az eredményt a gyorsítótárban is elhelyezi a tartomány SOA rekordjában lévő TTL érték által biztosított ideig. A gyakorlatban, mivel a rekurzív lekérdezések nagyon drágák, a rekordok szolgáltatók általi gyorsítótárazási ideje figyelmen kívül hagyhatja a tartomány TTL-értékeit, és két-négy órától több napig vagy akár egy hétig terjedő értékeket érhet el.
Most vegyél még egy pontot. A lekérdezések lehetnek rekurzívak vagy nem rekurzívak. A rekurzív kérés kész választ ad, pl. IP-címek vagy üzenetek arról, hogy a tartomány nem létezik, nincs delegálva stb. A nem rekurzív lekérdezés csak arra a zónára ad választ, amelyért az adott szerver felelős, vagy hibát ad vissza.
Mivel a rekurzív lekérdezések meglehetősen erőforrásigényesek, a legtöbb DNS-hálózati kiszolgáló a rekurzív lekérdezéseket nem rekurzív módon dolgozza fel. Vagy szelektíven is megtehetik, például a szolgáltató DNS-szerverei csak az ügyfeleik számára hajtanak végre rekurzív lekérdezéseket, a többi pedig nem rekurzív módon.
Esetünkben a kliens rekurzív kérést küldött a szolgáltató szerverére, amely viszont egymás után nem rekurzív kéréseket küldött, amíg meg nem találta a kívánt szervert, amely megadta a szükséges választ. Ugyanakkor nemcsak a felhasználói kérések eredményei kerülnek a szolgáltató szerverének gyorsítótárába, hanem a közbenső kérések eredményei is, ami lehetővé teszi az alábbi ilyen kérések nem rekurzív vagy minimális számú végrehajtását. kéréseket.
Például, ha egy felhasználó a Yandex Market felkeresése után úgy dönt, hogy használja a levelezési szolgáltatást, a szerver azonnal kérést küld a ns1.yandex.ru, mivel már tudja, hogy melyik szerver tárolja a zóna bejegyzéseit yandex.
Amikor egy regisztrátortól vásárol domaint, a rendszer felkéri, hogy delegálja azt, pl. Adja meg a DNS-kiszolgálókat, ahol a tartományzóna elhelyezkedni fog. Ezek lehetnek regisztrátor szerverek (általában ingyenes), hosting szerverek, nyilvános DNS szolgáltatások vagy saját névszerverek, ha ugyanabban a domain zónában található, akkor IP címeket is meg kell adni. Például így néz ki a domain delegálási ablaka egy jól ismert regisztrátornál:
Pontosan mit kell ott feltüntetni? Ez attól függ, hogy hol és hogyan tárolja webhelyét. Ha virtuális tárhelyet használ, akkor minden szükséges rekordokat amelyeket a tárhely automatikusan létrehoz, amikor hozzáadja webhelyét a tárhely vezérlőpultjához, mindössze annyit kell tennie, hogy delegálja a tartományt a tárhely NS-szerverére, azaz. jelezze őket ebben az ablakban. Ez a módszer egyszerűsége miatt kiválóan alkalmas kezdőknek, de van egy hátránya, hogy a DNS-zóna felhasználó általi kezelésének lehetősége hiányzik vagy minimális. Ráadásul tovább virtuális tárhely Az oldal IP-címét az adminisztrátorok a felhasználó értesítése nélkül módosíthatják, ezért ha nem kívánja használni a gazdagép NS szerverét, akkor ezt a problémát a technikai támogatással egyeztetni kell.
Ha átviszi a webhelyet egy másik gazdagépre, akkor át kell vinnie a webhelyet, és meg kell változtatnia a régi gazdagép névszervereit az új gazdagép szervereire a regisztrátornál. De ne feledje, hogy a DNS-kiszolgálók gyorsítótárában lévő információk nem frissülnek azonnal, hanem legalább a TTL tartományérték lejárta után, így egy ideig webhelye továbbra is elérhető a régi címen. Ha sürgősen dolgoznia kell vele, anélkül, hogy megvárná a szolgáltató DNS-gyorsítótárának frissítését, hozzáadhatja a fájlt otthont ad bejegyzés a következő tartalommal:
1.2.3.4 example.com
Ahol 1.2.3.4 És example.com az új IP-címet és a domain nevet.
Ha saját VPS-je van, vagy teljes mértékben szeretné felügyelni a domain zónát, akkor használja a regisztrátor szervereit vagy nyilvános szolgáltatásokat. Saját névszerver létrehozása véleményünk szerint nem életképes ötlet, hacsak nem saját tárhelyet csinálsz.
Ebben az esetben létre kell hoznia legalább két A-rekordot, amelyek a webhelyet ebben a tartományban kiszolgáló webszerverre mutatnak:
@ IN A 1.2.3.4
www IN A 1.2.3.4
A DNS-rekordokban lévő doggy szimbólum magát a tartományt jelöli, és mindenképpen hozzon létre egy rekordot a www aldomainhez, hogy a webhely címét www-ről tárcsázó felhasználók is hozzáférhessenek.
Nem vesszük fontolóra rekordok hozzáadását az e-mailekhez, erről cikkünkben olvashat:
Egy webhely migrálásakor csak az A-rekordokban lévő IP-címeket kell módosítania, és meg kell várnia a DNS-információk frissítését. Általában ez a legkellemetlenebb pillanat - úgy tűnik, hogy minden megtörtént, de nem tudsz semmit megváltoztatni, csak várnod kell. De ha követ néhány ajánlást, akkor ez a folyamat a lehető legfájdalommentesebben és észrevehetetlenül elvégezhető a látogatók számára.
Először is módosítsa a TTL értéket a SOA rekordban. Ez alapértelmezés szerint több óra, és ennyi ideig kell várnia, amíg a rekord frissül a DNS-kiszolgálók gyorsítótárában. Az aktuális TTL érték kiderítéséhez futtassa a parancsot, megadva a kívánt tartománynevet:
nslookup -typr=soa webhely
Esetünkben ez 4 óra: 
Ezért előre, legalább 4 órával (régi TTL érték) a tervezett átutalás előtt módosítsa a TTL értéket egy alacsonyabbra, például 900-ra (15 perc). Ezután állítsa a webhelyet írásvédett módba, és vigye át az új szerverre. Az oldalt nem szabad leállítani vagy karbantartásra vinni, elérhető lehet és kell is maradnia. De ki kell zárnia az információk felhasználók általi módosítását és hozzáadását, pl. megtiltani a regisztrációt, kommentálást, rendelés leadását stb. Ezenkívül ügyeljen arra, hogy jól látható helyen tegyen közzé egy üzenetet műszaki munkaés hozzávetőleges befejezési dátum.
Ha új szerverrel szeretne dolgozni a DNS-rekordok megváltoztatása nélkül, adja hozzá a szükséges sort a következőhöz host fájl. Miután elhelyezte az oldalt az új oldalon, és megbizonyosodott arról, hogy megfelelően működik, módosítsa a DNS rekordokat, most 15 perc múlva az első felhasználók elkezdik látogatni az oldalt az új szerveren. A régi szerver teljesítményét még egy ideig fenn kell tartani, ideális esetben akár egy hétig, mivel nem minden szolgáltató használja a SOA rekord TTL értékét a gyorsítótár frissítéséhez, saját beállításaival csökkenthető a terhelés a felszerelés.
Sikeres migráció után a TTL értéket a korábbi értékekre kell növelni, hogy ne keletkezzen szükségtelen terhelés a névszervereken.
A legtöbbet áttekintettük egyszerű áramkör, de a gyakorlatban az oldal mellett általában van egy irodai hálózat is, amelynek sok erőforrása kívülről is elérhető kell legyen. Tekintsük a következő diagramot:
Nyilvános szervereink vannak a webhelyhez és az e-mailekhez, valamint egy irodai hálózatunk, amelyhez aldomaint jelöltünk ki hivatal. Ha nincs különleges probléma a levelezéssel és a webszerverrel, akkor vannak lehetőségek az irodaterülettel kapcsolatban. A helyi zónát általában a saját DNS szolgálja ki, és semmilyen módon nem kapcsolódik a szülőzónához. Globális DNS-zónához iroda.example.com nem létezik, de az azonos nevű gazdagép létezik. Ez akkor indokolt, ha a vállalati hálózat a NAT mögött helyezkedik el, és csomópontjai csak szürke címekkel rendelkeznek, és a külső hozzáférés csak arra az átjáróra történik, amelyre a megfelelő portokat a belső csomópontokból továbbítják.
Ebben az esetben a DNS-rekordok a zónához tartoznak example.comígy nézhet ki:
@ IN A 1.2.3.4
www IN A 1.2.3.4
levél A 1.2.3.5
iroda IN A 5.6.7.8
Van azonban némi nehézség, amikor a hálózaton belül az ügyfelek belső neveken érik el a hálózati szolgáltatásokat: corp.office.example.com vagy rdp.office.example.com, amelyek a belső „szürke" címekre mutatnak. „A helyi hálózaton kívül azonban nem lehet IP-címet feloldani az ilyen nevekre, mivel a globális DNS-rendszer számára nincs olyan zóna, amely ezeket tartalmazza. A Split-DNS nevű mechanizmus lehetővé teszi, hogy kikerüljön a helyzetből, ami lehetővé teszi, hogy az ügyfél pozíciójától függően különböző eredményeket adjon.
A helyi hálózaton az ügyfelek DNS-kérelmeit a helyi szerver, amely rendelkezik a megfelelő rekordokkal, a rajta kívüli kérések a zónát kiszolgáló szerverre kerülnek example.com. Ugyanakkor az összes vállalati erőforrás, amelyet a helyi hálózat különböző szerverei képviselnek, kívülről egyetlen címen érhetők el: iroda.example.com. Ideje tehát az álnéven vagy a CNAME rekordon gondolkodni. Ez a bejegyzés lehetővé teszi további emlékeztetők vagy álnevek társítását a valódi gazdagépnévhez. Azonban vegye figyelembe, hogy az álnevek használata más bejegyzésekben nem megengedett. Esetünkben a következő bejegyzéseket kell hozzáadnunk:
Corp.office IN CNAME iroda.example.com.
rdp.office A CNAME-ben office.example.com.
Mostantól az ügyfél, függetlenül a helyétől, ugyanazt a nevet használhatja az erőforrásokhoz való hozzáféréshez, de az eredmény más lesz. A helyi hálózatban megkapja a szerver valós címét és közvetlenül csatlakozik, kívülről pedig a hálózati átjáróhoz kerül.
A CNAME rekordok segítségével az elfogadott tartományzónán kívülre is átirányíthat. A fő feltétel az, hogy a CNAME rekordnak valódi névre kell mutatnia az FQDN formátumban.
Az álnevek másik felhasználási módja a cím rövidítése. Mondjuk mint levelezőszerver az egész domain számára example.com olyan szervert szeretnénk használni, amely a moszkvai irodában található, és rendelkezik a címmel mail.iroda.msk.example.com, látod, nem tűnik túl vonzónak. Sokkal kényelmesebb lenne az űrlap címe mail.example.com, nincs könnyebb, adja hozzá a következő bejegyzést:
Levelezés CNAME-ben mail.office.msk.example.com.
De ne feledje, hogy a többi erőforrásrekordnak csak valódi neveket kell használnia, így ez a rekord helytelen lesz:
example.com. MX 10 levélben
Így lesz helyes:
example.com. IN MX 10 mail.office.msk
Végül beszéljünk a tartományi zónák delegálásáról. A fenti példában azt a helyzetet vettük figyelembe, amikor egy tartományon belül különböző aldomainek vannak allokálva különböző aldomainekhez, hiszen minden alegységnek saját infrastruktúrája van, vagyis célszerű a saját tartományzónáik kezelését rájuk delegálni. Erre a környéken example.com minden zónához helyezzen el egy NS-t és a hozzá tartozó A-rekordot. Például:
Msk IN NS ns1.msk.example.com.
msk IN NS ns2.msk.example.com.
ns1.msk IN A 1.2.3.4
ns2.msk IN A 5.6.7.8
Most, amikor hozzáfér a címhez, mondjuk mail.iroda.msk.example.com zóna névszerverek example.com kiadja a zónát kiszolgáló szerver nevét és címét msk.example.com. Ez lehetővé teszi a zóna adminisztrátorai számára, hogy maguk hajtsák végre a szükséges változtatásokat anélkül, hogy ez befolyásolná a szülőzóna működését, és anélkül, hogy felvenné a kapcsolatot a rendszergazdákkal olyan probléma esetén, amely a rekordok módosítását igényli.
