Name Resolution pruža osnovu za mnogo drugih servisa. Domain Name System (DNS) je široko prihvaćen kao standard za razrešavanje imena na IP mrežama. Da bi se osiguralo da mrežni servisi mogu da funkcionišu optimalno, administrator mora da planira implementaciju DNS servisa.

  • Selektovati identično ime za interni domen, na primer, linkgroup.com. Ovo pruža jednostavnost , što često predstavlja najbolji izbor za manje organizacije.
  • Izabrati različito ime domena, na primer linkgroup.priv. Ovo pruža očigledno odvajanje adresnog prostora. U kompleksnim mrežama koje imaju mnogo internet aplikacija korišćenje različitih imena predstavlja određenu jasnoću prilikom konfigurisanja ovih aplikacija. Na primer, ivični serveri (Edge Servers) koji se nalaze u perimeter mreži, često zahtevaju više mrežnih kartica, jednu koja je konektovana na privatnu mrežu i druga koja servisira zahteve koji dolaze sa javne mreže. Ako obe mreže imaju različito ime domena, često je u tom slučaju lakše kompletirati konfiguraciju na tom serveru.
  • Implementirati dete domen za ime javnog domena (Public Domain Name), na primer priv.linkgroup.com. Ovo nudi hibridni prilaz jer je ime različito i omogućava odvajanje adresnog prostora, ali je takođe povezano sa javnim imenom, što nudi jednostavnost.

  

Razrešavanje DNS imena

Administratori moraju da konfigurišu klijentske kompjutere na mreži tako da njihova kompjuterska imena mogu da budu razrešena u IP adrese. Kada konfigurišemo klijenta za razrešavanje imena (Name resolution), mi time osiguravamo da oni mogu da komuniciraju sa drugim kompjuterima koristeći imena kompjutera. Da bi dva hosta mogla da komuniciraju na mreži, MAC adresa svakog hosta mora da bude identifikovana. IP adresa je udružena sa MAC adresom, a ime kompjutera je udružena sa IP adresom. Razrešavanje imena (Name Resolution) je proces dobijanja IP adrese koja je udružena sa imenom kompjutera. Poznavanje različitih metoda za razrešavanja imena kompjutera može da vam umnogome pomogne u odrađivanju ovih administrativnih zadataka.

 

Razrešavanje imena u mrežnoj infrastrukturi (Name Resolution)

U Transmission Control Protocol-Internet Protocol (TCP-IP) mrežama mnoge komponente obezbeđuju komunikaciju između dva TCP-IP hosta i pristup mrežnim resursima. Deo uspešnog komunikacionog procesa u TCP-IP mreži je Name Resolution (razrešavanje imena). Name Resolution proces je prevođenje imena kompjutera (Display Name) u odgovarajuću IP adresu.

Host ime je prva komponenta sa leve strane DNS imena koje identifikuje hosta, kao što je na primer, kompjuter ili resurs. DNS imena su deo jedne velike hijerarhijske strukture. U DNS imenu na primer, webserver1.linkgroup.co.rs host ime predstavlja prvu komponentu sa leve strane (webserver1). Host i DNS imena se koriste za komunikaciju na Internetu i na intranetu.

 

Name Resolution Process

Kada korisnik ukuca ime kompjutera za određeni resurs, klijentski kompjuter prvo proverava svoj DNS Name Cache da bi odredio da li je DNS ime već ranije razrešeno i zatim IP adresu. Ako zapis postoji u DNS Name Cache-u, klijentski kompjuter će iskoristiti IP adresu da bi se povezao na resurs. Ako DNS Name Cache ne može da razreši ime u IP adresu, zahtev odlazi ka sledećoj komponenti Hosts fajlu. Lokalni Hosts fajl dalje pretražuje svoje zapise u potrazi za zapisom koji prevodi ime u IP adresu. Ako je zapis pronađen u Hosts fajlu, klijentski kompjuter kotisti IP adresu za pristup resursu. Ako Hosts fajl ne uspe da razreši ime u IP adresu, zahtev tada odlazi ka sledećoj komponenti -  DNS-u. DNS server pretražuje svoju bazu u kojoj se nalaze zapisi koji razrešavaju imena u IP adrese i ako pronađe potrebni zapis, klijentski kompjuter će moći da iskoristi IP adresu i konektuje se na resurs. U slučaju da se zapis ne nalazi u bazi DNS servera, zahtev odlazi do sledeće komponente - NetBIOS Name Cashe. NetBIOS Name Cache traži zapis koji prevodi ime u IP adresu i u slučaju da ga pronađe, šalje ga klijentskom kompjuteru koji će tada moći da se konektuje na resurs. U slučaju da NetBIOS Name Cache ne pronađe potrebni zapis, zahtev odlazi ka sledećoj komponenti - WINS-u. Zahtev šalje kompjuter koji je napravio zahtev ka WINS serveru. Windows server vrši pregled svih zapisa u svojoj lokalnoj bazi i u slučaju da pronađe željeni zapis, šalje ga klijentskom kompjuteru koji tada može da se konektuje na resurs. U slučaju da WINS server ne može da pronađe potrebni zapis u svojoj bazi, zahtev se prosleđuje ka sledećoj komponenti - NetBIOS Name Broadcast. Kompjuter šalje zahtev za emitovanjem u lokalnu podmrežu (Subnet) i ako neki od kompjutera na loklanoj podmreži može da razreši ime u IP adresu, taj kompjuter će poslati IP adresu klijentskom kompjuteru koji je napravio zahtev. Kompjuter koji je napravio zahtev moći će da pristupi resursu. Ako nijedan od kompjutera na lokalnoj podmreži nema potreban zapis, zahtev se šalje ka poslednjoj komponenti u Name Resolution Process-u, a to je Lmhosts fajl. Lokalni kompjuter tada pretražuje Lmhosts fajl u potrazi za zapisom i ako ga pronađe, kompjuter će moći da pristupi resursu. U slučaju da nijedna od komponenata u Name Resolutio procesu ne može da prevede Display ime u IP adresu, taj kompjuter tada neće moći da pristupi resursu.

  

Planiranje DNS Namespace-a (adresni prostor)

Kada počnemo da planiramo naš DNS adresni prostor, moramo da imamo na umi i interni adresni prostor i eksterni adresni prostor. Nema zahteva administratoru za implementiranje istog DNS domen imena interno i eksterno. Kada implementiramo ime domena za naš interni adresni priostor, postoje tri moguće strategije:

  • selektovati identično ime za interni domen, na primer linkgroup.com. Ovo pruža jednostavnost, što često predstavlja najbolji izbor za manje organizacije,
  • izabrati različito ime domena, na primer linkgroup.priv. Ovo pruža očigledno odvajanje adresnog prostora. U kompleksnim mrežama koje imaju mnogo internet aplikacija korišćenje različitih imena predstavlja određenu jasnoću prilikom konfigurisanja ovih aplikacija. Na primer, ivični serveri,  koji se nalaze u perimeter mreži, često zahtevaju više mrežnih kartica: jednu koja je konektovana na privatnu mrežu i drugu koja servisira zahteve koji dolaze sa javne mreže. Ako obe mreže imaju različito ime domena, često je u tom slučaju lakše kompletirati konfiguraciju na tom serveru.
  • implementirati dete domen za ime javnog domena (Public Domain Name), na primer priv.linkgroup.com. Ovo nudi hibridni prilaz jer je ime različito i omogućava odvajanje adresnog prostora, ali je takođe povezano sa javnim imenom, što nudi jednostavnost.

  

Planiranje DNS zona

Zona je baza podataka koja smešta informacije o delovima DNS adresnog prostora. Ako kreiramo poddomen, na primer, beograd.linkgroup.com, onda bi trebalo da razmislimo o implementaciji imena domena unutar naše DNS infrastrukture.

 

Postoje dva esencijalna prilaza:

  • Možemo da kreiramo novu zonu za novo DNS ime domena. Ova zona će imati svoje DNS Name servere i morali bismo da konfigurišemo odnos (Relationship) između novog DNS deteta domena i njegovog roditelja, linkgroup.com.
  • Alternativni metod je kreiranje poddomena u postojećem beograd.linkgroup.com zoni. U ovom scenariju nijedan Name server se ne nalazi unutar beograd.linkgroup.com dete domena, već, DNS serveri u roditeljskom domenu linkgroup.com, servisiraju zahteve za hostovima koji se nalaze u dete domenu beograd.linkgroup.com.

 

Planiranje poddomena

Izbor koji se odnosi na to da li da implementiramo odvojene zone za decu poddomene (Child Subdomens) primarno se  zasniva na dva faktora:

  • Administrativno odvajanje: Ako želimo da pružimo stepen administrativne odvojenosti adresnog prostora, onda možemo da kreiramo više zona, svaku za posebnog administratora.
  • Performansa: Ako je dete domen veliki i hostuje mnogo zapisa, potrebno je koristiti delegiranje tako da domen poseduje svoje DNS servere koji hostuju zonu. Ovo nudi najvišu i najbolju performansu.

 

Planiranje zonskih transfera

Jednom kada odredimo koliko ćemo zona kreirati, moraćemo da odredimo tip zone i kako će zonske informacije biti replicirane ili poslate između Name servera koji servisiraju zonu. Imamo nekoliko izbora:

  • Možemo da implementiramo Active Directory Integrated zone. U ovom slučaju, svi domenski kontroleri koji takođe hostuju DNS servisnu ulogu primaju zonske podatke automatski kroz Active Directory replikaciju. Ovo je jednostavniji prilaz i mnogo sigurniji pošto je Active Directory replikacioni saobraćaj autentifikovan i šifrovan.
  • Alternativno, možemo da implementiramo non-Actrive Directory integrisane zone. U ovoj instanci, kada izgradimo DNS uloge i kreiramo naše zone, moramo da definišemo da li će zona biti primarna ili sekundardna. Primarna zona može da se edituje, dok je sekundradna zona samo za čitanje i služi samo za servisiranje klijentskih zahteva. Sekundarna zona periodično prima svoje zonske podatke od master servera. Administrator mora da definiše odnos između sekundarne zone i njenog master servera – koji može da bude ili DNS server u primarnoj zoni ili drugi sekundarni DNS server. Kao dodatak, administrator bi trebalo da konfiguriše zonske transfere.

  

DNS prosleđivanje

Forwarder je mrežni DNS server koji prosleđuje DNS upite za eksternim DNS serverima izvan mreže (na Internet). Možemo, takođe da koristimo Conditional Forwarders (uslovno prosleđivanje) za prosleđivanje upita samo za specifična imena domena.

Mrežni DNS server je određeni prosleđivač (Forwarder) kada drugi DNS serveri u mreži prosleđuju ka njemu upite koje oni ne mogu lokalno da razreše. Koristeći prosleđivača možemo da upravljamo razrešavanjem imena koja se ne nalaze u našoj mreži, kao što su imena na Internetu i time poboljšamo efikasnost razrešavanja imena za naše mrežne kompjutere.

Server koji prosleđuje zahteve u mreži mora da bude u mogućnosti da komunicira sa DNS serverima koji se nalaze na Internetu. Ovo znači da bi trebalo ili da konfigurišemo prosleđivača da prosleđuje zahteve ka drugom DNS serveru ili da koristi Root Hint-ove za komunikaciju.

Potrebno je koristiti Central Forwarder DNS server za razrešavanje internet imena. Ovo može da poboljša performansu, da pojednostavi proces rešava problema i preporučuje se kao sigurnosni metod.

Možemo da koristimo stub zone umesto Conditional Forwarding-a za razrešavanje imena između specifičnih domena. Potrebno je koristiti stub zone kada želimo da DNS koji hostuje roditeljsku zonu ostane obavešten o autoritativnim DNS serverima za jedno od njegovih dece domena.

 

Šta treba imati na umu kad je u pitanju DNS uloga servera

Kada planiramo izgradnju DNS, postoje određene stavke koje administrator mora da pregleda. Te stavke su:

  • Koliko će DNS zona biti konfigurisano na serveru?
  • Koliko će DNS zapisa sadržati svaka zona?
  • Koliko će DNS klijenata komunicirati sa serverom na kojem je konfigurisana DNS uloga?
  • Gde ćemo postaviti DNS servere?
  • Da li ćemo smestiti DNS servere centralno ili ćemo ipak smestiti DNS servere u svakoj manjoj kancelariji?

  

Integracija aktivnog direktorijuma

Windows Server 2008 DNS uloga može da smesti DNS bazu podataka na dva različita načina:

  • Tekstualni fajl: DNS uloga servera smešta DNS zapise u tekstualni fajl, koji možemo da editujemo u tekst editoru.
  • Active Directory: DNS uloga servera smešta DNS zapise u bazu podataka aktivnog direktorijuma. Ova baza podataka može da se replicira na druge domenske kontrolere, čak i kada oni ne rade na Windows Server 2008 DNS ulogama. Ne možemo da koristimo tekstualni editor za editovanje DNS podataka koji su smešteni u aktivnom direktorijumu.


Integrisane zone aktivnog direktorijuma su lakše za upravljanje od tradicionalnih, zona zasnovanim na tekstu (Text-based zona) i, uz to, pružaju veći nivo sigurnosti. Replikacija zonskih podataka je deo replikacije aktivnog direktorijuma (AD).

 

Postavljanje DNS servera

Tipično, administrator će izgraditi DNS ulogu na svim domenskim kontrolerima. U slučaju da odlučimo da implementiramo neku drugu strategiju, potrebno je imati na umu sledeće:

  • Kako će klijentski kompjuteri razrešavati imena u slučaju da njihov DNS server, kojem se obično obraćaju, postane nedostupan?
  • Kakav će biti uticaj na mrežni saobraćaj ako klijentski kompjuteri počnu da koriste alternativni DNS server koji je, eventualno, dosta udaljen na mreži?
  • Kako ćemo implementirati zonske transfere? AD integrisane zone koriste AD replikaciju za transfer zone na sve domenske kontrolere. Ako implementiramo Non-AD integrisane zone, moramo da isplaniramo svoj mehanizam transfera zona.

 

 

 

Dodaj komentar Sviđa mi se - (0) Ne sviđa mi se - (0)    

  • Planiranje Name Resolution servisa 1
  • Planiranje Name Resolution servisa 2
  • Planiranje Name Resolution servisa 3
  • Planiranje Name Resolution servisa 4
  • Planiranje Name Resolution servisa 5