Лес 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и наоборот.

введите описание изображения здесь

( Домены 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контроллеры домена пока что ломают все .

domain-name-system active-directory

— HopelessN00b
источник

Это должно сработать - оно отражает настройки, которые у меня были на старой работе (такой плохой домен для вашего леса, у вас есть мое сочувствие), за исключением двух пространств имен и серверов пересылки. Клиентские системы получают ответ DNS NXDomain, пытаясь разрешить wwwимя, или они получают неправильный адрес? Или, наоборот, получают ли они правильный адрес, но не могут подключиться к этому адресу (размещен ли веб-сайт на серверах в сети, вызывая проблему с заколками NAT)?

— Шейн Мэдден

@ShaneMadden: Мои мысли точно и обсуждались в приватной беседе. Это должно работать, но не работает, и я не знаю, почему нет. Единственное, что я хотел бы предложить на этом этапе, - запустить захват пакетов на клиенте .prv и посмотреть, что происходит, когда они пытаются найти www.

— Joeqwerty

@ShaneMadden Похоже, они получают правильный адрес с помощью nslookup, и не должно быть никакой заколки NAT, так как веб-сайт размещен снаружи. (Клиент -> .prv DC -> .com DC -> межсетевой экран -> сети). Я видел эту работу раньше, когда машины в домене rootdnsname пытались получить доступ к rootdnsname, но еще не видели клиентов, подключенных к другому домену, которым требуется доступ к веб-сайту rootdnsname и rootdnsname. ... Так что я думаю, что проблема в этом.

— HopelessN00b

Я согласен с Эваном. На полпути и, работая в другой компании, которая занималась бессмысленной чепухой, стоит упомянуть одну хитрость: вы можете заставить свои общедоступные DNS-серверы контролировать записи (или поддомен), вставляя NSзаписи. При условии, что брандмауэр разрешает связь между контроллерами домена и внешним DNS-сервером, это несколько облегчает кошмар, а открытыми записями можно управлять на общедоступном сервере.

— Андрей B

@AndrewB Правдивая история, ITcluelessinc передала свой DNS внешнему поставщику, но не знает, какой именно, и не может его выяснить, следовательно, никаких хитростей NS на внешних серверах имен. Но я учту это за $ next_job, спасибо.

— HopelessN00b

Если клиенты правильно разрешают имя хоста, у вас есть другая проблема. 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. Проклятье. Если это так, то это, вероятно, наш астастический веб-прокси. Я был намного счастливее, когда думал, что это технически не разрешимо, и им, наконец, придется уже исправлять свой беспорядок в $ # @ ^%. :(

— HopelessN00b

Протестируйте с сервером или внутренним компьютером, который обходит любой веб-прокси и т. Д., И повторите тестирование. Как сказали Эван и Шейн, это определенно выполнимо с записью www. То, что невозможно, - это просто запись по умолчанию, например, itcluessinc.com, разрешающая доступ к веб-сайту в этом случае.

— TheCleaner

Да, так угадайте, что происходит, когда ИТ не управляет веб-сайтами, а отдел, который принимает решение сменить хостинговую компанию? Это верно, старая wwwзапись А не работает, сисадмин разозлился и усугубил его цирроз.

— HopelessN00b