Как правильно организовать ДНС?

Question

[Сергей]

Добрый день!
Есть небольшая компания COMPANYNAME, у которой есть сайт COMPANYNAME.ru. Сайт крутится на одном из известных хостеров. Компьютеров в сети немного, работали в одной рабочей группе, ссылки прописаны по айпишникам, ДНС у всех настроен 8.8.8.8. Создали внутренний домен COMPANYNAME.ru. Соответственно, ДНС-сервером стал контроллер домена. Прописываем его в качестве основного ДНС-сервера на всех компьютерах. При попытке зайти на интернетовский сайт, попадаем на этот же сервер. Если пропишем первым ДНС-сервером 8.8.8.8, а внутренний ДНС-сервер вторым, то с доменом начнутся проблемы.
Подскажите, как более правильно организовать структуру ДНС?

Answer 1

[Alex Zverev]

На вскидку - это "торчащие" в инет адреса компьютеров.
Лучше все же сделать .loc
если сертификат нужен локально - то и распространить чего через центр сертификации Microsoft active directory. Все внутренние клиенты будут ему доверять. Пускать внешних клиентов внутрь - это плохо. самоподписанному сертификату (в т.ч. CA) внешние клиенты доверять не будут, а подписанный доверенным корневым центром сертификации стоит денег, однако. каждый такой сертификат. а уж подписать корневой сертификат стоит столько... что лучше не стоит.
Так что внутри - все равно будет самоподписанный корень. а в этом случае - не все ли равно, как называется домен ? хоть .loc, хоть local - да и имя не будет играть роли - этим CA можно подписать ВСЕ. и dns-имя там будет иметь нулевое значение.

Я сам с этим столкнулся. уже год выпиливаю старый домен, меняю его на .loc. и то не смогу до конца выпилить.

ЗЫ. также, есть вещи типа "внутренний просмотр" и "внешний просмотр" - одни и те же dns-имена при резолве будут давать разные имена, в зависимости от адреса запрашивающего. так что вполне можно поставить почтовый сервер внутрь, и назвать его mail.companyname.ru, обеспечив доступ как клиентам локальной сети, так и "внешним" сотрудникам. Это также может пригодиться при планировании домена, ибо я не могу предоставить ситуацию, при которой понадобилось бы использовать в качестве имени домена реально зарегистрированный домен.
ЗЫ2. рекомендую ознакомиться: раз и два

Comments

[Сергей]

А как же вы батенька собираетесь при таком раскладе навешивать ru.wikipedia.org/wiki/DirectAccess ? Насколько я понял домен должен смотреть в обе стороны. Ситуация с сертификатом опять таки требует чтоб домен был реальный, а не loc. По феншую у нас должен домен смотреть в обе стороны. Если уж речь вести о "красивых" решениях .. то можно просто завести второй домен чисто для внутрянки (типо служебный).

[Alex Zverev]

Ну, как я понял - домен все же не должен смотеть в обе стороны - это раз.
ДиркетАцесс - не пользовался таким, предположил бы прописать в качестве DNS-сервера сервер компании или поднимать тот же vpn до компании, и ходить туда... ну, и пускать клиентов даже на свои рабочие машины из интернета, как и выставлять Windows "попой" в инет... ну, я бы не стал.
С сертификатами все равно ничего не могу понять. Как сертификат связан с именем домена Active Directory ?

[Сергей]

Сервера домена чуть позже будут смотреть одной ногой в интернет, компы - нет.

Answer 2

[Сергей]

Не совсем понятно как у вас комп dc1.COMPANYNAME.ru превратился в www.COMPANYNAME.ru

Answer 3

[Сергей]

Когда несколько контроллеров домена, то при пинге ИМЕНИ ДОМЕНА отвечает случайный контроллер. Если же он один в домене, то он и отзывается.

Comments

[Сергей]

Вы видимо слегка не в теме. Я же отписался выше. www.COMPANYNAME.ru Обратите внимание на www. Это не протокол передачи данных. Это домен третьего уровня. Запись такого типа может вести хоть на ямайский ip. Главное сопоставить. Не совсем ясно как запись такого типа появилась у вас на контроллерах домена и для чего она ведет на них же.

