PowerEdge: Webstedet kan ikke nås i et Windows-miljø med identiske interne og eksterne domænenavne

I alle eksemplerne nedenfor er AD-domænet og det registrerede domæne begge navngivet domain.com, og der er et virksomhedswebsted med navnet www.domain.com. De identiske domænenavne skaber et delt (eller split-brain) DNS-miljø. I denne situation har de interne og eksterne DNS-navneområder samme navn, men er adskilte.

Udgave 1: Et eksternt hostet firmawebsted er utilgængeligt inde fra kontoret.
Dette er det mest almindelige problem i et opdelt DNS-miljø. Virksomhedens websted eller en anden virksomhedsejet, internetforbundet ressource kan ikke nås inde fra kontoret af domænetilknyttede klienter. Maskiner uden for kontoret har ingen problemer med at nå hjemmesiden.

Problem 2: Et internt hostet offentligt websted er utilgængeligt inde fra kontoret.
Dette er en variation af udgave 1 ovenfor. Forskellen er, at hjemmesiden hostes internt, enten bag en firewall på virksomhedens interne netværk eller i en DMZ. Det formodes at være tilgængeligt for både interne og eksterne brugere, men interne brugere kan ikke nå det. Eksterne brugere rapporterer ingen problemer.

Nr. 3: Webstedet indlæses ufuldstændigt eller indlæses ikke, når problem 1 eller 2 er løst.
Webstedet indlæses muligvis slet ikke eller kan indlæses ufuldstændigt for interne brugere. Dele af webstedet vises muligvis ikke, og links på webstedet fungerer muligvis ikke. Eksterne brugere kan få adgang til webstedet uden problemer.

Problem 1: Et eksternt hostet firmawebsted er utilgængeligt inde fra kontoret.

Årsagen til, at dette sker, kan vises ved at undersøge, hvad der sker, når en intern bruger forsøger at gennemse virksomhedens websted:

1. Brugerens computer forespørger domænets DNS-server, typisk en domænecontroller (DC), om IP-adressen på www.domain.com.
2. DC er vært for en fremadrettet opslagszone med navnet domain.com, så den søger i denne zone efter en værtspost med navnet www.
3. DC finder ingen værtspost navngivet www, og da det er autoritativt for domain.com zone, videresender den ikke forespørgslen.
4. DC reagerer på brugerens computer og siger, at den ikke kunne finde en adresse til www.domain.com.
5. Browseren på brugerens computer viser "Siden kan ikke vises" eller en lignende fejl.

Problemet opstår, fordi en autoritativ DNS-server ikke sender forespørgsler efter navne i sine zoner til andre DNS-servere. Det returnerer svaret "ikke fundet", hvis der ikke er nogen post, der matcher en given forespørgsel. I dette eksempel er der andre DNS-servere med den korrekte post: de DNS-servere, der er vært for offentligheden domain.com zone. Dette fremgår af det faktum, at maskiner uden for kontoret kan nå hjemmesiden. Forespørgsler fra interne maskiner sendes dog ikke til den pågældende server.

Nr. 2: Et internt hostet offentligt websted er utilgængeligt inde fra kontoret.
Årsagen til problemet ligner den i udgave 1. Interne brugere kan i dette tilfælde korrekt fortolke webstedets navn til dets offentlige IP-adresse. De kan dog stadig ikke nå webstedet på grund af den måde, firewallen er konfigureret på. Den forventer, at brugerne på det interne netværk får adgang til webstedet ved hjælp af dens private adresse i stedet for dens offentlige adresse.

Nr. 3: Webstedet indlæses ufuldstændigt eller indlæses ikke, når problem 1 eller 2 er løst.
Dette kan ske, hvis webstedskoden omdirigerer browsere fra www.domain.com til domain.com. Interne links kan også henvise til webstedet som domain.com i stedet for www.domain.com. De samme symptomer ses på interne maskiner, uanset om webstedet hostes internt eller eksternt.

Spørgsmålet i dette tilfælde er lidt mere komplekst. For at maskiner kan løse domain.com til en IP-adresse, skal der være en tom værtspost i domain.com zone i DNS. Navnet på denne post vises som (samme som den overordnede mappe) i Windows DNS-konsollen. AD bruger dog tomme værtsposter i domain.com zone til at repræsentere DC'er for domain.com domæne. Hvis der er ekstra tomme værtsposter i domain.com Zone, forsinkelser eller godkendelsesproblemer kan resultere.

Af ovenstående årsager kan dette problem ikke løses ved hjælp af DNS alene. Oprettelse af en tom værtspost med webstedets IP-adresse løser kun periodisk problemet med webstedsadgang for interne brugere. De eksisterende tomme værtsposter, der henviser til DC'er, forstyrrer dette på grund af round robin DNS-funktionalitet. Da disse poster automatisk registreres af DC'erne, vises de regelmæssigt igen, hvis de fjernes fra DNS-zonen.
 

Problem 1: Et eksternt hostet firmawebsted er utilgængeligt inde fra kontoret.
Løsningen på dette problem er enkel. Opret en værtspost (A) med navnet www i domain.com-zonen på DC, og giv denne post webstedets IP-adresse. Maskiner, der forespørger på den DNS-server, modtager derefter det korrekte svar og kan gennemse webstedet.

Nr. 2: Et internt hostet offentligt websted er utilgængeligt inde fra kontoret.
Der er også en simpel løsning på dette. Opret en værtspost med navnet www i domain.com-zonen på DC, men giv posten webstedets private IP-adresse. Interne maskiner oversætter webstedets navn til den private adresse, mens eksterne maskiner fortsætter med at fortolke navnet til webstedets offentlige adresse.

Nr. 3: Webstedet indlæses ufuldstændigt eller indlæses ikke, når problem 1 eller 2 er løst.
Den enkleste måde at løse dette problem på er at ændre webstedets kode for at fjerne omdirigeringen. Interne links skal også henvise til webstedet som www.domain.com snarere end domain.com. Hvis det ikke er muligt at ændre koden, er den eneste anden mulighed for at løse problemet at omdøbe AD-domænet. Dette kan være en kompleks opgave, afhængigt af miljøets størrelse og kompleksitet.

Seddel: Hjemmesiden skal tilgås ved hjælp af navnet www.domain.com i alle disse eksempler. Adgang til webstedet ved hjælp af navnet domain.com virker ikke eller fungerer kun intermitterende.

Bedste fremgangsmåder for Active Directory-domænedesign (AD) fraråder at bruge et registreret domænenavn som navnet på et AD-domæne. Der er to foreslåede alternativer til dette:

• Brug et ikke-offentligt DNS-suffiks (.local eller .lan, for eksempel) i AD-domænenavnet.
• Gør AD-domænet til et underdomæne til det registrerede domæne (corp.domain.com, for eksempel).

Dette er kun muligt, hvis AD-domænet ikke allerede er oprettet, eller hvis en omdøbningshandling er i gang.