A dns működésének alapjai

előző ◈ a következő
  • Az adattárolás megoszlása ​​A különböző zónák adatait különböző szerverek tárolják
  • Az adminisztráció megoszlása ​​A különböző területek felelősek a különböző területekért
  • A lekérdezések gyorsítótárban való tárolhatóságának csökkentése és a válaszidő csökkentése.
  • Hibatűrés Több kiszolgáló felel az egyes zónákra vonatkozó információk tárolásáért

Nagyszerű vágyakozással a következő RFC 1034 1035 tanulmányozható

Domain - Egy egység a névfán, az összes alárendelt csomóponttal együtt. A domainszintek bal referenciaértéknek tekintendők.

  • A gyökérdomén "." (A DNS név végén található pont.) Példa: server1.moscow.domain.org.). Általában egy név beírásakor elhagyható, de megadható, majd megadja a nevét FQDN-ként (Teljesen minősített domainnév).
  • Az első szintű domainek (általában org, com, me, tv, ru, stb.) Tematikusak vagy regionálisak. Az ország vagy a foglalkozás meghatározása.
  • Második szintű domainek (például: mail, gmail, yandex) Ezek általában az interneten találhatók, regisztrátorok értékesítik őket. Egyesek érdemesek egy fillért sem, mások olyanok, mint néhány repülőgép.
  • A harmadik és egyéb szintek domainjeit ritkán adják el és regisztrálják. A kivétel lehet például a ****.Com.ru és hasonló nevek.

Aldomain - Slave tartomány. Például: server1.moscow.domain.org

  • A (z) domaindomain.com domainhez tartozó moscow domain név található
  • A hossza legfeljebb 127 aldomént tartalmazhat, amelyek mindegyikének legfeljebb 63 karakterből állhat. De a teljes hossz nem haladhatja meg a 254 karaktert

Erőforrásrekord - Egy információs tároló egység, egy név és egy domain névhez van kötve. Például: server1.moscow.domain.org

  • Az erőforrásrekord lesz szerver1, és rendelkezik az A-Record formátummal

Zóna - A domain név egy része az erőforrásrekordokkal és az aldomainekkel együtt, amely egy szerveren tárolódik. Gyakran szolgálja az adatok relevanciájáért felelős harmadik személyek felelősségének átruházását.

Gyökér-tanács - A gyökérdomainért felelős jól ismert szerver "." (Dot)

Felelősség - Kétféle létezik:

  • Hiteles - Amikor a DNS-kiszolgáló tárolja a kért zónát
  • Nem hiteles - Ha a DNS-kiszolgáló nem tárolja a kért zónát

Rekurzív és iteratív lekérdezés

A nevek megoldására kétféleképpen lehet megoldani.

A második rekurzív - ez az a módszer, amellyel a DNS-kiszolgáló egyszerűen továbbítja az adatokat az ügyfélről egy másik kiszolgálóra, feldolgozza a kérést és visszaadja a végleges adatokat. (a másik szerver rekurzív módon vagy ugyanúgy interaktív módon működhet)

Példaként említhető a következő történet:

  1. A Resolver rekurzív lekérdezést küld a DNS szerver NameServer1 számára
  2. NameServer1 iteratív kérések gyökér-tippeléshez
  3. mert az adatok nem oldhatók meg, akkor a COM zónának felelős DNS-kiszolgáló IP-címe visszakerül
  4. NameServer1 iteratív kéréseket küld a COM zónának felelős NS-nak
  5. mert az adatok nem oldhatók meg, a Reskit.com zónaért felelős DNS-kiszolgáló IP-címe visszakerül
  6. A NameServer1 iteratív lekérdezéseket tesz a Reskit.com zónához felelős NS-khez
  7. Megkapja a szükséges adatokat
  8. Visszaadja a Resolver ügyfélprogramot.

Fordított DNS lekérdezés

A DNS-kiszolgáló rekordjainak típusai

Csak a fő, csak azért adunk nagy számuk:

A névfeloldás és a gyorsítótárazással kapcsolatos javítások

Ez a szám az összes tételt mutatja:

Az összes hét lépés megkeresése megáll, amint az első esemény megfelel a feltételeknek.