[Сергей]

Я в теме, просто не обратил внимания на www. Такая запись в локальном домене не заводилась, т.к. пользователи заходят на сайт по имени COMPANYNAME.ru. Завести для внутренних пользователей A-запись www.COMPANYNAME.ru, которая будет указывать на сервер хостера, я считаю крайне не верным. У него целая ферма серверов, на которых крутятся сотни виртуальных хостов. Завтра сервер умрет или мигрирует на другой айпишник, на ДНС-серверах хостера появится изменение, а у меня перенаправление будет идти на старый айпишник. Через пару лет все забудут об этом костыле и при первой же смене айпишника придется мозг погнуть, пытаясь понять, где же сбой.

[Сергей]

Работ системного администратора и заключается в том что заниматься подобным. А ваша формулировка делает из этого трагедию. Если запись не нужна, то ее тупо сносят. Заводят новую. И всё снова стает на рельсы. И это не является "сбоем" как вы пишите. Решение с www как раз и есть общеупотребительным.

Answer 4

[Qwadrat]

Это обычная проблема, когда имя домена AD совпадает с именем сайта. Самым простым выходом, как уже верно подметили, является использование www внутри компании. Либо делать policy based routing, если позволяет инфраструктура.

Answer 5

[Сергей]

Спасибо всем. Я прочитал кучу информации по костылям, изобретаемым народом, но красивого решения проблемы не нашел. Решил потерять несколько часов работы, грохнул домен COMPANYNAME.ru и создал office.COMPANYNAME.ru. Пока далеко все не зашло, решил сразу сделать нормально, чтобы через годы не вылезли разные неисправимые проблемы.

Comments

[Сергей]

Тут не было костылей. Тут люди показывали проверенные решения. А ваше решение имеет один минус. =) Позже поймете какой.

[Сергей]

Если не секрет, поделитесь инфой.

Answer 6

[Dmitry Kireev]

Я бы переиментовал внутренний домен в COMPANYNAME.lan и все встало бы на свои места. Сайт отдельно, офис отдельно. Зачем оно вам, ваш офисный контроллер домена в паблик выставлять, или он должен служить dns сервером для сайта?

Comments

[Сергей]

Не учите человека плохому =)

[Dmitry Kireev]

А в чем собственно проблема? При заданной конфигурации этот домен нельзя использовать извне, использовать его как DNS сервер для чего-то кроме офиса я бы не стал по причине низкой доступности, а также удаленности от самого датацентра. У Вас другое мнение?

[Сергей]

lan пытаются зарегать. Это раз. Плюс сложности с получением сертификата. Это два.

Answer 7

[Ilya Evseev]

Костыль - установить на контроллере домена прокси-сервер на 80 порту.

Answer 8

[Сергей]

А где хабравчане вам порекомендовали в этой теме проксю? К тому же у вас неверное представление что такое костыль и что такое типовое решение. По сути своей мало кого вообще волнует в офисе как вы что-то реализуете. Всё должно работать. И днс не та область в которой косяк может быть смертелен. Вот давайте рассмотрим ваш костыль. У клиента прописан 0_о (о динамике слышали?) вторым днс сервером гугл паблик. То есть вы переживаете что не сможете обеспечить бесперебойную работу контроллера доменов и городите костыль. А ведь по феншую контроллеров должно быть два! Извините конечно .. вы тут слегка опустили людей с их советом и при этом сами городите костыли.

Answer 9

[Сергей]

Пара комментариев. Типовое решение - это не всегда правильное решение. Правильное решение, это когда админ забыл о способе решения или пришел другой админ и в случае любых проблем, корень ее находится за несколько минут. В некоторых организациях видел костыли, которые до поры до времени работают, но про которые все забыли или не знают. Потом поиск проблемы и ее устранение займут лишние часы.

По фен-шую серверов должно быть 2. Сейчас его нет, т.к. не предусматривали выделение финансов на него в этом году. На второй деньги заложены в бюджете следующего года. Надеюсь, существующий проживет несколько месяцев до получения второго. Придет второй сервер - добавлю одну строчку в настройках DHCP и все будет работать нормально. Где вы проблему увидели?

