Делегирование зоны dns: Создание или изменение делегирования DNS

Создание или изменение делегирования DNS

При добавлении в лес другого домена Active Directory в родительской зоне DNS должны быть созданы записи делегирования, указывающие на полномочные DNS-серверы для новой зоны. Записи делегирования передают орган разрешения имен и обеспечивают правильные ссылки на другие DNS-серверы и на клиентов новых серверов, которые были сделаны полномочными для новой зоны. При использовании DNS, интегрированной с Active Directory, эти DNS-серверы могут также быть контроллерами домена для этого домена.

Эти записи делегирования DNS можно создать перед запуском мастера установки службы AD DS, либо можно позволить мастеру создать их автоматически. Мастер проверяет наличие соответствующих записей в родительской зоне DNS после нажатия кнопки Далее на странице Дополнительные параметры контроллера домена. Если мастер не может проверить наличие этих записей в родительском домене, мастер предоставляет возможность создать записи автоматически и продолжить установку нового домена.

Например, чтобы добавить новый дочерний домен с именем na.contoso.com в лес contoso.com, в родительской зоне DNS необходимо создать делегирование для поддомена DNS (contoso.com).

Если полномочный DNS-сервер для вновь делегированного поддомена na.contoso.com называется ns1.na.contoso.com, чтобы сделать этот сервер известным другим серверам за пределами вновь делегированной зоны, для выполнения делегирования в новую зону в зоне contoso.com должны присутствовать две записи ресурсов. Эти записи ресурсов содержат следующие сведения:

• 
  Запись ресурса сервера имен (NS) для реализации делегирования. Эта запись ресурса сообщает, что сервер с именем ns1.na.example.microsoft.com является полномочным сервером для делегированного поддомена.
• 
  Для сопоставления имени сервера, заданного в записи ресурса сервера имен (NS) его IP-адресом, должна присутствовать запись ресурса узла (A или AAAA), также называемая связанной записью. Процесс разрешения имени узла в этой записи ресурса в делегированный DNS-сервер в записи ресурса сервера имен (NS) иногда называется «связывающим преследованием».

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

Делегирование обратной зоны подсети менее /24 в BIND. Как это работает / Хабр

Встала однажды передо мной задача, отдать одному из клиентов право на редактирование PTR-записей отданной ему подсети /28. Автоматизации для редактирования настроек BIND извне у меня нет. Поэтому я решил пойти другим путем — делегировать клиенту кусок PTR-зоны подсети /24.

Казалось бы — что может быть проще? Просто нужным образом прописываем подсеть и направляем на нужный NS как это делается с поддоменом. Но нет. Не так все просто (хотя на деле вообще примитивно, но интуиция не поможет ), поэтому я и пишу эту статью.

Кто захочет сам разобраться, тот может почитать RFC

Кто хочет готового решения, добро пожаловать под кат.

Чтобы не задерживать тех, кто любит метод копипасты, сначала я размещу практическую часть, а после нее теоретическую.

1. Практика. Делегируем зону /28

Допустим у нас есть подсеть 7.8.9.0/24. Нам надо делегировать подсеть 7.8.9.240/28 на днс-клиента 7.8.7.8 (ns1.client.domain).

На провайдерском днс надо найти файл, описывающий обратную зону этой подсети. Пусть будет 9.8.7.in-addr.arpa.

Записи от 240 до 255 комментируем, если есть. И в конец файла пишем следующее:

255-240  IN  NS      7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240

не забываем увеличить serial зоны и делаем

rndc reload

На этом провайдерская часть закончена. Переходим к клиентскому днс.

Для начала создадим файл /etc/bind/master/255-240.9.8.7.in-addr.arpa следующего содержания:

$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@                       1D IN SOA       ns1.client.domain. root.client.domain. (
                        2008152607      ; serial
                        3H              ; refresh
                        15M             ; retry
                        1W              ; expiry
                        1D )            ; minimum
@                       IN NS        ns1.client.domain.
@                       IN NS        ns2.client.domain.
241                     IN PTR          test.client.domain.
242                     IN PTR          test2.client.domain.
245                     IN PTR          test5.client.domain.

И в named.conf дописываем описание нашего нового файла:

zone "255-240.9.8.7.in-addr.arpa." IN {
        type master;
        file "master/255-240.9.8.7.in-addr.arpa";
};

B перезапускаем процесс bind.

/etc/init.d/named restart

Все. Теперь можно проверять.

#>  host 7.8.9.245 
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.

Обратите внимание, что отдается не только PTR-запись и но и CNAME. Так и должно быть. Если интересно почему, то добро пожаловать в следующую главу.

2. Теория. Как это работает.

Сложно настраивать и отлаживать черный ящик. Гораздо проще, если понимаешь что происходит внутри.

Когда мы делегируем поддомен в домене domain, то пишем что-то вроде этого:

client.domain.	NS	ns1.client.domain.
ns1.client.domain.	A	7.8.7.8

Мы говорим всем спрашивающим, что за этот участок не отвечаем и говорим кто отвечает. И все запросы на client.domain редиректятся на 7.8.7.8. При проверке мы видим следующую картину (опустим что там у клиента. это неважно):

# host test.client.domain
test.client.domain has address 7.8.9.241

Т.е. нам сообщили, что есть такая А запись и ее ip 7.8.9.241. Никакой лишней информации.

А как то же самое можно сделать с подсетью?

Т.к. наш DNS-сервер прописан в RIPE, то при запросе PTR ip-адреса из нашей сети, все равно первый запрос будет к нам. Логика та же что и с доменами. Вот только как вписать подсеть в файл зоны?

Пробуем вписать вот так:

255-240  IN  NS      7.8.7.8

И… чуда не произошло. Мы не получаем никакого перенаправления запроса. Все дело в том, что bind вообще не в курсе что вот эти записи в файле обратной зоны это ip-адреса и уж тем более не понимает запись диапазона. Для него это просто некий символьный поддомен. Т.е. для bind не будет разницы между «255-240» и «oursuperclient«. И запрос чтобы запрос ушел куда надо, адрес в запросе должен выглядеть вот так: 241.255-240.9.8.7.in-addr.arpa. Или вот так, если мы используем символьный поддомен: 241.oursuperclient.9.8.7.in-addr.arpa. Это отличается от обычного: 241.9.8.7.in-addr.arpa.

Руками такой запрос будет сделать проблематично. А если и получится, то все равно непонятно как это применить в реальной жизни. Ведь по запросу 7.8.9.241 нам по прежнему отвечает провайдерский DNS, а не клиентский.

А вот тут в игру вступают CNAME.

На стороне провайдера нужно сделать для всех ip-адресов подсети алиас в формат, который переправит запрос клиентскому DNS.

255-240  IN  NS      ns1.client.domain.
241     IN  CNAME   241.255-240
242     IN  CNAME   242.255-240
и т.д.

Это для трудолюбивых =).

А для ленивых больше подойдет конструкция ниже:

255-240  IN  NS      ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240

Теперь запрос информации по адресу 7.8.9.241 из 241.9.8.7.in-addr.arpa на днс-сервере провайдера будет преобразован в 241.255-240.9.8.7.in-addr.arpa и уйдет на днс-клиента.

Со стороны клиента нужно будет обрабатывать такие запросы. Соответственно мы создаем зону 255-240.9.8.7.in-addr.arpa. В ней мы в принципе можем размещать обратные записи для любых ip всей подсети /24, но спрашивать у нас будут только про те, которые провайдер к нам переадресует, так что побаловаться не получится =).

Для иллюстрации еще раз приведу пример содержания файла обратной зоны со стороны клиента:

$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@                       1D IN SOA       ns1.client.domain. root.client.domain. (
                        2008152607      ; serial
                        3H              ; refresh
                        15M             ; retry
                        1W              ; expiry
                        1D )            ; minimum
@                       IN NS        ns1.client.domain.
@                       IN NS        ns2.client.domain.
241                     IN PTR          test.client.domain.
242                     IN PTR          test2.client.domain.
245                     IN PTR          test5.client.domain.