Megjegyzés:
-A DNS cache-t a c: \> ipconfig / displaydns segítségével tekintheti meg

Windows IP konfiguráció

Felvétel neve. api.wordpress.org

Megjegyzés: Az összes fő paraméter érthető, nem fogok megadni

Amikor elindul a DNS-kiszolgáló szolgáltatás, az összes zóna adatait a RAM tárolja. Ne felejtsük el, hogy a DNS lekérdezések gyorsítótárát a memóriában tároljuk. Hasznos lehet a DNS-kiszolgálók rendszerkövetelményeinek figyelembevétele:

  1. A zónák nélküli DNS-kiszolgáló kb. 4 MB RAM-ot igényel
  2. Zónák hozzáadásakor az adatok be vannak töltve a fő memóriába
  3. Minden rekord kb. 100 bájtot vesz igénybe. Tehát, ha 1000 bejegyzésed van, akkor még 100 kilobájt lesz
  1. Kizárólag pénzforgalom - ne tároljon zónákat, csak szerverek, ahol a DNS lekérdezések gyorsítótárát tárolják. Ezért nem hoznak létre zónaátviteli forgalmat. A fiókirodát a DNS-forgalom csökkentése és a központi iroda között csökkentheti.
  2. Nem rekurzív - Olyan kiszolgálók, amelyeken a DNS zónát tárolják, és letiltják a rekurzív névfeloldás lehetőségét. Ez azt eredményezi, hogy ha a kiszolgáló nem tudja megoldani a nevet (nincs erőforrásrekordja), akkor a DNS-lekérdezés nem engedélyezett. Az ilyen kiszolgálókat a vállalatok külső DNS-kiszolgálóinak szerepébe lehet helyezni. Ezenkívül megvédi a DNS-kiszolgálókat a külső felhasználók használatától a DNS-nevek feloldására az interneten.
  3. Csak előre - A név alapján egyértelmű, hogy a kiszolgálók csak a DNS-kéréseket más szerverekre továbbítják (a normál rekurzív lekérdezés le van tiltva). Ebben az esetben, ha a szerver nem kap választ másoktól, akkor a kérés nem engedélyezett. Az ilyen szerverek a vállalati hálózat és az internet közötti DNS-forgalom kezelésére használhatók. Ebben a forgatókönyvben az összes belső kiszolgáló hozzáférhet a Forward-only kiszolgálóhoz a külső nevek megoldásához. Az internetes kapcsolat helyszíne egy DNS-kiszolgálóra csökken.
  4. Feltételes továbbítás - Nagyon hasonlít a Forward-only szerverre. de ellentétben velük, hogy megad egy csomagot, melyik tartományra szeretné továbbítani az IP-címet.

Ezért a contoso.msft-hez kapcsolódó összes lekérdezés. például a www.corp.contoso.msft átkerül a 10.10.0.10 címre

A Microsoft DNS-kiszolgáló biztonsági szintjei

Három szint van:

Névtér tervezés

A DNS névtér megfelelő tervezésével nem lesz probléma megoldani ezeket a neveket. Jelenleg minden cégnek kommunikálnia kell a külvilággal. Mit jelent ez számunkra?

  1. A belső DNS-kiszolgálónevek és -szolgáltatások - nem érhetők el az internetről
  2. A belső kiszolgálóknak képesnek kell lenniük a külső (internetes) nevek megoldására
  3. A külső felhasználóknak képesnek kell lenniük a külső nevek (például webhelynév, VPN kapcsolódási pont, Exchange OWA stb.) Feloldására,