Вы писали

Работ системного администратора и заключается в том что заниматься подобным. А ваша формулировка делает из этого трагедию. Если запись не нужна, то ее тупо сносят. Заводят новую. И всё снова стает на рельсы. И это не является "сбоем" как вы пишите. Решение с www как раз и есть общеупотребительным.

Для любого вменяемого админа важна максимальная автономность системы. Постоянно вручную отслеживать, не изменился ли адрес у веб-сервера. Виртуальный сервер будет мигрировать на другое железо при превышении порога нагрузки на железе, при выходе из строя комплектующих, а я буду отслеживать и переписывать записи в ДНС? Для этого есть ДНС сервера хостера, где хранится самая актуальная информация. А на них указывает как раз тот самый сервер 8.8.8.8, который у меня указан вторым или третьим по списку.

Почему меня не устроил костыль в виде записи www.companyname.ru в AD компании? Могу пояснить. На веб-сервере могут быть кнопки или ссылки, указывающие на имя "companyname.ru". Оператор, занимающийся обновлением информации на сайте, нажмет на такую ссылку и опять будет звонить мне, чтобы я разобрался, почему сайт не работает. Чтобы этого не случалось, надо отслеживать содержимое сайта. Завтра захотим поменять движок или прикрутить какой-нибудь плагин и опять отслеживать их исходники? Я могу забыть или сменить место работы, а в случае чего мозг вынесут мне. Зачем держать такой костыль, который будет работать только в определенных условиях и про который всегда надо помнить?

Прокси на 80-м порту контроллера тоже не рассматриваю. Серверов не так много, мало ли, захочу вывесить на цеб-страницу обновляемый из AD телефонный справочник или другую лабуду.

Answer 10

[Ilya Evseev]

Серверов не так много, мало ли, захочу вывесить на цеб-страницу обновляемый из AD телефонный справочник или другую лабуду.

Такому сайту можно дать название office.companyname.ru.
Прокси по полю "Host:" обратится на внутренний веб-сервер, который можно повесить на соседний порт.
Это проще, чем переименовывать домен.

Answer 11

[Сергей]

Я сейчас планирую поднимать на фряхе шлюз, который будет расставлять приоритеты использования трафика разным сегментам сети. Пакеты, идущие через прокси, будут выглядеть для шлюза одинаково. А городить для каждого сегмента несколько проксей - это еще один костыль. Так и получаются системы, когда лениво один раз перечеркнуть работу нескольких часов и сделать правильно, начинают городить невероятные конструкции из костылей. Все равно когда-нибудь это надо разрушить или само рассыпется со временем. Я решил сразу сделать правильно.

Answer 12

[Сергей]

Господи. Ну вы батенька и зануда. Обратились за помощью в том вопросе котором не разбирались, а потом еще и начали учить. Я не хуже вашего знаю то что касается этой темы. Все что от вас требовалось .. это закрыть тему после найденного решения и не нудеть.

Answer 13

[Сергей]

Почему очень часто обсуждение технических вопросов переходит в хамство? А еще находится "самый умный начальник", который решает, кто и что должен делать. Я задавал вопрос: "как НАИБОЛЕЕ ПРАВИЛЬНО решить этот вопрос", а не "каких костылей можно нагородить, чтобы сегодня от меня отстали". Я сам навскидку придумал штук 5 решений из разряда "костылей". Просто хотелось узнать мнение знающего и более опытного специалиста, а не решение тяп-ляпкина, работающее с оговорками или в определенных рамках. Некоторые предложенные решения я не считаю костылями, но они не вписались в мои планы по расширению структуры сети. Но все равно очень интересно почитать рекомендации коллег.

Answer 14

[Alex Zverev]