Вот из-за того, что мы со стороны провайдера используем CNAME, то и получаем в ответ на запрос данных по ip-адресу две записи, а не одну.

#>  host 7.8.9.245 
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.

И не забывайте корректно настраивать ACL. Потому что бессмысленно забирать себе PTR-зону и не отвечать никому из внешки =).

что это такое, как делегировать доменное имя на другие DNS-серверы?

Понятие «делегирование домена» тесно связано с понятием «DNS-серверы», которое освещалось в статье Что такое DNS? Если коротко: делегировать домен — это прописать для него несколько DNS-серверов (как правило, 2 сервера).  

Домен делегирован: что это значит

Домен делегирован, когда для него прописаны DNS-серверы поставщика услуг. При регистрации домена на 2domains, для него автоматически указываются DNS-серверы ns1.reg.ru и ns2.reg.ru.

Домен не делегирован, когда для него не указаны DNS-серверы/указана некорректная пара. В таком случае при вводе домена в браузере вы увидите ошибку (Не удается получить доступ к сайту).  

Также домен могут снять с делегирования. Тогда даже при наличии DNS-серверов домен не будет работать. Домены снимают с делегирования (или разделегируют) при нарушении правил регистрации.  

Для чего нужно делегировать домены

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

Также на DNS-серверах, которые указаны для домена, будет храниться информация обо всех добавленных ресурсных записях.

Сколько занимает делегирование домена

Делегирование доменных имен происходит не сразу. Это связано с тем, что информация на корневых DNS-серверах обновляется один раз в сутки. Поэтому максимальное время ожидания делегирования — 24 часа. Этот же принцип работает при смене DNS-серверов. Поэтому если вы меняете DNS домена, сайт на нём может перестать работать, пока изменения не вступят в силу. 

Какие DNS-серверы указать, чтобы делегировать домен

При регистрации домена в 2domains для него автоматически прописываются DNS-серверы ns1.reg.ru и ns2.reg.ru. Также доступны следующие пары DNS-серверов: 

• ns1.hosting.reg.ru и ns2.hosting.reg.ru (для хостинга),
• ns5.hosting.reg.ru и ns6.hosting.reg.ru (для VPS и аренды серверов),
• свои DNS-серверы (для сторонних услуг).

Вы можете делегировать домен на другие DNS-серверы самостоятельно по инструкции. 

Как настроить DNS сервер в windows server 2012R2-2 часть. Настройка дополнительной зоны. Создание и настройка заглушки

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

Настройка dns windows server 2012 r2

Настройку dns windows server 2012 r2 мы начнем с открывания оснастки Диспетчер DNS. Как видите, contoso.com еще пустая.

Как настроить DNS сервер в windows server 2012R2-2 часть—08

Для этого идем на ваш Контроллер домена, у меня это dc. Выбираем свойства нужной зоны

Как настроить DNS сервер в windows server 2012R2-2 часть—09

Идем на вкладку сервера имен. Нажимаем Добавить

Как настроить DNS сервер в windows server 2012R2-2 часть—11

пишем имя нужного сервера, у меня это sccm

Как настроить DNS сервер в windows server 2012R2-2 часть—12

В итоге у меня получился вот такой список.

Как настроить DNS сервер в windows server 2012R2-2 часть—13

Дальше идем на вкладку передачи зон и смотрим чтобы стаяла галка Разрешить передачу зон и только на сервера из списка серверов имен.

Если все DNS-серверы расположены на контроллерах доменов, для обеспечения согласованности данных зон среди всех DNS-серверов используется репликацияActive Directory. Однако эта возможность недоступна при установке DNS-сервера на компьютере, не являющемся контроллером домена. В таком случае зону нельзя сохранять в Active Directory, вместо этого нужно использовать  стандартную зону, которая сохраняет данные в локальном текстовом файле на каждом DNS-сервере. Если в организации используется много DNS-серверов, то  исходные данные можно копировать в управляемые другими серверами  дополнительные зоны с правом только для чтения. Для того чтобы обеспечить  согласованность и обновление данных между основной и дополнительными зонами, нужно настроить передачу зон.

Передача зон, по сути, представляет собой извлечение данных, инициируемое в дополнительных зонах, копирование данных главной зоны, которая сама по себе может быть основной или еще одной дополнительной зоной. Главной зоне необязательно даже быть стандартной по отношению к дополнительной зоне — вы можете отконфигурировать дополнительную зону для основной зоны, интегрированной в Active Directory. К примеру, у вас есть два сайта — один в Нью-Йорке, другой в Лос-Анджелесе, причем каждый сайт принадлежит  отдельному домену Active Directory. В каждом домене можно обеспечить разрешение имен для противоположного домена, не устанавливая новый контроллер домена и не управляя трафиком репликации между двумя сайтами.

Включение передачи зон

Передача данных для дополнительных зон может быть инициирована в любом из трех случаев.

■ По истечении интервала обновления начальной записи SOA основной зоны.

■ При загрузке дополнительной зоны сервером.

■ В результате изменения конфигурации основной зоны, если эта зона настроена для уведомления дополнительной зоны об обновлениях.

По умолчанию передача для всех зон отключена. Ее нужно включить на вкладке Передача зон (Zone Transfers) окна свойств зоны. Установив флажок разрешения передачи зон, можно выбрать одни из трех параметров передачи.

■ На любой сервер (To Any Server) Этот параметр обеспечивает минимальную безопасность. Поскольку передача зоны представляет собой копирование данных зоны, этот параметр позволяет кому угодно с сетевым доступом к DNS-серверу просмотреть содержимое зоны, включая имена всех серверов и компьютеров с их IP-адресами. Поэтому данный параметр следует  использовать только в частных сетях с высоким уровнем безопасности.

■ Только на серверы, перечисленные на странице серверов зон (Only To ServersListed On The Name Servers Tab) Этот параметр позволяет выполнять передачу зон с записью NS только на те дополнительные DNS-серверы, которые полномочны для данных зон.

■ Только на серверы из этого списка (Only To The Following Servers) Этот параметр позволяет указать список дополнительных серверов, на которые будет выполняться передача зон. Для этих дополнительных серверов не требуется идентификация с помощью записи NS в зоне.

Настройка уведомлений

На вкладке Передача зон (Zone Transfers) можно также настроить уведомление, которое будет отправлено дополнительным серверам в случае изменений в основной зоне. Поскольку передача зон представляет собой операции PULL, их нельзя конфигурировать для переноса новых данных на дополнительные серверы. Вместо этого при модификации данных основная зона отправляет уведомление на все указанные серверы, управляющие дополнительными зонами. Дополнительная зона, получившая уведомление, инициирует передачу зоны.

Для настройки уведомлений на вкладке Передача зон (Zone Transfers) щелкните кнопку Уведомить (Notify). Откроется диалоговое окно Уведомление  (Notify), где можно указать дополнительные серверы, которые будут оповещаться при обновлении зоны на локальном главном сервере.

По умолчанию при включении передачи зон все серверы, перечисленные на вкладке Серверы имен (Name Servers), автоматически уведомляются об обновлениях зоны.

Обновление дополнительной зоны вручную

Если щелкнуть дополнительную зону правой кнопкой мыши на вашем DNS, у меня это vcenter, откроется контекстное меню, в котором можно использовать следующие операции для обновления зоны.

■ Перезагрузка (Reload)

Перезагружается дополнительная зона из локального хранилища.

■ Передать зону с основного сервера (Transfer From Master)

Сервер, управляющий локальной дополнительной зоной, определяет истечение интервала обновления серийного номера дополнительной зоны в записи SOA и выполняет передачу зоны с главного сервера.

■ Перезагрузить повторно зону с основного сервера (Reload From Master)

Выполняется передача зоны с главного сервера дополнительной зоны независимо от серийного номера в записи SOA дополнительной зоны.

Выбираем Передать зону с основного сервера

Как настроить DNS сервер в windows server 2012R2-2 часть—14

Как видим если нажать F5 зона передалась

Как настроить DNS сервер в windows server 2012R2-2 часть—15

Все записи прилетели, единственное они не редактируемые.

