DNS vurderinger i et Windows miljø med identiske internt og eksternt domene navn

Beste praksis for bruk av Active Directory (AD)-domene design råd til å bruke et registrert domene navn som navnet på et AD-domene. Aktuell alternativer inkluderer bruk av et ikke-offentlig DNS suffiks (. lokalt eller . LAN, for eksempel) i AD-domenenavnet, eller for å gjøre ad-domenet til et under domene på det registrerte domenet (Corp.domain.com, for eksempel).

Du vil ikke alltid ha noe valg i noen tilfeller, men. Du kan ha støtte for et AD-domene som har samme navn som firmaets registrerte domene, og det er mulig at administrasjonen ikke ønsker å endre navnet. Dette kalles et delings DNS (eller delt hjerne DNS)-scenario der det finnes to forskjellige DNS-navne områder – det interne navne området som brukes av ad, og det eksterne navne området som brukes av felles domene registr-med samme navn. Dette scenariet kan vise noen unike utfordringer. Denne artikkelen diskuterer noen vanlige problemer som oppstår fra et delt DNS miljø, og hva du kan gjøre for å redusere dem.

I alle eksemplene nedenfor, heter AD Domain og registrert domene begge domain.com, og det er et firma nettsted som heter www.domain.com.

Problem 1: Eksternt nettsted som er vert for selskapet, ikke tilgjengelig på innsiden av kontoret
Dette er det mest vanlige problemet i et delt DNS miljø: selskapets nettsted, eller en annen bedrifts eide, Internet t-tilkoblet ressurs, kan ikke nås fra kontoret på maskiner som er koblet til AD-domenet, men maskiner utenfor Office har ingen problemer med nett staden. Grunnen til dette skjer, kan vises ved å undersøke hva som skjer når en intern bruker prøver å surfe på Netts IDen til firmaet:

1. Brukerens data maskin spør på domenets DNS server, vanligvis en domene kontroller (DC), for IP-adressen til www.domain.com.
2. DC-vertene er en videre oppslags sone kalt domain.com, slik at den ser ut i den sonen for en verts oppføring som kalles www.
3. DC finner ingen verts post med navnet www, og fordi den er autoritativ for domain.com -sonen, vil den ikke spørre etter noen andre DNS-servere.
4. DC svarer på brukerens data maskin, og sier at den ikke kunne finne en adresse for www.domain.com.
5. Nett leseren på brukerens data maskin viser at siden ikke kan vises.

Problemet oppstår fordi en DNS server som har en bestemt oppslags sone i databasen – domain.com -sonen i dette eksemplet-sender ikke spørringer for poster i den sonen andre steder. det returnerer ganske enkelt et svar som ikke ble funnet, hvis det ikke er noen post som Sams varer med en gitt forespørsel. I dette eksemplet er det en annen DNS server med riktig post: DNS-serveren som er vert for den offentlige domain.com -sonen som tilhører domene registreren, som er evident av det faktum at maskiner utenfor Office kan nå nett staden. Spørringer fra interne maskiner kommer aldri frem til denne serveren.

Løsningen på dette problemet er enkelt: opprette en verts oppføring med navnet www i domain.com -sonen på DC, og gi den en oversikt over IP-adressen til Netts IDen. Maskiner som spør på at DNS server deretter mottar riktig svar og kan surfe på Netts IDen.

Problem 2: Internt felles nettsted som ikke er tilgjengelig inne fra kontoret
Dette kan anses som en variant av problem 1 ovenfor. Forskjellen i dette tilfellet er at nett staden er vert for internt, enten bak en brann mur på firmaets interne nettverk eller i en DMZ. Den skal være tilgjengelig både for interne og eksterne brukere, men interne brukere er ikke i stand til å nå den, mens eksterne brukere ikke rapporterer noen problemer.

Årsaken til problemet er omtrent det som er i problem 1, men interne brukere i dette tilfellet kan løse nett navnet på nettstedet til den offentlige IP-adressen. De har imidlertid fortsatt ikke tilgang til nettstedet på grunn av måten brann muren er konfigurert på. Det forventer brukere på det interne nettverket for å få tilgang til Netts IDen ved hjelp av privat adressen i stedet for den offentlige adressen.

På nytt er det en enkel løsning: Opprett en verts oppføring med navnet www i domain.com -sonen på DC, men dette tidspunktet gir en post til den private IP-adressen til Netts IDen. Interne maskiner løser navnet på nett staden med den private adressen, mens eksterne maskiner fortsetter å løse navnet til nettstedets offentlige adresse.

Problem 3: Det er ikke nok å laste inn Netts IDene etter at du har gjort
de oven stående endringene Dette kan skje hvis steds koden omadresserer nett lesere fra www.domain.com til domain.com eller hvis interne koblinger refererer til stedet som domain.com , i stedet for www.domain.com. De samme symptomene ses på interne maskiner uansett om stedet er på et internt eller eksternt sted:

• Det kan hende at stedet ikke lastes i det hele tatt, og i så fall viser brukerens nett leser vanligvis domain.com i adresse feltet, selv om brukeren skriver www.domain.com inn i nett leseren.
• Det kan hende at stedet ikke lastes inn på nytt. deler av området kan ikke vises og/eller koblinger på stedet vil kanskje ikke fungere.
• I begge tilfeller er eksterne brukere i stand til å få tilgang til Netts IDen uten problemer.

Problemet i dette tilfellet er litt mer komplekst. For at maskiner skal kunne løse domain.com til en IP-adresse, må det være en tom verts post i domain.com -sonen i DNS. Navnet på denne oppføringen vises som (samme som overordnet mappe) i Windows DNS-konsollen. Det er imidlertid et problem i dette tilfellet: AD bruker tomme verts poster i domain.com -sonen for å representere DCs for domain.com -domenet. Domene medlemmer bruker disse postene når de søker etter en DC for godkjenning, og hvis det er ekstra tomme verts poster i domain.com -sonen, kan det oppstå forsinkelser eller godkjennings problemer.

Grunnen til at dette problemet ikke kan løses i DNS alene. Å opprette en tom verts oppføring med nettstedets IP-adresse, løser bare nett leser problemer for interne brukere, fordi det allerede finnes andre blanke oppføringer med IP-adressene til domene kontrollerne i domenet, og dette fører til at det oppstår problemer med domene godkjenningen.

Den enkleste måten å løse problemet på er å endre nettstedets kode for å fjerne omadresseringen eller løse de interne koblingene, slik at alt viser til stedet som www.domain.com i stedet for domain.com. Hvis det ikke er mulig å endre koden, kan du gi nytt navn til AD-domenet når du skal løse problemet. Dette kan være en komplisert oppgave, avhengig av størrelsen og kompleksiteten på miljøet.