A modern internet nem más, mint különféle számítógépek, laptopok és mobil eszközök egy hálózatban csatlakoznak egymáshoz. Valójában ezek az eszközök szerverek. Végül is mindegyiknek egyedi IP-címe van. Az IP-nek köszönhetően megtörténik az eszközök azonosítása a globális hálózatban.
Ugyanakkor az internethez kétféle szerverre van szükség: elsődleges és másodlagos. Az elsőt felhasználói webhelyek tárolására használják. Attól függően, hogy mennyi információt küldenek és fogadnak, különböző számú webhely tárolható a szerveren - egytől (facebook.com, mail.ru, odnoklassniki.ru) több ezerig. A második típust a helper szerverek képviselik, amelyek általános együttműködési képességet biztosítva segítik a főhálózat működését. A DNS-kiszolgálók az ilyen segítő eszközök egyik típusa.
Mi az a DNS szerver és mire használják
A DNS-kiszolgáló lényegében egy számítógép, de valójában nem. A Domain Name System (DNS) részét képező elosztott adatbázis hosztolására szolgál, amely az érdeklődésre számot tartó domainekkel kapcsolatos információk fogadására, továbbítására és továbbítására szolgál. A DNS-kiszolgálók egy hálózathoz csatlakoznak, és egy adott protokoll használatával kommunikálnak egymással.
Lehetne egyszerűbb leírást is adni. A DNS-kiszolgáló használatával az általunk megszokott webhelynév megfelelését annak IP-címe határozza meg. Ezeket az információkat egy folyamatosan frissített adatbázisban tároljuk.
Tekintsük az egész sorozatot a gyakorlatban. A böngésző, amelyben a felhasználó megnyitja a webhelyet, először felveszi a kapcsolatot a DNS-kiszolgálóval, és értesíti őt, hogy meg akarja találni és eljutni arra a webhelyre, amelynek címe a címsor szövegmezőjébe került. Menj tovább. A DNS-kiszolgáló a bázisa alapján meghatározza, hogy a hálózaton hol található egy ilyen nevű webhely, összehasonlítja azt a szerver IP-címével a rajta található erőforrással, és kérést küld oda. Ennek eredményeként válasz jön létre, amely a webhelyet alkotó különféle fájlokból áll (HTML-dokumentumok, képek és táblázatok, CSS-stílusok), és elküldik a felhasználó böngészőjének.
Hol vannak a DNS-kiszolgáló beállításai, és hogyan lehet megtudni a címét a Windows 7 rendszerben
Vegyünk egy olyan helyzetet, amikor egy felhasználó a Windows 7 rendszert futtató számítógépén csendesen "szörföl" az interneten. Ez azt jelenti, hogy a DNS-kiszolgáló működik. Ezt úgy ellenőrizheti, hogy a "Szolgáltatások" menüben a vezérlőpult "Adminisztráció" lapján átmegy, és megtekinti a DNS-kliens állapotát. A szolgáltatást az automatikus indítási típus kiválasztásakor engedélyezni kell.
A DNS-kiszolgáló címének megtudásához használja az ipconfig / all parancsot annak beírásával parancs sor a cmd.exe segédprogram rendszergazdaként fut.
Telepítés és konfigurálás: utasítások
A DNS-kiszolgáló a hálózati protokoll konfigurálásakor csatlakozik.
Indítási sorrend:
Megjegyzendő, hogy ez az automatikus konfiguráció csak akkor lehetséges, ha a DHCP-kliens szolgáltatás engedélyezve van, amely lehetővé teszi a DHCP-szerver elindulását és működését a hálózaton. Beállításai a megfelelő elem kiválasztásával megtekinthetők és módosíthatók nyitott ablak rendszerszolgáltatások a vezérlőpult „Adminisztráció” lapján.
Az automatikus konfiguráció a szolgáltató DNS-kiszolgálóit használja. Ez nem mindig tanácsos, mert nehézségek adódhatnak. Például a szolgáltató szerverei messze nem mindig képesek megbirkózni a felmerülő terhelésekkel, és nem végeznek szűrést. Ebben az esetben célszerű nagy, jól ismert cégeken keresztül csatlakozni.
Yandex DNS szerverek:
Google DNS szerverek:
OpenDNS DNS szerverek:
A kiválasztott cégtől függően az Internet protokoll tulajdonságai ablakban a preferált és alternatív DNS-kiszolgálók mezőiben egy címpár kerül beírásra, amikor a használatukra vonatkozó választógombot bejelöljük.
Lehetséges problémák és megoldások
Ha problémái vannak az internet-hozzáféréssel, ne rohanjon idegesnek lenni. Lehetséges, hogy ez a DNS-kiszolgáló meghibásodása miatt történt.
Főbb problémák:
Előfordulhat, hogy szolgáltatója bekapcsolta egyes DNS-kiszolgálók blokkolását, vagy a hálózati protokoll beállításaiban megadott címek elérhetetlenné váltak. A probléma megoldása nagyon egyszerű. Először próbálja meg megváltoztatni a DNS-kiszolgálók címét, és ha ez nem sikerül, akkor kapcsolja be az automatikus fogadásukat. Ha a probléma nem oldódik meg, keressen más okot, vagy lépjen kapcsolatba a szervizközponttal.
Videó: Mi a teendő, ha a DNS nem válaszol, és hogyan lehet más problémákat kijavítani
DHCP szerver és miben különbözik a DNS-től
A DHCP-kiszolgáló a kiszolgálók kiegészítő típusára utal, amely tartalmaz hálózati protokoll egy csomópont dinamikus konfigurációjának biztosítása bármely, az internethez csatlakozó hálózati eszköz automatikus konfigurálásának szakaszában. Ebben az esetben a hálózati rendszergazda csak a címtartományt adja meg. Ebben az esetben nincs kézi beállítás, és ennek megfelelően csökken a fellépő hibák száma. Ennek az az oka, hogy a szerver automatikusan elosztja a címeket a számítógépek között a megadott tartománynak megfelelően. A legtöbb TCP/IP hálózat DHCP-t használ.
A DNS a Domain Name System, azaz a „Domain Name System” rövidítése. Ez egy olyan rendszer, amelyben a szerverek összes tartományneve egy bizonyos hierarchia szerint van elosztva. Nézzük meg, mire valók a DNS-kiszolgálók, hogyan konfigurálhatjuk őket Windows 7 rendszeren, mi a teendő, ha a kiszolgáló nem válaszol, és hogyan lehet kijavítani a lehetséges hibákat.
Mi az a DNS és mire való
A DNS-kiszolgáló információkat tárol a tartományokról. Mire való? Az a tény, hogy a számítógép nem érti a hálózati erőforrások betűjeleit. Például a yandex.ru. Ezt a webhely címének nevezzük, és számítógépen ez csak egy 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ó bináris számként jelennek meg. 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ér egy erőforráshoz, de a négyjegyű címek memorizálása nehéz lenne. 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 beír egy webhely címét a böngésző keresősávjába, az adatok elküldésre kerülnek a DNS-szervernek, amely az adatbázisával megegyező találatokat keres. Ezután a DNS elküldi a szükséges 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 a DNS-t beállítja a számítógépen, a hálózathoz való csatlakozás egy DNS-kiszolgálón keresztül megy végbe, amely lehetővé teszi a számítógép védelmét a vírusoktól, a szülői felügyelet beállítását, bizonyos webhelyek letiltását és még sok mást.
Hogyan lehet megtudni, hogy a DNS-kiszolgáló engedélyezve van-e a számítógépen
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.
Hogyan kell telepíteni
Videó: DNS szerver beállítása
Miért kell megváltoztatni a DNS-kiszolgáló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 lassúak, vagy egyáltalán nem működnek. Nagyon gyakran az üzemeltetők DNS-kiszolgálói nem tudnak megbirkózni a terheléssel és az „összeomlással”. Ami miatt lehetetlen felmenni az internetre.
Ezenkívül a szabványos DNS-kiszolgálóknak csak az IP-címek észlelésének és karakterekké alakításának funkciói vannak, de nincs szűrési funkciójuk. A nagyvállalatok harmadik féltől származó DNS-kiszolgálói (például a Yandex.DNS) mentesek ezektől a hátrányoktól. Szervereik mindig különböző helyeken találhatók, és az Ön kapcsolata a legközelebbi helyen megy keresztül. Ennek köszönhetően megnő az oldalak betöltésének sebessége.
Szűrő funkcióval rendelkeznek és szülői felügyeleti funkciót hajtanak végre. Ha gyermekei vannak, akkor ez a legjobb megoldás - a kétes webhelyek, amelyeket nem a gyermekek közönségének szántak, 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ó webhelyek blokkolva lesznek, és nem fog tudni véletlenül elkapni egy vírust.
A harmadik fél DNS-kiszolgálói 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. De tény, hogy az internetszolgáltatók kénytelenek megtiltani a hozzáférést a Roskomnadzor által letiltott oldalakhoz a DNS-szervereiken. A független DNS-szervereknek, a Goggle-nek, a Yandex-nek és másoknak erre egyáltalán nincs szükségük, így különféle torrentkövetők, közösségi hálózatok és egyéb oldalak látogathatók lesznek.
DNS beállítása/módosítása
Itt konfigurálhatja a DNS-kiszolgálók elérésének sorrendjét. A tapasztalatlan felhasználóknak érdemes elmagyarázni, hogy nincs olyan szerver, amely az összes létező internetcímet tárolná. Túl sok webhely van mostanában, ezért sok DNS-kiszolgáló van. És ha a megadott cím nem található az egyik DNS-kiszolgálón, a számítógép a következőhöz kapcsol. Tehát a Windows rendszerben beállíthatja, hogy milyen sorrendben érje el a DNS-kiszolgálókat.
A DNS-utótagok konfigurálhatók. 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 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 területen van, ami viszont a com területen van. A szerver DNS-utótagja domain.com. Bár az IP-címek eltérőek, a szerver csak a domain.com oldalon található. A Windows rendszerben testreszabhatja az utótagok hozzárendelését, ami bizonyos előnyökkel jár a belső hálózatok számára. Ami az internetet illeti, a DNS szerverek készítői már mindent automatikusan beállítottak, amire szükségük van.
Lehetséges hibák és azok kijavítása
Mi a teendő, ha a szerver nem válaszol vagy nem található
Mi a teendő, ha amikor megpróbálok elérni egy webhelyet, a következő hibaüzenet jelenik meg: „A számítógép beállításai megfelelően vannak konfigurálva, de az eszköz vagy az erőforrás (DNS-szerver) nem válaszol”? Lehetséges, hogy a DNS szolgáltatás valamilyen okból le van tiltva a számítógépen. Lehet, hogy az Ön által használt DNS-kiszolgáló leállt.
Helytelenül oldja meg a neveket
Ha a DNS-kiszolgáló nem vagy nem megfelelően oldja fel a neveket, annak két oka lehet:
- A DNS helytelenül van beállítva... Ha mindent megfelelően konfigurált, akkor magában a DNS-kiszolgálóban lehet hiba. Változtassa meg a DNS-kiszolgálót, a problémát meg kell oldani.
- Technikai problémák a távközlési szolgáltató szerverein... A probléma megoldása ugyanaz: használjon másik DNS-kiszolgálót.
DHCP szerver: mi ez és mik a jellemzői
A DHCP szerver automatikusan konfigurálja a hálózati paramétereket. Az ilyen szerverek segítenek az otthoni hálózatban, hogy ne konfigurálják külön az egyes csatlakoztatott számítógépeket. A DHCP függetlenül rendeli hozzá a hálózati paramétereket a csatlakoztatott eszközhöz (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 csak szimbolikus címként dolgozza fel a kérést, é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 ISP-szerverekkel szemben), 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 egy pillanat alatt történik, és a legtöbb probléma megoldható egy másik DNS-kiszolgálóra váltással.
Folytatva a webhelyépítés témáját, beszéljünk egy olyan fontos szempontról, mint a domain névrendszer - DNS - munkája. A DNS-zóna konfigurációja és elhelyezkedése számos, a kezdeti elhelyezéssel, valamint a helyek különböző szerverek közötti átvitelével és a tárhely-szolgáltatással kapcsolatos problémához kapcsolódik. A domain névrendszer működésének megértése lehetővé teszi a saját domainek és a kapcsolódó webhelyek és egyéb szolgáltatások egyszerű 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, határozottan biztos abban, hogy erre a webhelyre fog eljutni, nem pedig máshová. A domain név ugyanakkor nemcsak weboldalt jelenthet, hanem e-mail szervert, rövid üzenetváltást, vagy egyéb internetes és hálózati szolgáltatást is. A tartománynevek tartományzó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 szükséges 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 pontozott gyökértartomány, amely információkat tartalmaz az első szintű tartományokról, pl. ru, com, org stb. A gyökérzónát 13 gyökérszerver támogatja, amelyek szerte a világon találhatók, é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 protokoll sajátosságaiból csak 13 legfelső szintű csomópont adható meg, ezért a rendszer skálázhatóságát és hibatűrését az egyes gyökérszerverek tükrei biztosítják.
Az első szintű tartományok számunkra ismerős domain zónák, amelyeket nemzeti és nemzetközi szervezetek is kezelhetnek, és saját használati feltételekkel rendelkeznek. Minden első szintű tartomány zóna lehetővé teszi korlátlan számú második szintű tartomány hosztolá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 fogadását, amelyekben, mint egy fészkelő babában, elhelyezheti a negyedik, ötödik stb. tartományait. szinteket. Annak érdekében, hogy egyértelműen meg lehessen határozni a különböző zónákban elhelyezkedő csomópontokat, bevezettük a koncepciót teljesen minősített domain név (FQDN, Teljesen minősített domain név), amely a DNS-hierarchiában lévő összes szülőtartománynevet tartalmazza. Például webhelyünk esetében az FQDN a következő lesz: webhely. Pontosan így, a gyökérzónát jelző ponttal végződve.
Ez egy nagyon fontos szempont. V mindennapi használat A végpontot szokás eldobni, de a DNS rekordokban az utolsó pont hiánya azt jelenti, hogy ez a domain név az aktuális tartományzónához tartozik, pl. A DNS-kiszolgáló ehhez a névhez hozzáadja a saját tartományzónáját és az összes magasabb szintű zónát a gyökérig.
Például a szerverünkön a zónában webhely hozzáadunk egy CNAME rekordot, amely egy harmadik fél szerverére mutat, mondjuk a Yandex mailre. A helyes bejegyzésnek így kell kinéznie:
MailIN CNAMEdomain.mail.yandex.net.
Ebben az esetben az e-mail név nem teljes tartománynév, és hozzá lesz fűzve mail. site., ha elfelejtünk pontot tenni a Yandex domain név végére, akkor ez a név szintén nem lesz FQDN, és ki kell egészíteni a teljes domain névre. A hibás bejegyzés az alábbiakban látható:
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 egy ilyen konstrukció egy nem létező címre küld minket: domain.mail.yandex.net.site.
Még egy pont. A tartományi zónák összes rekordját a zóna adminisztrátorai írják be a saját DNS-kiszolgálójukon. 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 benne lévő gazdagépekről és gyermekzónákról tartalmaz rekordokat. A downstream zóna csomópontjaira vonatkozó információkat a saját szerverein tárolják. Ezt delegálásnak nevezik, és csökkentheti a gyökérkiszolgálók terhelését, és biztosítja a szükséges autonómiát a gyermektartományi zónák tulajdonosainak.
Tehát vásárolt egy domaint, mondjuk example.org, utána delegálnia kell, pl. adja meg a névszervereket (DNS-kiszolgálókat), amelyek ennek a fájlzónának a rekordjait tartalmazzák. Ezek lehetnek saját szerverei vagy nyilvános szolgáltatásai, például a Yandex DNS.
Ebben az esetben a tartományi zónában org egy 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ózatokban helyezkednek el. A gyakorlatban gyakran egy szerverrel gazdálkodnak, két különböző tartományból származó IP-címet szerezve neki.
Most azt elemezzük, hogyan történik a számunkra szükséges DNS-rekord keresése, é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 akarja látogatni a népszerű Yandex Market erőforrást, beírja a böngésző címsorába a megfelelő webhely nevét, és megnyomja 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 domain névnek.
A DNS-kliens viszont ellenőrzi a rekordokat a hosts fájlban, majd a helyi gyorsítótárban, és ott nem találva a szükséges rekordokat, elküldi a kérést a hálózati beállításokban megadott DNS-kiszolgálónak. Ez valószínűleg egy helyi gyorsítótárazó DNS-proxy, például dnsmasq vagy egy vállalati helyi DNS-kiszolgáló. Ezek a megoldások általában nem a globális DNS rendszer teljes értékű szerverei és nem részei annak, csak a helyi zónát szolgálják ki és gyorsítótárazza a DNS kéréseket, így egy ilyen kérés, ha az adatok nincsenek a gyorsítótárban, az upstream felé kerül elküldésre. DNS-kiszolgáló, általában a szolgáltató szervere.
A kérés beérkezését követően a szolgáltató szervere ellenőrzi a saját rekordjait, majd a gyorsítótárát, és ha az eredményt megtalálja, értesíti a klienst, 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 felveszi a kapcsolatot az egyik gyökérszerverrel, és kérést továbbít 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 ru - 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 lehet, hogy ezt nem teszi meg, ha nem rendelkezik ilyen információval, ebben az esetben a szerverrel való kapcsolatfelvétel előtt szükséges 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 ez a szerver sem rendelkezik a szükséges rekordokkal, hanem jelenti, hogy melyik zónát yandex a szerver válaszol ns1.yandex.rués szükségszerűen megadja a címét. Ellenkező esetben a rekurzió nem fejezhető be, mivel a zónán túl yandex a zónában lévő szerver válaszol yandex... Ehhez a magasabb szintű zónában a zónát kiszolgáló névszerverekről szóló NS rekord mellett egy "linkelve" Egy 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. A kapott eredményt a gyorsítótárba helyezi a tartomány SOA rekordjában megadott TTL-érték által meghatározott ideig. A gyakorlatban, mivel a rekurzív lekérdezések nagyon drágák, a szolgáltató gyorsítótárazási ideje figyelmen kívül hagyhatja a tartományi TTL értékeket, és két-négy órától több napig vagy akár egy hétig terjedhet.
Most nézzünk 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 kérés csak arra a zónára ad választ, amelyért ez a kiszolgáló felelős, vagy hibaüzenetet ad.
Mivel a rekurzív lekérdezések meglehetősen erőforrás-igényesek, a legtöbb DNS-kiszolgáló a hálózaton nem dolgozza fel rekurzívan a rekurzív lekérdezéseket. Vagy szelektíven is megtehetik, például a szolgáltató DNS-szerverei csak az ügyfelek 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 folyamatosan nem rekurzív kéréseket küldött, amíg meg nem találta a kívánt szervert, amely a kívánt választ adta. Ebben az esetben nem csak a felhasználói kérések eredményei, hanem a közbenső kérések eredményei is a szolgáltató szerverének gyorsítótárába kerülnek, ami lehetővé teszi az alábbi ilyen kérések nem rekurzív vagy minimális számú kéréssel történő végrehajtását.
Például, ha egy felhasználó a Yandex Market meglátogatása 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, melyik szerver tartalmazza a zóna rekordjait yandex.
Elmélettől gyakorlatig
Amikor egy regisztrátortól vásárol domaint, a rendszer felkéri annak delegálására, pl. adja meg azokat a DNS-kiszolgálókat, amelyeken a tartományzóna található. 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 az 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átortól:
Pontosan mit kell ott feltüntetni? Ez attól függ, hogy hol és hogyan tárolja webhelyét. Ha megosztott tárhelyet használsz, akkor az összes szükséges rekordot a tárhely automatikusan létrehozza, amikor a webhelyedet hozzáadod a tárhely vezérlőpulthoz, már csak a tartományt kell delegálni a tárhely NS-szerverére, pl. adja meg őket ebben az ablakban. Ez a módszer egyszerűsége miatt kiválóan alkalmas kezdőknek, de van egy hátránya is, hogy a DNS-zóna felhasználó általi vezérlése hiányzik vagy minimális. Ráadásul tovább megosztott 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 tárhely NS-szerverét, akkor ezt a kérdést a technikai támogatással egyeztetni kell.
Ha egy webhelyet egy másik tárhelyre visz át, akkor át kell vinnie a webhelyet, és a regisztrátornál módosítania kell a régi tárhely névkiszolgálóját az új szerverére. 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ő lehet a régi címen. Ha sürgősen dolgoznia kell vele, hozzáadhatja a fájlt anélkül, hogy megvárná a szolgáltató DNS-gyorsítótárának frissítését. 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-el rendelkezik, 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 érdemes vállalkozás, 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 a "kutyás" szimbólum magát a tartományt jelöli; emellett mindenképpen hozzon létre egy rekordot a www aldomainhez, hogy azok a felhasználók is hozzáférhessenek, akik a www-ből írják be a webhely címét.
Nem foglalkozunk az e-mail rekordok hozzáadásával, erről cikkünkben olvashat:
Webhely átvitelekor 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, minden kész, de nem tudsz semmit megváltoztatni, csak várnod kell. De ha betartja néhány ajánlást, akkor ez a folyamat a lehető legfájdalommentesebben és a látogatók számára láthatatlanul elvégezhető.
Először módosítsa a TTL értéket a SOA rekordban. Alapértelmezés szerint ez 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 megállapításához futtassa a parancsot a szükséges tartománynév megadásával:
Nslookup -typr = soa site
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 helyezze csak olvasható módba webhelyét, és vigye át az új szerverre. Az oldalt nem szabad kikapcsolni vagy átvinni karbantartásra, hozzáfé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 kiegészítését, pl. megtiltani a regisztrációt, kommentálást, rendelés leadását stb. Ne felejtsen el jól látható helyen elhelyezni egy üzenetet a műszaki munkákról és azok befejezésének hozzávetőleges időpontjáról.
Ha a DNS-rekordok megváltoztatása nélkül szeretne dolgozni az új kiszolgálóval, adja hozzá a szükséges sort hosts fájl... Miután elhelyezte az oldalt egy új webhelyen, é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 kezdik meglátogatni webhelyét az új szerveren. A régi szervert egy ideig, ideális esetben akár egy hétig is karban kell tartani, mivel nem minden szolgáltató használja a SOA rekord TTL értékét a gyorsítótár frissítéséhez; a berendezés terhelésének csökkentése érdekében használhatja saját beállításait.
Sikeres migráció után a TTL értéket a korábbi értékekre kell növelni, hogy elkerüljük a névszerverek felesleges terhelését.
Mi a legegyszerűbb sémát vettük figyelembe, de a gyakorlatban a telephelyen kívül általában van egy irodai hálózat is, amelynek sok erőforrását kívülről is elérhetővé kell tenni. Tekintsük a következő diagramot:
Nyilvános szervereink vannak a weboldalhoz és az e-mailekhez, valamint egy irodai hálózatunk, amelyhez aldomaint dedikáltunk hivatal... Ha nincs különleges kérdés a levelezéssel és a webszerverrel, akkor az irodaterülettel vannak lehetőségek. A helyi zónát jellemzően saját DNS szolgálja ki, és semmilyen módon nem kapcsolódik a szülőzónához. A globális rendszer DNS-zónájá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 van, é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 belső csomópontok megfelelő portjai továbbítva vannak.
Ebben az esetben a zóna DNS-rekordjai example.comígy nézhet ki:
@ IN A 1.2.3.4
www IN A 1.2.3.4
levél A-BAN 1.2.3.5
iroda IN A 5.6.7.8
De van némi nehézség, hogy a hálózaton belül az ügyfelek belső nevekkel hivatkoznak a hálózati szolgáltatásokra: corp.office.example.com vagy rdp.office.example.com amelyek belső „szürke" címekre mutatnak. A helyi hálózaton kívül azonban nem lehetséges az ilyen nevek IP-címének feloldása, mivel a globális DNS-rendszer számára nincs olyan zóna, amely ezeket tartalmazza. ami lehetővé teszi, hogy különböző eredményeket adjon attól függően az ügyfél helyzetéről.
A helyi hálózaton az ügyfelek DNS-kérelmeit a helyi szerver amely rendelkezik megfelelő rekordokkal, azon kívül a kérések a zónát kiszolgáló szerverhez fognak irányítani 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 emlékezni az álnévre vagy a CNAME rekordra. Ez a bejegyzés lehetővé teszi további mnemonikus nevek vagy álnevek társítását a valódi gazdagépnévhez. Kérjük, vegye figyelembe, hogy az álnevek használata más rekordokban nem megengedett. Esetünkben rekordokat kell hozzáadnunk:
Corp.office IN CNAME iroda.example.com.
rdp.office A CNAME-ben office.example.com.
Mostantól az ügyfél, tartózkodási helyétől függetlenü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 valódi szervercímet és közvetlenül csatlakozik, kívülről pedig a hálózati átjáróhoz kerül.
Ezenkívül a CNAME rekordok használhatók az elfogadott tartományzónán kívülre történő átirányításra. 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 levelezőszerverként a teljes tartományhoz example.com a moszkvai irodában található és címmel rendelkező szervert szeretnénk használni mail.iroda.msk.example.com, be kell vallani, nem tűnik túl vonzónak. Sokkal kényelmesebb lenne az űrlap címét használni mail.example.com, nem is lehetne könnyebb, adja hozzá a következő bejegyzést:
Levelezés CNAME-ben mail.office.msk.example.com.
De ne feledje, hogy más erőforrásrekordokban csak valódi neveket szabad használni, így ez helytelen:
example.com. MX 10 levélben
Helyesen így lesz:
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 a különböző alosztályokhoz saját aldomaineket osztanak ki, hiszen mindegyik 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 zónában example.com minden zónához el kell helyezni 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 kapcsolatba lép egy címmel, mondjuk mail.iroda.msk.example.com zóna névszerverek example.com megadja 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 önállóan hajtsák végre a szükséges változtatásokat anélkül, hogy ez befolyásolná a magasabb szintű zóna működését, és anélkül, hogy felvenné a kapcsolatot az adminisztrátorokkal olyan kérdésben, amely a rekordok módosítását igényli.
Egyes internetszolgáltatók időszakos (vagy állandó) DNS-problémákkal küzdenek. Otthoni felhasználó számára, ha nem áll rendelkezésre szolgáltatóváltás, a probléma megoldható vagy más DNS-szervereinek (ideológiailag helytelen) használatával (a címeket a fórumokon megtudhatja), vagy saját DNS-szerver futtatásával. , ami nem is olyan nehéz, mint amilyennek első pillantásra tűnhet.
A Windows szerververziójában létezik beépített DNS-szerver, de a Microsoft marketingszakembereinek erőfeszítéseinek köszönhetően az asztali kiadásban (Windows 2000 / XP / Vista) nem található, ezért, ahogy az lenni szokott, térjünk rá a nagylelkű Unix világ. A leghíresebb DNS-kiszolgálók a BIND, a djbdns, a PowerDNS, a MaraDNS és a Unbound. A BIND-ot nem kívánjuk figyelembe venni, a djbdns sajátosságaiból fakadóan mereven kötődik a Unixhoz, a PowerDNS nem frissíti a Windows verzióját, így marad a MaraDNS és az Unbound. Kipróbálhatja az egyiket vagy a másikat, de ne feledje, hogy nem működnek egyszerre.
A kézikönyv egy rövid HowTo stílusában készül majd egy gyakorlott felhasználónak (inkább rendszergazdának), így ha nem értesz semmit, hívd az ismerős "számítógépedet".
Ha nem igazán érti a DNS működését, de nagyon szeretné megérteni, mit csinálunk itt (indítunk egy DNS-gyorsítótárat, amely képes rekurzív kéréseket fogadni és iteratív kéréseket küldeni), elolvashatja a kézikönyv fejezetet (orosz nyelven).
Kötetlen
Megyünk a http://unbound.net/ webhelyre a Letöltések részben, és megtaláljuk a következő sorokat:
A Windows 32 bites verziója a forrásból lett lefordítva.Telepítő:
A hivatkozásról (az írás idején - unbound_setup_1.3.0) töltse le a terjesztési készletet. Futtassa a fájlt, kattintson a "Tovább" gombra, olvassa el a licencszerződést, ha egyetért, kattintson az "Elfogadom" gombra, törölje a pipát a "DLV - dlv.isc.org" jelölőnégyzetből (nem kell ellenőriznünk a DNSSEC aláírásokat), kattintson a "Tovább" gombra. "Következő", "Telepítés", "Befejezés". A szolgáltatás telepítése és elindítása automatikusan megtörténik. Minden, amire szüksége van a kezdéshez (beleértve a README.txt fájlt is), a C: \ Program Files \ Unbound mappában található.
MaraDNS
A MaraDNS elindítása Windows alatt, mint kiderült, meglehetősen nem triviális feladat, így ha nagyon akarod, kipróbálhatod magad.
Windows beállítás
Tehát telepítettük és elindítottuk a DNS-kiszolgálót, most konfigurálnunk kell a Windows-t.
Az "Általános" lapon az internetkapcsolat tulajdonságainál ("Start", "Beállítások", "Hálózati kapcsolatok", a kívánt kapcsolat, a helyi menü, "Tulajdonságok") nyissa meg az "Internet Protocol TCP / IP" elemet, ha a beállítás "DNS-cím -szerver automatikus beszerzése ", akkor módosítania kell a "Használja a következő DNS-kiszolgálócímeket" értékre, és regisztrálnia kell a 127.0.0.1 címet. Ha aktiválta a "Használja a következő DNS-szervercímeket" paramétert, és megadta a szolgáltató DNS-kiszolgálójának címét, törölje mindkettőt vagy az egyiket (egy papírra való felírás után), és regisztrálja ugyanazt a 127.0.0.1. Nem szükséges kétszer megadni ugyanazt a címet (127.0.0.1). Kattintson az "OK", "OK" gombra, várja meg, amíg minden mentésre kerül, és próbáljon meg megnyitni egy webhelyet. Egy másik ellenőrzési módszer valódi rendszergazdáknak való. Bemegyünk a konzolba, futtassuk az nslookup parancsot, majd futtassuk:
> szerver 127.0.0.1 Alapértelmezett szerver: localhost Cím: 127.0.0.1> www.mail.ru Szerver: localhost Cím: 127.0.0.1 Nem hiteles válasz: Név: www.mail.ru Címek: 194.67.57.26, 157.1626, 194.16. 194.67.57.226, 194.67.57.20> kilépésEbben az esetben sikeresen megoldottuk a www.mail.ru (A-típusú) rögzítést.
Ha nem működik, a szolgáltató átjárójának pingelésével ellenőrizzük, hogy van-e internetkapcsolata (az ipconfig / all segítségével megtudhatja). Ha csatlakoztatva van, keresse meg a Feladatkezelőt a DNS-kiszolgáló folyamatának elindításához. Ha nem fut, nézze meg a Services beépülő modult (futtassa a services.msc fájlt a konzolon): próbálja meg elindítani a szolgáltatást, és ellenőrizze, hogy az automatikus indítás... Ha nem segít, akkor vagy elolvassuk a dokumentációt (DNS szerver), bekapcsoljuk a naplót és megnézzük a tűzfal és DNS szerver konfigurációs fájlunkat (bár alapból már konfigurálva kell), vagy hívjunk valakit, aki képesítéssel rendelkezik, vagy töröljük a program, visszaállítja a beállításokat, és [sad | menjünk sétálni | sört inni | ...].
Elméletileg azonban nincs semmi bonyolult a leírt folyamatban, így működnie kell (ahogyan a szerzőnél).
Megjegyzések:
- Általában minden kiszolgáló viszonylag biztonságos alapértelmezett beállításokkal rendelkezik, de hasznos ellenőrizni, hogy a DNS-kiszolgáló 53 TCP- és UDP-porton figyel-e a 127.0.0.1-en, és nem a 0.0.0.0-n (minden helyi címen). Ezt a TCPView segítségével lehet megtenni. A Beállításokban kapcsolja be a Nem kapcsolt végpontok megjelenítése és a Címek feloldása funkciót. Keresse meg a DNS-kiszolgáló folyamatát, két bejegyzésnek kell lennie: TCP helyi címmel 127.0.0.1:53, valamint State LISTENING és UDP azonos címmel és üres állapot mezővel.
- A szerző nem használ DNS-kiszolgálókat Windows alatt, és ennek megfelelően jelen cikk anyaga a gyakorlatban, ezért kérjük, ne írjon "nekem nem megy, mit tegyek?" stílusban.
- A cikk megírásához a szerző a Windows XP-t használta, ha a Windows más verziója van, igazítsa az elérési utat és a parancsokat az operációs rendszer verziójához.
- Ha ezt egy szervezet számítógépén próbálja megtenni, akkor a legjobb megoldás az lenne, ha megkéri a rendszergazdát, hogy állítson be egy irodai átjárót az Internetre GNU Linux / * BSD alatt valódi (Unix alatti) DNS-kiszolgálóval, és ha nem tud, keress egy ilyen embert.
- A cikk rendkívül leegyszerűsített, ezért ha hibát, pontatlanságot vagy homályos pontot talál, írjon, ha úgy tűnik, hogy az anyagot nem hozták nyilvánosságra (például nincs leírva a rekurzív és a mérvadó / hiteles / hiteles DNS-kiszolgáló közötti különbség ) - nem szabad írni. Rengeteg kézikönyv található a DNS beállításáról az interneten (beleértve a szoftveroldalakon található dokumentációt is).
- A Windows nem a legjobb platform DNS-szervernek (legalábbis Unix-ról portolva), így előfordulhat, hogy mindez nem működik tökéletesen (elsősorban a sebesség szempontjából).
- A névfeloldáshoz szokásos „asztali – szolgáltató DNS szervere” kommunikáció esetén az esetek túlnyomó többségében egy kérés érkezik és egy válasz érkezik. Esetünkben többszörösen több kérés és válasz lesz, hiszen átvesszük a szolgáltató DNS szerverének funkcióit. Ez nem befolyásolja jelentősen a teljes forgalmat, mivel a DNS-lekérdezések és -válaszok nagyon kicsik, de hatással lehet a webhelyek megnyitásának sebességére. De mivel a kérések gyorsítótárban vannak, ez valószínűleg csak az internetes munka első perceiben lesz észrevehető.
Ennyi, köszönöm a figyelmet.
A zóna egy olyan adatbázis, amely hiteles információkat tartalmaz a DNS-névtér hatóköréről. Amikor DNS-kiszolgálót és tartományvezérlőt telepít, automatikusan létrejön egy DNS-zóna az Active Directory-tartomány támogatására. Ha a DNS-kiszolgálót tartományvezérlőre, tartományi tagkiszolgálóra vagy önálló kiszolgálóra telepítették, a zónákat manuálisan kell létrehozni és konfigurálni.
Ez a lecke leírja, hogyan kell zónát létrehozni és konfigurálni, és megadja a zóna megfelelő beállításához szükséges információkat.
Zónák létrehozása
Zóna A DNS olyan rekordokat tartalmazó adatbázis, amelyeka neveket a DNS-névtér leírt hatókörében lévő címekkel társítja. Bára DNS-kiszolgáló gyorsítótárazottat használhatmás kiszolgálókról származó információkat, csak a következő helyen jogosult kérésekre válaszolnihelyileg beadott zóna. A DNS névtér bármely hatóköréhezamelyet egy domain név képvisel (pl. google .ru), csak egy vanzónaadatok hiteles forrása.
Ha új zónát kell létrehoznia a DNS-kiszolgálón, használhatja az Új zóna varázslót a DNS-kezelőben. A varázsló elindításához kattintson jobb gombbal a kiszolgáló ikonjára a DNS-kezelő konzolfájában, és használja az Új zóna parancsot.
Az Új zóna varázsló a következő konfigurációs oldalakat tartalmazza:
■ Zóna típusa;
■ Zóna replikációs hatókör integrált v Active Directory (Active Directory Zone Replication Scope);
■ Forward vagy Reverse Lookup Zone;
■ Zóna neve;
■ Dinamikus frissítés
A következő szakaszok a varázsló öt oldalához kapcsolódó konfigurációs fogalmakat ismertetik.
Zóna típus kiválasztása
Az Új zóna varázsló Zónatípus oldalán kiválaszthatja, hogy főzónát, másodlagos zónát vagy csonkzónát kíván-e létrehozni. Ha létrehoz egy elsődleges vagy csonkzónát egy tartományvezérlőn, a zónaadatokat az Active Directoryban tárolhatja.
* Fő zónák
A DNS-zóna leggyakoribb típusa az elsődleges zóna. Nyers olvasási/írási forrásadatokat biztosít, amelyek feljogosítják a helyi DNS-kiszolgálót, hogy válaszoljon a DNS-névtér hatókörére vonatkozó DNS-lekérdezésekre.
Az elsődleges zónát kezelő helyi DNS-kiszolgáló az elsődleges információforrás a zónáról. A szerver a zónaadatok mesterpéldányát egy helyi fájlban vagy az Active Directory tartományi szolgáltatásokban (AD DS) tárolja. Ha a zóna fájlba van mentve, és nem az Active Directoryba, akkor a fájl neve alapértelmezés szerint megtörténik zóna_neve.dnsés a % systemroot% \ System 32 \ DNS mappában van tárolva a kiszolgálón.
* További zónák
A fő zóna vagy egy másik másodlagos zóna csak olvasható hiteles másolatát biztosítja.
A másodlagos zónák lehetővé teszik a DNS-lekérdezések forgalmának csökkentését a hálózat erősen lekérdezett és zónaadatokhoz használt területein. Ezenkívül abban az esetben, ha az elsődleges zónát kezelő kiszolgáló nem elérhető, a másodlagos zóna névfeloldást tud biztosítani mindaddig, amíg az elsődleges kiszolgáló újra elérhetővé nem válik.
Az eredeti zónákat, ahonnan a további zónák információkat kapnak, mester zónáknak, a zónainformációkat naprakészen tartó adatmásolási eljárásokat pedig zónaátvitelnek nevezzük. A mester zóna lehet a fő zóna vagy egy másik másodlagos zóna. Az Új zóna varázslóban létrehozandó további zónához mester zónát rendelhet. Mivel a másodlagos zóna egy másik kiszolgáló által kezelt elsődleges zóna másolata, nem tárolható az Active Directoryban.
* Stub Zones
Hasonló a másodlagos zónához, de tartalmazza az elsődleges zónában lévő mérvadó DNS-kiszolgálók azonosításához szükséges erőforrásrekordokat. A csonkzónákat gyakran azért használják, hogy a szülőzóna (például google .ru) a delegált gyermekzónában elérhető névszerverek frissített listáját használja (például: translate .google .ru). A névfeloldás javítását és a DNS-adminisztráció egyszerűsítését is szolgálják.
* Zónák tárolásaAktívKönyvtár
Amikor létrehoz egy elsődleges vagy csonkzónát egy tartományvezérlőn, a varázsló Zónatípus lapján kiválaszthatja, hogy a zónát az Active Directoryba menti-e. Az Active Directoryba integrált zónaadatok automatikusan replikálódnak az Active Directoryba az Active Directory zóna replikációs hatóköre oldalon kiválasztott beállításoknak megfelelően. Ezzel az opcióval nincs szükség a zónák további kiszolgálókra való átvitelének konfigurálására.
A DNS-zóna Active Directoryba való integrálása számos előnnyel jár. Először is, mivel az Active Directory replikálja a zónákat, nincs szükség külön mechanizmus konfigurálására a DNS-zónák elsődleges és másodlagos kiszolgálók közötti átviteléhez. A hálózaton történő többszörös replikáció automatikusan hibatűrést és nagyobb teljesítményt biztosít több elsődleges kiszolgáló elérhetőségével olvasási/írási hozzáféréssel. Másodszor, az Active Directory lehetővé teszi a DNS-kiszolgálókon lévő erőforrásrekordok adott tulajdonságainak frissítését és replikálását. hálózati erőforrások zónaátvitel során. Végül, az Active Directoryba integrált zónák a dinamikus frissítések opcionális biztonsági követelményeit is biztosítják, amelyek az Új zóna varázsló Dinamikus frissítés oldalán állíthatók be.
JEGYZET: Olvassa el a tartományvezérlőket és az Active Directory integrált zónákat
A hagyományos tartományvezérlőkön a zóna másolata olvasási/írási hozzáférést kap. Az csak olvasható tartományvezérlőkön (RODC) a zóna másolata csak olvasási hozzáféréssel rendelkezik.
* Szabványos zónák
Ha zónát hoz létre egy tartományvezérlőn, a zóna Active Directoryba való mentése a Zónatípus oldalon alapértelmezés szerint be van jelölve. Ez a jelölőnégyzet azonban törölhető, és létrehozható egy úgynevezett standard zóna. Olyan kiszolgálón, amely nem tartományvezérlő, csak szabványos zónákat hozhat létre, és az ezen az oldalon lévő jelölőnégyzet szürkén jelenik meg.
Az Active Directoryba integrált zónákkal ellentétben a szabványos zóna egy szöveges fájlban tárolja adatait a helyi DNS-kiszolgálón. Ezen túlmenően szabványos zónák használata esetén csak a mester másolat konfigurálható olvasási / írási hozzáféréssel a zóna adatokhoz. A zóna összes többi példánya (további zónák) csak olvasási jogosultsággal rendelkezik.
A szabványos zónamodell a zóna újraírható változatának egy meghibásodási pontját jelenti. Ha a fő zóna nem elérhető a hálózaton, a zónán nem lehet változtatni. A zónában lévő nevekre vonatkozó lekérdezések azonban nem szakadhatnak meg, amíg további zónák állnak rendelkezésre.
A beépített zóna replikációs hatókörének kiválasztásaAktívKönyvtár
Az Új zóna varázsló Active Directory zónareplikációs hatóköre oldalán kiválaszthatja a hálózaton lévő tartományvezérlőket a zónaadatok mentéséhez. Ez az oldal csak akkor jelenik meg, ha be van jelölve a zóna és az Active Directory mentése. A zónareplikációs hatókör beállításai határozzák meg azokat a tartományvezérlőket, amelyek között a zónaadatok replikálódnak.
Ezen az oldalon a következő lehetőségek találhatók:
■ A zóna mentése az összes tartományvezérlőn, amely egyben DNS-kiszolgáló is a teljes Active Directory erdőben;
■ A zóna megőrzése minden DNS-kiszolgálóként is szolgáló tartományvezérlőn és a helyi Active Directory tartományon;
■ A zóna megőrzése az összes tartományvezérlőn és a helyi Active Directory tartományon (a Windows 2000 rendszerrel való kompatibilitás érdekében használatos);
■ Megőrzi a zónát az összes megadott tartományvezérlőn és az egyéni Active Directory-partíció hatókörét.
Ezeket a lehetőségeket a második témakörben ismertetjük részletesebben.
Hozzon létre előre és hátrafelé keresési zónákat
Az Új zóna varázsló Forward vagy Reverse Lookup Zone oldalán válassza ki a létrehozandó zóna típusát; Forward Lookup Zone vagy Reverse Lookup Zone.
Az előrekeresési zónák esetében a DNS-kiszolgálók az FQDN-eket IP-címekhez rendelik hozzá. A fordított keresési zónákban a DNS-kiszolgálók leképezik az IP-címeket az FQDN-ekre. Így az előrekeresési zónák az FQDN-re válaszolnak az IP-cím-feloldási kérésekre, a fordított keresési zónák pedig az IP-címekre válaszolnak az FQDN-feloldási kérésekre. Vegye figyelembe, hogy a továbbítási zónák a D NS-tartománynevek szerint vannak elnevezve, amelyekhez az engedély végrehajtásra kerül, például a google.com . A fordított keresési zónák elnevezése a címtér első három oktettjének fordított sorrendjében történik, amelyhez a névfeloldás biztosított, valamint az opcionális in-addr.arpa címkét. Például, ha feloldja a 192.168.1.0/24 alhálózat neveit, a fordított keresési zóna neve 1.168.192.in-addr.arpa lesz. A továbbított keresési zónában az egyetlen adatbázisrekordot, amely egy gazdagépnevet leképez egy címre, a csomó(A). A fordított keresési zónában egyetlen adatbázis-bejegyzés kerül meghívásra, amely egy IP-címet képez le egy gazdagépnévhez mutató vagy egy PTR rekord.
Előre és hátrafelé történő keresésem elve az ábrán látható.
Élő nézet terület
Fordított keresési zóna
JEGYZET: DNS-kiszolgáló konfigurációs varázsló
A DNS-kiszolgáló konfigurálása varázsló segítségével egyszerre hozhat létre előre és hátrafelé irányuló keresési zónákat. A varázsló elindításához a DNS-kezelő konzolfájában kattintson jobb gombbal a kiszolgáló ikonjára, és válassza a DNS-kiszolgáló konfigurálása lehetőséget.
Zónanév kiválasztása
Az Új zóna varázsló Zónanév lapján kiválaszthat egy nevet a létrehozott előrekeresési zónának A visszkereső zónák elnevezése a mérvadó IP-címek tartománya szerint történik.
Ha zónát hoz létre névfeloldáshoz egy Active Directory tartományban, a legjobb, ha olyan zónanevet ad meg, amely megegyezik az Active Directory tartománynévvel. Ha például egy szervezetnek két Active Directory tartománya van, amelyek neve google .ru és fordítása .google .ru, akkor a névfeloldó infrastruktúrának tartalmaznia kell két zónát, amelyeket ezekről a tartománynevekről neveztek el.
Ha az Active Directoryon kívül hoz létre zónát egy DNS-névtér számára, meg kell adnia a szervezet internetes tartománynevét, például wikipedia .org.
JEGYZET: HozzáadásDNS-kiszolgáló tartományvezérlőnként
Ha DNS-kiszolgálót szeretne hozzáadni egy meglévő tartományvezérlőhöz, általában hozzá kell adni az elsődleges zóna másolatát, hogy a helyi Active Directory tartományban névfeloldást biztosítson. Ehhez csak létre kell hoznia egy zónát, amelynek neve megegyezik a helyi Active Directory tartományban meglévő zóna nevével. Az új zóna a tartomány többi DNS-kiszolgálójáról származó adatokkal lesz feltöltve.
Dinamikus frissítési beállítások konfigurálása
A DNS-ügyfélszámítógépek DNS-kiszolgálón keresztül regisztrálhatják és dinamikusan frissíthetik erőforrásrekordjaikat. Alapértelmezés szerint a statikus IP-címekkel rendelkező DNS-kliensek frissítik a gazdagép (A vagy AAAA) és a mutató (PTR) rekordokat, míg a DHCP-kliensek csak a gazdagéprekordokat frissítik. Munkacsoportos környezetben a DHCP-kiszolgáló minden alkalommal frissíti a mutatóbejegyzéseket a DHCP-kliens nevében, amikor az IP-konfiguráció frissül.
A sikeres DNS dinamikus frissítéshez azt a zónát, amelyben az ügyfelek regisztrálják vagy frissítik a rekordokat, úgy kell beállítani, hogy elfogadja a dinamikus frissítéseket. Kétféle ilyen frissítés létezik:
■ Biztonságosfrissítés (Biztonságosfrissítések)
Csak az Active Directory tartományban lévő számítógépekről engedélyezi a regisztrációt, és csak az eredetileg regisztrált számítógépről frissít.
■ Nem biztonságosfrissítések (Nem biztonságosfrissítések)
Lehetővé teszi a frissítést bármely számítógépről.
Az Új zóna varázsló Dinamikus frissítés oldalán engedélyezheti a biztonságos, nem biztonságos dinamikus frissítéseket, vagy teljesen letilthatja a frissítéseket az újonnan létrehozott zónában.
Inline erőforrásrekordok elemzése
Új zóna létrehozásakor kétféle rekord jön létre automatikusan. Először is, egy ilyen zóna mindig tartalmazza a Start Of Authority (SOA) zónarekordot, amely meghatározza a zóna alapvető tulajdonságait. Ezenkívül az új zónák legalább egy névkiszolgáló (NS) rekordot tartalmaznak, amely meghatározza a zóna mérvadó kiszolgálójának (kiszolgálóinak) nevét. E két erőforrásrekord funkcióit az alábbiakban ismertetjük.
Kezdeti zóna rekordok
Egy zóna betöltésekor a DNS-kiszolgáló a Start Of Authority (SOA) zónarekordot használja a zóna alapvető tulajdonságainak és jogosultságának meghatározásához. Ezek a paraméterek az elsődleges és másodlagos szerverek közötti zónák átviteli gyakoriságát is jellemzik. Ha duplán kattint egy SOA-bejegyzésre, megnyílik a zónatulajdonságok párbeszédpanel jogosultság kezdete (SOA) lapja.
■ SorozatszámSorozatszám
Ez a szövegdoboz a Zone Initial Record (SOA) lapon tartalmazza a zónafájl verziószámát. Az itt felsorolt szám minden alkalommal növekszik, amikor a zónában lévő erőforrásrekordok megváltoznak. Manuálisan is növelhető a Növelés gombbal.
Ha a zónák úgy vannak beállítva, hogy zónaátvitelt hajtsanak végre egy vagy több másodlagos kiszolgálóhoz, akkor ezek a másodlagos kiszolgálók rendszeresen lekérdezik a zóna sorozatszámát az alapkiszolgálótól. Az ilyen kéréseket SOA-kéréseknek nevezzük. Ha a SOA-kérés a másodlagos zóna sorozatszámával megegyező elsődleges zóna sorozatszámot kap, nem történik átvitel. Ha azonban a zóna sorozatszáma az elsődleges kiszolgálón nagyobb, mint a kérelmező másodlagos kiszolgáló megfelelő értéke, az utóbbi zónaátvitelt kezdeményez.
JEGYZET: Zónák átvitele a fő szerveren
A Növelés gombra kattintva elindítja a zóna átvitelét.
■ Alapvetőszerver (ElsődlegesSzerver)
■ Felelősszemély (felelős személy)
Ebben a mezőben adja meg a zóna adminisztrátorának tartományi postafiókjának megfelelő felelős személy (RP) nevet. Az ebbe a mezőbe beírt névnek mindig ponttal kell végződnie. Az alapértelmezett a hostmaster.
■ IntervallumFrissítési intervallum
Az ebben a mezőben található érték megadja, hogy a másodlagos DNS-kiszolgáló mennyi ideig várjon, mielőtt zónafrissítést kérne a főkiszolgálón. A frissítési intervallum végén a másodlagos DNS-kiszolgáló lekérdezi a mestertől az aktuális SOA-rekord másolatát. A válasz beérkezése után a másodlagos DNS-kiszolgáló összehasonlítja az elsődleges szerver aktuális SOA rekordjának sorozatszámát (a válaszban megadott) sorozatszám a helyi SOA rekordot. Ha ezek az értékek eltérőek, a másodlagos DNS-kiszolgáló zónaátvitelt kér az elsődleges DNS-kiszolgálótól. Alapértelmezés szerint a frissítési időköz 15 perc.
■ IntervallumÚjrapróbálkozási időköz
■ Termlejárután (lejár után)
Az ebben a mezőben található érték határozza meg azt az időtartamot, amely alatt a másodlagos kiszolgáló továbbra is végrehajtja a DNS-ügyfelektől érkező lekérdezéseket anélkül, hogy kapcsolatba lépne az elsődleges kiszolgálóval. Ezen idő letelte után az adatok megbízhatatlannak minősülnek. Alapértelmezés szerint ez a paraméter egy naphoz van hozzárendelve.
■ MinimáliskifejezéstTTL élettartam (minimum (alapértelmezett)T TL)
A TTL értékek nem vonatkoznak a mérvadó zónákban lévő erőforrásrekordokra. És ezek a zónák az erőforrás írási gyorsítótár élettartamát használják a nem hiteles kiszolgálókon a TTL értékekhez. Az egy korábbi kérésből származó erőforrásrekordot gyorsítótárazó DNS-kiszolgáló kiüríti a rekordot, de a rekord TTL-je lejár.
■ Term élet(TTL)rekordokat(TTL ehhez a rekordhoz)
Az ebben a mezőben megadott érték határozza meg az aktuális SOA rekord élettartamát. Ez az érték felülírja az előző mezőben megadott alapértelmezett értéket.
Névszerver rekordok
A névkiszolgáló (NS) rekord határozza meg a zóna mérvadó kiszolgálóját. Amikor létrehoz egy zónát a Windows Server 2008 rendszerben, minden kiszolgálónak, amely egy Active Directoryba integrált zóna főpéldányát kezeli, saját NS-rekordja lesz az új alapértelmezett zónában. Szabványos elsődleges zóna létrehozásakor a rendszer alapértelmezés szerint hozzáadja a helyi szerver NS rekordját.
A másodlagos zónákat kezelő kiszolgálók esetében manuálisan kell hozzáadnia az NS rekordokat a zóna elsődleges másolatához.
Az NS rekordok más eljárással jönnek létre, mint a más típusú erőforrásrekordok. NS-rekordok hozzáadásához kattintson duplán bármelyik meglévő NS-rekordra a DNS-kezelőben. Megnyílik a zóna tulajdonságai párbeszédpanel Névszerverek lapja. A Névkiszolgálók lapon kattintson a Hozzáadás gombra a helyi elsődleges zóna másodlagos zónáját kezelő kiszolgáló FQDN-jének és IP-címének hozzáadásához. Új kiszolgáló hozzáadása után kattintson az OK gombra, és egy új NS-rekord jelenik meg a DNS-kezelőben, amely ezt a kiszolgálót jelzi.
JEGYZET: További zónákba való átvitel engedélyezése
A másodlagos zóna nem ismeri fel ezt a bejegyzést érvényes névszervernek mindaddig, amíg a zónaadatok érvényes másolatát tartalmazza. Ahhoz, hogy egy további zóna fogadhassa ezeket az adatokat, engedélyeznie kell a zónaátvitelt az adott szerverhez a zóna tulajdonságai párbeszédpanel Zóna átvitelek lapján. Ezt a lapot a következő témakörben ismertetjük részletesebben.
Az alábbiakban egy példa látható egy szabványos zónafájlban létrehozott rekordra:
@ NS dns1.lucernepublishing.com.
A @ szimbólum a zónát jelöli a zónafájlban lévő SOA rekordban meghatározottak szerint. A teljes rekord ezután leképezi a wikipedia .org tartományt a dns1.wikipedia .org DNS-kiszolgálóra.
Erőforrásrekordok létrehozása
A SOA- és NS-rekordokon kívül számos más erőforrásrekord is automatikusan létrejön. Például egy új DNS-kiszolgáló telepítése során, amikor a kiszolgáló tartományvezérlőként van kijelölve, számos Active Directory tartományi szolgáltatások (AD DS) SRV rekordok automatikusan létrejönnek a helyileg felügyelt zónában. Ezenkívül alapértelmezés szerint sok DNS-ügyfél dinamikus frissítések révén automatikusan regisztrálja a gazdagép (A és AAAA) és a mutató (PTR) rekordokat egy zónában.
Bár sok erőforrásrekord automatikusan generálódik, a vállalati környezeteknek általában manuálisan kell létrehozniuk néhány erőforrásrekordot, például levelezőszerverekhez, álneveket (CNAME) a webszerverekhez és alkalmazásszerverekhez, valamint gazdagéprekordokat a szerverekhez és az ügyfelekhez. saját frissítések.
Egy zóna erőforrásrekordjának manuális hozzáadásához a DNS-kezelő konzolban kattintson a jobb gombbal a zóna ikonjára, és válassza ki a létrehozandó rekord típusát a helyi menüből.
A helyi menüben egy bejegyzés kiválasztása után megnyílik egy párbeszédpanel, ahol megadhatja a bejegyzés nevét és a kapcsolódó számítógépet. Ne feledje, hogy IP-címmel rendelkező számítógépnévhez csak a gazdagéprekordok vannak társítva. A legtöbb rekordtípus szolgáltatásnevet vagy álnevet társít az eredeti gazdagéprekordhoz. Ezért az MX rekord a 12.nwtraders .msft SRV csomópont jelenlétére támaszkodik a zónában.
Hozzászólás típusai
A következők a gyakori kézi erőforrásrekordok:
■ csomópont (AvagyALAA);
■ alias (CNAME);
■ levélhőcserélő (MX);
■ mutató (PTR);
■ elhelyezkedésszolgáltatás (SRV).
Csomópont (A vagy AAAA)
A legtöbb hálózat esetében a zónaadatbázisban található erőforrásrekordok többsége gazdagép erőforrásrekord. Ezeket a rekordokat a zónában arra használják, hogy számítógépneveket (gazdagépneveket) társítsanak IP-címekhez.
Még ha engedélyezi is a zónák dinamikus frissítését, bizonyos forgatókönyvek esetén a gazdagéprekordoknak kézzel kell rekordokat hozzáadniuk a zónához. Az alábbi ábrán a Contoso, Inc. a contoso .com tartománynevet használja a nyilvános névtérben és a belső Active Directory tartományban. Ebben az esetben a www .contoso .com nyilvános webszerver az Active Directory tartományon kívül található, és csak a nyilvános, hiteles contoso .com DNS-kiszolgálón hajt végre frissítéseket. A belső ügyfelek azonban továbbítják DNS-lekérdezéseiket a belső DNS-kiszolgálóknak. Mivel a www .contoso .com kiszolgáló A rekordja nem frissül dinamikusan a belső DNS-kiszolgálókon, manuálisan adják hozzá, hogy a belső ügyfelek feloldhassák a neveket és csatlakozhassanak a nyilvános webszerverhez.
A gazdagéprekordok manuálisan is hozzáadhatók, ha UNIX-kiszolgálót használ a hálózaton. Például a Fabrikam, Inc. egy Active Directory tartománya van a fabrikam, com nevű privát hálózatán. Ez a hálózat magában foglalja az App1.fabrikam, com UNIX szervert is, amely a vállalat napi működéséhez elengedhetetlen alkalmazást futtat. Mivel a UNIX-kiszolgálók nem tudnak dinamikus frissítéseket végrehajtani, manuálisan kell hozzáadnia az App1-kiszolgáló gazdagéprekordját a fabrikam zónát (com) kezelő DNS-kiszolgálóhoz. Ellenkező esetben a felhasználók nem tudnak csatlakozni az alkalmazáskiszolgálóhoz annak teljes tartománynév megadásával.
Alias (CNAME)
Ezeket a feljegyzéseket néha kanonikus neveknek nevezik. Lehetővé teszik több név használatát egyetlen csomópontra való hivatkozáshoz. Például a jól ismert szerverneveket (ftp, www) általában CNAME rekordok segítségével rögzítik. Ezek a rekordok leképezik a szolgáltatásaikhoz társított gazdagépneveket a szolgáltatást futtató számítógép tényleges rekordjához.
■ Ha át szeretné nevezni az azonos zóna A rekordjában megadott csomópontot.
■ Amikor egy jól ismert kiszolgáló csoportnevét (például www) egyedi számítógépek csoportjává kell feloldani (mindegyik egyedi A rekordot tartalmaz), amelyek ugyanazt a szolgáltatást nyújtják (például redundáns webszerverek csoportja).
levélváltó (MX)
Ezeket a rekordokat az e-mail alkalmazások arra használják, hogy lokalizálják a levelezőszervert a zónában. Lehetővé teszik az e-mail címben megadott tartománynév és a tartomány levelezőkiszolgálóját kezelő számítógép rekordjának egyeztetését. Így ez a típusú rekord lehetővé teszi a DNS-kiszolgáló számára, hogy feldolgozza azokat az e-mail címeket, amelyek nem tartalmaznak levelezőszervert.
Az MX rekordok gyakran azért jönnek létre, hogy hibatűrést biztosítsanak egy másik levelezőszerver számára arra az esetre, ha az előnyben részesített kiszolgáló nem elérhető.
A preferenciaértékek több szerverhez vannak hozzárendelve. Minél alacsonyabb az érték, annál magasabb a szerver preferencia sorrendje.
JEGYZET: Szimbólum @
V ezt a példát a @ szimbólum az e-mail címben található helyi domain nevet jelöli.
MutatóPTR
Ez a bejegyzés csak a fordított keresési zónákban használatos, hogy támogassa az IP-címek gazdagépnevekké vagy teljes tartománynevekké történő feloldásakor előforduló fordított keresést. A fordított keresés az in -addr .arpa tartomány gyökérzónáiban történik. A PTR rekordok manuálisan vagy automatikusan hozzáadhatók a zónákhoz.
Az alábbiakban egy példa a DNS-kezelőben generált PTR-rekord szöveges megjelenítésére egy zónafájlban, amely a 192.168.0.99 IP-címet képezi le az 1.google .ru szerver gazdagépnevével:
99 PTRszerver 1.Google.ru.
JEGYZET: 99-es rekordszámPRT
Fordított kereséskor az IPv 4-cím utolsó oktettje megegyezik a gazdagépnévvel. Ezért a 99-es szám a 0.168.192.in -addr .arpa zónán belüli csomóponthoz rendelt nevet jelöli. Ez a zóna a 192.168.0.0 alhálózatnak felel meg.
Szolgáltatás helyeSRV
Felvételek Az SRV a szolgáltatások helyének jelzésére szolgál egy tartományban. Az SRV-t használó ügyfélalkalmazások használhatják a DNS-t az alkalmazáskiszolgálók SRV-rekordjainak lekérésére.
Az SRV-t használó alkalmazás a Windows Server 2008 Active Directory. Netlogon A bejelentkezés SRV rekordokat használ a tartományvezérlők lokalizálására, az Active Directory Lightweight Directory Access Protocol (LDAP) tartományában keresve. DNS a hibatűrés javítása vagy a hálózati szolgáltatások hibaelhárítása érdekében.
BekapcsolniDNS a feloldáshozGYŐZ
A zónatulajdonságok ablak WINS lapján megadhatja azt a WINS-kiszolgálót, amellyel a DNS-kiszolgáló szolgáltatás felveszi a kapcsolatot a DNS-lekérdezésekkel nem talált nevek megkereséséhez. Ha megad egy WINS-kiszolgálót a tulajdonságok párbeszédpanel WINS lapján egy továbbítási keresési zónához, egy speciális WINS-bejegyzést ad a zónához, amely az adott WINS-kiszolgálóra hivatkozik. Ha megad egy WINS-kiszolgálót a névleges keresési zóna tulajdonságai párbeszédpanel WINS lapján, egy speciális WINS -R bejegyzés kerül a zónába a WINS-kiszolgáló azonosítására.
Például, ha egy DNS-ügyfél a ClientZ .contoso .com nevet kéri, és az előnyben részesített DNS-kiszolgáló nem találja meg a választ normál forrásokból (gyorsítótár, helyi zónaadatok és más kiszolgálók lekérdezése), a szerver a CLIENTZ-t kéri. a WINS rekordban megadott WINS szerveren. Ha a WINS-kiszolgáló válaszol a kérésre, a DNS-kiszolgáló visszaküldi a választ az ügyfélnek.
Elavult rekordok törlése és törlése
A DNS-ben időbélyegeket használnak a dinamikusan regisztrált erőforrásrekordok korának nyomon követésére. Az elavult rekordok törlése az elavult időbélyeggel ellátott rekordok eltávolításának folyamata. A tisztítás csak időbélyegek használata esetén végezhető el. Az időbélyegzés és a súrolás együtt eltávolítja a régi rekordokat, amelyek idővel felhalmozódhatnak egy zónában. Alapértelmezés szerint az időbélyegzés és a törlés le van tiltva.
Tisztítás engedélyezése
Ha egy adott zónában engedélyezni szeretné a takarítást, engedélyeznie kell ezt a szolgáltatást a szerver és a zóna szintjén.
A kiszolgáló szintű tisztítás engedélyezéséhez a DNS-kezelő konzolfájában kattintson a jobb gombbal a kiszolgáló ikonjára, és használja a Set Aging / Scavenging For All Zones (Összes zónához tartozó öregedés/tisztítás beállítása) lehetőséget. Ezután a megnyíló Kiszolgáló öregedési/tisztítási tulajdonságai párbeszédpanelen jelölje be az Elévült erőforrásrekordok eltávolítása jelölőnégyzetet. Noha ez a beállítás tartalmazza az összes új zóna kiszolgálószintű időbélyegzését és törlését, nem tartalmazza az Active Directoryba integrált meglévő zónák időbélyegzését és törlését.
Engedélyezésükhöz kattintson az OK gombra, majd a megjelenő Kiszolgáló öregedésének/tisztításának megerősítése párbeszédpanelen jelölje be a jelölőnégyzetet, hogy alkalmazza ezeket a beállításokat a meglévő Active Directoryba integrált zónákra.
Az időbélyegzés és a zóna szintű tisztítás engedélyezéséhez nyissa meg a Zóna tulajdonságait, majd az Általános lapon kattintson az Öregedés gombra. A megnyíló Zone Aging / Scavenging Properties párbeszédpanelen jelölje be az Elévült erőforrásrekordok eltávolítása jelölőnégyzetet.
Időbélyegek A DNS-kiszolgáló a tisztítást a zónában lévő erőforrásrekordokon beállított időbélyegek használatával hajtja végre. Az Active Directory-ba integrált zónák beállítják az alapértelmezett időbélyegértékeket a dinamikusan naplózott bejegyzésekhez, mielőtt az ürítést engedélyeznék. Az alapvető szabványos zónák azonban csak az ürítés engedélyezése után állítanak be időbélyeget a zónában lévő dinamikusan naplózott bejegyzésekhez. Az összes zónatípushoz manuálisan létrehozott erőforrásrekordhoz 0 időbélyeg van hozzárendelve; ez azt jelenti, hogy életkorukat nem határozzák meg. A bélyegző utolsó frissítése és a lehetséges következő frissítés közötti idő. A blokkolás megakadályozza, hogy a szerver feldolgozza a szükségtelen frissítéseket, és csökkenti a forgalmat. Az alapértelmezett letiltási intervallum 7 nap.
■ Módosításintervallummegújítás
A frissítési időköz a legkorábbi időbélyeg-frissítés és a rekord törlésének megkezdésének legkorábbi időpontja közötti intervallum. A zárolási és frissítési időközök letelte után a rekordok törölhetők a zónából. Alapértelmezés szerint az intervallum 7 nap. Ezért, ha engedélyezi az időbélyegeket, a dinamikusan regisztrált erőforrásrekordok 14 nap elteltével törölhetők.
Takarítás végrehajtása
A tisztítás a területen automatikusan vagy manuálisan történik. A tisztítás automatikus végrehajtásához engedélyeznie kell az elavult erőforrásrekordok automatikus törlését a DNS-kiszolgáló tulajdonságai párbeszédpanel Speciális lapján.
Ha ez az opció nincs engedélyezve, akkor manuálisan tisztíthatja meg a zónákat, ha a jobb gombbal a kiszolgáló ikonjára kattint a DNS-kezelő konzolfájában, és használja a Scavenge Stale Resource Records parancsot.
GlobalNames Zone
A Windows Server 2008 tartalmaz egy új szolgáltatást, amely lehetővé teszi az Active Directory erdőben lévő összes DNS-ügyfél számára, hogy egycímkés neveket (például Mail) használjon a szervererőforrásokhoz való csatlakozáshoz. Ez az összetevő akkor hasznos, ha a DNS-ügyfelek alapértelmezett DNS-utótag-keresési listája megakadályozza, hogy a felhasználók gyorsan csatlakozzanak (vagy egyáltalán csatlakozzanak) egy erőforráshoz ilyen egycímkés név használatával.
A Windows Server 2008 DNS-kiszolgálója lehetővé teszi a GlobalNames zóna létrehozását. Alapértelmezés szerint a GlobalNames zóna nem létezik, azonban az ilyen nevű zóna telepítésével hozzáférést biztosíthat a kiválasztott erőforrásokhoz egyetlen címke neveivel, WINS használata nélkül. Általában az egycímkés neveket olyan fontos és széles körben használt szerverekhez rendelik hozzá, amelyekhez már statikus IP-cím van hozzárendelve. GlobalNames a távoli kiszolgálón, cserélje ki a pontot a távoli kiszolgáló nevére.
■ Teremtész ony GlobalNames
A GlobalNames zóna üzembe helyezésének következő lépése egy zóna létrehozása egy DNS-kiszolgáló számára, amely Windows Server 2008 tartományvezérlőként szolgál. A GlobalNames zóna nem egy speciális zónatípus, hanem csak egy Active Directoryba integrált, GlobalNames nevű előremutató keresési zóna. . Zóna létrehozásakor válassza ki az erdőben található összes DNS-kiszolgáló zónaadatainak replikálását. Ez a beállítás egy Active Directory integrált zóna Replikációs hatóköre oldalán található (Az egycímkés névfeloldás engedélyezéséhez hozzon létre egy erőforrás-alias (CNAME) rekordot a G lobalNames zónához. Az egyes CNAME rekordokhoz rendelt név egy címkés nevet képvisel hogy a felhasználók az erőforráshoz való csatlakozást használhatják. Vegye figyelembe, hogy minden CNAME rekord egy másik zónában lévő gazdagéprekordot határoz meg.
Backdoor egy hacker számára a számítógépen - BackDoor spyware
WinLocker írása delphiben
Erőforrás-szerkesztő EXE és DLL fájlokhoz Hogyan lehet megtudni egy exe fájl tartalmát
Hogyan lehet elrejteni a bat ablakot, ha a cmd fájl fut
Hogyan védekezhet a WannaCry vírus ellen