1. Location:
  2. / Computer learning >> Datamaskin læring >> system >> windows 2003 >>

DNS Betinget Forwarding i Windows Server 2003


Betinget videresending er en ny funksjon i DNS i Windows Server 2003 som kan brukes til å øke hastigheten på navneoppslag i enkelte scenarier. De kan også brukes til å hjelpe bedrifter å løse hverandres navnerom i en situasjon der selskapene samarbeide om fusjon er i gang. Denne artikkelen vil se i detalj på hvordan betinget videresending fungerer, hvordan du konfigurerer den, og når du kan bruke det. Men først, la oss kort gjennomgå begrepene videresending og speditører i tradisjonell DNS, og starter med ulike typer navnespørringer.

Lass og Forwarding

Når et navn server er spørres i DNS, måten den reagerer avhenger av hvilken type spørring utstedt, som enten kan være iterativ eller rekursiv. I en iterativ spør
, spør klienten navnet server for best mulig svar på sitt spørsmål. Navnet server sjekker sin cache og sonene som det er autoritativ og returnerer best mulig svar til klienten, som kan være enten en full svar som "her er IP-adressen til verten du er ute etter" eller et delvis svar som "prøve denne andre navn server i stedet, kan det vet svaret." I en rekursiv spørring
, ting fungerer litt annerledes for her klienten krever enten en full svar (IP-adressen til målet vert) eller en feilmelding som "beklager, navn ikke funnet." I Windows DNS, klientmaskiner alltid sende rekursive spørringer til navnetjenere, og navnetjenere vanligvis sender iterative forespørsler til andre navnetjenere.