Как настроить DNS сервер в windows server 2012R2-2 часть—16

Иногда может не получиться, тогда перезапустите службу на сервере DNS где дополнительная зона, сто процентов проканает.

Зона-заглушка

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

Зоны-заглушки можно использовать в следующих целях:

• Поддержка самых текущих сведений о зоне. С помощью регулярного обновления зоны-заглушки для одной из дочерних зон DNS-сервер, содержащий как родительскую зону, так и зону-заглушку, будет поддерживать текущий список полномочных DNS-серверов для дочерней зоны.
• Улучшение разрешения имен. С помощью зон-заглушек DNS-сервер может выполнять рекурсию, используя список серверов имен из зоны-заглушки, без необходимости отправки запроса о пространстве имен DNS в Интернет или на внутренний корневой сервер.
• Упрощение администрирования DNS. С помощью использования зон-заглушек в инфраструктуре DNS можно распределить список полномочных DNS-серверов для зоны без необходимости использования дополнительных зон. Однако назначение зон-заглушек отличается от назначения дополнительных зон, и зоны-заглушки не являются альтернативой увеличению избыточности и распределению нагрузки.

Существует два списка DNS-серверов, участвующих в загрузке и поддержке зоны-заглушки:

• Список главных серверов, из которого DNS-сервер загружает и обновляет зону-заглушку. Главный сервер может быть главным или дополнительным DNS-сервером для зоны. В обоих случаях он будет располагать полным списком DNS-серверов для зоны.
• Список полномочных DNS-серверов для зоны. Список содержится в зоне-заглушке с использованием записей ресурсов сервера имен (NS).

Создадим зону заглушку или как еще ее называют stub zone.

Щелкаем правым кликом по зоны прямого просмотра и выбираем создать

Как настроить DNS сервер в windows server 2012R2-2 часть—17

Откроется мастер создания зоны.

Как настроить DNS сервер в windows server 2012R2-2 часть—18

Выбираем зона заглушка

Как настроить DNS сервер в windows server 2012R2-2 часть—19

задаем имя зоны

Как настроить DNS сервер в windows server 2012R2-2 часть—20

создать новый файл, в котором все будет храниться.

Как настроить DNS сервер в windows server 2012R2-2 часть—21

Пишем имя главного dns с которого будем запрашивать зону

Как настроить DNS сервер в windows server 2012R2-2 часть—22

Готово

Как настроить DNS сервер в windows server 2012R2-2 часть—23

Видим что файл зоны заглушки лежим в папке windows\system32\dns

Как настроить DNS сервер в windows server 2012R2-2 часть—24

Файл кстати открывается любым текстовым редактором.

Как настроить DNS сервер в windows server 2012R2-2 часть—25

Пример зоны-заглушки

Предположим, вы работаете администратором DNS-сервера Dns1.microsoft.com, который уполномочен для зоны Microsoft.com. Ваша компания имеет дочерний домен Active Directory с именем India.microsoft.com, для которого выполняется делегирование. При начальном делегировании дочерняя зона, интегрированная иActive Directory, содержит только два полномочных DNS-сервера — 192.168.2.1 и 192.168.2.2. Позже администраторы домена India.microsoft.com развертывают дополнительные контроллеры домена и устанавливают роль DNS-сервер (DNSServer) на новых контроллерах. Однако администраторы не уведомили вас о том, что добавили полномочные DNS-серверы на свой домен. В результате на сервереDns1.microsoft.com оказались не отконфигурированными записи новых DNS-серверов, уполномоченных для домена lndia.microsoft.com, и запросы продолжают пересылаться лишь на два DNS-сервера, заданный в начальном делегировании.

Эту проблему можно устранить, создав зону-заглушку на сервере Dns1. microsoft.com для домена India.microsoft.com. С помощью новой зоны-заглушки компьютер Dns1 посредством передачи зон изучает новые серверы имен, уполномоченные для родительской зоны India.microsoft.com. Таким образом, сервер Dns1 сможет направлять запросы пространства имен Inclia.microsoft.com на все полномочные DNS-серверы дочерней зоны.

В следующей статье мы поговорим про дополнительные настройки и вкладки DNS сервера windows server 2008R2-2012R2

что это такое, что значит снять с него домен и делегировать права на хостинг

Есть проблемы с ранжированием, проект не растет, хотите проверить работу своих специалистов по продвижению? Закажите профессиональный аудит в Семантике

Получи нашу книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

Подпишись на рассылку и получи книгу в подарок!

Создание домена состоит из двух этапов: регистрации и делегирования. В первом случае происходит получение доменного имени у регистратора с занесением информации в соответствующую базу. Далее необходимо привязать имя домена к хостингу. Этот процесс называют делегированием.

Что значит делегирование домена

Домен – это символьное имя или идентификатор. Он дает возможность пользователям находить адрес интернет-сервера. Для того, чтобы ресурс стал доступен для широкой аудитории по конкретному доменному имени, необходимо связать его с сервером hosting, на котором размещается сайт. Делегирование домена – это процесс присоединения домена к серверу. Хостинг входит в пакет по обслуживанию, а делегирование – одно из главных условий размещения файлов сайта в сети. Сервер, отвечающий за определенный домен, может передать часть его функций другому серверу, который, в свою очередь, берет на себя ответственность за работоспособность.

Проще говоря, делегировать домен – это присвоить ему адрес, по которому люди смогут переходить на сайт. Для этого в настройках домена регистрируется запись о ДНС-серверах организаций, предоставляющих услуги размещения сайтов на своих технических площадках. Воспользоваться функцией можно через панель управления.

Чтобы обеспечить бесперебойный процесс работы сайта и его доступность для пользователей, нужно внести записи сразу о нескольких DNS-серверах. Для проверки того, делегирован домен или нет, необходимо зайти на сервис проверки доменов Whois-сервис, ввести имя сайта в поисковую строку и получить соответствующую информацию. Делегированный домен имеет запись следующего содержания: «состояние: зарегистрирован, делегирован». В противном случае запись будет такой: «состояние: зарегистрирован, не делегирован».

Что значит снять домен с делегирования

Существует множество причин, в соответствии с которыми домен рискует оказаться снятым с делегирования. Он будет заблокирован и недоступен, однако whois-сервер все равно будет отображать информацию о прописанных ранее серверах и статусе домена.

Инициатива снятия с делегирования принадлежит либо компании, которая предоставляет хостинг, либо самому владельцу сайта. Регистратор имеет право принудительно снять домен с делегирования при нарушении условий сотрудничества или поступления жалоб от третьих лиц. В этом случае необходимо сразу обратиться к регистратору с письменным заявлением в свободной форме.

Веб-мастер может самостоятельно отвязать от домена все сервисы и связанные с ним сайты. Для этого следует выполнить простые действия:

• Найти нужный домен, авторизовавшись и пройдя в соответствующий раздел.
• Нажать кнопку «Приостановить делегирование домена».

В зависимости от доменной зоны, срок снятия с делегирования может занимать от нескольких часов до суток.

Как делегирование домена повлияет сайт

После делегирования домена на несколько серверов они несут ответственность него и берут на себя обязанности отвечать на запросы, в соответствии с идентичностью IP-адреса с доменным именем.

Хостинг DNS и хостинг веб-ресурса представляют собой разные услуги, несмотря на то, что часто предоставляются хостинговой компанией в едином пакете. Они не связаны друг с другом, поэтому веб-мастер может без негативных последствий поменять хостинг ДНС. Функциональность и работоспособность сайта от этого не пострадает.

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

Как делегировать права на домен

Когда домен и хостинг приобретаются по отдельности, рано или поздно перед веб-мастером встанет задача по их совмещению. Во-первых, это позволит сайту ранжироваться в поисковых системах и быть доступным для пользователей при вбивании домена в адресную строку. Во-вторых, только таким образом можно развивать проект.

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

1. Войти в панель удаленного администрирования веб-ресурсов через браузер, она располагается на сайте регистратора.
2. Найти домен, который подлежит делегированию, и нажать на него.
3. Удалить заполнение всех старых полей DNS на странице редактирования.
4. Открыть панель хостинга,перейти в раздел «Домены» и внести новую информации: имя, пароль и т. д.

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

