Что такое DNS-зона

Обновлено: 26.06.2024

В этой статье объясняются основные понятия доменов, зон DNS, записей DNS и наборов записей. Вы узнаете, как это поддерживается в Azure DNS.

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

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

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

DNS-зоны

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

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

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

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

Записи DNS

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

Типы записей

Каждая запись DNS имеет имя и тип. Записи организованы в различные типы в зависимости от данных, которые они содержат. Наиболее распространенным типом является запись «A», которая сопоставляет имя с адресом IPv4. Другим распространенным типом является запись MX, которая сопоставляет имя с почтовым сервером.

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

Наборы записей

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

Типы записей 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 позволяют владельцам доменов указывать, какие центры сертификации (ЦС) уполномочены выдавать сертификаты для своего домена. Эта запись позволяет центрам сертификации избежать неправильной выдачи сертификатов в некоторых случаях. Записи CAA имеют три свойства:

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

Тег: строка ASCII, которая может быть одной из следующих:

проблема: если вы хотите указать центры сертификации, которым разрешено выдавать сертификаты (всех типов)
issuewild: если вы хотите указать ЦС, которым разрешено выдавать сертификаты (только сертификаты с подстановочными знаками)
iodef: укажите адрес электронной почты или имя хоста, на которые центры сертификации могут отправлять уведомления о несанкционированных запросах на выпуск сертификатов

Записи CNAME

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

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

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

NS записи

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

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

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

Записи SOA

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

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

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

Записи SPF

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

В DNS RFC изначально был введен новый тип записи 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».
priority, вес, порт и цель указываются как параметры каждой записи в записи. установить.

TXT-записи

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

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

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

Несколько строк в записи 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, и в этом случае любые одновременные изменения, которые произошли, будут перезаписаны.

< tr>

Заголовок	Поведение
Нет	PUT всегда завершается успешно (без проверки Etag)
If-match	PUT завершается успешно только в том случае, если ресурс существует и Etag соответствует
If-match *	PUT завершается успешно, только если ресурс существует
If-none-match *	PUT успешно, только если ресурс не существует

Ограничения

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

Общедоступные зоны DNS

Ресурс	Ограничение
Общедоступные зоны DNS на подписку	250 1
Наборы записей на общедоступную зону DNS	10 000 1
Записей на набор записей в общедоступной зоне DNS	20
Количество записей псевдонимов для одного ресурса Azure	20

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

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

Ресурс	Ограничение
Частные зоны DNS на подписку	1000
Наборов записей на частную зону DNS	25000
Записей на запись установлено для частных зон DNS	20
Виртуальные сетевые ссылки на частную зону DNS	1000
Ссылки на виртуальные сети на частные зоны DNS с включенной автоматической регистрацией	100
Количество частных зон DNS, которые может получить виртуальная сеть связано с включенной автоматической регистрацией	1
Количество частных зон DNS, к которым может быть подключена виртуальная сеть	1000	1000
Количество DNS-запросов, которое виртуальная машина может отправить распознавателю DNS Azure, в секунду	1000 1
Максимальное количество DNS-запросов в очереди (ожидающих ответа) на виртуальную машину	200 1

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

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

Уровни зон DNS

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

Корневая зона DNS

Корневая зона DNS управляется 13 логическими серверами, которыми управляют такие организации, как Verisign, Исследовательские лаборатории армии США и НАСА. Любой рекурсивный DNS-запрос (узнайте больше о типах DNS-запросов) начинается с обращения к одному из этих корневых серверов и запроса сведений для следующего уровня вниз по дереву — сервера домена верхнего уровня (TLD).

Зоны ДВУ

Доменные зоны

Дополнительные зоны DNS

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

Все о файле зоны DNS

Файлы зон DNS определены в RFC 1035 и RFC 1034. Файл зоны содержит сопоставления между доменными именами, IP-адресами и другими ресурсами, организованные в виде ресурсных записей (RR).

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

