Предположим, я использую EasyDNS в качестве поставщика услуг DNS.
Там у меня есть A-запись для ns-at-premises.example.com указывая на IP-адрес 192.0.2.123, где у меня расположен DNS-сервер, прослушивающий порт 53.
Также есть CNAME-запись для ns.example.com со значением ns-at-premises.example.com (Я где-то читал, что NS-Записи должны получить CNAMEd).
example.com имеет A-запись 192.0.2.234, VPS, размещенный на AWS и www.example.com имеет CNAME из example.com, но это не имеет значения.
Есть поддомен dynamic.example.com который имеет NS-Запись ns.example.com, который отправит любой запрос на *.dynamic.example.com или dynamic.example.com быть решенным в 192.0.2.123, где * может быть что угодно.
-
Теперь я хочу добавить резервный сервер имен на случай, если 192.0.2.123 идет вниз. Это означает, что сервер порта 53 на 192.0.2.124 должен быть запрошен в случае 192.0.2.123 недоступен.
Я бы добавил A-Запись для ns-backup.example.com указывает на 192.0.2.124, а CNAME для ns2.example.com со значением ns-backup.example.com
-
Вопрос в том, как я теперь могу сказать EasyDNS, что dynamic.example.com должен запросить или перенаправить на ns2.example.com когда ns.example.com недоступен?
Я прочитал это, просто добавив второй NS-Запись со значением ns2.example.com к dynamic.example.com приведет к тому, что клиенты будут использовать ns.example.com и ns2.example.com для поиска в режиме Round-Robin, но на самом деле я хочу, чтобы ns2.example.com запрашивается только если ns.example.com не работает.
Итак, я действительно ищу способ добавить веса серверам имен, например MX-Записи в состоянии предоставить.
Это возможно? Или я должен согласиться с идеей, что ни один из этих двух серверов имен не будет основным, и обращаться с ними как с серверами без приоритета с балансировкой нагрузки?
Протокол DNS не предоставляет механизма для назначения основного и резервного серверов имен.
Вы можете настроить несколько авторитетных серверов имен, но ожидается, что каждый из них будет отвечать (и обычно будет возвращать идентичные ответы на идентичные запросы), и все они будут опрошены.
Тебе не нужно исправляться ns1.example.com и ns2.example.com. Вам просто нужно иметь действующую запись для NS, поэтому даже напрямую ns-at-premises.example.com может быть настроен как сервер имен и нет ns1.example.com cname необходимо настроить.
Как уже упоминалось здесь, нет доступного варианта использования, о котором вы спрашиваете ... Что вы можете сделать, так это настроить мастер на ns1 который уведомит об изменениях в нс2 который потянет изменения в локальный кеш, так что "стандартная" конфигурация ведущий / ведомый.
В этот момент оба DNS-сервера могут разрешать один и тот же ответ, поэтому в конце вам не нужно заботиться о том, какой DNS-сервер предоставил ответ. Четный ns1 будет временно недоступен нс2 будет по-прежнему действительная кэшированная информация на время ns1отключение.
Что также может иметь место, так это наличие «скрытого» сервера имен в предпосылках, которые даже не будут передаваться в DNS. Там можно было просто обработать изменения и действовать как хозяин. Другой DNS-сервер, который будет расположен в DC (например), может быть объявлен в DNS как NS для домена. Любые изменения, сделанные во время на территории онлайн-статус может быть напрямую передан (втянут) на публично известный NS-сервер. В случае сбоя изменения будут применены при следующей успешной проверке один раз. ns1 вверх.
Нигде не требуется, чтобы «настоящий мастер», где обрабатываются записи зон, был постоянно общедоступным. Он должен быть достаточно доступен, чтобы не истек срок действия зон, кэшированных на ведомых устройствах. Для функциональности DNS все NS, перечисленные в определении домена (в основном верхний NS - например, для example.com это NS для .com), могут быть даже всеми подчиненными, поскольку для целей разрешения разницы нет. Роль ведущего / ведомого только для целей обслуживания зоны (где она обрабатывается).