Внутренняя DNS Best Practice - должен ли раб разрешать интернет-доменные имена?
Я унаследовал внутреннее решение DNS в моей новой компании, и я хочу начать повышать его надежность! На данный момент существует один мастер для внутреннего домена, который перенаправляет внешние DNS-запросы нашему провайдеру. Есть один подчиненный, который, кажется, разрешает только внутренние запросы.
Для повышения отказоустойчивости я должен настроить подчиненное устройство так же, чтобы оно осуществляло поиск в Интернете?
Спасибо за любую помощь.
3 ответа
Да, подчиненный должен быть тем же самым, что и ведущий во всех отношениях, за исключением того, что он имеет ссылку на ведущий для подачи любых других изменений. Назначение подчиненного DNS - точно продолжать делать то, что делал мастер, до тех пор, пока он не вышел из строя.
В большинстве случаев вторичный сервер никогда не будет запрашиваться для поиска, внутреннего или внешнего. Предполагая, что все ваши DNS-клиенты имеют основной сервер, указанный в качестве их основного DNS-сервера, и дополнительный сервер, указанный в качестве их вторичного DNS-сервера, единственная причина, по которой DNS-клиент будет когда-либо запрашивать вторичный сервер, заключается в том, что основной сервер был недоступен. Если это на самом деле описывает проблему, с которой вы имеете дело, то я думаю, что вы решаете ее с неправильной стороны. Если у вас есть проблемы со стабильностью и надежностью основного сервера, то я предлагаю исправить эти проблемы. Это, конечно, основано на предположении, что ваша установка довольно проста; один сайт (офис, местоположение и т. д.), 2 DNS-сервера (основной и дополнительный), и что все ваши DNS-клиенты настроены на использование основного сервера в качестве основного DNS-сервера и вторичного сервера в качестве дополнительного DNS-сервера.
При этом вторичный сервер должен быть способен разрешать внешние запросы. Существуют сценарии, когда вторичный игрок может играть:
Основной сервер недоступен
Вторичный сервер устанавливается в качестве основного DNS-сервера для некоторых клиентов DNS.
И т. Д. И т. Д.
Имейте в виду, что DNS-сервер является главным для зоны и ведомым для зоны. Обычная практика заключается в том, что все домены, находящиеся под его техническим административным контролем, находятся на одном сервере в качестве главных зон (и мы называем сервер "главным"), а те же зоны назначаются в качестве подчиненных для остальных серверов имен (и поэтому мы называем их "подчиненные" серверы). Но (если предположить, например, два сервера), ничто не мешает кому-то запускать некоторые зоны как главные, а некоторые как подчиненные на первой и наоборот для второй. Или даже запуск зон в качестве мастер-зон на обоих серверах (хотя это создает административные издержки и легко приводит к ошибкам).
В этом случае "ведущий" и "ведомый" - это термины, которые должны использоваться для зон, о которых серверы имен знают, чтобы отвечать на запросы с абсолютной уверенностью и без необходимости переадресовывать вопрос на другой сервер. Существуют люди (и программное обеспечение и их комбинация), которые разделяют роли между главным / подчиненным и кэширующими серверами. Например, люди, использующие bind, могут объединить все три роли в одном экземпляре, и я предполагаю, что вы используете BIND или что-то подобное. И наличие второго сервера для запроса поиска, когда первый отказывает, определенно помогает. Это помогает больше, когда они не находятся в одной и той же подсети / локальной сети, поскольку, если существует проблема с подключением для одного, это, скорее всего, влияет и на другое. Иногда может помочь их размещение в отдельных сетях (представьте, что первая сеть отключена от сети, а второй сервер полностью подключен. Если вы сможете запросить второй сервер, у вас будет поиск DNS). Хотя я не фанат djbdns, эта страница является хорошей отправной точкой для различных стратегий DNS, которые можно развернуть.