Типы зон DNS

Существует два типа файлов зон:

Основной файл DNS, который авторитетно описывает зону
Файл DNS-кэша, в котором содержится список содержимого DNS-кэша — это только копия официальной зоны DNS.

Записи зоны DNS

В файле зоны каждая строка представляет запись ресурса DNS (RR). Запись состоит из следующих полей:

Имя — это буквенно-цифровой идентификатор записи DNS. Его можно оставить пустым, и он наследует свое значение от предыдущей записи.
TTL (время жизни) указывает, как долго запись должна храниться в локальном кэше DNS-клиента. Если он не указан, используется глобальное значение TTL в начале файла зоны.
Класс Record указывает пространство имен — обычно IN, то есть пространство имен Интернета.
Тип записи — это тип записи DNS. Например, запись A сопоставляет имя хоста с адресом IPv4, а CNAME — это псевдоним, который указывает имя хоста на другое имя хоста.
Данные записи содержат один или несколько информационных элементов, в зависимости от типа записи, разделенных пробелом. Например, запись MX состоит из двух элементов: приоритета и доменного имени почтового сервера.

Структура файла зоны

Файлы зоны DNS начинаются с двух обязательных записей:

Глобальное время жизни (TTL), которое указывает, как записи должны храниться в локальном кэше DNS.
Запись начала полномочий (SOA) — определяет основной полномочный сервер имен для зоны DNS.

После этих двух записей файл зоны может содержать любое количество записей ресурсов, включая:

Советы по файлам зон

При добавлении записи для имени хоста имя хоста должно заканчиваться точкой (.)
Имена хостов, которые не заканчиваются точкой, считаются относительными к имени основного домена — например, при указании записи "www" или "ftp" точка не нужна.
Вы можете добавлять комментарии в файл зоны, добавляя точку с запятой (;) после записи ресурса.

Пример файла зоны DNS

Зоны DNS и службы DNS следующего поколения

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

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

Это руководство предназначено для начинающих, и вы узнаете:

Что такое зона DNS.
Что такое файл зоны
Как зоны DNS связаны с доменами
Различные типы зон
Как работает перенос зоны

Чтобы объяснить, что такое зоны и файлы зон и как они работают, мы начнем с простой аналогии.

Представьте, что вы (Билл) организовали футбольную лигу, состоящую из трех команд.

Команды A, B, C, в каждой команде по 20 игроков.

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

