Dns secondary что это
What Exactly Is Secondary DNS?
We see a fair amount of confusion around secondary DNS — partly because it’s an overloaded term. A lot of registrars ask you for “primary” and “secondary” nameservers for your domain, but that’s not really what secondary DNS is all about.
Instead, you can think of secondary DNS as such: a way for a DNS server or service to pull DNS records from another DNS server, and keep them up to date, using the DNS protocol itself.
Primary and Secondary DNS
In order to understand secondary DNS, we need to have a clear understanding of the RFC definitions of a primary/secondary DNS server setup. The primary/secondary DNS (RFC 1996) server setup includes one primary DNS server and one or more secondary DNS servers. The primary DNS server is any authoritative server configured to be the source of zone transfer for one or more secondary servers. There are other types of primary/secondary DNS configurations, but for the purpose of clearly explaining secondary DNS, we’ll keep the configuration examples simple.
In a primary/secondary DNS server setup, the secondary server is created at a second DNS provider to provide redundancy in the DNS network.
The primary DNS server is an authoritative server for which the zone information is locally configured, (RFC 2182) usually via via the provider’s interface or API. There can be both primary and secondary servers within the primary DNS server network.
The secondary DNS server is an authoritative server that obtains information about a zone from the primary server via zone transfer. (RFC 2182) The secondary DNS server is therefore tied to the primary server.
Reasons to Use Secondary DNS
However, in today’s internet there are still uses for secondary DNS. Some customers have tools, code, or other dependencies on an existing DNS server or service, but want to leverage a high performance, reliable platform to deliver DNS. For example, you might have scripts that automate creation of new DNS records in BIND zone files on an in-house DNS server, but you don’t want to run your own anycasted, SLA-guaranteed DNS network. You can continue using your existing DNS setup as the management plane and setup secondary DNS with a reputable anycasted, SLA-guaranteed provider. In this scenario you can keep your records in sync, and point your domains at your anycasted provider for high performance, highly available delivery.
Other customers have stringent requirements around single points of failure. Some organizations, especially high traffic sites that can be heavily affected by any outage, place a premium on the idea that no one system or service should be responsible for any critical piece of the delivery pathway, including DNS. These customers might use two or more managed DNS providers and configure nameservers from both for their domains.
Rather than needing to make record changes in the systems of both providers, a common approach is to configure one of the providers as primary and the other as secondary, subservient to the primary provider. Then, all management is done in the primary provider, but both primary and secondary are used for delivery. Any catastrophic failure in the primary provider is mitigated by the secondary provider. By adding a second DNS provider, you have two separate DNS networks running simultaneously. These two networks provide backup for each other and for your users in the event one network is offline or has degraded performance.
For more information on using secondary DNS, or for other DNS solutions, see this article on setting up NS1 secondary zones or see our Dedicated DNS solutions page.
Часто задаваемые вопросы о DNS
Компьютеры в интернете не имеют имен, данные передаются с использованием сложных для запоминания IP-адресов (числовые адреса вида 123.123.123.123). Упростить работу с сайтами призвана система DNS (Domain Name System). Она преобразует доменное имя, которое вводит пользователь в браузере, в IP-адрес для доступа к серверу.
DNS-сервер — это сервер, на котором запущенно специальное программное обеспечение. Изначально назначение этого программно-аппаратного комплекса было хранение таблицы DNS-записей вида: «имя домена» — «IP-адрес», так называемых записей типа «А», например: Домен IP-адрес сервера nic.ru 115.115.115.115 Сейчас В системе DNS содержатся и другие ресурсные DNS-записи: «MX», «TXT», «CNAME» и др. Они необходимы для работы домена как адреса сайта, почты и многих других сервисов.
Ресурсные записи (DNS-записи домена) — это записи в системе доменных имен о соответствии имени и служебной информации о сервере, на которое это имя должно указывать. Каждая ресурсная запись необходима для работы определённой службы. Например, в ресурсную запись типа MX вносятся данные для корректной работы электронной почты на домене.
Без размещения информации о домене на DNS-серверах работа сайта или почты на нем невозможна. Для гарантии отказоустойчивости DNS-серверы прописываются парами — выход из строя одного сервера не скажется на доступности сайта.
Для изменения списка DNS-серверов следует:
Не влияет. Обращение в сети к DNS-серверам, указанным для домена, происходит случайным образом. Сами DNS-серверы должны быть настроены по отношению друг к другу как первичный и вторичный.
Динамический DNS — технология, которая позволяет назначать постоянное имя устройству с изменяющимся IP-адресом, обеспечивая доступ по доменному имени к сетевым устройствам — компьютерам, роутерам, веб-камерам и т.д. Динамический DNS поддерживается на всех тарифах услуги DNS-хостинг.
Для управления A, MX и другими ресурсными DNS-записями домена необходимо использовать услугу DNS-Хостинг. Подробнее ознакомиться с этой услугой и заказать её можно на нашем сайте. Если услуга DNS-хостинг у вас есть, изменения в файл зоны домена можно внести с помощью редактора DNS-Master.
Вероятно, при заполнении заявки на регистрацию доменного имени вы не указали DNS-серверы.
Да, можете. Для того чтобы делегировать домен без тестирования серверов, в настройках домена достаточно указать список DNS-серверов и нажать Сохранить изменения. Для указания списка DNS-серверов домена следуйте инструкции.
У DNS-сервера ns.www.com сменился IP-адрес. Для того чтобы информация об этом обновилась в DNS, нужно изменить информацию в зоне www.com. Обратитесь к администратору домена www.com или к своему провайдеру, который администрирует этот DNS-сервер.
Нужно в вышестоящем домене второго уровня сделать NS-запись для домена третьего уровня. Например, чтобы делегировать домен masha.test.ru, и при этом в качестве Primary и Secondary-серверов использовать ns.my-provider.ru, ns.myprovider.ru, нужно в зоне test.ru сделать такую запись:
| masha | NS | ns.my-provider.ru. |
| NS | ns.myprovider.ru. |
В вышестоящем домене второго уровня необходимо сделать NS-записи для домена четвертого уровня, например:
| new.masha | NS | ns.my-provider.ru. |
| NS | ns.myprovider.ru. |
Для отказа от рассылки сообщений технического характера нужно: перейти по ссылке, приведенной в последнем абзаце каждого направляемого вам сообщения; сделать запрос на исключение вашего адреса электронной почты из списка рассылки. Для направления запроса необходимо знать номер договора, в контактных данных которого указан ваш адрес электронной почты. Номер договора можно найти в любом из писем рассылки, от которой вы отказываетесь. На указанный в запросе email-адрес незамедлительно будет направлено письмо с просьбой подтвердить свое намерение исключить этот адрес из списка рассылки RU-CENTER. До тех пор, пока запрос не будет вами подтвержден, email-адрес не будет удален из контактных данных по договору.
Исправить серийный номер на наших вторичных DNS-серверах не представляется возможным как и изменить зону домена. Зона домена копируется с первичного DNS-сервера и все изменения производятся на первичном DNS-сервере.
Не поддерживает. Можно подписать зону на собственном первичном DNS-сервере и в случае отсутствия вторичных DNS-серверов, воспользоваться нашими, которые предоставляются в рамках услуги «Secondary». Наши вторичные DNS-серверы будут копировать зону, в том числе записи типа «DS», с первичного DNS-сервера, IP-адрес которого будет указан для наших вторичных серверов.
Услуга DNS-хостинга — что это такое?
Пришло время подробно рассказать о нашей услуге, которую мы предоставляем бесплатно нашим пользователям SSD VDS или выделенных серверов от ITLDC. Речь пойдет об услуге DNS-хостинга или, другими словами — о предоставлении кластера вторичных NS-серверов.
Как известно, для размещения доменных зон требуется не менее двух NS-серверов, которые должны иметь разные IP-адреса, причем желательно — из разных сетей. Некоторые пользователи для этого заказывают дополнительный адрес IPv4, устанавливают его вторичным (алиасом) на свой сервер и обрабатывают DNS-запросы локально, с одного сервера или VDS.
Несомненно, подобный способ имеет право на жизнь — мало того, он широко используется. Вместе с тем, у такого варианта есть один существенный недостаток — в случае недоступности сервера не будут работать все сервисы, связанные с DNS, а пользователи, которые будут делать запросы в момент неполадок, «закэшируют» так называемый негативный ответ (что хост не найден) на 10-15 минут.
Именно поэтому рекомендуется, чтобы DNS-серверы были расположены в различных сетевых инфраструктурах и локациях — в этом случае все поступившие запросы будут корректно отработаны вне зависимости от доступности основного сервера. Приятным побочным эффектом этого является также более высокая скорость отклика на DNS-запросы.
Система устроена таким образом, что на сервере или VDS пользователя расположен «основной» (primary) DNS, где хранятся оригинальные мастер-экземпляры доменных зон, однако пользовательские запросы он не обрабатывает. Задача primary DNS — дать возможность нашему DNS-кластеру получить экземпляры доменных зон, это обновление происходит после каждого изменения мастер-копий или раз в несколько суток. После этого все запросы обрабатываются только нашими DNS-серверами — максимально быстро.
Мы используем четыре синхронизированных DNS-сервера, расположенные в разных локациях — в Голландии, США, Болгарии и Украине. Названия данных серверов нейтральны — nsX.layer6.net, где Х — число от 1 до 4. Серверы расположены в различных сегментах Интернет и имеют отличные характеристики сетевой доступности, как и требуется для корректной работы DNS.
Заказать сервис очень просто — в разделе услуг системы самообслуживания выберите пункт «Хостинг DNS», затем «Вторичные NS (ns*.layer6.net)». Обратите внимание, что услуга бесплатна для тех пользователей, которые имеют другие активные сервисы — на последнем шаге заказа в этом случае стоимость услуга будет равна €0,00. Через несколько минут DNS-хостинг будет активирован и вам придет сообщение об активации с подробным описанием способа настройки вашей панели ISPManager. Если же панель не используется, будет необходимо самостоятельно отредактировать конфигурацию «основного» DNS-сервера (разрешив transfer и notify), а также вручную указать в интерфейсе управления услугой доменные имена, которые должны обрабатываться нашим DNS-кластером.
Управление трафиком на основе географического расположения на основных и вспомогательных серверах с помощью политики DNS
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016
С помощью этого раздела вы узнаете, как создать политику DNS для управления трафиком на основе географического расположения, если развертывание DNS включает как основной, так и дополнительный DNS-серверы.
В предыдущем сценарии используется политика DNS для управления трафиком на основе Geo-Location с серверами-источниками. инструкции по настройке политики DNS для управления трафиком на основе географического расположения на основном DNS-сервере. Однако в инфраструктуре Интернета DNS-серверы широко развертываются в модели «первичная-вторичная», где доступная для записи копия зоны хранится на выбранных и защищенных основных серверах, а доступные только для чтения копии зоны хранятся на нескольких серверах-получателях.
Серверы-получатели используют протоколы зонных передач (AXFR) и добавочную зонную пересылку (IXFR) для запроса и получения обновлений зоны, содержащих новые изменения в зонах на основных DNS-серверах.
Дополнительные сведения о параметре AXFR см. в запросе IETF (Internet Engineering Task Force) для получения комментариев 5936. Дополнительные сведения о IXFR см. в статье запрос в IETF (Internet Engineering Task Force) для получения комментариев 1995.
Пример управления трафиком на основе Geo-Location Primary-Secondary
Ниже приведен пример использования политики DNS в развертывании по первичному вторичному приложению для обеспечения перенаправления трафика на основе физического расположения клиента, выполняющего запрос DNS.
В этом примере используются две вымышленные компании — облачные службы Contoso, которые предоставляют решения для веб-приложений и размещения в домене. и службы Woodgrove Food, которые предоставляют услуги по доставке пищи в нескольких городах по всему миру и имеют веб-сайт с именем woodgrove.com.
Чтобы клиенты woodgrove.com могли отвечать на запросы с веб-сайта, компания Woodgrove хочет, чтобы европейские клиенты направлялись в центр обработки данных США и американские клиенты, направляемые в центре обработки данных. Клиенты, расположенные в любом месте мира, могут направляться в любой из центров обработки данных.
Облачные службы Contoso имеют два центра обработки данных: один в США и другой в Европе, на котором Contoso размещает портал заказов на продукты для woodgrove.com.
Развертывание Contoso DNS включает два вторичных сервера: SecondaryServer1с IP-адресом 10.0.0.2; и SecondaryServer2с IP-адресом 10.0.0.3. Эти серверы-получатели функционируют в качестве серверов имен в двух разных регионах, где SecondaryServer1 находится в Европе и SecondaryServer2, расположенном в США.
В сервер (IP-адрес 10.0.0.1) доступна запись основной зоны с возможностью записи, где вносятся изменения в зоны. При обычной передаче зоны на серверы-получатели серверы-получатели всегда обновляются в соответствии с новыми изменениями зоны в сервер.
Этот сценарий показан на следующем рисунке.
Как работает система DNS-Primary-Secondary
При развертывании управления трафиком на основе географического расположения в первичном и вторичном развертывании DNS важно понимать, как обычная передача данных из основной зоны происходит перед изучением передачи уровня области зоны. В следующих разделах приведены сведения о передаче данных на уровне зоны и зоны.
Зонные передачи в первичном и вторичном развертывании DNS
Вы можете создать DNS-сервер с первичным и вторичным развертыванием и синхронизировать зоны, выполнив следующие действия.
Передача на уровне области зоны в первичном и вторичном развертывании DNS
Сценарий управления трафиком требует дополнительных действий по секционированию зон в разные области зоны. По этой причине дополнительные действия необходимы для перемещения данных в областях зоны на серверы-получатели, а также для перемещения политик и подсетей клиентов DNS на серверы-получатели.
После настройки инфраструктуры DNS с основным и дополнительным серверами передача уровня зоны выполняется автоматически службой DNS с помощью следующих процессов.
Чтобы обеспечить перемещение на уровне зоны, DNS-серверы используют механизмы расширений для DNS (EDNS0) OPT RR. Все запросы на зонные зоны (AXFR или IXFR) из зон с областями исходят из-за неявной записи ресурса EDNS0, для параметра ID которого по умолчанию задано значение «65433». Дополнительные сведения о ЕДНСО см. в запросе IETF о комментариях 6891.
Значение RR OPT — это имя области зоны, для которой отправляется запрос. Когда основной DNS-сервер получает этот пакет от доверенного вторичного сервера, он интерпретирует запрос как поступающий для этой области зоны.
Если на сервере-источнике есть область зоны, она реагирует на данные перемещения (КСФР) из этой области. Ответ содержит RR с тем же параметром с ИДЕНТИФИКАТОРом «65433» и значением, заданным для той же области зоны. Серверы-получатели получают этот ответ, извлекают сведения об области из ответа и обновляют эту конкретную область зоны.
После выполнения этого процесса сервер-источник будет поддерживать список доверенных получателей, которые отправили такой запрос области зоны для уведомлений.
Для дальнейшего обновления в области зоны на серверы-получатели отправляется уведомление IXFR с той же ЗАПИСЬю OPT. Область зоны, получающая это уведомление, делает запрос IXFR, содержащий эту запись ресурса OPT, и тот же процесс, описанный выше.
Настройка политики DNS для управления трафиком на основе Geo-Location Primary-Secondary
Прежде чем начать, убедитесь, что выполнены все действия, описанные в разделе Использование политики DNS для управления трафиком на основе Geo-Location с первичными серверами, а на основном DNS-сервере настроены зоны, области зоны, подсети клиентов DNS и политика DNS.
В этом разделе приведены инструкции по копированию подсетей клиентов DNS, областей зоны и политик DNS с основных серверов DNS на серверы-получатели DNS для начальной настройки DNS и проверки. В будущем может потребоваться изменить параметры подсети клиента DNS, области зоны и политики на сервере-источнике. В этом случае можно создать скрипты автоматизации для синхронизации серверов-получателей с сервером-источником.
Чтобы настроить политику DNS для ответов основной реплики на основе географического расположения, необходимо выполнить следующие действия.
В следующих разделах приведены подробные инструкции по настройке.
в следующих разделах приведены примеры Windows PowerShell команд, которые содержат примеры значений для многих параметров. Перед выполнением этих команд обязательно замените примеры значений в этих командах значениями, подходящими для вашего развертывания.
Членство в DnsAdmins(или аналогичное) требуется для выполнения следующих процедур.
Создание дополнительных зон
Можно создать вторичную копию зоны, которую необходимо реплицировать в SecondaryServer1 и SecondaryServer2 (при условии, что командлеты выполняются удаленно из одного клиента управления).
Например, можно создать вторичную копию www.Woodgrove.com в SecondaryServer1 и SecondarySesrver2.
для создания дополнительных зон можно использовать следующие команды Windows PowerShell.
Дополнительные сведения см. в разделе Add-днссерверсекондаризоне.
настройка Параметры зонных передач в основной зоне
Необходимо настроить параметры основной зоны таким образом, чтобы:
для настройки параметров зонных передач в основной зоне можно использовать следующие команды Windows PowerShell.
В следующем примере команда NOTIFY указывает, что сервер — источник будет отправлять уведомления об обновлениях в список выбора получателей.
Дополнительные сведения см. в разделе Set-днссерверпримаризоне.
Копирование подсетей клиента DNS
Необходимо скопировать подсети клиента DNS с основного сервера на серверы-получатели.
для копирования подсетей на серверы-получатели можно использовать следующие команды Windows PowerShell.
Дополнительные сведения см. в разделе Add-днссерверклиентсубнет.
Создание областей зоны на сервере-получателе
Необходимо создать области зоны на серверах-получателях. В DNS области зоны также начинают запрашивать Ксфрс с сервера-источника. При любом изменении областей зоны на сервере-источнике уведомление, содержащее сведения об области зоны, отправляется на серверы-получатели. Затем серверы-получатели могут обновить свои области зоны с помощью добавочного изменения.
для создания областей зоны на серверах-получателях можно использовать следующие команды Windows PowerShell.
В этих примерах команд параметр -ErrorAction Ignore включен, так как область зоны по умолчанию существует в каждой зоне. Область зоны по умолчанию не может быть создана или удалена. Конвейеризация приведет к попытке создать эту область, и она завершится ошибкой. Кроме того, можно создать области зон, не заданные по умолчанию, в двух дополнительных зонах.
Дополнительные сведения см. в разделе Add-днссерверзонескопе.
Настройка политики DNS
После создания подсетей, разделов (областей зоны) и добавления записей необходимо создать политики, соединяющие подсети и секции, чтобы при получении запроса из источника в одной из подсетей DNS-клиента ответ был получен из правильной области действия этой зоны. Для сопоставления области зоны по умолчанию не требуются никакие политики.
чтобы создать политику dns, связывающую подсети клиента DNS и области зоны, можно использовать следующие команды Windows PowerShell.
Теперь вторичные DNS-серверы настраиваются с помощью необходимых политик DNS для перенаправления трафика на основе географического расположения.
Когда DNS-сервер получает запросы на разрешение имен, DNS-сервер оценивает поля в DNS-запросе на соответствие настроенным политикам DNS. Если исходный IP-адрес в запросе разрешения имен соответствует любой из политик, область связанной зоны используется для ответа на запрос, а пользователь направляется к ресурсу, который является географически ближайшим к ним.
Вы можете создавать тысячи политик DNS в соответствии с требованиями к управлению трафиком, а все новые политики применяются динамически, без перезапуска DNS-сервера во входящих запросах.
Первичный и вторичные DNS
Вступление
Протоколы DNS являются частью основных стандартов Интернета. Они определяют процесс, при котором один компьютер может найти другой компьютер на основе его имени. Реализация протоколов DNS означает, что сервер содержит все программное обеспечение, необходимое для создания запросов и ответов службы доменных имен.
Примечание: BIND это программа для реализации протоколов системы доменных имен (DNS). Название BIND расшифровывается как “Berkeley Internet Name Domain”, так как программное обеспечение возникла в начале 1980-х годов в университете Калифорнии в Беркли. В последние годы слово BIND стала больше, чем аббревиатура.
Первичный и вторичный DNS
Первичный (primary, master) сервер DNS
Master сервер DNS хранит полную, оригинальную базу данных своей доменной зоны. Данные хранятся в файлах.
При запросе к первичному серверу DNS, он дает авторитативный ответ, благодаря которому по домену находится IP ресурса.
Важно понимать, что только на master сервере можно вносить изменения в базу данных DNS. Повторюсь, только на первичном сервере DNS, хранится база данных доменных имен прикрепленной к серверу доменной зоны этого DNS.
Вторичные (secondary, slave) сервера DNS
Как я уже упомянул, для каждой доменной зоны должно быть создано или прикреплено минимум два сервера DNS. Именно минимум. Число вторичных серверов может быть до 12. В большинстве своем, такое количество вторичных серверов это перебор. Как правило, с запасом, достаточно трех вторичных DNS. Да вы и сами видели, что у любого регистратора доменных имен, не больше четырех полей для ввода адресов DNS серверов. Один для первичного сервера, три – для вторичных.
На вторичных DNS серверах база данных имен не храниться, она периодически считывается с первичного сервера, естественно по сети. Периодичность считывания, определяется в записи DNS типа SOA (параметр Refresh, в секундах). Обычно, 3600 секунд, то есть информация на вторичном сервере обновляется каждый час.
Обращу внимание, что считывать данные любой вторичный сервер может не только с первичного сервера, но и любого вторичного. В этом случае, этот сервер с которого считывается информация, будет master сервером для вторичного сервера.
Как лучше разместить первичный и вторичные DNS
Нужно понимать, если DNS сервер «падает», то все сайты, находящиеся в доменной зоне этого DNS падают тоже. Если падает первичный сервер, отвечать на запросы начинают последовательно вторичные DNS сервера. А вот тут и проблема, если все DNS сервера лежат в одной сети, то при падении этой сети, падают все DNS. Отсюда простой вывод, «не нужно хранить все яйца в одной корзине» или в нашем случае, нужно разнесите DNS сервера по разным хостам, а еще лучше по разным территориальным зонам.
Например, хостинг – провайдер предоставил вам два сервера DNS для вашего домена. Правильнее наоборот, он включил ваш домен в доменную зону своих DNS серверов. Найдите в Интернет, сервер вторичных DNS (платный или бесплатный) и дополните свои первичный и вторичный сервера, сторонними DNS серверами. Тем самым, вы обезопасите свой ресурс на случай падения DNS серверов провайдера.
С хотингами могут быть проблемы с добавлением сторонних DNS серверов. У каждого провайдера, своя «песочница» и он устанавливает свои правила. Некоторые хостинги ограничивают клиентов, только своими DNS. Другое дело если у вас, сервер VPS/VDS. Здесь вы полный хозяин и можете сами создавать DNS сервера на своем домене. И опять-таки, на VPS создайте два своих DNS сервера и дополните их двумя сторонними, и лучше разными, DNS серверами.
Где необходимо регистрировать DNS сервера
DNS сервера должны быть прописаны (зарегистрированы) на вашем хостинге или сервере и у регистратора доменных имен. На сервере вторичных доменных имен вы регистрируете только свой домен и берете их вторичные DNS. Независимо от места прикрепления, ваш домен и ваши DNS сервера должны быть зарегистрированы, а, следовательно, связаны:
Выводы
Сервера вторичных DNS
Приведу несколько серверов, где можно взять вторичные DNS.
При аренде сторонних первичных, да и вторичных DNS серверов, с осторожностью относитесь к импортным DNS хостингам. Попробуйте проверить время их отклика на запрос, для этого есть масса online сервисов. Нормальное время ответа на запрос DNS должен быт от 20 до 120 ms. Хоть у импортных хостингов и сервера разбросаны по всему миру, но, к сожалению, этот мир может быть настолько далеко от вас, что время отклика достигает 800-4000 ms. А это не хорошо.
Как проверить DNS сервера сайта
Для проверки своих и чужих DNS воспользуйтесь любым сервисом Whois – сервиса проверки доменных имен. При проверке не забывайте, что при смене DNS кэширующий сервер очищается каждые 24-72 часа.