Я настраиваю новую серверную среду, состоящую из 70+ серверов, все под управлением Linux (смешанные Redhat / CentOS). Я хочу настроить пару DNS-серверов (первичный / вторичный), которые будут использоваться / настроены на всех серверах, которые должны принимать заботиться в основном о следующих вещах.
1. Авторитетный DNS для разрешения записей локального сервера.
Я хочу назначать серверам простые доменные имена (в основном записи A), например db1.example.int
или app1.example.int Основная идея состоит в том, что серверы должны иметь возможность связываться друг с другом через имеющиеся (внутренние) DNS-имена.
2. Рекурсивное / кешированное разрешение DNS для общедоступных доменов (например, google.com).
Для разрешения любых записей DNS, отличных от локального домена (example.int), вопросы следует отправлять на вышестоящие DNS-серверы, настроенные как пересылки.
В настоящее время для этой цели я изучаю BIND & dnsmasq. Следует ли мне использовать BIND или попробовать dnsmasq (с отключенным dhcp - поскольку все мои серверы будут использовать статические IP-адреса), поделитесь своими мыслями и опытом, если вы работали с аналогичной настройкой.
Обычно это называется «разделенный DNS». Вы создаете систему, в которой записи DNS, видимые за пределами компании, отличаются от записей DNS, видимых внутри компании. В частности, посторонние видят www.example.com и другие видимые извне хосты. Внутри компании все машины имеют записи DNS ... эти записи не видны снаружи.
Обычно машины внутри компании находятся в субдомене домена компании. Например, если ваша компания - example.com, все машины внутри - MACHINENAME.corp.example.com. Проблема в том, что вы никогда не можете использовать "corp.example.com" в качестве внешнего DNS-имени.
Предупреждение: однажды я видел, как компания использовала «внутри» вместо «корп». Когда маркетологи захотели создать внешний веб-сайт под названием «inside.example.com» («руководство для инсайдеров» по использованию их продукта), это стало политическим кошмаром.
Предупреждение: я настоятельно рекомендую дополнительный уровень иерархии. MACHINENAME.LOCATION.corp.example.com. "location" может быть "hq" для штаб-квартиры, "nyc" для офиса продаж Нью-Йорка и т. д. Большинство организаций используют трехбуквенные коды, часто это код ближайшего аэропорта.
Когда я работал в одной компании, у нас в головном офисе каждая машина называлась MACHINENAME.corp.example.com, потому что мы не думали, что у нас когда-либо будут местные офисы. Когда мы открывали большие офисы в другом месте, они назывались MACHINENAME.SITE.corp.example.com. Каждый инструмент, который мы написали, имел «особый случай», потому что HQ был другим. В конце концов нам пришлось изменить штаб-квартиру, чтобы она была такой же, как и все другие сайты. Это был болезненный переход. Тем не менее, я вижу, как компании повторяют эту ошибку снова и снова. Поэтому, даже если у вас нет планов роста за пределами одного здания, я все равно рекомендую MACHINENAME.LOCATION.corp.example.com.
BIND и другие системы DNS могут быть настроены для предоставления разных ответов в зависимости от источника запроса DNS или интерфейса, через который поступил запрос DNS.
Например, если у вас есть DNS-сервер с 1 сетевой картой внутри компании и 1 сетевой картой за пределами компании:
Внутри сетевой карты:
За пределами сетевой карты:
Вы также можете иметь 2 разные машины, каждая с разной конфигурацией.
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ:
Примечание: я не думаю, что dnsmasq может разделять DNS. BIND может, как и большинство других «корпоративных» продуктов. Поищите в руководстве «просмотры» или «разделенный DNS».