Metod tips för Active Directory (AD) Domain design Advise mot att du använder ett registrerat domän namn som namn på en AD-domän. Livskraftiga alternativ innefattar att använda ett icke-offentligt DNSt suffix (. local eller . LAN) i AD-DOMÄNNAMNet eller göra AD-domänen till en under domän till den registrerade domänen (t. ex.Corp.domain.com).
Du har inte alltid ett val i frågan, även om; Du kan hitta dig själv som har stöd för en AD-domän som har samma namn som företagets registrerade domän, och det kanske inte vill ändra något namn. Detta kallas för ett delat DNS (eller delat-hjärna DNS), där det finns två distinkta DNS namn områden – det interna namn området som används av AD och det externa namn området som används av offentlig domän registrator-med samma namn. Detta scenario kan ge några unika utmaningar. I den här artikeln beskrivs några vanliga problem som uppstår i samband med en delad DNS miljö och vad som kan göras för att mildra dem.
I alla exemplen nedan finns både AD-domänen och den registrerade domänen båda namngivna Domain.com, och det finns en företags webbplats som heter www.domain.com.
Problem 1: Externt värdbaserad företags webbplats är oåtkomlig från insidan av kontoret
Det här är det vanligaste problemet i en delnings DNS miljö: företagets webbplats eller någon annan företagsspecifik Internet-ansluten resurs kan inte nås från insidan av kontoret av maskiner som är anslutna till AD-domänen, men maskiner utanför kontoret har inga problem med att nå webbplatsen. Orsaken till detta kan visas genom att undersöka vad som händer när en intern användare försöker att gå till företagets webbplats:
Problemet uppstår på grund av att en DNS server med en viss söknings zon i databasen – Domain.com Zone i det här exemplet-inte skickar frågor för poster i den zonen någon annan stans; det returnerar bara ett svar som "not found" om det inte finns någon post som matchar en viss fråga. I det här exemplet finns det en annan DNS-server med rätt post: DNS-servern som är värd för den offentliga Domain.com -zon som tillhör domän registratorn, vilket tydligt framgår av det faktum att maskiner utanför kontoret kan nå webbplatsen. Frågor från interna maskiner når aldrig den servern trots detta.
Lösningen på det här problemet är enkel: skapa en värd post med namnet www i Domain.com -zonen på DC och ge den posten på webbplatsens IP-adress. Maskiner som frågar DNS servern får rätt svar och kan bläddra på webbplatsen.
Problem 2: Intern webbplats som värd är oåtkomlig från insidan av kontoret
Detta kan anses vara en variant av problem 1 ovan. Skillnaden i detta fall är att webbplatsen är värdbaserad internt, antingen bakom en brand vägg i företagets interna nätverk eller i en DMZ. Det ska vara åtkomligt för både interna och externa användare, men interna användare kan inte nå det, medan externa användare inte rapporterar några problem.
Orsaken till problemet liknar den i problem 1, men interna användare i detta fall kan lösa webbplatsens namn på dess offentliga IP-adress på rätt sätt. Men de kan fortfarande inte nå webbplatsen på grund av sättet som brand väggen kon figurer ATS på. Det förväntar sig att användare i det interna nätverket kommer åt webbplatsen via dess privata adress i stället för dess offentliga adress.
Det finns en enkel lösning: skapa en värd post med namnet www i Domain.com -zonen på DC, men den här gången ger posten på webbplatsen den privata IP-adressen. Interna maskiner matchar webbplatsens namn på den privata adressen, medan externa maskiner fortsätter att matcha namnet till webbplatsens offentliga adress.
Problem 3: Webbplatsen läses in i eller fortfarande inte in efter att ovanstående ändringar har gjorts
Detta kan inträffa om webbplats koden omdirigerar webbläsare från www.domain.com till Domain.com eller om interna länkar hänvisar till platsen som Domain.com snarare än www.domain.com. Samma symptom visas på interna maskiner oavsett om webbplatsen är värdbaserad internt eller externt:
Problemet i detta fall är lite mer komplicerat. För att maskiner ska kunna lösa Domain.com till en IP-adress måste det finnas en tom värd post i Domain.com -zonen i DNS. Namnet på den här posten visas som (samma som överordnad mapp) i Windows DNS-konsolen. Det finns dock ett problem i detta fall: AD använder tomma värd poster i Domain.com -zonen för att representera DCs för Domain.com -domänen. Domän medlemmar använder dessa poster när de lokaliserar en DOMÄNKONTROLLANT för autentisering, och om det finns extra tomma värd poster i Domain.com -zonen kan det uppstå förseningar eller autentiseringsproblem.
Orsaken ovan innebär att problemet inte kan lösas i DNS ensamma. Om du skapar en tom värd post med webbplatsens IP-adress kan du bara lösa problemet på webbplats åtkomsten för interna användare, eftersom det redan finns andra tomma värd poster med IP-adresserna till DCs i domänen och detta orsakar problem med domänautentisering.
Det enklaste sättet att lösa problemet är att ändra webbplatsens kod så att du antingen tar bort omdirigeringen eller korrigerar de interna länkarna så att allt hänvisar till platsen som www.domain.com snarare än Domain.com. Om det inte går 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 komplicerad uppgift, beroende på storleken och komplexiteten på miljön.