Noen ganger denne prosessen ikke er nok likevel. Et enkelt eksempel er et selskap som har Active Directory utplassert på sitt interne nettverk og bruker en privat toppnivådomene som .local for sin skog. For eksempel si at et selskap har en enkelt Active Directory-domene som heter test2003.local, en domenekontroller (og DNS-server) som heter SRV220 og har en dedikert tilkobling til Internett. En bruker som heter Bob går til sin stasjonære PC heter DESK231, åpner Internet Explorer, og forsøker å få tilgang til Google (www.google.com). Her er hva som skjer DNS-messig så langt som navneløsing er bekymret:

  • DESK231 sender en rekursiv spørring til SRV220 ber om å løse www.google.com til den tilknyttede IP-adresse.
  • SRV220 ser i sin DNS database og finner soneinformasjon bare for test2003.local domene, innser www.google.com er ikke en del av dette domenet, bestemmer det har ingen måte å vite hvordan du løser www.google.com inn en IP-adresse, og hva som skjer videre avhenger:
  • Hvis, når du forfremmet den frittstående server til rollen som domenekontroller ved hjelp dcpromo, ble maskinen koblet fra Internett, og det var ingen andre DNS-servere i nettverket, så dcpromo skaper en rotsonen (".") i sin DNS database som angir seg selv som root navnetjener
    for alle DNS navn oppløsning (det vil si «den stopper her"). I dette tilfellet, innser SRV220 det kan ikke svare på spørringen og returnerer en "navn ikke funnet" feilen til klienten og Bob kan ikke åpne Google-hjemmesiden.
  • Hvis derimot, når du forfremmet serveren til en domenekontroller, maskinen ble koblet til Internett, og deretter Windows-kontakter den første tilgjengelige Internet root navnetjenere og laster ned en liste over alle Internet root navnetjenere, som blir sin liste over root hint
    . I så fall navn oppløsning nå fortsetter som følger:
  • SRV220 sender en iterativ spørring til den første tilgjengelige Internet root navnetjener, som svarer med IP-adressen til en navnetjener autoritativ for .com topp- domenet.
  • SRV220 sender en andre iterativ spørring til navnet serveren autoritative for .com, og denne maskinen svarer med IP-adressen til en navnetjener autoritativt for domenet google.com.
  • SRV220 sender en tredje iterativ spørring til navnet serveren autoritative for google.com, og denne maskinen svarer med IP-adressen til verten heter www.google.com.
  • SRV220 returnerer IP-adressen til www.google.com til DESK231 og Bob ser Google-hjemmesiden vises i nettleseren sin.

    Nå det er mange av trinnene, og om selskapet har en langsom WAN-kobling til Internett da du bruker verdifull båndbredde. En bedre tilnærming enn å "gå opp til root" for å løse www.google.com ville være å konfigurere en speditør. En forwarder
    er en navneserver som håndterer navnespørringer som ikke kan løses med et annet navn server. La oss se hvordan de ovennevnte scenario fungerer når en speditør er konfigurert på det interne navnet serveren SRV210:

  • DESK231 sender en recusrive spørring til SRV220 ber om å løse www.google.com til den tilknyttede IP-adresse.
  • SRV220 ser i sin DNS database og finner soneinformasjon bare for test2003.local domene, innser www.google.com er ikke en del av dette domenet, bestemmer det har ingen måte å vite hvordan du løser www.google.com inn en IP-adresse, og kontrollerer sin liste over bærere for å se om noen bærere er konfigurert for det.
  • På lass liste det finner IP-adressen til den eksterne navnetjener hostet av selskapets Internet Service Provider, så det videresender forespørselen til ISP navn server for å håndtere.
  • ISP navn server går opp til root etter behov (som kan involvere to eller flere spørringer) å løse www.google.com inn IP-adressen og returnerer denne adressen til SRV220.
  • SRV220 returnerer adressen til Bob og han ser Google vises i nettleseren sin.

    Merk at denne prosedyren tar omtrent samme antall skritt som før, men de fleste av disse trinnene er utført offsite av ISP navn server, slik at mengden av båndbredden som brukes over Internett tilkobling er betydelig mindre og behandlingsbelastningen på det interne navneserveren SRV220 minimaliseres også. Og dette er gode ting fra en administrator perspektiv. Selvfølgelig, hvis speditøren ikke svarer innen tidsavbruddet konfigurert, serveren kan enten prøve en annen speditør (hvis konfigurert) eller bruke root hint (hvis tilgjengelig), eller gi opp og returnere en feil.

    På Windows 2000, blir videresending konfigureres ved hjelp av kategorien Generelt i DNS-serverens egenskaper ark i DNS-konsollen:


    Hva er annerledes i Windows Server 2003 er begrepet betinget
    videresending, som jeg skal se på neste.

    Hva Betinget Forwarding Betyr

    En betinget forwarder er en som håndterer navneløsing bare for et bestemt domene. For eksempel kan du konfigurere navnetjener for å videresende forespørsler for verter i domenet google.com direkte til et bestemt navn server som er autoritativ for google.com-domenet. Hva dette er hastigheten på navneløsing prosessen ved å eliminere behovet for å gå opp til roten for å finne dette autoritativ server. I dette tilfellet vår forrige eksempel ville nå se slik ut:

  • DESK231 sender en recusrive spørring til SRV220 ber om å løse www.google.com til den tilknyttede IP-adresse.
  • SRV220 ser i sin DNS database og finner soneinformasjon bare for test2003.local domene, innser www.google.com er ikke en del av dette domenet, bestemmer det har ingen måte å vite hvordan du løser www.google.com inn en IP-adresse, og kontrollerer sin liste over bærere for å se om noen bærere er konfigurert for det.
  • På lass liste det finner en betinget speditør konfigurert, som spesifiserer IP-adressen til en autoritativ navnetjener for domenet google.com, så det videresender forespørselen til denne navnetjener for å håndtere det.
  • The google.com navnetjener løser umiddelbart www.google.com inn IP-adressen uten behov for å gå opp til rot og returnerer denne adressen til SRV220.
  • SRV220 returnerer adressen til Bob og Google viser raskt opp i nettleseren sin, spørre Bob å si: "Hei, sikkert er nettverket fort i dag!"

    La oss nå se hvordan du konfigurerer dette i Windows Server 2003 DNS.

    Slik konfigurerer Betinget Forwarding

    Først la oss finne en navnetjener autoritativ for google. com-domenet. For å gjøre dette vil vi bruke WHOIS-oppslag verktøyet på Network hjemmeside http://www.networksolutions.com/en_US/whois/index.jhtml. Gå til denne siden, skriver google.com inn i WHOIS søkeboksen, skriver du inn koden vises (en funksjon som hindrer masse oppslag ved automatiserte programmer), og følgende resultater vises:

    google.com Anmeldelser

    Whois Server versjon 1.

    Domenenavn i .com og .net-domener kan nå være registrert
    med mange forskjellige konkurrerende registrarer. Gå til http://www.internic.net
    for detaljert informasjon

    Domain Name:. GOOGLE.COM
    Registrar:. ALLDOMAINS.COM INC
    Whois Server: whois.alldomains. com
    Referral URL: http://www.alldomains.com
    Name Server: NS2.GOOGLE.COM
    Name Server: NS1.GOOGLE.COM
    Name Server: NS3.GOOGLE.COM < BR> Name Server: NS4.GOOGLE.COM
    Status: REGISTRAR-LOCK
    Oppdatert Dato: 03-Oct-2002
    Creation Date: 15-sep-1997
    Utløpsdato: 14-sep- 2011

    La oss finne ut IP-adressen til navnetjener NS1.GOOGLE.COM hjelp ping:

    Nå som vi har IP-adressen til en av navnetjenerne autoritative for google .com-domenet, kan vi konfigurere Windows Server 2003 DNS til betinget frem alle navnespørringer for dette domenet til dette navnet server.

    For å konfigurere betinget videresending, åpne DNS-konsollen i henhold til Administrative verktøy, høyreklikker du på DNS-serveren node, velg Egenskaper for å åpne egenskapsarket for DNS-serveren, og velg fanen Forwarding:
    < P>

    Hvis du sammenligner dette til forrige tall for Windows 2000 DNS ovenfor, vil du se noen forskjeller. Først, hvis du bare ønsker å konfigurere en vanlig speditør her, la "Alle andre DNS-domener" valgt i DNS-domene listeboksen, skriv inn IP-adressen til forwarder (vanligvis adressen til din ISP navn server) i den stiplede boksen, og Klikk på Legg til. Hvis du vil legge til en betinget
    forwarder imidlertid gjøre følgende. Først klikker på Ny-knappen, og skriv inn navnet på domenet du vil at navnet serveren til betinget frem til:


    Klikk OK og det nye domenet vises øverst i listeboksen (sørg for at det er valgt for neste trinn):

    Nå skriver du inn IP-adressen til betinget forwarder i den stiplede boksen og klikk på Legg til legge den til den valgte domenet bærere liste:


    Klikk OK for å bruke endringene og lukke egenskaper arket og du er ferdig. Nå navnespørringer for google.com domene som er utstedt mot navnet serveren blir videresendt direkte til navnetjener for domenet google.com å løse.

    Bruke betinget Forwarding

    Når kan det være lurt å bruke betinget videresending i den virkelige verden? Jeg kan tenke på flere situasjoner der det kan være nyttig:


      For å bedre navneløsing mellom to separate selskaper som trenger å gi sine brukere med tilgang til ressurser i den andre bedriftens intranett. Denne typen situasjon er vanlig i en fusjon situasjon eller mellom forsyningskjeden partnere. Bare sette opp DNS-servere i hvert selskap å videresende navne forespørsler om ressurser i den andre bedriftens nettverk direkte til IP-adressene til navnetjenere i det andre selskapet, og du er ferdig. Selvfølgelig, dette kan også gjøres ved hjelp av stubb soner som jeg omtalt i min forrige artikkel DNS Stub Zones i Windows Server 2003 Anmeldelser og jeg skal sammenligne de to tilnærmingene i et øyeblikk.
    • For å forbedre navneløsing innenfor et Active Directory implementering som har en usammenhengende navnerom (separate skog eller flere domenenavn trær) eller en dyp hierarki av underdomener. I en slik situasjon kan du sette opp betinget videresending slik at brukerne i ett domene kan unngå å måtte gå hele veien til roten å finne ressurser i egen skog, et annet domene tre, eller helt ned domenehierarkiet i et tre. Igjen, kan aksel soner også brukes for dette formål, om ønskelig.
    • Og så er det å bruke det bare å videresende navnespørringer for spesifikke nettsteder som google.com som i eksempelet ovenfor, men som eksempel var ment kun å være illustrerende for prosedyren for å konfigurere betinget videresending på ditt navn server - min Selskapet har ingen planer om sammenslåing med Google når som helst snart.

      Sammendrag

      Til slutt, er det noe du må passe deg for om du bruker betinget videresending? To ting kommer til hjernen Først er betinget videresending egnet hvis du har å gjøre med en fast DNS-infrastruktur. Det betyr at i en fusjon eller supply-chain scenario må du være sikker på at det andre selskapet ikke planer om å endre sin DNS infrastruktur ved å avvikle gamle navnetjenere, distribuere nye, eller endre IP-adressene til eksisterende. Hvis de endrer sin infrastruktur og ikke informere deg om dette, så din navnetjener kan plutselig finne seg selv videresending spørringer til ikke-eksisterende navnetjenere som resulterer i mislykkede navnespørringer og frustrerte brukere flom help desk med samtaler. I så fall kan det være bedre å opprette stub soner på navnetjenere for soner for hvor andre selskapets navneservere er autoritativ. Det er fordi stubbsonene automatisk oppdatere seg med dagens liste over navnetjenere i sonen mens du konfigurerer videresending er en prosess som må gjøres manuelt. Samme i en stor bedrift som har en kompleks Active Directory-skogen - hvis du ikke er sikker på at ledere i andre avdelinger i selskapet kommer til å fortelle deg på forhånd når de endrer sine DNS-infrastrukturer, ikke iverksette betinget forwarding- -Bruk stubb soner i stedet.

      Det andre forbeholdet om betinget videresending er ikke å få til båret bort implementere det. Du tenker kanskje du kan forbedre navneoppslag for brukerne ved å legge til flere titalls bærere for de mest populære nettsteder de bruker for arbeid formål, men dette kan være en dårlig idé. Årsaken er, når du har en lang liste med betinget videresending konfigurert, har navnet ditt serveren for å gå gjennom hele listen til det enten finner domenet spurt eller ikke klarer å finne det, i så fall standard videresending brukes (hvis konfigurert), etter som root hint er prøvd og standard rekursjon ansatt. Resultatet av dette er at navnet serveren har til å utføre ekstra behandling for å gå gjennom de lass liste hver gang en spørring er mottatt, og i tillegg til å øke CPU belastningen på serveren din dette kan også resultere i tregere Anmeldelser Navnet løsning istedenfor raskere på grunn av tiden det tar å behandle en spesielt lang liste. Og hvis forwarder i seg selv er også en del av din egen
      selskapets DNS-infrastruktur da være klar over at den ekstra belastningen av å motta videresendte forespørsler fra andre navnetjenere og utføre rekursive spørringer for å løse dem betyr at bærere vil oppleve spesielt tung CPU utnyttelse og må kanskje ha sin hardware styrket betraktelig for å håndtere det. Så hvis du har planer om å bruke betinget videresending, særlig innenfor din egen bedrift, sørg for å bruke det kun der det virkelig gjør en forskjell og bruk den med måte.