PowerEdge: Nettsted som ikke kan nås i et Windows-miljø med identiske interne og eksterne domenenavn

I alle eksemplene nedenfor er AD-domenet og det registrerte domenet begge navngitt domain.com, og det er et selskapsnettsted som heter www.domain.com. De identiske domenenavnene oppretter et delt (eller delt hjerne) DNS-miljø. I dette tilfellet har de interne og eksterne DNS-navneområdene samme navn, men er separate.

Utgave 1: Et eksternt driftet bedriftsnettsted er utilgjengelig fra innsiden av kontoret.
Dette er det vanligste problemet i et delt DNS-miljø. Selskapets nettsted, eller en annen bedriftseid, Internett-tilkoblet ressurs, kan ikke nås fra kontoret av domenetilknyttede klienter. Maskiner utenfor kontoret har ingen problemer med å nå nettstedet.

Problem 2: Et internt driftet offentlig nettsted er utilgjengelig fra innsiden av kontoret.
Dette er en variant av problemstilling 1 ovenfor. Forskjellen er at nettstedet er vert internt, enten bak en brannmur på selskapets interne nettverk eller i en DMZ. Det skal være tilgjengelig for både interne og eksterne brukere, men interne brukere kan ikke nå det. Eksterne brukere rapporterer ingen problemer.

Utgave 3: Nettstedet lastes ufullstendig eller lastes ikke inn etter at problem 1 eller 2 er adressert.
Nettstedet lastes kanskje ikke i det hele tatt eller lastes ufullstendig for interne brukere. Deler av nettstedet kan ikke vises, og koblinger på nettstedet fungerer kanskje ikke. Eksterne brukere kan få tilgang til nettstedet uten problemer.

Problem 1: Et eksternt driftet bedriftsnettsted er utilgjengelig fra innsiden av kontoret.

Årsaken til at dette skjer kan vises ved å undersøke hva som skjer når en intern bruker forsøker å bla gjennom selskapets nettside:

1. Brukerens datamaskin spør domenets DNS-server, vanligvis en domenekontroller (DC), om IP-adressen til www.domain.com.
2. DC er vert for en oppslagssone for fremover kalt domain.com, slik at den ser i denne sonen etter en vertspost med navnet www.
3. DC finner ingen vertsoppføring navngitt www, og siden det er autoritativt for domain.com sone, videresender den ikke spørringen.
4. DC svarer på brukerens datamaskin, sier at den ikke kunne finne en adresse for www.domain.com.
5. Nettleseren på brukerens datamaskin viser "Siden kan ikke vises" eller en lignende feil.

Problemet oppstår fordi en autoritativ DNS-server ikke sender spørringer for navn i sonene til andre DNS-servere. Den returnerer et "ikke funnet"-svar hvis det ikke finnes noen post som samsvarer med en gitt spørring. I dette eksemplet er det andre DNS-servere med riktig post: DNS-serverne som er vert for publikum domain.com sone. Dette fremgår av det faktum at maskiner utenfor kontoret kan nå nettstedet. Spørringer fra interne maskiner sendes imidlertid ikke til den serveren.

Utgave 2: Et internt driftet offentlig nettsted er utilgjengelig fra innsiden av kontoret.
Årsaken til problemet er tilsvarende som i utgave 1. Interne brukere kan i dette tilfellet løse nettstedets navn til den offentlige IP-adressen. Imidlertid kan de fortsatt ikke nå nettstedet på grunn av måten brannmuren er konfigurert på. Det forventer at brukere på det interne nettverket skal få tilgang til nettstedet ved hjelp av sin private adresse i stedet for den offentlige adressen.

Utgave 3: Nettstedet lastes ufullstendig eller lastes ikke inn etter at problem 1 eller 2 er adressert.
Dette kan skje hvis nettstedskoden omdirigerer nettlesere fra www.domain.com til domain.com. Interne lenker kan også referere til nettstedet som domain.com i stedet for www.domain.com. De samme symptomene ses på interne maskiner enten nettstedet er vert internt eller eksternt.

Problemet i dette tilfellet er litt mer komplekst. For at maskinene skal løse seg domain.com til en IP-adresse, må det være en tom vertsoppføring i domain.com sone i DNS. Navnet på denne posten vises som (samme som den overordnede mappen) i Windows DNS-konsollen. AD bruker imidlertid tomme vertsposter i domain.com sone for å representere DC-er for domain.com domene. Hvis det er ekstra tomme vertsposter i domain.com Sone-, forsinkelser eller autentiseringsproblemer kan oppstå.

Av årsakene ovenfor kan dette problemet ikke løses ved hjelp av DNS alene. Oppretting av en tom vertsoppføring med webområdets IP-adresse løser bare periodevis problemet med nettstedstilgang for interne brukere. De eksisterende tomme vertspostene som refererer til DC-er, forstyrrer dette på grunn av round robin DNS-funksjonalitet. Siden disse postene registreres automatisk av DC-ene, vises de regelmessig på nytt hvis de fjernes fra DNS-sonen.
 

Problem 1: Et eksternt driftet bedriftsnettsted er utilgjengelig fra innsiden av kontoret.
Løsningen på dette problemet er enkel. Opprett en vertspost (A) med navnet www i domain.com-sonen på DC-en, og gi denne posten nettstedets IP-adresse. Maskiner som spør om den DNS-serveren, mottar deretter riktig svar og kan bla gjennom nettstedet.

Utgave 2: Et internt driftet offentlig nettsted er utilgjengelig fra innsiden av kontoret.
Det er en enkel løsning på dette også. Opprett en vertsoppføring med navnet www i domain.com-sonen på DC, men gi posten nettstedets private IP-adresse. Interne maskiner løser nettstedets navn til den private adressen, mens eksterne maskiner fortsetter å løse navnet til nettstedets offentlige adresse.

Utgave 3: Nettstedet lastes ufullstendig eller lastes ikke inn etter at problem 1 eller 2 er adressert.
Den enkleste måten å løse dette problemet på er å endre nettstedets kode for å fjerne omdirigeringen. Også interne lenker bør referere til nettstedet som www.domain.com i stedet for domain.com. Hvis det ikke er mulig å endre koden, er det eneste andre alternativet for å løse problemet å gi nytt navn til AD-domenet. Dette kan være en kompleks oppgave, avhengig av størrelsen og kompleksiteten i miljøet.

Notat: Nettstedet må nås ved å bruke navnet www.domain.com i alle disse eksemplene. Få tilgang til nettstedet ved hjelp av navnet domain.com fungerer ikke eller fungerer bare periodisk.

Beste praksis for Active Directory (AD) domenedesign fraråder bruk av et registrert domenenavn som navn på et AD-domene. Det er to foreslåtte alternativer til dette:

• Bruk et ikke-offentlig DNS-suffiks (.local eller .lan, for eksempel) i AD-domenenavnet.
• Gjøre AD-domenet til et underdomene av det registrerte domenet (corp.domain.com, for eksempel).

Dette er bare mulig hvis AD-domenet ikke allerede er opprettet, eller hvis en navneendring er i gang.