PowerEdge: Webbplatsen kan inte nås i en Windows-miljö med identiska interna och externa domännamn

I alla exempel nedan heter både AD-domänen och den registrerade domänen domain.com, och det finns en företagswebbplats med namnet www.domain.com. De identiska domännamnen skapar en delad (eller split-brain) DNS-miljö. I det här fallet har de interna och externa DNS-namnrymderna samma namn men är separata.

Problem 1: En extern företagswebbplats är inte tillgänglig inifrån kontoret.
Det här är det vanligaste problemet i en delad DNS-miljö. Företagets webbplats, eller en annan företagsägd, internetansluten resurs, kan inte nås inifrån kontoret av domänanslutna kunder. Maskiner utanför kontoret har inga problem att nå webbplatsen.

Problem 2: En internt värdbaserad offentlig webbplats är inte tillgänglig inifrån kontoret.
Detta är en variant av nummer 1 ovan. Skillnaden är att webbplatsen ligger internt, antingen bakom en brandvägg på företagets interna nätverk eller i en DMZ. Den ska vara tillgänglig för både interna och externa användare, men interna användare kan inte nå den. Externa användare rapporterar inga problem.

Problem 3: Webbplatsen laddas ofullständigt eller kommer inte att laddas efter att problem 1 eller 2 har åtgärdats.
Webbplatsen kanske inte laddas alls eller kan laddas ofullständigt för interna användare. Delar av webbplatsen kanske inte visas och länkar på webbplatsen kanske inte fungerar. Externa användare kan komma åt webbplatsen utan problem.

Problem 1: En extern företagswebbplats är inte tillgänglig inifrån kontoret.

Orsaken till detta kan visas genom att undersöka vad som händer när en intern användare försöker surfa på företagets webbplats:

1. Användarens dator frågar domänens DNS-server, vanligtvis en domänkontrollant (DC), efter IP-adressen för www.domain.com.
2. Domänkontrollanten är värd för en zon för vanlig sökning med namnet domain.com, så den söker i den zonen efter en värdpost med namnet www.
3. Domänkontrollanten hittar ingen värdpost med namnet www, och eftersom den är auktoritativ för domain.com vidarebefordrar den inte frågan.
4. Domänkontrollanten svarar användarens dator och säger att den inte kunde hitta en adress för www.domain.com.
5. Webbläsaren på användarens dator visar "Sidan kan inte visas" eller ett liknande fel.

Problemet uppstår eftersom en auktoritativ DNS-server inte skickar frågor om namn i sina zoner till andra DNS-servrar. Den returnerar svaret "hittades inte" om det inte finns någon post som matchar en viss fråga. I det här exemplet finns det andra DNS-servrar med rätt post: de DNS-servrar som är värdar för den offentliga domain.com zon. Detta framgår av det faktum att maskiner utanför kontoret kan nå webbplatsen. Frågor från interna datorer skickas dock inte till den servern.

Problem 2: En internt värdbaserad offentlig webbplats är inte tillgänglig inifrån kontoret.
Orsaken till problemet liknar den i fråga 1. Interna användare kan i det här fallet korrekt matcha webbplatsens namn till dess offentliga IP-adress. De kan dock fortfarande inte nå webbplatsen på grund av hur brandväggen är konfigurerad. Den förväntar sig att användare i det interna nätverket ska komma åt webbplatsen med hjälp av dess privata adress snarare än dess offentliga adress.

Problem 3: Webbplatsen laddas ofullständigt eller kommer inte att laddas efter att problem 1 eller 2 har åtgärdats.
Detta kan hända om webbplatskoden omdirigerar webbläsare från www.domain.com till domain.com. Interna länkar kan också hänvisa till webbplatsen som domain.com i stället för www.domain.com. Samma symptom visas på interna datorer oavsett om webbplatsen finns internt eller externt.

Frågan i det här fallet är lite mer komplicerad. För att maskiner ska kunna lösa domain.com till en IP-adress måste det finnas en tom värdpost i domain.com zon i DNS. Namnet på den här posten visas som (samma som den överordnade mappen) i Windows DNS-konsolen. AD använder dock tomma värdposter i domain.com zon för att representera domänkontrollanter för domain.com domän. Om det finns extra tomma värdposter i domain.com kan det uppstå fördröjningar eller autentiseringsproblem.

Av ovanstående skäl kan det här problemet inte lösas med enbart DNS. Om du skapar en tom värdpost med webbplatsens IP-adress löses endast tillfälligt problemet med webbplatsåtkomst för interna användare. De befintliga tomma värdposterna som refererar till domänkontrollanter stör detta på grund av DNS-funktionen för resursallokering. Eftersom dessa poster registreras automatiskt av domänkontrollanterna visas de regelbundet om de tas bort från DNS-zonen.
 

Problem 1: En extern företagswebbplats är inte tillgänglig inifrån kontoret.
Lösningen på detta problem är enkel. Skapa en värdpost (A) med namnet www i domain.com-zonen på domänkontrollanten och ge den posten webbplatsens IP-adress. Datorer som frågar DNS-servern får sedan rätt svar och kan surfa på webbplatsen.

Problem 2: En internt värdbaserad offentlig webbplats är inte tillgänglig inifrån kontoret.
Det finns en enkel lösning på detta också. Skapa en värdpost med namnet www i domain.com-zonen på domänkontrollanten, men ge posten webbplatsens privata IP-adress. Interna maskiner matchar webbplatsens namn till den privata adressen, medan externa datorer fortsätter att matcha namnet till webbplatsens offentliga adress.

Problem 3: Webbplatsen laddas ofullständigt eller kommer inte att laddas efter att problem 1 eller 2 har åtgärdats.
Det enklaste sättet att lösa det här problemet är att ändra webbplatsens kod för att ta bort omdirigeringen. Interna länkar bör också hänvisa till webbplatsen som www.domain.com snarare än domain.com. Om det inte är möjligt att ändra koden är det enda andra alternativet för att lösa problemet att byta namn på AD-domänen. Detta kan vara en komplex uppgift, beroende på miljöns storlek och komplexitet.

Not: Webbplatsen måste nås med namnet www.domain.com i alla dessa exempel. Komma åt webbplatsen med hjälp av namnet domain.com fungerar inte eller fungerar bara intermittent.

Bästa praxis för AD-domändesign (Active Directory) avråder från att använda ett registrerat domännamn som namn på en AD-domän. Det finns två föreslagna alternativ till detta:

• Använd ett icke-offentligt DNS-suffix (.local eller .lan, till exempel) i AD-domännamnet.
• Gör AD-domänen till en underdomän till den registrerade domänen (corp.domain.com, till exempel).

Detta är endast möjligt om AD-domänen inte redan har skapats eller om en namnbytesoperation pågår.