Можно ли обойти процедуру делегирования

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

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

DNS сервер BIND — Сайт одного DevOpsa

Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.

Основные понятия Domain Name System

Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:

Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов, о которых ниже пойдет речь. «Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечающих за домены первого уровня (ru, net, org и др). Информация о серверах корневой зоны расположена на данном сайте корневых серверов. Настройки корневой зоны всегда доступны тут. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.

Зона — это любая часть дерева системы доменных имен, размещаемая как единое целое на некотором DNS-сервере. Зону, для бОльшего понимания, можно назвать «зоной ответственности». Целью выделения части дерева в отдельную зону является передача ответственности (Делегирование) за эту ветвь другому лицу или организации. На иллюстрации, примеры зон выделены синим градиентом (зона name., зона k-max.name. со всем подчиненными ресурсами, www.openoffice.org со всем подчиненными поддоменами и ресурсами). На иллюстрации выделены не все зоны, а лишь некоторые для общего понимания и представления. В каждой зоне имеется, по крайней мере, один авторитетный сервер DNS, который хранит ВСЮ информацию о зоне, за которую он отвечает.

Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:

Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.

Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — слэш, а в DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает структуру иерархии DNS. Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.

FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:

mail.k-max.name.
 |     |  |  | |
 |     |  |  | +-корневой домен
 |     |  |  +---домен первого уровня
 |     |  +------точка, разделяющая домены/части FQDN
 |     +---------домен второго уровня
 +---------------поддомен/домен третьего уровня, возможно - имя хоста

Различие между FQDN и обычным доменным (неFQDN) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.

Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.

Итак, на схеме выше мы рассмотрели корневой домен, следующим в иерархии идут домены первого/верхнего уровня, они жеTLD, они же Top-Level Domain. К данным доменам относятся национальные домены (ru., ua. и др) и общие домены (com., net., и др). Существуют так же специализированные домены, которые не опубликованы в системе DNS, но используются программами (домен .onion используется анонимной сетью Tor для перехвата и последующей маршрутизации обращений к скрытым сервисам этой сети). Еще есть т.н. зарезервированные доменные имена, определенные в RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. К таким именам относятся например example.com, example.org и example.net, а также test, invalid и др. Ниже по иерархии, как видно, идут домены третьего уровня и т.д. Заканчивается доменная иерархия —именами хостов, которые задаются соответствующими ресурсными записями или хостовыми записями.

Ресурсные записи

Ресурсная запись — это то, собственно ради чего в конечном счете и существует DNS. Ресурсная запись — это единица хранения и передачи информации в DNS. Каждая такая запись несет в себе информацию соответствия какого-то имени и служебной информации в DNS, например соответствие имени домена — IP адреса.

Запись ресурса состоит из следующих полей:

• имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись, либо IP адрес. При отсутствии данного поля, запись ресурса наследуется от предыдущей записи.
• Time To Live (TTL) — дословно «время жизни» записи, время хранения записи в кэше DNS (после указанного времени запись удаляется), данное поле может не указываться в индивидуальных записях ресурсов, но тогда оно должно быть указано в начале файла зоны и будет наследоваться всеми записями.
• класс (CLASS) — определяет тип сети, (в 99,99% случаях используется IN (что обозначает — Internet). Данное поле было создано из предположения, что DNS может работать и в других типах сетей, кроме TCP/IP)
• тип (TYPE) — тип записи синтаксис и назначение записи
• данные (DATA) — различная информация, формат и синтаксис которой определяется типом.

При этом, возможно использовать следующие символы:

• ;   —  Вводит комментарий
• #  —  Также вводит комментарии (только в версии BIND 4.9)
• @  — Имя текущего домена
• ( )    — Позволяют данным занимать несколько строк
• *    — Метасимвол (только в поле имя)

Со всем набором ресурсных записей можно ознакомиться в wikipedia. Наиболее часто применяемые ресурсные записи следующими(далее, мы обязательно рассмотрим их на практике):

Давайте рассмотрим, что есть Делегирование. Делегирование (корректнее сказать делегирование ответственности) — это операция передачи ответственности за часть дерева доменных имен (зону) другому лицу или организации. За счет делегирования, в DNS обеспечивается распределенность администрирования и хранения зон. Технически, делегирование заключается в выделении какой-либо части дерева в отдельную зону, и размещении этой зоны на DNS-сервере, принадлежащем другому лицу или организации. При этом, в родительскую зону включаются «склеивающие» ресурсные записи (NS и А), содержащие указатели на авторитативные DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS-серверах дочерней зоны. Например, на иллюстрации корневой домен делегирует полномочия серверам отвечающим за TLD, TLD же в свою очередь, делегируют полномочия управления зонами — серверам второго уровня, иногда на этом цепочка заканчивается, но бывает, что делегирование простирается до 4 и даже 5 уровней.

Для бОльшего понимания, приведу пример. Делегирование управления поддоменом k-max.name другому лицу (в моем случае — хостеру) приводит к созданию новой зоны, которая администрируется независимо от остального пространства имен (независимо от вышестоящего name.). Зона k-max.name после делегирования полномочий теперь не зависит от name. и может содержать все (вернее сказать — любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name.содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или любая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name,ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.

Т.о. после делегирования ответственности, информация хранимая делегирующей зоной уже не включает информацию по делегированному поддомену и его ресурсным записям хостов, а хранит информацию о серверах имен, являющихся для делегируемого поддомена авторитативными. Это и есть «склеивающие» записи, о чем я выше уже говорил. В таком случае, если у DNS-сервера родительского домена запрашиваются данные об адресе, принадлежащем делегированному поддомену, в ответ предоставляется список DNS-серверов, которые обладают соответствующей информацией.

Серверы DNS

Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Кроме данных типов, существует еще один тип — кэширующий.

Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.

Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного отвторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) иинкрементальное (incremental) копирование зоны (IXFR).

Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.

Возможно так же настроить DNS в режиме stels (т.н. невидимый), информацию о данном сервере невозможно получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем самым оградить зону от атак на зону.

Клиенты DNS (resolver)

Как же программы на конечных машинах знают куда и в каком виде посылать запросы DNS? Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется библиотека Resolver. Это не какое-то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают системные вызовы gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании настроек в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то файл /etc/hosts или DNS) и в каком порядке использовать. В ранних версиях библиотеки Linux — libc, использовалсяфайл /etc/host.conf. Вот фрагмент файла, который нас интересует:

root@DNS:~# cat /etc/nsswitch.conf
......
hosts:          files dns
networks:       files

Две строки данного фрагмента указывают ядру производить преобразование имен хостов в IP (строка hosts: files dns) сначала изфайла hosts, затем силами DNS, а так же преобразование имен сетей в IP (строка networks: files) с помощью файла /etc/network.Возможны так же параметры nis или nisplu, определяющие использовать Network Information System (NIS) чтобы найти адрес. Порядок, в котором перечислены сервисы, определяет последовательность их опроса.
Если согласно /etc/nsswitch.conf запрос отправляется DNS, то используются настройки из файла /etc/resolv.conf, который определяеткакие серверы DNS использовать. Вот типичный пример файла /etc/resolv.conf:

root@DNS:~# cat /etc/resolv.conf
nameserver 192.168.1.1
nameserver 192.168.1.2
domain  examle.com

Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. В данном файле указано использовать север имен сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х параметров nameserver. Если опция nameserver не задана, то резолвер попытается соединиться с сервером на локальном хосте. Параметр domain определяет заданное по умолчанию имя домена, которое будет подставлено, когда DNS не удастся найти имя хоста. Существует так же опция search, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.

Кроме кэша на ДНС сервере, существуют кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:

Запросы DNS

В DNS имеются следующие типы запросов: итеративный (он же прямой), обратный и рекурсивный.

Итеративный (он же прямой, он же нерекурсивный) запрос посылает доменное имя DNS серверу и просит вернуть либо IP адрес этого домена, либо имя DNS сервера, авторитативного для этого домена. При этом, сервер DNS не опрашивает другие серверы для получения ответа. Так работают корневые и TLD серверы.

Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.