Таким образом, вы можете создать бумажный список и записать в него имена и номера телефонов. (Это фактически был подход с файлом hosts.

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

В качестве альтернативы можно создать три списка: один для команды A, один для команды B и один для команды C.

Если добавится еще одна команда, вы создадите еще один бумажный список для teamD. Итак, теперь у вас есть три списка, но кто управляет списками?
Ну, у каждой команды есть менеджер, поэтому вы позволяете менеджеру вести список для команды. Итак

Джон руководит командой А
Фред управляет командой B
Джейн управляет командой C

Теперь организатору лиги Биллу нужен номер телефона Стива, который играет за TeamA. Как он это получает?

Сначала ему нужно узнать, у кого есть список игроков TeamA.

Поэтому Биллу нужен список с именами и номерами телефонов всех менеджеров..

На самом деле важно не имя менеджера, а только номер телефона.

Поэтому, если кто-то хочет найти номер телефона Стива из команды А, он связывается с Биллом, который возвращает номер телефона менеджера команды А (Джона). Затем они связываются с Джоном, чтобы узнать номер телефона Стива. Как показано на диаграмме ниже: Если сравнить это с IP-адресами и доменными именами

Стив = веб-сервер, например
Номер телефона = IP-адрес
TeamA = доменное имя
Билл, Джон, Фред, Джейн — это серверы имен.
Списки – это зоны или файлы зон.

Обратите внимание, что у Билла есть список не игроков, а менеджеров, т. е. он содержит не имена хостов (записи A), а имена менеджеров (записи сервера имен NS-записи).

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

то есть вы проходите дерево сверху вниз, а не снизу вверх. См. Общие сведения о поиске DNS

Первичные и вторичные зоны и перенос зон

Что происходит, когда менеджер уходит в отпуск?

Что ж, все, что им нужно сделать, это скопировать свой список и передать его кому-то другому (например, Барри), а также сообщить Биллу контактный номер этого человека, чтобы Билл мог обновить свой список.

Примечание. В DNS всегда есть два сервера имен для обеспечения устойчивости.

На диаграмме ниже я изменил список счетов, включив в него Барри.

Нам также нужно добавить примечание в список Джона, чтобы включить Барри, так как ему нужно отправить ему список и обновления списка.

Зона может быть основной или дополнительной зоной.

Примечание. Основные зоны теперь называются главными зонами, а дополнительные зоны теперь называются подчиненными зонами.

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

Для простоты только Джон может обновлять список. У него есть эталонная копия (основная зона).

Когда он меняет список, ему нужно отправить копию Барри, у которого есть копия (дополнительные зоны или подчиненные зоны).

В DNS эти изменения копируются во дополнительные зоны в процессе, называемом переносом зоны.

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

В нашем примере Барри запрашивает список обновлений у Джона.

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

По сути, перенос зоны — это просто копирование файла.

DNS-сервер, на котором размещена основная зона, обычно называется первичным сервером имен (главным), а сервер, на котором размещена дополнительная зона, — вторичным сервером имен (подчиненным).

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

По аналогии, у Джона может быть копия списка TeamB на случай, если Фред уедет в отпуск.

Поэтому DNS-сервер может быть как первичным, так и вторичным сервером имен.

И первичный, и вторичный серверы имен считаются авторитетными для домена.

Зоны и домены DNS

Использование зон и файлов зон позволяет DNS быть распределенной и отказоустойчивой системой.

Зоны DNS предоставляют очень простой и удобный способ группировки доменных данных из нескольких доменов вместе для хранения.

Чтобы домены могли совместно использовать зону и, следовательно, файл зоны, домены должны быть смежными.

Администратор домена будет нести ответственность за создание зон и делегирование ответственности за эти зоны администратору и DNS-серверу.

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

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

Хранилище файлов зоны

В нашей аналогии данные хранятся в бумажном списке и хранятся у менеджера группы.

Файл зоны – это текстовый файл формата, определенного в RFC 1035 и 1034, который хранится на DNS-сервере (сервере имен).

Файлы зон содержат данные IP и имени, записи MX и другие служебные записи.

Они также содержат связующие данные, соединяющие их с другими DNS-серверами.

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

На каких DNS-серверах есть данные для домена 2.
На каких DNS-серверах есть данные для домена 3, поддомена 1 (т. е. зоны 3).
Список корневых серверов (корневые подсказки)
Список серверов переадресации (если используется переадресация)

DNS-сервер, отвечающий за домен 1 — поддомен 1 и 2, т. е. Зона 2, не знает, у кого есть данные для домена 3, поддомен 1, то есть Зона 3, и не нуждается в них.

Структура файла зоны и содержимое записи

Файл зоны DNS состоит из директив и записей ресурсов.

Директивы начинаются с символа $. Есть три директивы

$TTL — значение срока жизни для зоны.
$ORIGIN – определяет базовое имя, используемое при замене доменного имени.
$INCLUDE– включить файл

Директива $TTL должна находиться в верхней части файла зоны перед записью SOA.

SOA (начало полномочий) должно присутствовать в файле зоны и определяет глобальные значения домена, главным образом связанные с передачей зоны.

Пример записи показан ниже.

Подробнее см. в этой главе книги Pro Bind and DNS.

Делегирование зоны

Когда администратор домена решает передать ответственность за дочерний домен кому-то еще, например. поддомен 1 домена 3. то они делегируют зону.

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

Мы видели это, когда Биллу нужно было знать, у кого есть список для Teams A.B.C.

Кэширование и TTL

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

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

В нашем примере выше, когда кто-то запрашивает номер телефона Стива, Билл запоминает эту информацию на короткое время на случай, если она понадобится кому-то еще.

Проблема с кэшированием данных заключается в том, что произойдет, если данные изменятся, но в кеше останутся старые данные?

Чтобы гарантировать, что клиенты и серверы не хранят старые данные слишком долго, записи DNS имеют значение TTL (время жизни), которое сообщает клиенту/серверу, как долго он может хранить данные в своем кэше.

Кэширование значительно снижает нагрузку на корневые DNS-серверы.

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

Зоны обратного сопоставления предоставляют данные для обратного поиска, т. е. IP-адрес для имени.

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

Поэтому без него некоторые приложения могут работать некорректно.

Обратное сопоставление использует домены IN-ADDR.ARPA для адресов IPv4 и IP6.ARPA для адресов IPv6.

Большинство инструментов администрирования DNS автоматически создают запись обратного сопоставления при создании записи хоста.
Подробнее см. в главе 3 книги Pro DNS and Bind.

Что такое DNS?

Каждое устройство в Интернете имеет уникальный IP-адрес, который позволяет другим устройствам легко идентифицировать устройство и связываться с ним. Но этот IP-адрес трудно запомнить людям, потому что он представляет собой набор чисел. Например, это 8.8.4.4 для IPv4 и 2001:4860:4860::8888 для IPv6 для Google.

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

Викимедиа

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

Что такое зоны DNS?

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

Другими словами, эти зоны созданы для простоты администрирования и резервирования, а также помогают администраторам повысить производительность и доступность.

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

Типы зон DNS

В целом существует пять типов зон DNS.

Основная зона
Вторичная зона
Зона, интегрированная с Active Directory
Заглушка
Зона обратного просмотра

Основная зона

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

Зона, интегрированная с Active Directory

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

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

Однако ограничение заключается в том, что вы должны установить DNS на контроллере домена.

Вторичная зона

Дополнительная зона – это доступная только для чтения копия другой основной, интегрированной в Active Directory или дополнительной зоны. Поскольку это только копия только для чтения, вы не можете вносить в нее какие-либо изменения.

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

Заглушка

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

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

Зона обратного просмотра

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

Теперь, когда вы хорошо разобрались с основами DNS и зонами DNS, давайте посмотрим, как их настроить и использовать.

Настройка зоны DNS

Вот пошаговая инструкция по настройке зоны DNS в Windows Server 2019, и этот процесс одинаков для Windows Server 2016, 2012 и т. д., вплоть до Windows 2000.

Перейдите к DNS-серверу и разверните панель слева.
Нажмите правой кнопкой мыши на сервере и выберите "Новая зона". Откроется мастер создания зоны.
На втором этапе вы увидите разные зоны, поэтому выберите нужную.
Наконец, обратите внимание на флажок справа внизу. Установите этот флажок, если хотите реплицировать эту зону на другие контроллеры домена.
На следующем шаге проверьте, является ли это зоной прямого или обратного просмотра.
Далее назовите свою зону, и в следующем окне вы будете проинформированы о том, что будет создан файл зоны.
В следующем окне вы можете разрешить динамические обновления. По умолчанию он не настроен в основной зоне, отличной от Active Directory, поэтому при необходимости измените значения по умолчанию. Рекомендуется использовать значение по умолчанию, чтобы предотвратить взлом DNS.
На следующем экране нажмите кнопку "Готово", и вы увидите новую зону DNS на своем DNS-сервере, и по умолчанию она будет иметь начальные полномочия, а также записи сервера имен.
Нажмите правой кнопкой мыши только что созданную зону DNS и выберите "Новый хост".
Введите внутренний IP-адрес. Вы также можете создать запись обратного указателя, установив флажок внизу. Наконец, нажмите «Добавить зону».
Для проверки откройте командную строку и введите ping, а затем имя только что созданной зоны. Вы должны увидеть введенный вами IP-адрес.

При этом ваши внутренние пользователи могут получить доступ к этой зоне. Но для внешних пользователей сделайте переадресацию порта 443 и порта 80 TCP.

Использование прямой консоли IPAM

Кроме описанного выше метода, вы также можете использовать прямую консоль IPAM для создания зон DNS. Вот как это сделать.

Перейдите в Диспетчер серверов и нажмите IPAM, чтобы открыть консоль.
Перейдите к разделу «Мониторинг и управление» и нажмите «Серверы DNS и DHCP». В разделе «Тип сервера» нажмите DNS-сервер, и вы увидите все DNS-серверы, управляемые IPAM.
Выберите DNS-сервер, к которому вы хотите добавить зону. Щелкните его правой кнопкой мыши и выберите «Создать зону DNS».
В диалоговом окне перейдите в «Общие свойства» и выберите тип и категорию зоны. Укажите имя зоны и просмотрите другие значения, прежде чем нажать кнопку "ОК".

Это создаст вашу зону DNS.

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

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

Зона DNS

Зона DNS относится к определенной части или административному пространству в глобальной системе доменных имен (DNS). Каждая зона DNS представляет собой границу полномочий, подлежащую управлению определенными объектами. Совокупность всех зон DNS, которые организованы в виде иерархического древовидного порядка каскадных доменов более низкого уровня, образуют пространство имен DNS.

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

Файл зоны DNS

Файл зоны DNS является представлением зоны DNS — это фактический файл, который содержит все записи для определенного домена. В файле зоны DNS каждая строка может содержать только одну запись, и каждый файл зоны DNS должен начинаться с TTL (время жизни), которое указывает, как долго записи должны храниться в кэше DNS-сервера. Другой обязательной записью для файла зоны DNS является запись SOA (Start of Authority), которая указывает основной полномочный сервер имен для зоны DNS.

После указания этих двух записей можно добавить дополнительные записи, например записи A или NS. При добавлении записи для имени хоста имя хоста должно заканчиваться точкой (.). Имена хостов, которые не заканчиваются точкой, считаются относительными к основному доменному имени, для которого создана Зона DNS. Например, при указании записи "www" точку после нее ставить не нужно.

Комментарии в файле зоны DNS должны начинаться с точки с запятой (;), а начало многострочного комментария обозначается квадратными скобками ("("), а комментарии снова должны начинаться с точки с запятой. Когда многострочные комментарии заканчиваются , они должны быть снова закрыты скобками ("")", размещенными на одной строке.

Пример файла зоны DNS:

$ORIGIN example.com. ; обозначает начало этого файла зоны в пространстве имен
$TTL 1h ; Время истечения срока действия по умолчанию для записи ресурса без собственного значения TTL
example.com. В SOA ns.example.com. root.example.com. (
2008120710 ; серийный номер этого файла зоны
1d ; обновление подчиненного устройства (1 день)
1d ; время повторного запуска подчиненного устройства в случае возникновения проблемы (1 день)
4w ; подчиненное устройство срок действия (4 недели)
1 час ; минимальное время кэширования в случае неудачных поисков (1 час)
)
example.com. NS dns1.ntchosting.com. ; ns.example.com — это сервер имен для example.com
example.com. NS dns2.ntchosting.com. ; ns.somewhere.com — это резервный сервер имен для example.com
example.com. MX 10 mx1.ntchosting.com
example.com. MX 10 mx2.ntchosting.com ; mail.example.com — это почтовый сервер для example.com
example.com. А 209.25.134.47 ; IP-адрес для «example.com»
www A 209.25.134.47

Управление зоной DNS

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

Читайте также: