Stub soner er en ny funksjon i DNS i Windows Server 2003 som kan brukes til å effektivisere navn oppløsning, spesielt i en split navnerom scenario. De kan også bidra til å redusere mengden av DNS-trafikk på nettverket, noe som gjør DNS mer effektiv særlig over langsomme WAN-koblinger. Denne artikkelen vil se i detalj på hva som stubb sonene er, hvordan de fungerer, og når man skal bruke dem. Jeg vil også lede deg gjennom prosessen med å lage en stump sone for å lette navneoppslag mellom to separate skoger. Men først er litt bakgrunnsinformasjon om DNS-soner er nødvendig for å se hvor stubb soner passer inn i helheten.

Typer DNS soner

A sonen
er en sammenhengende del av DNS navne forvaltes av en eller flere navnetjenere. Sonene inneholder ressurs poster
som spesifiserer navnet på DNS-serveren autoritative for sonen (SOA rekord), navn og IP-adressene til alle navnetjenere i sonen (NS records), navn og IP-adresser fra andre maskiner (A records), alias for verter (CNAME records), og så videre.

I den opprinnelige implementeringen av DNS funnet i RFC 1034 og 1035, to forskjellige typer soner ble definert:

Primær soner
, som lagrer sine soneinformasjon i en skrivbar tekstfil på navnet serveren.
• Sekundære soner
  , som lagrer sin sone informasjon i en skrivebeskyttet tekstfil på navnet serveren.
  

  I implementering av DNS på Windows NT, ble disse to typer soner referert til som standard soner
  . Et typisk scenario for et selskap som hadde en enkelt Windows NT domene utplassert ville innebære å sette opp to navnetjenere på nettverket, en som inneholder standard primærsonen ( primær navnetjener
  for domenet) og den andre inneholder standard sekundær sone ( sekundær navnetjener
  ). Hver gang en ny vert (for eksempel en filserver) ble tilsatt til nettverket, begge disse navneservere måtte være oppdatert, slik at kundene kan finne den nye vert ved hjelp av DNS. For å gjøre dette, ville administratoren opprette en ny A rekord på hovednavnet serveren siden den eneste primærsonen kan bli endret. Hovednavnet serveren vil da gi beskjed til sekundær at dets poster hadde forandret seg, og det sekundære ville trekke den oppdaterte soneinformasjon fra primær før det hadde en identisk kopi av primærsonen. Fra perspektivet til den sekundære navnetjener, representerer hovednavnet serveren mester navnetjener
  for denne sonen.
  

  Hovedproblemet med denne ordningen var at hvis hovednavnet server gikk ned, kan det ikke gjøres endringer i ressursrekorder siden sekundære navnetjenere inneholdt kun lesesone informasjon. Også, betydde det at alle endringene du har gjort i DNS måtte utføres på et enkelt navn server (primær), som kan være en ulempe hvis selskapet gikk over flere steder.
  

  Windows 2000 gitt en løsning på disse problemene ved å innføre Active Directory Integrerte soner
  , som lagres sin sone opplysninger innen Active Directory i stedet for tekstfiler. Fordelene med denne nye typen sonen inkluderes ved å bruke Active Directory-replikering for soneoverføringer og tillater ressurs poster som skal legges til eller endres på en domenekontroller som kjører DNS. Med andre ord, alle Active Directory Integrerte soner er alltid foretrukne soner som de inneholder skrivbare kopier av sonen databasen.
  

  Active Directory Integrerte soner fungere godt for de fleste Windows 2000-baserte nettverk, men de har noen problemer. En begrensning er hvis du har å gjøre med to separate skoger (usammenhengende namespace), et vanlig scenario når selskaper sammenslåing eller en del av et konglomerat. For eksempel si Selskap A har nære bånd virksomhet med selskapet B og ansatte i selskapet A trenger tilgang til ressurser på selskapets B interne nettverk. Den vanlige måten å gi dem denne tilgangen ville være for DNS administrator av selskapet A å legge til en standard sekundærsone på hver av selskapet et navn servere. Disse sekundære sonene vil da peke til navnetjenere på selskapets B nettverk som deres mester navnetjenere, og vil få sine ressurs poster ved soneoverføringer med selskap B navn servere. Selv om det virker, er det overkill av flere grunner. Først genererer det mye sone transfer trafikk mellom navnetjenere i Selskap A og Selskap B, som kan utgjøre et problem dersom selskapene er knyttet sammen av en langsom WAN-tilkobling. For det andre, hvis selskapet B bestemmer seg for å avvikle en av sine navnetjenere uten å fortelle administratoren av selskapet A, noen av de sekundære soner på selskapet et navn servere kan plutselig finne seg selv uten en mester, og en gang sine poster utløper selskapet en kunder som bruker dem vil ikke lenger være i stand til å få tilgang til ressurser i selskapet B.
  
  Hva Stub Zones Gjør
  

  Enter stubb soner til unnsetning. En spire sonen er som en sekundær sone i som henter det sin ressurs poster fra andre navnetjenere (ett eller flere master-navnetjenere). En spire sonen er også beskyttet som en sekundær sone, slik at administratorer ikke kan manuelt legge til, fjerne eller endre ressursoppføringer på den. Men forskjellene ende her, som stubb sonene er ganske forskjellig fra videregående soner i et par vesentlige måter.
  

  Først, mens sekundære soner inneholde kopier av alle de ressursoppføringer i tilsvarende sone på master navnetjener, stubb sonene inneholder bare tre typer ressurs poster:
  

  • En kopi av SOA rekord for sonen.
  • Kopi av NS-poster for alle navnetjenere autoritative for sonen.
  • Kopi av A-poster for alle navnetjenere autoritative for sonen
    

    Det er det -. Ingen CNAME-poster, MX-poster, SRV-poster, eller A-poster for andre vertene i sonen. Så mens en sekundær sone kan være ganske stor for et stort selskap nettverk, er en stubb sone alltid veldig liten, bare noen få poster. Dette betyr replikere sone informasjon fra mester til stubb sonen legger nesten null DNS-trafikk til nettverket som postene for navnetjenerne sjelden endres med mindre du avvikle en gammel navnetjener eller distribuere en ny. Også, mens de fleste DNS-servere kan konfigureres for å hindre sone overføringer til videregående soner oppstår, stubb soner be bare SOA, NS, og A-poster for navnetjenere, som alle er gitt uten begrensning av noen navn server siden disse postene er viktig for navneløsing å fungere skikkelig. Til slutt, siden stubb soner kan bli integrert i Active Directory (sekundære soner kan ikke), de kan gjøre bruk av Active Directory-replikering å forplante sin informasjon til alle domenekontrollere i nettverket.
    

    I forrige tilfellet stub soner kan brukes i stedet for sekundære soner for å redusere mengden av sonen overføring trafikk over WAN-koblingen som forbinder de to selskapene. For å gjøre dette, ville administratoren for selskapet A bare logge på en av domenekontrollere, åpne DNS-konsollen, og opprette en ny spire sone som bruker ett eller flere av selskapets B navn servere som mester navnetjenere. Ved å gjøre dette stub sone en Active Directory integrert sone, stubben sonen vil da bli automatisk kopiert til alle andre domenekontrollere på Company A nettverk. Nå når en klient på Selskap A nettverk ønsker å koble til en ressurs på selskapets B nettverk, utsteder kunden en DNS-spørring til nærmeste Company A domenekontroller, som deretter videresender forespørselen til en av selskapets B navn servere for å løse.
    
    Hvordan lage en Stub Zone
    

    La oss se hvordan det fungerer i praksis. I min lab har jeg to skoger satt opp, en etter Selskapet A kjører Windows 2003 Server og heter test2003.local, og den andre for selskapet B kjører Windows 2000 og oppkalt test2000.local. Domenekontroller for roten domenet til Selskap A er oppkalt SRV220 mens domenekontrollere for rotdomene av Selskap B er oppkalt SRV210, SRV211 og SRV212. Sally er ansatt i selskapet A og hennes stasjonær datamaskin er oppkalt DESK231, og hun trenger å få tilgang til en aksje som heter CATALOG ligger på SRV210 i selskapet B. For å gjøre dette hun klikker Start, velger Kjør, og typer \\\\ srv210.test2000.local \\ katalog og resultatet er en feil:
    

    
    Dette er fordi hennes kommando problemer en DNS-spørring mot sin navnetjener SRV220 som ikke har noen informasjon i sin DNS-databasen om test2000.local, roten domenet av selskapet B:
    å tillate brukere Company A å få tilgang til ressurser i selskapet B, administrator av selskapet A bestemmer seg for å lage en stump sone etter Selskapet B domene. For å gjøre dette, høyreklikk på Forward Lookup Zones i figuren ovenfor, og velg New Zone. Dette starter Zone Wizard Ny:
    Klikker Neste bringer opp Zone Type skjermen, og vi vil velge Stub Zone her og merker for å skape en Active Directory Integrert stump sone:
    Klikk Neste og Active Directory Zone Replication Scope-skjermen vises, som vi vil forlate på standardinnstillingen for automatisk replikering av stump sone informasjon til alle domenekontrollere i test2003.local domene.
    klikke ved siden viser sonenavn skjermen, og her vi skriver test2000.local som navnet på stubben sone siden dette er navnet på målet domene på selskapets B nettverk:
    Klikker Neste viser Master DNS-tjenere-skjermen, og vi går inn i IP-adressen 172.16.11.210 for en av navnetjenerne om selskapet B nettverk:
    Klikker Neste og deretter Fullfør kjører veiviseren og skaper ny spire sonen, som her er markert i DNS-konsollen koblet til SRV220 på Company A nettverk:
    Note i figuren ovenfor at som forventet stubben sonen inneholder bare en SOA rekord, en NS rekord for hvert navn server i domenet, og en En rekord for hvert navn server i domenet. Nå når Sally klikker Start, velger Kjør, og typer \\\\ srv210.test2000.local \\ katalogisere et vindu åpner viser innholdet av katalogen aksje på SRV210 i avsidesliggende skog:
    
    Sammendrag
    Stub soner er enkle å lage, og kan gjøre navneløsing mellom skoger mer effektive, men de har andre bruksområder også. For eksempel kan stubbsoner kan navnetjenere å utføre rekursjon uten å måtte spørre Internet root navnetjenere eller interne bedrifts rot servere, og dermed redusere antall hopp mellom navnetjenere og lage navneløsing mer effektiv. En annen bruk av stubb soner er å holde delegert sone informasjonen oppdatert og hindre halt delegasjoner fra wrecking navneløsing i en skog, og som ville gjøre et godt emne for en fremtidig artikkel. Begge disse er gode temaer for fremtidige artikler, så følg med for mer om stubb soner senere. Anmeldelser

    
    
    
    Previous:NAT i Windows 2003
    Next Page:Installere DNS På Windows 2003