Обратный запрос посылает IP  и просит вернуть доменное имя.

Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.

Обычно, провайдер выдает в локальной сети стоит DNS-сервер, обрабатывающий рекурсивные запросы, а так же, скорее всего, он настроен на кэширование запросов, что экономит трафик и снижает нагрузку на сеть. Схему взаимодействия клиента и DNS серверов можно представить следующей картинкой:

Давайте разберем, что тут нарисовано по шагам:

1. Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запрос резолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
2. Резолвер посылает запрос указанному серверу имен.
3. Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запрос серверу, отвечающему за корневую зону.
4. Сервер корневой зоны не обрабатывает рекурсивные запросы, в результате обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
5. Сервер последовательно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
6. пока не получает удовлетворительный ответ, данных шагов может быть больше, в зависимости от длины доменного имени
7. и «вложенности» доменных имен.
8. В итоге, сервер получает необходимый ответ от сервера имен, хранящего необходимую ресурсную запись о хосте.
9. Сервер провайдера локальной сети возвращает резолверу клиента запрошенные данные.

Обычно, количество шагов сокращено до минимума, т.к. на пути прохождения запросов встречается кэширующий сервер, который хранит необходимую информацию в кэше. В данной схеме может возникнуть вопрос: каким образом локальный DNS сервер, получивший рекурсивный запрос от резолвера, выбирает DNS-сервер из списка авторитативных? Существует множество корневых DNS-серверов в сети Интернет, какому из корневых серверов наш DNS-сервер отправит запрос?

Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.

До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.

Ответы DNS сервера

Ответы DNS бывают следующего типа:

• Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
• Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).

Ответ DNS обычно содержит следующую информацию:

• Запись заголовка — служебную информацию о запросе.
• Запись запроса — повторяет отправленный запрос.
• Запись ответа — собственно, сам ответ.
• Записи авторитетных серверов — информацию об авторитетных серверах, хранящих информацию по текущему запросу.
• Дополнительную информацию — дополнительные записи, например адреса NS-серверов.

Вышенаписанное наглядно подтверждается утилитой dig:

root@DNS:~# dig ya.ru
; <<>> DiG 9.7.3 <<>> ya.ru (раздел заголовка)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53499
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION: (раздел запроса)
;ya.ru.                         IN      A

;; ANSWER SECTION: (раздел ответа)
ya.ru.                  4813    IN      A       87.250.250.203
ya.ru.                  4813    IN      A       87.250.251.3
ya.ru.                  4813    IN      A       93.158.134.3
ya.ru.                  4813    IN      A       93.158.134.203
ya.ru.                  4813    IN      A       213.180.204.3
ya.ru.                  4813    IN      A       77.88.21.3
ya.ru.                  4813    IN      A       87.250.250.3

;; AUTHORITY SECTION: (авторитативные сервера)
ya.ru.                  4813    IN      NS      ns1.yandex.ru.
ya.ru.                  4813    IN      NS      ns5.yandex.ru.

;; ADDITIONAL SECTION: (дополнительная информация - адреса авторитативных name servers)
ns5.yandex.ru.          345565  IN      A       213.180.204.1
ns1.yandex.ru.          345565  IN      A       213.180.193.1
ns1.yandex.ru.          3565    IN      AAAA    2a02:6b8::1

;; Query time: 7 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Jul  2 23:02:45 2011
;; MSG SIZE  rcvd: 238

Обратное преобразование имен

DNS используется в первую очередь для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый Обратное преобразование имен или обратным отображением. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может эффективно выполнять поиск по IP адресу в такой базе. Для обратного преобразования в DNS используется специальный домен in-addr.arpa. Ресурсные записи в данном домене в поле Nameсодержат IP-адреса, в поле Type — PTR, а в поле Data — FQDN-имя соответствующее данному IP.

На схеме представлена структура домена arpa. Думаю, что тут все довольно наглядно. Домен arpa. имеет 2 поддомена in-addr иip6, отвечающие за IPv4 и IPv6 адреса соответственно. Домен in-addr.arpa. имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых так же имеет по 256 поддоменов.

В целях уменьшения объёма нежелательной корреспонденции (спама) многие почтовые серверы могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.

Наглядно приведенную схему можно представить командами:

[root@DNS~]# dig www.ru
...
;; QUESTION SECTION:
;www.ru                                IN      A

;; ANSWER SECTION:
www.ru                 52119   IN      A       194.87.0.50
...
[root@DNS~]# dig -x 194.87.0.50
...
;; QUESTION SECTION:
;50.0.87.194.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
50.0.87.194.in-addr.arpa. 30385 IN      PTR     www.ru
....

При этом, команду dig -x 194.87.0.50 правильнее будет представить как dig 50.0.87.194.in-addr.arpa., то есть записи в поддоменах *.in-addr.arpa. представлены в так называемой обратной нотации (или reverse форме), то есть хосту с IP 194.87.0.50 будет соответствовать PTR-запись, имеющая FQDN 50.0.87.194.in-addr.arpa., которая в свою очередь указывает на домен www.ru  Хочется отметить, что чаще всего за обратную зону и ее редактирование отвечает поставщик интернета.

Как и обещал, описываю ресурсную запись PTR в домене IN-ADDR.ARPA, соответствующая приведенной выше записи А для машины www.ru. будет иметь такой вид:

50.0.87.194 IN PTR www.ru

Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно «www.ru«. Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — IN-ADDR.ARPA.(заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:

80 IN PTR www.ru

Регистрация доменных имен

В двух словах хотел бы затронуть вопрос регистрации доменных имен.

Регистрация доменов — это действие, посредством которого клиент сообщает регистратору, каким DNS-серверам следует делегировать поддомен, и также снабжает регистратора контактной и платежной информацией. Регистратор передает информацию в соответствующий реестр. Чаще всего, это процесс внесения в реестр зоны первого уровня (то есть в TLD зоны ru, com или др.), записи о новом доменном подимени.

Регистратор доменных имён — это организация, имеющая полномочия создавать (регистрировать) новые доменные имена и продлевать срок действия уже существующих доменных имён в домене, для которого установлена обязательная регистрация.

Уровни доменов, для которых необходима обязательная регистрация лица, ответственного за домен, следующие:

• корневой домен
• все домены первого уровня (TLD)
• некоторые домены второго уровня (например, com.ru или co.uk)

Регистратором для корневого домена является организация ICANN. Чтобы стать регистратором доменов в зонах второго уровня (.com .net .org .biz .info .name .mobi .asia .aero .tel .travel .jobs …), необходимо получить аккредитацию ICANN.

Правила регистрации в международных (gTLD — com., org, и др.) доменах устанавливаются ICANN. Правила регистрации в национальных (ccTLD — ru, us и др.) доменах устанавливаются их регистраторами и/или органами власти соответствующих стран, например единые правила для всех регистраторов в доменах .ru, и.рф задаются Координационным центром национального домена сети Интернет. Для многих доменов (в том числе и для ru) регистратор не единственный. При наличии нескольких регистраторов все они должны использовать единую (централизованную или распределённую) базу данных для исключения конфликтов и обеспечения уникальности доменного имени.

Услуга регистрации домена в большинстве случаев платная, цену и условия регистрации определяет регистратор. Для регистрации домена, необходимо выбрать свободное имя и отправить заявку на регистрацию у одного из регистраторов (например nic.ru), оплатить предоставление услуги. После подтверждения регистрации, необходимо в интерфейсе регистратора определить (делегировать) dns сервера, скорее всего это будут DNS вашего хостера.

В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.

Так же хочу отметить, что доменный адрес и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.

Резюме

Итак, в сегодняшней статье я постарался как можно понятней описать работы доменной системы имен. Надеюсь, это у меня получилось. Мы рассмотрели иерархическую структуру базы данных DNS, а так же рассмотрели процессы взаимодействия клиентов и серверов DNS, а так же разновидности серверов DNS. В следующей статье я рассмотрю практические вопросы установки и настройки DNS сервера BIND на Linux. Буду рад Вашим комментариям.

Что еще почитать:

man (5) resolver: http://www.opennet.ru/man.shtml?topic=resolver&category=5&russian=0
man (3) gethostbyname:  http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=gethostbyname&category=3
Linux Network Administrators Guide v2 Russian: скачать.
RFC882, 1035, 1183

>Делегирование управления DNS-зоной | Путь Тыжменеджера

>

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

однако это не даст ему прав соединяться с сервером посредством консоли DNS (мы можем, конечно, работать с dnscmd, скажем, но… GUI есть GUI =) ):

