Назад | Перейти на главную страницу

Лес Active Directory с тем же именем, что и корневая зона DNS, и переход на сайт с тем же именем

В связи с этим предыдущим моим вопросом о том, почему использовать имя корневого домена в качестве имени леса Active Directory - плохая идея ...

У меня есть работодатель, которого я буду называть ITcluelessinc из соображений простоты (и честности). У этого работодателя есть внешний веб-сайт, www.ITcluelessinc.comи несколько доменов Active Directory. Не имея представления об ИТ, много лет назад они создали лес Active Directory под названием ITcluelessinc.prv, и совершил против него невыразимые зверства. Эти невыразимые зверства в конце концов настигли их, и когда все вокруг них рушилось, они решили заплатить кому-то огромную сумму денег, чтобы «исправить это», включая миграцию с ужасно сломанной ITcluelessinc.prv лес.

И, конечно же, не зная об ИТ, они не знали хороших советов, когда слышали их, принимали рекомендацию назвать свой новый лес AD. ITcluelessinc.com, вместо разумного совета, который они тоже получили, и начали приставать к нему. Перенесемся на несколько часов назад, и у нас есть компания, большая часть сотрудников которой присоединилась к старой ITcluelessinc.prv Лес Active Directory с большим количеством новых вещей, подключенных и / или использующих ITcluelessinc.com лес. Чтобы сделать эту работу относительно гладкой, я использовал серверы условной пересылки в DNS для отправки ITcluelessinc.com движение к ITcluelessinc.prv, и наоборот.

(The corp.ITcluelessinc.com и eval.ITcluelessinc.com домены - это правильно названные домены, к которым я пришел и настроил позже, и пока они не актуальны.)

Вернемся к тому, что было несколько часов назад, и сотрудник ITcluelessinc, не имеющий технического образования, заметил, что не может перейти к www.ITcluelessinc.com со своего рабочего места (внутри корпоративной сети ITcluelessinc) и решила, что это проблема, поэтому она связалась с VIP-сотрудником ITcluelessinc, который решает, что это должно быть решено, самое Рикки-тик. Обычно это не имеет большого значения, добавьте запись A для www в зоне DNS для ITcluelessinc.com, и вы можете просматривать сайт, если вы не используете голую ссылку.

Итак, похоже, все настроено правильно. Экспедиторы, www запись хоста в DNS, и все же клиенты, использующие ITcluelessinc.prv контроллер домена, поскольку DNS-серверы получают тайм-аут подключения при попытке просмотра www.ITcluelessinc.comвместо веб-страницы, которую я получаю из домашней сети.

Есть ли у кого-нибудь мысли о том, как я могу разрешить внутренним клиентам ITcluelessinc.prv домен для просмотра www.ITcluelessinc.com, учитывая наличие ITcluelessinc.com Лес Active Directory и необходимые ему серверы условной пересылки? Или, наоборот, убежден ли кто-нибудь [еще], что единственный способ заставить его работать - это избавиться от ITcluelessinc.com Лес Active Directory?

Оно делает кажется как настройки, которые у меня есть сейчас должен работает, но это явно не так, и я понятия не имею, где мне взять такую ​​испорченную тестовую среду для экспериментов. И что бы это ни стоило, я несколько вежливо предложил, чтобы единственный способ исправить это - перейти в леса с правильными именами, которые я настроил, и когда это недостаточно хороший ответ, запланируйте размещение зеркала веб-сайта на всех наш ITcluelessinc.com контроллеры домена, пока это не сломается все.

Если клиенты правильно разрешают имя хоста, у вас есть другая проблема. DNS исчезнет из поля зрения, как только имя хоста будет разрешено клиентом.

Некоторые вещи для размышления:

  • Используют ли клиенты какой-либо HTTP-прокси для доступа в Интернет? Есть ли у прокси-сервера правильная информация о DNS?

  • Как выглядит кеш DNS на клиенте после неудачной попытки доступа? Вы видите правильный IP-адрес, кэшированный для имени хоста?

  • Что на самом деле происходит на клиенте? Вы видите, что соединение застряло в состоянии SYN_SENT с правильным IP-адресом сервера, TCP-порт 80?

  • Существуют ли какие-либо правила брандмауэра, которые могут относиться к блокировке доступа к адресу веб-сайта?

Это пахнет проблемой брандмауэра / прокси / кеша / фильтра, а не проблемой DNS.

К сожалению, я не могу сказать ничего действительно убедительного об избавлении от плохо названного домена Active Directory. Очень жаль, что они выбрали этот путь, но технически это жестяная банка работай. (Я тоже ненавижу такую ​​плохую практику именования ... "мерзко", как я называл это в прошлом... Жаль, что у меня не было хорошего совета, чтобы переслать вам аргумент о переименовании домена ...)