Все же правльно не смешивать внешний и внутренний домен.
У вас есть зона COMPANYNAME.ru, и вы создаете еще одну зону COMPANYNAME.ru
Естественно, что будут проблемы.
значит, надо создавать либо COMPANYNAME.loc (COMPANYNAME.local), либо office.COMPANYNAME.ru (что тоже будет не слишком правльным решением)
Или попробовать прописать SRV-запись для _http._tcp
пример тут help.dnsmadeeasy.com/record-entry/srv-2/

Не факт, что браузеры будут проверять эту запись. не тестировал.

Ну, либо все же вбить костыль вида "перенаправлять запросы на 80 порт контроллера домена на внешний сайт". Но это будет все же костыль.

Answer 15

[Сергей]

Я слабо представляю, как различный софт обрабатывает эту запись, но за идею спасибо. Я в эту сторону даже и не думал. COMPANYNAME.loc решил не делать, мало ли что будет в будущем? Захотим сертификат в будущем сделать, а он, насколько я помню, на левые домены не делается. Решил из "рекомендованного" диапазона имен сделать, остановился на методе office.COMPANYNAME.ru. А какие подводные камни могут в этом случае вылезти? Я навскидку пока проблем не придумал, а то может быть стоит еще что то переделать, пока компы в домен не повгонял?

Answer 16

[Сергей]

Они не "торчат" в интернет. Шлюз за PPPoE туннелем до провайдера, диапазон получаемых адресов динамический. Сами компы за НАТом на фряхе, акцесс-листы и все такое. Если не поднимать VPN до компьютера по разрешенным портам, то в сеть снаружи не пробиться.

Про самоподписанные сертификаты я не говорю, их вообще не проблема нагенерировать. Я говорю именно про официальные, выданные доверенным центром. Стоят дорого, но серверное брэндовое оборудование, сетевое оборудование cisco, лицензионное ПО - все дорого стоит.

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

В будущем, я планирую раширить канал, уйти от провайдера, вынести в корневой домен COMPANYNAME.ru зону DMZ с почтовиком, файловым сервером, веб-сервером и т.д., а компы за файрволом будут в office.COMPANYNAME.ru. ИМХО нормально. Или есть еще подводные камни?

Comments

[Alex Zverev]

Если у вас нейм-сервера зоны companyname.ru лежат у хостера, то это будут те самые подводные камни. Надо чтобы нейм-сервер был "внутри" сети и смотрел наружу. С динамическим адресом это ... плохо.
У вас таким образом будет 2 зоны companyname.ru - одна у вас и одна у хостера. Синхронизировать их.. будет тяжко.

Также, я все же не могу понять про сертификаты. А какие именно сертификаты вы хотите получить ? На веб-сайт - легко можно получить на "правильное" доменное имя "companyname.ru". На что-то, доступное из интернета, типа почтового сервера ? Аналогично, dns-алиасы никто не отменял. На что-то, доступное только внутри локальной сети ? А для чего на это заводить "реальные" сертификаты, если там хватит самоподписанных ?

В любом случае - имя домена Active Directory никак не повиляет на получение сертификатов. И на почту, и на веб-сервер, и преславутое "т.д.".

Компы за файрволом... ну, я бы назвал все же .local. Но причин, мешающих назвать их .office.companyname.ru, я не вижу (кроме чисто эстетических).

ЗЫ. Не забывайте, что в таком случае NetBIOS-имя домена у вас будет office.

[Сергей]

Пока ДНС-сервера и само содержимое находятся у хостера. Лишняя работа, лишние деньги, лишние телодвижения. Расширю в следующем году канал на контору, поставлю дополнительные сервера, оба контроллера одной ногой вынесу в DMZ, выбью небольшой пул статических адресов для ДНС и веб-сервера. ДНС-ы будут у меня, веб-сервер будет у меня, все будет красиво. :-)

По поводу сертификатов - это пока не в реальных планах, просто рассматриваю возможность и закладываю заранее возможность.

Я не представляю, что будет в дальнейшем. Поэтому, чтобы не искать проблемы в будущем, решил с "неправильными" доменами типа .local не связываться. Слишком часто приходилось сталкиваться, когда раньше не предусмотренные фичи понадобились, а без глобальных разрушений ввести их нельзя. Поэтому стараюсь максимально все предусмотреть и обезопаситься.