Что делать в такой ситуации? Ну мы можем дать нашему младшему администратору административные полномочия на сервере, но:

1. это немного слишком

2. он получит права на весь DNS, а не только на зону

3. обычно DNS-серверы расположены на DC, так что наш младшой получит права администратора домена

Оказывается, достаточно просто дать ему право Read на сам объект сервера в консоли DNS:

После чего наш младшой уже будет иметь тот доступ, который мы ему желали выдать:

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

Поделиться ссылкой:

Понравилось это:

Нравится Загрузка…

Похожее

Обзор делегирования

Azure DNS | Документы Microsoft

• 19.02.2019
• 4 минуты на чтение

В этой статье

Azure DNS позволяет размещать зону DNS и управлять записями DNS для домена в Azure. Чтобы DNS-запросы для домена могли достичь Azure DNS, домен должен быть делегирован в Azure DNS из родительского домена.Имейте в виду, что Azure DNS не является регистратором домена. В этой статье объясняется, как работает делегирование домена и как делегировать домены в Azure DNS.

Как работает DNS-делегирование

Домены и зоны

Система доменных имен — это иерархия доменов. Иерархия начинается с «корневого» домена, имя которого просто «». ‘. Ниже находятся домены верхнего уровня, такие как com, net, org, uk или jp. Ниже этих доменов верхнего уровня находятся домены второго уровня, такие как org.uk ‘или’ co.jp ‘. И так далее. Домены в иерархии DNS размещаются с использованием отдельных зон DNS. Эти зоны распределены по всему миру и размещаются на серверах имен DNS по всему миру.

Зона DNS — домен — это уникальное имя в системе доменных имен, например contoso.com. Зона DNS используется для размещения записей DNS для определенного домена. Например, домен contoso.com может содержать несколько записей DNS, таких как mail.contoso.com (для почтового сервера) и www.contoso.com ‘(для веб-сайта).

Регистратор доменов — Регистратор доменов — это компания, которая может предоставлять доменные имена в Интернете. Они проверяют, доступен ли Интернет-домен, который вы хотите использовать, и позволяют вам его приобрести. После регистрации доменного имени вы становитесь его законным владельцем. Если у вас уже есть Интернет-домен, вы будете использовать текущего регистратора домена для делегирования в Azure DNS.

Дополнительную информацию об аккредитованных регистраторах доменов см. В разделе «Регистраторы, аккредитованные ICANN».

Разрешение и делегирование

Есть два типа DNS-серверов:

• На полномочном DNS-сервере размещаются зоны DNS. Он отвечает на запросы DNS только для записей в этих зонах.
• Рекурсивный DNS-сервер не поддерживает зоны DNS. Он отвечает на все DNS-запросы, вызывая авторитетные DNS-серверы для сбора необходимых данных.

Azure DNS предоставляет авторитетную службу DNS. Он не предоставляет рекурсивную службу DNS.Облачные службы и виртуальные машины в Azure автоматически настраиваются для использования рекурсивной службы DNS, которая предоставляется отдельно как часть инфраструктуры Azure. Сведения о том, как изменить эти параметры DNS, см. В разделе Разрешение имен в Azure.

DNS-клиенты на ПК или мобильных устройствах обычно вызывают рекурсивный DNS-сервер для выполнения любых DNS-запросов, необходимых клиентским приложениям.

Когда рекурсивный DNS-сервер получает запрос DNS-записи, такой как «www.contoso.com», ему сначала необходимо найти сервер имен, на котором размещена зона для «contoso.com ‘домен. Чтобы найти сервер имен, он запускается с корневых серверов имен, а оттуда находит серверы имен, на которых размещена зона com. Затем он запрашивает серверы имен com, чтобы найти серверы имен, на которых размещена зона contoso.com. Наконец, он может запрашивать у этих серверов имен «www.contoso.com».

Эта процедура называется преобразованием имени DNS. Строго говоря, разрешение DNS включает дополнительные шаги, такие как отслеживание CNAME, но это не важно для понимания того, как работает делегирование DNS.

Как родительская зона «указывает» на серверы имен для дочерней зоны? Для этого используется специальный тип DNS-записи, называемый NS-записью (NS означает «сервер имен»). Например, корневая зона содержит NS-записи для «com» ​​и показывает серверы имен для зоны «com». В свою очередь, зона com содержит записи NS для contoso.com, которые показывают серверы имен для зоны contoso.com. Настройка NS-записей для дочерней зоны в родительской зоне называется делегированием домена.

На следующем изображении показан пример DNS-запроса.Contoso.net и partners.contoso.net — это зоны Azure DNS.

1. Клиент запрашивает www.partners.contoso.net со своего локального DNS-сервера.
2. Локальный DNS-сервер не имеет записи, поэтому он делает запрос к их корневому серверу имен.
3. Корневой сервер имен не имеет записи, но знает адрес сервера имен .net , он предоставляет этот адрес DNS-серверу
4. Локальный DNS-сервер отправляет запрос на .net сервер имен.
5. Сервер имен .net не имеет записи, но знает адрес сервера имен contoso.net . В этом случае он отвечает адресом сервера имен для зоны DNS, размещенной в Azure DNS.
6. Локальный DNS-сервер отправляет запрос на сервер имен для зоны contoso.net , размещенной в Azure DNS.
7. Зона contoso.net не имеет записи, но знает сервер имен для партнеров .contoso.net и отвечает адресом. В данном случае это зона DNS, размещенная в Azure DNS.
8. Локальный DNS-сервер отправляет запрос на сервер имен для зоны partners.contoso.net .
9. Зона partners.contoso.net имеет запись A и отвечает IP-адресом.
10. Локальный DNS-сервер предоставляет IP-адрес клиенту
11. Клиент подключается к веб-сайту www.partners.contoso.net .

Каждая делегация фактически имеет две копии записей NS; один в родительской зоне указывает на дочернюю, а другой в самой дочерней зоне.Зона contoso.net содержит записи NS для contoso.net (в дополнение к записям NS в net). Эти записи называются авторитетными NS-записями, и они находятся на вершине дочерней зоны.

Следующие шаги

Узнайте, как делегировать свой домен в Azure DNS

.

Создание или обновление делегирования DNS

Когда вы добавляете другой домен Active Directory в лес, записи делегирования, указывающие на полномочные DNS-серверы для новой зоны, должны создаваться в родительской зоне системы доменных имен (DNS). Записи о делегировании передают полномочия по разрешению имен и предоставляют правильные ссылки на другие DNS-серверы и клиенты новых серверов, которые становятся полномочными для новой зоны. Если вы используете DNS, интегрированный в Active Directory, эти DNS-серверы также могут быть контроллерами домена для этого домена.

Вы можете создать эти записи делегирования DNS перед запуском мастера установки доменных служб Active Directory или попросить мастера создать их автоматически. Мастер проверяет наличие соответствующих записей в родительской зоне DNS после того, как вы щелкните Далее на странице Дополнительные параметры контроллера домена . Если мастер не может проверить, существуют ли записи в родительском домене, мастер предоставляет вам возможность автоматически создать записи и продолжить установку нового домена.

Например, чтобы добавить новый дочерний домен с именем na.contoso.com в лес contoso.com, необходимо создать делегирование для поддомена DNS (na.contoso.com) в родительской зоне DNS (contoso.com).

