Aanbevolen procedures voor Active Directory (AD) domein ontwerp adviseren tegen het gebruik van een geregistreerde domeinnaam als de naam van een AD-domein. Levensvatbare alternatieven zijn onder andere het gebruik van een niet-openbaar DNS achtervoegsel (. local of . LAN, bijvoorbeeld) in de naam van het AD-domein, of het maken van het AD-domein een subdomein van het geregistreerde domein (bijvoorbeeldCorp.domain.com).
U hoeft niet altijd zelf een keuze te hebben, hoewel; het is mogelijk dat u een AD-domein krijgt dat dezelfde naam heeft als het geregistreerde domein van het bedrijf en dat het management een andere naam niet wil wijzigen. Dit wordt een gesplitste DNS -scenario (of gesplitste hersenen DNS) genoemd, waarbij twee verschillende DNS naamruimten-de interne naamruimte die door AD wordt gebruikt, en de externe naamruimte die door de openbare domeinregistratieservice wordt gebruikt-met dezelfde naam. Dit scenario kan enkele unieke problemen opleggen. In dit artikel worden enkele veelvoorkomende problemen beschreven die voortkomen uit een gesplitste DNS omgeving en wat u kunt doen om ze te beperken.
In alle onderstaande voorbeelden hebben het AD-domein en het geregistreerde domein beide de naam Domain.comen is er een bedrijfswebsite met de naam www.domain.com.
Probleem 1: Extern gehoste bedrijfswebsite die niet toegankelijk is binnen het kantoor
Dit is het meest voorkomende probleem in een gesplitste DNS omgeving: de website van het bedrijf of een andere, internetverbinding met een ander bedrijf, kan niet binnen het kantoor worden bereikt door computers die zijn toegevoegd aan het AD-domein, maar computers buiten het kantoor hebben geen problemen op de website. De reden hiervoor kan worden weergegeven door te onderzoeken wat er gebeurt wanneer een interne gebruiker probeert door te bladeren door de website van het bedrijf:
Het probleem doet zich voor omdat een DNS-server met een bepaalde opzoek zone in de database-de Domain.com -zone in dit voorbeeld geen query's verzendt voor records in die zone overal anders; het resultaat is alleen een "not found"-antwoord als er geen record overeenkomt met een bepaalde zoekopdracht. In dit voorbeeld is er een andere DNS server met de juiste record: de DNS-server die als host fungeert voor de openbare Domain.com zone die deel uitmaakt van de domeinregistratie, zoals blijkt uit het feit dat computers buiten het kantoor de website kunnen bereiken. Bij query's van interne computers wordt die server nooit bereikt, hoewel.
De oplossing voor dit probleem is eenvoudig: Maak een host-record met de naam www in de Domain.com -zone op de DC en geef die record het IP-adres van de website. Machines die vragen dat DNS server de juiste respons ontvangt en op de website kunt bladeren.
Probleem 2: Intern gehoste openbare website die niet toegankelijk is binnen het kantoor
Dit kan worden beschouwd als een variant van probleem 1 hierboven. Het verschil in dit geval is dat de website intern wordt gehost, hetzij achter een firewall op het interne netwerk van het bedrijf of in een DMZ. Het is toegankelijk voor zowel interne als externe gebruikers, maar interne gebruikers kunnen deze niet bereiken, terwijl externe gebruikers geen problemen rapporteren.
De reden voor het probleem is vergelijkbaar met die in probleem 1, maar interne gebruikers in dit geval kunnen de naam van de website correct omzetten naar het bijbehorende openbare IP-adres. Ze zijn echter nog steeds niet in staat om de website te bereiken vanwege de manier waarop de firewall is geconfigureerd. Het verwacht dat gebruikers op het interne netwerktoegang hebben tot de website met behulp van hun privéadres in plaats van het openbare adres.
Het is ook een eenvoudige oplossing: een hostrecord met de naam www in de Domain.com -zone op de DC maken, maar deze tijd geeft het particuliere IP-adres van de website op. De interne computers verhelpen de naam van de website op dat particuliere adres, terwijl externe computers de naam blijven omzetten naar het openbare adres van de website.
Probleem 3: Website wordt onvolledig geladen of wordt nog steeds niet geladen nadat de bovenstaande wijzigingen zijn aangebracht
. Dit kan gebeuren als de websitecode browsers omleidt van www.domain.com naar Domain.com of als interne koppelingen naar de locatie verwijzen als Domain.com in plaats van www.domain.com. Dezelfde symptomen worden weergegeven op de interne computers, ongeacht of de locatie intern of extern wordt gehost:
Het probleem in dit geval is iets ingewikkelder. Om te voorkomen dat computers Domain.com op een IP-adres kunnen omzetten, moet er een lege hostrecord aanwezig zijn in de Domain.com -zone in DNS. De naam van deze record wordt weergegeven als (zelfde als bovenliggende map) in de Windows DNS console. Er is echter een probleem in dit geval: AD gebruikt lege hostrecord-records in de Domain.com -zone om dc's voor het Domain.com -domein te vertegenwoordigen. Domeinleden gebruiken deze records bij het vinden van een DC voor verificatie en als er extra lege hostrecord-records aanwezig zijn in de Domain.com -zone, kunnen vertragings-of verificatieproblemen optreden.
Voor de bovenstaande reden kan dit probleem niet worden opgelost in DNS alleen. Het maken van een lege hostrecord met het IP-adres van de website zal slechts af en toe het probleem met de website-toegang voor interne gebruikers oplossen, omdat er al andere lege host-records zijn met de IP-adressen van de Dc's in het domein, en daardoor problemen met de domeinverificatie veroorzaken.
De eenvoudigste manier om dit probleem op te lossen is door de code van de website te wijzigen om de omleiding te verwijderen of de interne koppelingen te repareren, zodat alles verwijst naar de locatie als www.domain.com in plaats van Domain.com. Als het niet mogelijk is om het probleem op te lossen, dan kunt u de naam van het AD-domein wijzigen in de enige andere optie voor het oplossen van het probleem. Dit kan een ingewikkelde taak zijn, afhankelijk van de grootte en complexiteit van de omgeving.