Нужны предложения по передовому опыту.
- В настоящее время есть домен AD с отключенными безопасными динамическими обновлениями DNS (например, любой клиент может обновить запись DNS). Хотелось бы отойти от этого.
- Более 50 удаленных объектов (подключенных с помощью MPLS, и каждый из них также имеет выход в Интернет) — некоторые с локальными DHCP-серверами (Windows), а многие с DHCP, работающим на коммутаторах Cisco. Только около 30–40 % объектов имеют локальный ИТ-персонал.
- Некоторые клиенты указывают на AD для DNS (но большинство сайтов не имеют сервера AD), другие на резолверы BIND. Переход на резолверы BIND на локальных сайтах для обработки разрешения Интернета за пределами интернет-цепи сайта для лучшей геолокации и производительности для приложений SaaS, а также для RPZ. Мы подчинили зоны AD серверам BIND для производительности и отказоустойчивости. Однако, если клиенты указывают на BIND, очевидно, что динамические обновления DNS работать не будут.
Мы пытаемся стандартизировать и сделать все максимально безопасным. Рассматриваем варианты:
- Включите безопасные обновления DNS в AD и дайте DHCP-серверам возможность обрабатывать обновления DNS-имен от имени клиентов. Похоже, это не добавляет никакой ценности безопасности, так как любой может отправить DHCP-запрос с заголовком Option 81. Кроме того, не уверен, что устройства Cisco могут безопасно обновлять динамический DNS (например, с помощью Kerberos). Предполагаю, что нет.
- Аналогично пункту 1, но для обновлений используется только MS DHCP (в этом случае DHCP не обязательно будет локальным для офиса, если на сайте нет серверной инфраструктуры).
- Получите сервер AD на каждом сайте, который может использоваться клиентами для первичного DNS (и DHCP) (и обрабатывать безопасные обновления DNS напрямую от клиентов). Также имейте сервер BIND для поиска в Интернете.
- То же, что и #3, но AD делает и внутреннюю, и интернет. Однако мы довольно активно используем представления BIND, поэтому не уверены, что это возможно, если мы не перейдем на Server 2016 (сейчас на 2012).
Чем занимаются те из вас, кто работает в средних и крупных организациях?
решение1
В моей сети из 1000+ местоположений мы давно отказались от наличия AD DC в каждом местоположении по очевидным причинам стоимости, не говоря уже о том, что если сеть не работает, пользователи в любом случае не получают никакой работы, с AD или без AD (промышленные системы обрабатываются отдельно). У нас есть различные подходы к DHCP/DNS, но основным является:
- централизованный DHCP на выделенных устройствах (которые по сути являются оберткой для ISC DHCP и BIND). Они обрабатывают динамические обновления DNS от опции 81 до DNS-серверов AD, используя для этого специальную учетную запись службы. В других местах мира это по-прежнему обрабатывается с помощью MS DHCP. Мы не особенно доверяем именам, которые динамически обновляются в DNS, но пока не чувствовали необходимости идти дальше, так как это, скорее всего, потребовало бы гораздо лучшей безопасности периметра в сети, чтобы неуправляемые устройства вообще не могли попасть в сеть.
- Внутренний DNS на контроллерах домена AD доступен в центрах обработки данных и крупнейших местах расположения пользователей
- специализированные устройства для публичного разрешения имен
- все клиенты указывают на AD DNS, который затем перенаправляет на устройства для внешних доменов. Здесь не так много продвинутой функциональности.
Основная проблема этой настройки в том, что геолокализация не работает, поскольку публичные резолверы есть только в 3 основных центрах обработки данных. Обычно это не большая проблема, так как большинство запросов браузера проксируются через облачную службу фильтрации, которая обрабатывает DNS, но в последнее время это усложняет ситуацию, когда мы используем видеосервисы (например, Google Hangouts), которые могли бы получить выгоду от точной геоинформации для выбора правильного центра обработки данных.