Если полномочный DNS-сервер для вновь делегированного субдомена na.contoso.com называется ns1.na.contoso.com, чтобы сделать этот сервер известным другим пользователям за пределами новой делегированной зоны, в contoso.com должны присутствовать две записи ресурсов. зона, чтобы завершить делегирование в новую зону.Эти записи ресурсов включают следующее:

• Запись ресурса сервера имен (NS) для выполнения делегирования. Эта запись ресурса объявляет, что сервер с именем ns1.na.example.microsoft.com является официальным сервером для делегированного поддомена.
• Запись ресурса хоста (A или AAAA), также известная как связующая запись, должна присутствовать для преобразования имени сервера, указанного в записи ресурса сервера имен (NS), в его IP-адрес. Процесс разрешения имени хоста в этой записи ресурса на делегированный DNS-сервер в записи ресурса сервера имен (NS) иногда называют «поиском клея».«

Чтобы создать делегирование зоны, откройте DNS Manager , щелкните правой кнопкой мыши родительский домен и выберите Новое делегирование . Следуйте инструкциям мастера создания делегирования для создания делегирования.

.Обзор зон и записей

DNS — Azure DNS

• 18.12.2017
• Читать 12 минут

В этой статье

На этой странице объясняются ключевые концепции доменов, зон DNS, записей и наборов записей DNS, а также способы их поддержки в Azure DNS.

Доменные имена

Система доменных имен — это иерархия доменов.Иерархия начинается с «корневого» домена, имя которого просто «». ‘. Ниже находятся домены верхнего уровня, такие как com, net, org, uk или jp. Ниже находятся домены второго уровня, такие как org.uk или co.jp. Домены в иерархии DNS распределены по всему миру и размещаются на серверах имен DNS по всему миру.

Регистратор доменного имени — это организация, которая позволяет вам приобретать доменное имя, например contoso.com . Приобретение доменного имени дает вам право управлять иерархией DNS под этим именем, например, позволяя вам указать имя www.contoso.com на веб-сайт вашей компании. Регистратор может разместить домен на своих собственных серверах имен от вашего имени или разрешить вам указать альтернативные серверы имен.

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

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

Зоны DNS

Зона DNS используется для размещения записей DNS для определенного домена. Чтобы начать размещать свой домен в Azure DNS, вам необходимо создать зону DNS для этого доменного имени. Каждая запись DNS для вашего домена создается внутри этой зоны DNS.

Например, домен contoso.com может содержать несколько записей DNS, например mail.contoso.com (для почтового сервера) и www.contoso.com (для веб-сайта).

При создании зоны DNS в Azure DNS:

• Имя зоны должно быть уникальным в группе ресурсов, и зона уже не должна существовать. В противном случае операция завершится неудачно.
• Одно и то же имя зоны можно повторно использовать в другой группе ресурсов или в другой подписке Azure.
• Если несколько зон имеют одно и то же имя, каждому экземпляру назначаются разные адреса серверов имен.Регистратор доменного имени может настроить только один набор адресов.

Примечание

Вам не нужно владеть доменным именем для создания зоны DNS с этим доменным именем в Azure DNS. Однако вам необходимо владеть доменом, чтобы настроить серверы имен Azure DNS в качестве правильных серверов имен для доменного имени с регистратором доменного имени.

Дополнительные сведения см. В разделе Делегирование домена в Azure DNS.

DNS-записи

Записать имена

В Azure DNS записи указываются с использованием относительных имен.Полное доменное имя (FQDN) включает имя зоны, тогда как относительное имя не включает. Например, относительное имя записи www в зоне contoso.com дает полное имя записи www.contoso.com .

Запись apex — это запись DNS в корне (или apex ) зоны DNS. Например, в зоне DNS contoso.com запись вершины также имеет полное имя contoso.com (иногда его называют голым доменом ). По соглашению относительное имя «@» используется для представления записей вершины.

Типы записей

Каждая запись DNS имеет имя и тип. Записи разбиты на различные типы в зависимости от содержащихся в них данных. Самый распространенный тип — это запись «А», которая сопоставляет имя с IPv4-адресом. Другой распространенный тип — это запись MX, которая сопоставляет имя почтовому серверу.

Azure DNS поддерживает все распространенные типы записей DNS: A, AAAA, CAA, CNAME, MX, NS, PTR, SOA, SRV и TXT.Обратите внимание, что записи SPF представлены с использованием записей TXT.

Рекордные наборы

Иногда необходимо создать более одной записи DNS с заданным именем и типом. Например, предположим, что веб-сайт www.contoso.com размещен на двух разных IP-адресах. Веб-сайту требуются две разные записи A, по одной для каждого IP-адреса. Вот пример набора рекордов:

  www.contoso.com. 3600 IN A 134.170.185.46
www.contoso.com. 3600 В А 134.170.188.221
  

Azure DNS управляет всеми записями DNS, используя наборов записей . Набор записей (также известный как набор записей ресурса ) — это набор записей DNS в зоне с одинаковым именем и одного типа. Большинство наборов записей содержат одну запись. Однако примеры, подобные приведенному выше, в котором набор записей содержит более одной записи, не являются редкостью.

Например, предположим, что вы уже создали запись A «www» в зоне «contoso».com ‘, указывая на IP-адрес’ 134.170.185.46 ‘(первая запись выше). Чтобы создать вторую запись, вы должны добавить эту запись к существующему набору записей, а не создавать дополнительный набор записей.

Типы записей SOA и CNAME являются исключением. Стандарты DNS не разрешают использование нескольких записей с одним и тем же именем для этих типов, поэтому эти наборы записей могут содержать только одну запись.

Срок службы

Время жизни, или TTL, указывает, как долго каждая запись кэшируется клиентами перед запросом.В приведенном выше примере TTL составляет 3600 секунд или 1 час.

В Azure DNS TTL указывается для набора записей, а не для каждой записи, поэтому для всех записей в этом наборе записей используется одно и то же значение. Вы можете указать любое значение TTL от 1 до 2 147 483 647 секунд.

Записи с подстановочными знаками

Azure DNS поддерживает записи с подстановочными знаками. Записи с подстановочными знаками возвращаются в ответ на любой запрос с совпадающим именем (если нет более близкого совпадения из набора записей без подстановочных знаков).Azure DNS поддерживает наборы записей с подстановочными знаками для всех типов записей, кроме NS и SOA.

Чтобы создать набор записей с подстановочными знаками, используйте имя набора записей «*». Кроме того, вы также можете использовать имя с символом «*» в качестве крайней левой метки, например, «* .foo».

CAA записи

Записи

CAA позволяют владельцам доменов указывать, какие центры сертификации (CA) имеют право выдавать сертификаты для их домена. Это позволяет центрам сертификации в некоторых случаях избегать неправильной выдачи сертификатов. Записи CAA имеют три свойства:

• Флаги : это целое число от 0 до 255, используемое для представления критического флага, имеющего особое значение в соответствии с RFC

.

• Тег : строка ASCII, которая может быть одной из следующих:
  • проблема : используйте это, если вы хотите указать центры сертификации, которым разрешено выдавать сертификаты (все типы)
  • issueewild : используйте это, если хотите указать центры сертификации, которым разрешено выдавать сертификаты (только сертификаты с подстановочными знаками).
  • iodef : укажите адрес электронной почты или имя хоста, на которые центры сертификации могут отправлять уведомления о неавторизованных запросах на выдачу сертификатов.
• Значение : значение для конкретного выбранного тега

Записи CNAME

Наборы записей CNAME не могут сосуществовать с другими наборами записей с тем же именем.Например, вы не можете создать набор записей CNAME с относительным именем «www» и запись A с относительным именем «www» одновременно.

Поскольку вершина зоны (name = ‘@’) всегда содержит наборы записей NS и SOA, которые были созданы при создании зоны, вы не можете создать набор записей CNAME на вершине зоны.

Эти ограничения вытекают из стандартов DNS и не являются ограничениями Azure DNS.

NS записи

Запись NS, установленная на вершине зоны (имя ‘@’), создается автоматически для каждой зоны DNS и автоматически удаляется при удалении зоны (ее нельзя удалить отдельно).