A helyes megoldás a DNS-struktúra megosztása a cselekvés körébe (helyi hálózat és internet). Számos tipikus megoldás létezik. Tekintsük őket, és döntsük el, melyiket válasszuk. Egy névtér. Az előnyök közé tartozik egy névtér a helyi hálózat és az internet számára. Ebben az esetben a különböző DNS-kiszolgálók felelősek a különböző erőforrásrekordokért. Ha a belső DNS-t az Active Directoryhoz és hasonló erőforrásokhoz használja, akkor a külső DNS-t a WWW-oldalakhoz, VPN-belépési pontokhoz stb. Használják. Szintén eltérő látómező-területek.

  • Egy névtér. Az előnyök közé tartozik egy névtér a helyi hálózat és az internet számára. Ebben az esetben a különböző DNS-kiszolgálók felelősek a különböző erőforrásrekordokért. Ha a belső DNS-t az Active Directoryhoz és hasonló erőforrásokhoz használja, akkor a külső DNS-t a WWW-oldalakhoz, VPN-belépési pontokhoz stb. Használják. Szintén eltérő látómező-területek.
  • Aldomain. Abban az esetben, ha a belső infrastruktúra számára a fődomainből egy aldomainet osztunk ki.
      1. Könnyebb beadni
      2. Értsd meg azonnal a hálózati topológiát
      3. A belső névtér a külső kérések számára láthatatlan marad
  • Egy külön névtér. A második esethez hasonlóan megosztjuk a névteret is. De ebben az esetben például a vallásos világnézetek vagy más feladatok akaratának megfelelően - szükség van arra, hogy ne osszunk meg közkincset. Ebben az esetben a belső igényekhez külön domaint hozunk létre, és külön választunk a külső felhasználók számára. Bár a képen és a második szintű domainek ugyanazok, de ez nem kötelező feltétel.

  • A DNS zónáknak három típusa van, mindegyikük igényeikhez igazítható:

    A Windows DNS-kiszolgáló dinamikus frissítéseket támogat. Számos típus létezik.

    • Biztonsági dinamikus frissítés az Active Directoryban - ez a funkció csak akkor érhető el, ha az AD DNS zónák integrálva vannak. Mivel a zóna AD-ben tárolódik, az adatokat az Active Directory szolgáltatásai segítségével biztonságossá teheti. Az ACL (Hozzáférés-vezérlési lista) segítségével meghatározhatja a szerkesztésre / olvasásra vonatkozó jogokat
    • Dinamikus DNS-frissítés DHCP-ről - Ez a szolgáltatás lehetővé teszi a DNS-rekordok DHCP-kiszolgálókhoz történő frissítését. A frissítés akkor következik be, amikor a DHCP-kiszolgáló ügyfél megkapja az IP-címet. DHCP-kiszolgálókon meg kell határoznia azokat a DNS-zónákat, amelyeken a kiszolgáló dinamikusan frissíti az értékeket. A DNS-kiszolgálón állapítsa meg, hogy csak a DHCP-kiszolgálók frissíthetik a rekordokat.
    • DNS ügyfél dinamikus frissítése - majdnem ugyanaz, mint a 2. pontban. A különbség az, hogy a DNS-ben lévő adatokat az ügyfelek automatikusan frissítik. Ez a lehetőség az XP verziója óta. Ez a módszer kevésbé biztonságos, mert A támadó könnyen megváltoztathatja a rekordot a DNS-ben. Ha engedélyezi ezeket a dinamikus frissítéseket, megnyit egy másik ajtót a támadónak.

    Zónaátvitel és replikáció

    Mivel az elosztott struktúrákat használják a DNS-kiszolgálók magas rendelkezésre állásának biztosítására. Szükség van az ezen adatokért felelős összes kiszolgálóra vonatkozó adatok frissítésének szinkronizálására. Ehhez zónátovábbítást használok (replikáció az Active Directoryban).

    Zóna tárolóhelyek

    A küldöttség a jogok átruházásának folyamata egy domain név egy részéhez, például egy másik szervezethez, fióktelephez stb.

    Mikor kell küldeni?

    1. Ha át kell adnia a domain név egy részének ellenőrzését a részvétel nélkül történő adminisztrációra
    2. Ha van egy nagy DNS-adatbázis, hogy hibatűrést biztosítsunk, akkor az adatbázis különböző kiszolgálókon terjedhet
    3. Ha új aldomainet kell felvennie az új iroda számára, és át kell adnia a kezelési jogot.

    Megvizsgáljuk a Windows DNS szerver képességeit

    Az alapot, amelyen átmentünk, most menjünk át a DNS által nyújtott lehetőségeken. Ehhez telepítenie kell a DNS-kiszolgáló szerepét a kiszolgálón. Ezek a lépések kihagyásra kerülnek, mert túllépik e cikk alkalmazási körét.

    1. Futtassa az Új DNS zóna varázslót.

    Válassza ki a zóna típusát és helyét

    • Elsődleges, másodlagos és pálca
    • Tárolja a zónát az Active Directoryban - tartsuk az új zónát az Active Directoryban
  • Állítsa be a zóna nevét (www vagy egyéb aldomainek nélkül)
  • Ha exportálta a zónát, akkor egyszerűen illessze be a fájlt (a meglévő fájl használata). A fájlt a% systemroot% \ system32 \ dns fájlba kell helyezni
  • Válassza ki, hogy szükség van-e dinamikus frissítésekre a zónához. mert Hozzon létre egy zónát a weboldalamhoz, akkor nem kell frissítenem. Magam is felveszi a jegyzeteket. a feljegyzések nem több, mint egy tucat.
  • A Névszolgálatok lapon megadhatja, hogy hol tárolják az adott zónára vonatkozó adatokat, pl. más NS szerverek.
  • A Zónaátvitel fülön meg tudja határozni, hogy ki engedélyezheti a zónát. A legegyszerűbb opció a Névjegyszerverek lapon található Csak a szerverek listájában található. Ami arra utal, hogy csak a kifejezetten meghatározott NS szerverek tudják átvinni a zónát. Az összes kiszolgálót vagy csak a kiválasztott IP-címeket engedélyezheti

    DNS és Active Directory

    Mint már sokan tudják, az Active Directory nagymértékben támaszkodik a DNS-infrastruktúrára. Ő az alap munkaerő. Lássuk tehát, milyen rekordok vannak jelen és szükségesek az AD munkához.

    Ha a kiszolgálói szerepkör DC-re emelkedik, az összes szükséges DNS-bejegyzés automatikusan létrejön. Később, ha más DC-ket, webhelyeket is hozzáad, törölje az adatokat. Mindez a DNS-ben van előírva. Éppen ezért a DNS-kiszolgálónak támogatnia kell az erőforrásrekordok dinamikus frissítését. A rekordadatok megtalálhatók a% systemroot% \ System32 \ Config \ Netlogon.dns fájlban.

    Most beszéljünk részletesebben, és kezdjünk el _msdcs-el

    • _msdcs a Microsoft által definiált aldomain. Feladata, hogy meghatározza a DC helyét, amely bizonyos szerepeket végez az erdőben és a tartományban. Ez a zóna az erdészeti alkalmazás címtárpartíciójában található. Hálózati bejelentkezés szolgáltatást regisztrál SRV rekord proxyhitelesítési jól ismert források, mint a DC (Domain Controller), GC (globális katalógus), PDC (Primary Domain Controller), Domain (globálisan egyedi azonosító, GUID), mind az aldomain prfiksy _msdcs. Az így definiált aldomainek meghatározzák a Domain Controller-eket a tartományban vagy az erdőben, és bizonyos szerepet töltenek be. A DC-típus típus vagy GUID helyének meghatározásához a Windows-kiszolgálók az SRV-t a következő minta alapján regisztrálják:

    _Service._Protocol.DcType._msdcs.DnsDomainName

    • SRV rekordok. Amikor egy tartományvezérlő indít, a Net Logon szolgáltatás dinamikus frissítéseket használ fel az SRV és az A rekordok regisztrálására a DNS-kiszolgálón. Az SRV rekordok segítségével rögzítheti a szolgáltatás nevét (például az LDAP-t) azon számítógép DNS-nevén, amelyen a szolgáltatás fut. Amikor egy munkaállomás csatlakozik egy tartományhoz, az SRV rekordok DNS-jét lekérdezi a következő űrlapon:

    Mivel az Active Directory a TCP protokollt használja, az ügyfelek megtalálják az LDAP kiszolgálót ebben a formában:

    • SRV rekordok a Net Logon szolgáltatás által regisztrálva

    Lehetővé teszi az ügyfél számára, hogy olyan kiszolgálót találjon a DnsDomainName domainben futó LDAP szolgáltatással. Például: _ldap._tcp.inadmin.ru

    _ldap._tcp. Webhely_neve. _sites. Dnsdomainname.

    Lehetővé teszi az ügyfél számára, hogy megtalálja a kiszolgálót a DnsDomainName domainben működő LDAP szolgáltatással a SiteName webhelyen. A SiteName egy relatív név, amelyet az Active Directory konfigurációs tartalma tárol. Például: _ldap._tcp.Moscow._Sites.inadmin.ru

    Lehetővé teszi az ügyfél számára, hogy megtalálja a tartományvezérlőt a DnsDomainName domainben. Minden DC regisztrálja ezt az SRV rekordot.

    _ldap._tcp. Webhely_neve. _sites.dc._msdcs. Dnsdomainname.

    Lehetővé teszi az ügyfél számára, hogy megtalálja a tartományvezérlőt a DnsDomainName tartományban a SiteName oldalon. Minden DC regisztrálja ezt az SRV rekordot.

    Lehetővé teszi az ügyfél számára, hogy megtalálja a PDC-t a DnsDomainName domainben, csak a PDC kiszolgáló regisztrálja ezt az SRV rekordot.

    Lehetővé teszi az ügyfél számára, hogy megtalálja a PDC-t a DnsForestName erdőben, csak a GC-kiszolgálók regisztrálják ezt az SRV rekordot.

    _ldap._tcp. Webhely_neve. _sites.gc._msdcs. DnsForestName.

    Lehetővé teszi, hogy az ügyfél megtalálja a GC-t a DnsForestName erdőben, csak az erdőhöz tartozó GC kiszolgálók regisztrálják ezt az SRV rekordot. Például: _ldap._tcp.Moscow._Sites._gc._msdcs.inadmin.ru

    _ gc._tcp. DnsForestName.

    Lehetővé teszi az ügyfél számára, hogy megtalálja a GC-t az adott tartományban. Csak az erdő DnsForestName-hez tartozó GC kiszolgálók regisztrálják ezt az SRV rekordot. Például: _gc._tcp.inadmin.ru

    _ gc._tcp. Webhely_neve. _sites. DnsForestName.

    Lehetővé teszi az ügyfél számára, hogy megtalálja a GC-t az adott DnsForestName erdőben a SiteName oldalon. Csak az erdő DnsForestName-hez tartozó GC kiszolgálók regisztrálják ezt az SRV rekordot. Például: _gc._tcp._Moscow._Sites.inadmin.ru

    _ldap._tcp. DomainGuid. domains._msdcs. DnsForestName.

    Lehetővé teszi az ügyfelek számára, hogy megtalálják a DC-t a GUID segítségével. A GUID egy 128 bites egyedi mutató. Akkor számolt, amikor a DnsDomainName és a DnsForestName megváltozott. Például: _ldap._tcp.4f904480-7c78-11cf-b057-00aa006b4f8f.domains. _msdcs.inadmin.ru

    Lehetővé teszi az ügyfelek számára, hogy Kerberos KDC-t találjanak az adott tartomány DnsDomainName-jében. Minden DC regisztrálja ezt az SRV rekordot.

    Ugyanaz, mint a _kerberos._tcp. DnsDomainName csak UDP-n keresztül

    _kerberos._tcp. Webhely_neve. _sites. Dnsdomainname.

    Lehetővé teszi az ügyfelek számára, hogy Kerberos KDC-t találjanak az adott DnsDomainName domainben a SiteName-ben. Minden DC regisztrálja ezt az SRV rekordot.

    Lehetővé teszi az ügyfelek számára, hogy megtalálják a DC-t, amelyen a Kerberos KDC szerepkör fut a DnsDomainName domainben. A KDC szerepkörrel rendelkező összes DC-k regisztrálják ezt az SRV rekordot.

    _kerberos.tcp. Webhely_neve. _sites.dc._msdcs. Dnsdomainname.

    Lehetővé teszi az ügyfelek számára, hogy megtalálják a DC-t, amelyen a Kerberos KDC szerepkör a SiteName webhely DnsDomainName domainjén fut. A KDC szerepkörrel rendelkező összes DC-k regisztrálják ezt az SRV rekordot.

    Lehetővé teszi az aktuális tartomány Kerberos jelszóváltásának megtalálását. A kerberos KDC szerepét betöltő összes DC-k regisztrálják ezt az SRV rekordot

    Ugyanaz, mint a _kpassword._tcp. DnsDomainName csak UDP-n keresztül

    Kapcsolódó cikkek

    • előző ◈ a következő