Управление трафиком на основе географического расположения на основных и вспомогательных серверах с помощью политики 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-сервера во входящих запросах.
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-хостинга — что это такое?
Пришло время подробно рассказать о нашей услуге, которую мы предоставляем бесплатно нашим пользователям 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
Вступление
Протоколы 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 часа.
Primary DNS vs. Secondary DNS and Advanced Use Cases
Related Resources
What Exactly Is Secondary DNS?
DNS Protocol
Redundant & Secondary DNS
What is Primary DNS?
A primary DNS server is the first point of contact for a browser, application or device that needs to translate a human-readable hostname into an IP address. The primary DNS server contains a DNS record that has the correct IP address for the hostname. If the primary DNS server is unavailable, the device contacts a secondary DNS server, containing a recent copy of the same DNS records.
How Does a Primary DNS Server Work?
When a computer or device needs to connect to another device on the Internet, it typically uses a human-readable domain name, like “www.example.com”. The browser or application needs to translate the domain name into a numeric Internet Protocol (IP) address like “192.100.100.1”. This translation is done by the Domain Name System (DNS).
The device first contacts the primary DNS server that hosts the controlling zone file. This file contains the authoritative DNS information for the domain or subdomain. “Authoritative” means it is the trusted source for information like the IP address of the domain, administrator contact information, and settings like Time to Live (how long this IP address should be saved in a local cache).
The primary DNS server server resolves the query by returning the IP address for the requested hostname. However, if the primary server is slow to respond, or is unavailable, the device is referred to one or more secondary DNS servers.
What is Secondary DNS?
Changes to DNS records—for example, changing the IP for a domain name—can only be done on a primary server, which can then update secondary DNS servers. DNS servers can be primary for one DNS zone and secondary for another DNS zone.
A secondary server holds a secondary DNS zone—a read-only copy of the zone file, which contains the DNS records. It receives an updated version of the copy in an operation called zone transfer. Secondary servers can pass a change request if they wish to update their local copy of the DNS records.
Secondary DNS servers are not mandatory—the DNS system can work even if only a primary server is available. But it is standard, and often required by domain registrars, to have at least one secondary server.
Benefits of having a secondary DNS server for a domain:
DNS Zone, Primary DNS and Secondary DNS Configuration
In the preceding discussion we referred to DNS zones. A DNS zone is a distinct part of the domain name space, delegated to a specific legal entity which is responsible for managing it.
For example, a root domain such as “acme.com” is a DNS zone, which can be delegated to a company, Acme Corporation Inc. Acme Corporation then assumes responsibility for setting up a primary DNS server, called an Authoritative Name Server, which holds correct DNS records for that domain.
DNS zones exist at higher and lower levels of the DNS hierarchy. For example, the Top Level Domain “.com” is also a DNS zone, which has an Authoritative Name Server providing DNS records for all the domains in the “.com” namespace. A subdomain, such as “support.acme.com” is also a DNS zone, which can be managed by Acme Corporation, or delegated to another entity.
Primary and Secondary DNS Management in Modern DNS Infrastructure
The classic primary/secondary DNS architecture is no longer used by modern, managed DNS providers.
Today, most DNS providers offer customers several name server IPs to use. Behind each of these IPs are pools of DNS servers, with requests routed via anycast (a one-to-many transport protocol). This provides improved redundancy and high availability compared to the primary/secondary model.
However, even in advanced DNS deployments, secondary DNS can help you:
To learn more about how you can leverage primary and secondary DNS to power state-of-the-art, high performance and highly available DNS deployments, see NS1’s Secondary DNS solution.