Этот набор записей содержит имена серверов имен Azure DNS, назначенных зоне. Вы можете добавить дополнительные серверы имен в этот набор записей NS для поддержки совместного размещения доменов с несколькими поставщиками DNS. Вы также можете изменить TTL и метаданные для этого набора записей. Однако вы не можете удалить или изменить предварительно заполненные серверы имен Azure DNS.

Это относится только к записи NS, установленной на вершине зоны. Другие наборы записей NS в вашей зоне (используемые для делегирования дочерних зон) можно создавать, изменять и удалять без ограничений.

Записи SOA

Набор записей SOA создается автоматически на вершине каждой зоны (name = ‘@’) и автоматически удаляется при удалении зоны. Записи SOA нельзя создавать или удалять отдельно.

Вы можете изменить все свойства записи SOA, за исключением свойства host, которое предварительно настроено для ссылки на имя основного сервера имен, предоставленное Azure DNS.

Серийный номер зоны в записи SOA не обновляется автоматически при внесении изменений в записи в зоне.При необходимости его можно обновить вручную, отредактировав запись SOA.

SPF записи

Записи структуры политики отправителя (SPF) используются для указания, какие почтовые серверы могут отправлять электронную почту от имени доменного имени. Правильная конфигурация записей SPF важна, чтобы получатели не пометили вашу электронную почту как нежелательную.

В RFC DNS изначально был представлен новый тип записи SPF для поддержки этого сценария. Для поддержки старых серверов имен они также разрешили использование типа записи TXT для указания записей SPF.Эта неоднозначность привела к путанице, которая была устранена в RFC 7208. В нем говорится, что записи SPF должны создаваться с использованием типа записи TXT. В нем также указано, что тип записи SPF устарел.

Записи SPF поддерживаются Azure DNS и должны быть созданы с использованием типа записи TXT. Устаревший тип записи SPF не поддерживается. При импорте файла зоны DNS все записи SPF, использующие тип записи SPF, преобразуются в тип записи TXT.

SRV записи

Записи

SRV используются различными службами для определения расположения серверов.При указании записи SRV в Azure DNS:

• Служба и протокол должны быть указаны как часть имени набора записей с префиксом подчеркивания. Например, _sip._tcp.name. Для записи на вершине зоны нет необходимости указывать «@» в имени записи, просто используйте службу и протокол, например, «_sip._tcp».
• Приоритет , вес , порт и цель указаны как параметры каждой записи в наборе записей.

TXT записей

записей TXT используются для сопоставления доменных имен с произвольными текстовыми строками. Они используются во многих приложениях, в частности, связанных с конфигурацией электронной почты, таких как Sender Policy Framework (SPF) и DomainKeys Identified Mail (DKIM).

Стандарты DNS позволяют одной записи TXT содержать несколько строк, каждая из которых может иметь длину до 254 символов. Если используется несколько строк, они объединяются клиентами и обрабатываются как одна строка.

При вызове API REST Azure DNS необходимо указать каждую строку TXT отдельно. При использовании портала Azure, PowerShell или интерфейсов CLI следует указать одну строку для каждой записи, которая при необходимости автоматически разделяется на сегменты по 254 символа.

Не следует путать несколько строк в записи DNS с несколькими записями TXT в наборе записей TXT. Набор записей TXT может содержать несколько записей, каждая из которых может содержать несколько строк.Azure DNS поддерживает общую длину строки до 1024 символов в каждом наборе записей TXT (для всех записей вместе).

Теги

Теги — это список пар «имя-значение», которые используются Azure Resource Manager для маркировки ресурсов. Azure Resource Manager использует теги для включения фильтрованных представлений вашего счета за Azure, а также позволяет вам установить политику, для которой требуются теги. Дополнительные сведения о тегах см. В разделе Использование тегов для организации ресурсов Azure.

Azure DNS поддерживает использование тегов Azure Resource Manager для ресурсов зоны DNS.Он не поддерживает теги в наборах записей DNS, хотя в качестве альтернативы «метаданные» поддерживаются в наборах записей DNS, как описано ниже.

Метаданные

В качестве альтернативы тегам набора записей Azure DNS поддерживает аннотирование наборов записей с помощью «метаданных». Подобно тегам, метаданные позволяют связывать пары имя-значение с каждым набором записей. Это может быть полезно, например, для записи цели каждого набора записей. В отличие от тегов, метаданные не могут использоваться для предоставления отфильтрованного представления вашего счета за Azure и не могут быть указаны в политике Azure Resource Manager.

Предположим, два человека или два процесса одновременно пытаются изменить запись DNS. Кто победит? И знает ли победитель, что он перезаписал изменения, созданные кем-то другим?

Azure DNS использует Etags для безопасной обработки одновременных изменений одного и того же ресурса. Etags отделены от тегов Azure Resource Manager. Каждый ресурс DNS (зона или набор записей) имеет связанный с ним Etag. Каждый раз, когда извлекается ресурс, также извлекается его Etag. При обновлении ресурса вы можете выбрать возврат Etag, чтобы Azure DNS могла проверить соответствие Etag на сервере.Поскольку каждое обновление ресурса приводит к регенерации Etag, несоответствие Etag указывает на то, что произошло одновременное изменение. Etags также можно использовать при создании нового ресурса, чтобы убедиться, что ресурс еще не существует.

По умолчанию Azure DNS PowerShell использует Etags для блокировки одновременных изменений зон и наборов записей. Дополнительный переключатель -Overwrite может использоваться для подавления проверок Etag, и в этом случае любые одновременные изменения, которые произошли, перезаписываются.

На уровне Azure DNS REST API теги Etags указываются с помощью заголовков HTTP. Их поведение представлено в следующей таблице:

Пределы

При использовании Azure DNS применяются следующие ограничения по умолчанию:

Публичные зоны DNS

¹ Если вам нужно увеличить эти ограничения, обратитесь в службу поддержки Azure.

Частные зоны DNS

¹ Эти ограничения применяются к каждой отдельной виртуальной машине, а не на уровне виртуальной сети.Запросы DNS, превышающие эти ограничения, отбрасываются.

Следующие шаги

.

зон DNS, интегрированных в Active Directory | Документы Microsoft

• 31.05.2017
• 2 минуты на чтение

В этой статье

Применимо к: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Серверы системы доменных имен

(DNS), работающие на контроллерах домена, могут хранить свои зоны в доменных службах Active Directory (AD DS).Таким образом, нет необходимости настраивать отдельную топологию репликации DNS, которая использует обычные передачи зон DNS, потому что все данные зоны реплицируются автоматически посредством репликации Active Directory. Это упрощает процесс развертывания DNS и дает следующие преимущества:

• Для репликации DNS создано несколько мастеров. Таким образом, любой контроллер домена в домене, на котором запущена служба DNS-сервера, может записывать обновления в зоны DNS, интегрированные в Active Directory, для доменного имени, для которого они являются полномочными.Отдельная топология передачи зоны DNS не требуется.

• Поддерживаются безопасные динамические обновления. Безопасные динамические обновления позволяют администратору контролировать, какие компьютеры и какие имена обновляют, и предотвращать перезапись неавторизованными компьютерами существующих имен в DNS.

DNS, интегрированный в Active Directory, в Windows Server 2008 хранит данные зоны в разделах каталога приложений. (Нет никаких изменений в поведении по сравнению с интеграцией DNS на базе Windows Server 2003 с Active Directory.) Во время установки AD DS создаются следующие разделы каталога приложений, относящиеся к DNS:

• Раздел каталога приложений в масштабе леса, который называется ForestDnsZones

• Разделы каталога приложений на уровне домена для каждого домена в лесу с именем DomainDnsZones

Дополнительные сведения о том, как AD DS хранит информацию DNS в разделах приложений, см. В Техническом справочнике DNS.

Примечание

Мы рекомендуем устанавливать DNS при запуске мастера установки доменных служб Active Directory (Dcpromo.исполняемый файл). Если вы это сделаете, мастер автоматически создаст делегирование зоны DNS. Дополнительные сведения см. В разделе «Развертывание корневого домена леса Windows Server 2008».

.