Назад | Перейти на главную страницу

Лучшая практика внутреннего DNS - должно ли ведомое устройство разрешать доменные имена в Интернете?

Я унаследовал внутреннее DNS-решение в своей новой компании и хочу начать повышать его надежность! На данный момент для внутреннего домена существует один мастер, который пересылает запросы внешних DNS нашему интернет-провайдеру. Есть одно подчиненное устройство, которое, кажется, решает только внутренние запросы.

Для повышения отказоустойчивости следует ли мне настроить ведомое устройство на пересылку запросов в Интернете?

Спасибо за любую помощь.

В большинстве случаев вторичный сервер никогда не будет опрашиваться на предмет поиска, внутреннего или внешнего. Предполагая, что у всех ваших DNS-клиентов первичный сервер указан как их первичный DNS-сервер, а вторичный сервер указан как вторичный DNS-сервер, единственная причина, по которой DNS-клиент когда-либо будет запрашивать вторичный, - это если первичный сервер был недоступен. Если это на самом деле описывает проблему, с которой вы имеете дело, то я думаю, что вы обращаетесь к ней не в том направлении. Если у вас возникли проблемы со стабильностью и надежностью основного сервера, я предлагаю исправить эти проблемы. Это, конечно, основано на предположении, что ваша установка довольно проста; один сайт (офис, местоположение и т. д.), 2 DNS-сервера (первичный и вторичный), и что все ваши DNS-клиенты настроены на использование первичного сервера в качестве первичного DNS-сервера и вторичного сервера в качестве вторичного DNS-сервера.

При этом вторичный сервер должен уметь разрешать внешние запросы. Есть сценарии, в которых вторичный может вступить в игру:

  1. Основной сервер недоступен

  2. Вторичный сервер устанавливается как первичный DNS-сервер для некоторых DNS-клиентов.

  3. И т. Д. И т. Д.

Имейте в виду, что DNS-сервер является главным для зона и раб для зона. Обычной практикой является то, что все домены под его техническим административным контролем на одном сервере являются главными зонами (и мы называем сервер «главным»), а те же зоны назначаются подчиненными для остальных серверов имен (и поэтому мы называем их «подчиненные» серверы). Но (при условии, например, двух серверов) нет ничего, что мешало бы кому-то запускать некоторые зоны как ведущие, а некоторые как ведомые на первом и наоборот для второго. Или даже запуск зон в качестве основных на обоих серверах (даже если это создает административные издержки и легко приведет к ошибкам).

Таким образом, главный и подчиненный - это термины, которые следует использовать в отношении зон, о которых серверы имен знают, чтобы отвечать на запросы с абсолютной уверенностью и без необходимости пересылать вопрос на другой сервер. Существуют люди (и программное обеспечение и их комбинация), которые разделяют роли между главным / подчиненным и кэширующими серверами. Например, люди, которые используют bind, могут объединить все три роли в одном экземпляре, и я предполагаю, что вы используете BIND или что-то подобное. И наличие второго сервера, который будет запрашивать поиск при выходе из строя первого, определенно помогает. Это помогает больше, когда они не находятся в одной подсети / LAN, поскольку, если существует проблема с подключением для одной, это, скорее всего, влияет и на другую. Иногда может помочь их расположение в разных сетях (представьте, что первая сеть отключена от сети, а второй сервер полностью подключен. Если вы можете запросить второй сервер, у вас будет поиск DNS). Хотя я не фанат djbdns, эта страница является хорошей отправной точкой для различных стратегий DNS, которые можно развернуть.

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