В связи с моим предыдущим вопросом о том, почему плохая идея использовать имя корневого домена в качестве имени леса 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и наоборот.
( Домены corp.ITcluelessinc.comи - это eval.ITcluelessinc.comдомены с правильными именами, на которые я зашел и настроил позже, но они пока не актуальны.)
Еще несколько часов назад нетехнический сотрудник ITcluelessinc заметил, что она не может зайти на www.ITcluelessinc.com со своей рабочей станции (внутри корпоративной сети ITcluelessinc), и решил, что это проблема, поэтому она связывается с ней. VIP-сотрудник ITcluelessinc, который решает, что это должно быть решено наиболее Ricky-Tick. Как правило, это не так уж и сложно, добавьте запись 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контроллеры домена пока что ломают все .
источник
wwwимя, или они получают неправильный адрес? Или, наоборот, получают ли они правильный адрес, но не могут подключиться к этому адресу (размещен ли веб-сайт на серверах в сети, вызывая проблему с заколками NAT)?NSзаписи. При условии, что брандмауэр разрешает связь между контроллерами домена и внешним DNS-сервером, это несколько облегчает кошмар, а открытыми записями можно управлять на общедоступном сервере.Ответы:
Если клиенты правильно разрешают имя хоста, у вас есть другая проблема. DNS перестает работать, как только имя хоста разрешено клиентом.
Некоторые вещи для размышления:
Используют ли клиенты какой-либо HTTP-прокси для доступа в Интернет? Имеет ли прокси правильную информацию DNS?
Как выглядит кэш DNS на клиенте после неудачной попытки доступа? Вы видите правильный IP-адрес, кэшированный для имени хоста?
Что на самом деле происходит на клиенте? Вы видите соединение, застрявшее в состоянии SYN_SENT с правильным IP-адресом сервера, TCP-порт 80?
Существуют ли правила брандмауэра, которые могут касаться блокировки доступа к адресу сайта?
Это пахнет проблемой брандмауэра / прокси / кэша / фильтра, а не проблемой DNS.
К сожалению, я ничего не могу сказать о том, как избавиться от плохо названного домена Active Directory. К сожалению, они решили пойти по этому пути, но технически это может сработать. (Я тоже ненавижу такую плохую практику именования ... "мерзко", я думаю, это то, как я упоминал об этом в прошлом ... Жаль, что у меня не было хорошего совета, чтобы передать вам аргумент переименования домена ...)
источник
If the clients are resolving the hostname properly then you've got another problem.Проклятье. Если это так, то это, вероятно, наш астастический веб-прокси. Я был намного счастливее, когда думал, что это технически не разрешимо, и им, наконец, придется уже исправлять свой беспорядок в $ # @ ^%. :(wwwзапись А не работает, сисадмин разозлился и усугубил его цирроз.