Что такое a запись dns зоны: Обзор зон и записей DNS в службе DNS Azure

Файлы и записи зон DNS

Файл зоны

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

;
; Database file test.fio.ru.dns for test.fio.ru zone.
; Zone version: 1;
@ IN SOA mcio-08kwa653t4.fio.ru. admin.fio.ru. (
1 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL;
; Zone NS records
;
@ NS mcio-08kwa653t4.fio.ru.
;
; Zone records
;

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

Любой файл зоны должен содержать как минимум следующее:

• одну запись Start Of Authority (SOA), содержащую параметры зоны;
• не менее одной записи Name Server (NS), содержащей адреса DNS-серверов, ответственных за хранение и обслуживание зоны;
• не менее одной записи Host (A), содержащей информацию о соответствии имени DNS-сервера, указанного в каждой записи NS, его IP-адресу.

Записи зон

При создании и изменении зоны вы чаще всего будете использовать следующие типы записей:

Тип записи	Назначение записи
Start Of Authority (SOA)	Описывает зону и ее параметры. В файле зоны встречается однократно и не требует редактирования вручную
Name Server (NS)	Описывает один DNS-сервер
Host (A)	Описывает соответствие имени хоста его IP-адресу. Используется часто
Canonical Name (CNAME)	Описывает альтернативное имя для уже существующего хоста
Mail Exchanger (MX)	Описывает почтовый хост, обрабатывающий электронную почту домена
Pointer (PTR)	Описывает соответствие IP-адреса имени хоста. Используется в зонах обратного просмотра
Service Location (SRV)	Описывает сервисы, предоставляемые хостами

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

Внимание!

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

Общий синтаксис записей зон

Любая DNS-запись имеет следующий вид:

владелец [класс] [TTL] тип данные

Описание полей DNS-записи приведено в таблице.

Поле	Описание
владелец	Относительное или полное имя записи. Если значение этого поля совпадает с именем зоны, то вы можете использовать символ @ вместо полного имени зоны
класс	Определяет класс, к которому принадлежит запись. Например, IN указывает, что запись принадлежит к классу записей Интернет-ресурсов. Это единственный класс записей, поддерживаемых DNS-сервером, входящим в состав Windows 2000. В связи с этим в любой записи поле класса может быть опущено, хотя стандарт DNS требует обязательного указания класса записи
TTL	Определяет время жизни конкретной записи в кэше других DNS-серверов. Является необязательным для большинства типов записей. Если поле TTL у записи опущено, то берется соответствующее значение из параметров зоны (запись SOA). Для того, чтобы предотвратить кэширование записи указывайте значение 0 в качестве TTL
тип	Обязательное поле, содержащее один из стандартных текстовых идентификаторов, определяющих тип записи
данные	Обязательное поле, содержащее данные переменной длины. Формат данных определяется типом записи

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

Служебные записи (SOA и NS)

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

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

Синтаксис записи NS

Название	Name Server
Определена в	RFC 1035
Описание	Запись, указывающая один из серверов, обслуживающих зону. В виде NS-записей указываются все сервера (основной и дополнительные). Тот сервер, который указан в SOA-записи, считается основным, все остальные — дополнительными.
Синтаксис	владелец [класс] [TTL] NS хост
Параметры	Полное DNS-имя сервера, который должен быть определен в DNS. Допускается определение серверов в той же зоне, которую они обслуживают.
Пример	@ NS mcio-08kwa653t4.fio.ru @ NS host1.test.fio.ru

Синтаксис SOA-записи

Название	Start Of Authority
Определена в	RFC 1035
Описание	Запись, описывающая зону ответственности.
Синтаксис	владелец класс SOA первичный_сервер ответственный (редакция обновление повтор устаревание TTL)
Параметры	Первичный сервер — полное имя сервера, содержащего основную копию зоны. Ответственный — почтовый адрес лица, ответственного за управление зоной. Символ @ в почтовом адресе заменяется на точку.Редакция — число, указывающее порядковый номер редакции зоны. При внесении любых изменений вручную необходимо увеличивать это число, т. к. дополнительные DNS-серверы определяют необходимость копирования зоны именно по этому параметру. При изменении зоны через Консоль управления это число увеличивается автоматически.Обновление — интервал в секундах, в течение которого дополнительные DNS-серверы ожидают, прежде чем отправить запрос об изменении зоны. По истечении этого интервала дополнительный DNS-сервер запрашивает запись SOA с основного, проверяет в ней поле Редакция и определяет необходимость загрузки файла зоны. По умолчанию — 900 секунд (15 минут).Повтор — интервал в секундах, в течение которого дополнительные DNS-серверы ожидают, прежде чем произвести повторную попытку обновления зоны с основного сервера в случае неудачи предыдущей попытки. По умолчанию — 600 секунд (10 минут).Устаревание — интервал в секундах, по истечении которого информация зоны считается устаревшей. Этот параметр используется дополнительными серверами, которые перестают отвечать на запросы после того, как пройдет указанное количество времени с момента последнего успешного обновления. По умолчанию — 86 400 секунд (24 часа).TTL — минимальное время жизни записей зоны, для которых не указано индивидуальное значение. Используется для указания другим DNS-серверам и DNS-клиентам, в течение какого периода времени они могут кэшировать записи зоны. По умолчанию — 3 600 секунд (1 час).
Пример	@ IN SOA mcio-08kwa653t4.fio.ru. admin.fio.ru. ( 1 900 600 86400 3600)

Пример служебных записей зоны:

; Database file test.fio.ru.dns for test.fio.ru zone.
; Zone version: 2541744385
;
@ IN SOA ns1.test.fio.ru. admin.fio.ru. (
2541744385 ; serial number
10800 ; refresh
3600 ; retry
604800 ; expire
86400 ) ; minimum TTL
;
; Zone NS records
;
@ NS ns1. test.fio.ru.
@ NS ns2.test.fio.ru.
@ NS ns2.fio.ru.
;
; Zone records
;
ns1 A 195.34.17.1
ns2 A 213.128.193.119

Записи хостов (A и PTR)

Для установления соответствия между именем хоста и его IP-адресом используется запись A, для обратного соответствия — запись PTR. Для одного и того же IP-адреса допустимо использование нескольких имен хостов, однако для одного IP-адреса рекомендуется использовать только одну запись PTR. Записи A используются в зонах прямого просмотра, PTR — в зонах обратного просмотра.

Синтаксис записи A

Название	Host Address
Определена в	RFC 1035
Описание	Запись, устанавливающая соответствие имени определенному IP-адресу.
Синтаксис	владелец [класс] [TTL] A IP_адрес
Параметры	IP-адрес хоста.
Пример	host1 IN A 192.168.0.1

Синтаксис AAAA-записи

Название	IPv6 Host Address
Определена в	RFC 1886
Описание	Запись, устанавливающая соответствие имени определенному IP-адресу версии 6.
Синтаксис	владелец [класс] [TTL] AААА IP_адрес_v6
Параметры	IP-адрес версии 6 хоста.
Пример	host2 IN AAAA 4321:0:1:2:3:4:567:89ab

Синтаксис PTR-записи

Название	Pointer
Определена в	RFC 1035
Описание	Запись, устанавливающая соответствие IP-адреса доменному имени. Используется в зонах обратного просмотра
Синтаксис	владелец [класс] [TTL] PTR имя
Параметры	Полное DNS-имя хоста, соответствующего указанному IP-адресу.
Пример	1.0.168.192.in-addr.arpa PTR host1.test.fio.ru

Записи A и PTR могут быть добавлены в зону следующим образом:

• можно вручную создать необходимые записи (A и PTR) для компьютеров со статическими IP-адресами;
• компьютеры, работающие под управлением Windows 2000 и использующие динамические IP-адреса, самостоятельно добавляют или изменяют необходимые записи (A и PTR) в зоне;
• для компьютеров, работающих под управлением более ранних версий Windows и использующих динамические IP-адреса, добавление или изменение необходимых записей (A и PTR) осуществляется DHCP-сервером из состава Windows 2000 Server.

Примечание

Записи A и PTR не требуются для всех компьютеров. Они необходимы только для компьютеров, предоставляющих свои ресурсы в совместное использование. Тем не менее при использовании домена Active Directory Windows 2000 создает запись A для каждого компьютера в домене.

Записи альтернативных имен (CNAME)

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

Синтаксис CNAME-записи

Название	Canonical Name
Определена в	RFC 1035
Описание	Указывает, что владелец записи является альтернативным именем, для DNS-имени, указываемого как параметр.
Синтаксис	владелец [класс] [TTL] CNAME имя
Параметры	Полное или относительное DNS-имя хоста.
Пример	alias CNAME host1.test.fio.ru alias2 CNAME host2

Альтернативные имена используются для:

• изменения имени хоста, определенного при помощи записи A;
• задания привычных имен для хостов, предоставляющих определенные сервисы;
• распределения нагрузки между серверами, предоставляющими один и тот же сервис.

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

• cоздайте запись A с новым именем, указывающую на IP-адрес хоста;
• cоздайте запись CNAME со старым именем, указывающую на новое имя хоста;
• удалить запись A хоста со старым именем.

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

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

Рассмотрим это на примере.

Изначально в сети существовал хост, предоставляющий Web- и FTP-сервисы. Соответствующие записи зоны имели следующий вид:

host-a IN A 10.0.0.20

www IN CNAME host-a

ftp IN CNAME host-a

Со временем было принято решение переместить FTP-сервер на отдельный хост. За счет использования записей CNAME это было сделано прозрачно для пользователей:

host-a IN A 10.0.0.20

host-b IN A 10.0.0.21

www IN CNAME host-a

ftp IN CNAME host-b

Со временем нагрузка на Web-сервер возросла, и было принято решение установить дополнительный Web-сервер, разделяя нагрузку между ними, что было сделано прозрачно для пользователей за счет записей CNAME:

host-a IN A 10.0.0.20

host-b IN A 10.0.0.21

host-c IN A 10.0.0.22

www IN CNAME host-a

www IN CNAME host-c

ftp IN CNAME host-b

Внимание!

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

Записи почтовых хостов (MX)

Записи почтовых хостов домена используются почтовыми серверами и программами для определения хоста, на который должна быть отправлена почта. При этом почтовый сервер пытается найти запись MX в домене, имя которого получается отсечением от почтового адреса имени пользователя и символа @. Например, при отправке почты на адрес [email protected], поиск записи MX будет проводиться в домене fio.ru. Записи почтовых хостов указывают серверы, которые занимаются обработкой входящей почты для соответствующего домена. При наличии нескольких записей MX почтовый сервер пытается сначала использовать запись с наименьшим приоритетом.

Синтаксис записи MX

Название	Mail eXchanger
Определена в	RFC 1035
Описание	Запись, указывающая на сервер, осуществляющий обработку и доставку входящей почты.
Синтаксис	владелец [класс] [TTL] MX приоритет хост
Параметры	Приоритет — число от 0 до 65535, определяющее приоритет сервера при наличии в зоне нескольких MX записей с одним именем. Обработка начинается с сервера с наименьшим приоритетом.Хост — полное или относительное имя хоста почтового сервера, который должен быть определен в DNS.
Пример	test.fio.ru MX 10 host1.test.fio.ru @ MX 20 host1.test.fio.ru

Рассмотрим пример:

@ IN MX 10 mailserver1

@ IN MX 20 mailserver2

Здесь будет сначала использован сервер mailserver1, а при невозможности отправить почту через него — mailserver2. Если и второй сервер будет недоступен, автору сообщения будет отправлено уведомление о невозможности доставки почты.

Записи сервисов (SRV)

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

Синтаксис записи SRV

Название	Service locator
Определена в	RFC 2052
Описание	Запись, определяющая сервера, предоставляющие определенные сервисы.
Синтаксис	сервис.протокол.имя [класс] [TTL] SRV приоритет вес порт хост
Параметры	Сервис — символьное имя сервиса. Имена для стандартных сервисов (_telnet, _smtp и т. п.) определены в RFC 1700.Протокол — символьное имя протокола. Обычно используются _tcp и _udp, хотя может быть использован любой протокол, определенный в RFC 1700 . Имя — доменное имя, которое будет использовано для поиска информации о сервисах.Приоритет — число от 0 до 65535, определяющее приоритет сервера, указываемого в поле хост , при использовании нескольких записей SRV с одинаковым именем.Вес — число от 1 до 65535, которое в дополнение к приоритету используется для балансировки нагрузки между несколькими серверами. Значение этого поля учитывается при использовании нескольких записей SRV с одинаковыми приоритетами. Если балансировка нагрузки не используется, в качестве веса указывается 0.Порт — число от 0 до 65535, определяющее номер порта сервера, через который предоставляется указанный сервис. Соответствие портов стандартным сервисам определено в RFC 1700 , хотя можно использовать другие невостребованные номера портов.Хост — полное или относительное имя хоста сервера, который предоставляет указанный сервис. Хост должен быть определен в DNS. Вместо имени хоста может быть указана точка, значит указанный сервис не предоставляется в соответствующем домене
Пример	_ldap. _tcp.ms-dcs SRV 0 0 389 host1.test.fio.ru_ldap._tcp.ms-dcs SRV 10 0 389 host1.test.fio.ru

Так как все необходимые записи SRV создаются системой автоматически, вряд ли вам понадобится добавлять или настраивать их вручную. Для работы Active Directory используются динамически обновляемые зоны, все обновления в которые система вносит самостоятельно. Если ваша зона обслуживается сервером, не поддерживающим DDNS (допустим, старые версии DNS-серверов для платформы UNIX), можно добавить все необходимые записи SRV в зону из файла %systemroot%system32Confignetlogon.dns. Он обновляется каждый раз при внесении изменений в конфигурацию AD.

Domain Name System — система доменных имён

Что такое DNS?

Что такое обратная зона DNS?

Как мне внести изменения в зону DNS?

Какой должен быть адрес сайта: domain.ru или www.domain.ru?

Как быстро изменения в зоне вступают в силу?

Какие бывают записи dns?

Могу ли я сделать домен domain2. ru синонимом domain.ru?

Можно ли одному домену назначить две A-записи?

Можно ли одному домену назначить две MX-записи?

Что такое DNS?

DNS (расшифровывается как «Система доменных имен») — распределенная система, благодаря которой можно пользоваться доменными именами. Если бы не DNS, нам бы пришлось вводить в строке браузера не demos.ru, а 194.87.5.183, писать письма не на [email protected], а на [email protected] и т.д. Иными словами, DNS связывает доменные имена с реальными адресами устройств в сети. Информация об этих связях хранится на специальных DNS-серверах. Для правильного функционирования доменного имени необходимо, чтобы ему было сопоставлено как минимум два DNS-сервера. Наверх

Что такое обратная зона DNS?
В обратной зоне ip-адресу ставится в соответствие доменное имя. Поскольку ip-адреса, в отличие от доменных имен, принадлежат провайдерам. Поэтому для изменения обратной зоны нужно обращаться к провайдеру, которому принадлежит нужный ip-адрес. Наверх

Как мне внести изменения в зону DNS?

Если Вы зарегистрировали домен в нашей компании и его зона размещена на серверах ns1/ns2.root.ru, то Вы можете самостоятельно вносить изменения в зону, воспользовавшись редактором зоны, попасть в который можно со страницы выбора ns-серверов в панели регистрации и управления доменами. В противном случае все изменения производятся нашими специалистами по Вашей заявке на адрес [email protected]. Наверх

Какой должен быть адрес сайта: domain.ru или www.domain.ru?
Как Вам удобнее. Исторически сложилось, что для сайтов выделяется домен 3-го уровня www. Точно также для почтовых серверов часто употребляют домен mx. Обычно на сайт можно попасть по обоим именам, с www и без него. При этом для самого домена domain.ru прописывают a-запись, которая указывает на нужный ip-адрес, а для www.domain.ru — запись cname. Наверх

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

Какие бывают записи dns?

У каждой зоны есть записи SOA, в которой описано, как функционирует эта запись, и NS в которой перечислены dns-сервера, на которых хранится описание зоны. Обычно используют: A-запись указывает на адрес сервера, на котором расположен веб-сайт. Также, на этот адрес будет приходить почта для домена, если не определена запись MX. MX-запись указывает на имя сервера, на который будет приходить почта для домена CNAME-запись превращает домен в псевдоним для другого домена PTR-запись в обратных зонах служит для сопоставления доменного имени ip-адресу. Наверх

Могу ли я сделать домен domain2.ru синонимом domain.ru?
Средствами DNS, т.е. установкой записи типа CNAME &mdash нет. В соответствии с RFC 1034 запись типа CNAME должна быть единственной для домена. В то же время для domain2.ru обязательно должны быть записи SOA и NS. Можно для обоих доменов сделать одинаковые a-записи. Тогда при изменении ip-адреса нужно не забыть поменять его для обоих доменов Наверх

Можно ли одному домену назначить две A-записи?
Да можно. Тогда запросы будут распределяться между этими адресами. Наверх

Можно ли одному домену назначить две MX-записи?
Да, можно. Если записи будут с одним весом, то письмо будет отправляться на один из серверов случайным образом. Если вес у записей разный, то сначала будет предпринятая попытка отправить письмо на сервер с меньшим весом. Если попытка не увенчается успехом, то отправка письма повторится для сервера с большим приоритетом. Наверх

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

— Azure DNS

• Статья
• 29.09.2022
• 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 записи указываются с использованием относительных имен. A полностью квалифицированный 9Доменное имя 0060 (FQDN) включает имя зоны, а относительное имя — нет. Например, относительное имя записи www в зоне contoso.com дает полное имя записи www.contoso.com .

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

Типы записей

Каждая запись DNS имеет имя и тип. Записи организованы в различные типы в зависимости от данных, которые они содержат. Наиболее распространенным типом является запись «A», которая сопоставляет имя с адресом 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 В А 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 позволяют владельцам доменов указывать, какие центры сертификации (ЦС) уполномочены выдавать сертификаты для своего домена. Эта запись позволяет центрам сертификации избежать неправильной выдачи сертификатов в некоторых случаях. Записи 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 и метаданные для этого набора записей. Однако удаление или изменение предварительно заполненных серверов имен Azure DNS не допускается.

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

Записи 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.

Etags

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

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

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

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

.

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

Ограничения

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

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

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

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

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

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

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

Частный преобразователь DNS

Ресурс	Ограничение
Частные преобразователи DNS на подписку	15
Входящие конечные точки на частный преобразователь DNS	2
Исходящие конечные точки на частный преобразователь DNS	2
Правила переадресации в соответствии с набором правил переадресации DNS	25
Виртуальные сетевые ссылки на набор правил переадресации DNS	10
Исходящие конечные точки на набор правил переадресации DNS	2
Наборы правил переадресации DNS для каждой исходящей конечной точки	2
Целевые DNS-серверы по правилу переадресации	6

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

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

DNS-запись: что такое файл зоны?

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

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

Файл зоны

Файл зоны (или «мастер-файл») — это текстовый файл, содержащий RR в текстовом формате, который используется для авторитетного определения зоны. Зона (или зона DNS) — это любая отдельная, непрерывная часть пространства доменных имен в DNS, административная ответственность за которую делегирована одному менеджеру. Зона может включать одно доменное имя, доменное имя с несколькими поддоменами или множество доменных имен. В случае одного доменного имени зона по существу является доменным именем.

Файл зоны содержит информацию о домене и инструкции о том, как определенные DNS-серверы будут обрабатывать запросы для этого домена. Хотя в некоторых случаях файл зоны также может быть файлом, используемым для перечисления содержимого кеша DNS. Файлы зон являются стандартной практикой в ​​индустрии DNS и очень важны при переносе доменной зоны к другому провайдеру DNS или при создании резервной копии записей вашего домена на вторичном сервере имен. Файлы зон по умолчанию хранятся в «именованном» рабочем каталоге (/var/named/) и могут быть экспортированы из вашего DNS-провайдера.

Ниже приведен пример файла зоны (источник Википедия):

Для корректной обработки данных в файле зоны необходимо соблюдать определенные правила, иначе DNS не сможет работать должным образом (или клиент получит ошибку сообщение SERVFAIL). По этой причине файл зоны следует синтаксису DNS, определенному в RFC 1035, раздел 5. При этом каждая запись в файле зоны соответствует «строчно-ориентированной» последовательности (т. е. одна строка на запись), и каждая запись строки будет либо директива или текстовое описание записи ресурса .

Директивы необязательны, но для предоставления службы DNS в зону необходимы записи ресурсов. Каждая запись состоит из полей, разделенных любой комбинацией пробелов (табуляции и пробелов), и заканчивается разрывом строки, за исключением строкового значения поля в кавычках или пары закрывающих круглых скобок (например, скобок). Запись строки может заканчиваться текстом комментария, которому предшествует точка с запятой «;» (таким образом создается информация о записи DNS без обработки текста сервером). Записи могут располагаться в файле зоны в любом порядке, за некоторыми исключениями. Вы можете вставлять пустые строки, чтобы структурировать свои записи. Они также просто игнорируются системой во время считывания.

A. Директивы

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

• $ORIGIN , за которым следует доменное имя, которое будет использоваться в качестве источника (или корневого домена) для последующих относительных доменных имен. Любое NAME, используемое в RR, которое не заканчивается завершающей точкой ( . ) добавляются с доменным именем, указанным в источнике.
• $INCLUDE , за которым следует имя файла и необязательное имя исходного домена, которые будут использоваться при интерпретации его содержимого. Настраивает «именованный» каталог для включения другого файла зоны в этот файл зоны. Это позволяет сохранять дополнительные настройки зоны отдельно от основного файла зоны.
• За $TTL следует число, которое будет использоваться в качестве TTL (времени жизни) по умолчанию для зоны. Это время в секундах, в течение которого зона RR действительна. Увеличение этого значения позволяет удаленным серверам имен кэшировать информацию о зоне в течение более длительного периода времени, уменьшая количество запросов к зоне и увеличивая количество времени, необходимое для распространения изменений RR. Это считается глобальным TTL всех RR. Добавление этой директивы может позволить опустить поле TTL в RR. Однако, если RR указывает свое значение TTL, значение в этой директиве будет переопределено.
• $GENERATE — это нестандартное расширение, принятое программным обеспечением BIND и некоторым другим программным обеспечением серверов имен для вставки нескольких RR с одной записью, за которой следует краткое представление возрастающей последовательности неотрицательных чисел, а затем запись шаблона RR. Для каждого числа в последовательности добавляется RR с использованием шаблона с неэкранированными символами «$», заменяемыми числом.

B. Записи ресурсов

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

Каждая запись DNS содержит разные поля, однако они по-прежнему имеют общие поля. Эти общие поля описаны ниже:

• ИМЯ — В этом поле указывается полное доменное имя (FQDN), а также указывается имя владельца записи. Если это поле оставить пустым в записи, оно унаследует поле от предыдущей записи. Если это поле имеет отдельно стоящий @, это обозначает текущий ORIGIN (или корневой домен), установленный в директивах. И если в этом поле есть «www», или «ftp» и т. д., это может обозначать поддомен текущего ORIGIN.
• TYPE – Это поле представляет собой 2-байтовое значение, указывающее тип RR. Тип определяет предполагаемое использование записи. DNS-имя может иметь более одного типа записей. Например, DNS-имя может иметь запись A (значение = 1), которая используется для преобразования доменного имени в соответствующий адрес IPv4, запись CNAME (значение = 5) используется для преобразования псевдонима в соответствующее каноническое имя и т. д. В этой статье будет представлено более подробное описание наиболее распространенных типов DNS-записей.
• КЛАСС – Это поле определяет семейство протоколов для записи. Каждый класс является независимым пространством имен с потенциально разными делегированиями зон DNS. Для этого поля возможен только класс Интернета (IN), и он назначается общим записям DNS, включающим имена хостов в Интернете, серверы или IP-адреса. Исторически, когда RR были впервые введены, также были возможны классы Hesiod (HS) и Chaos (CH). Однако и Гесиод, и Хаос сегодня больше не действуют.
• TTL (время жизни) — Это поле представляет собой продолжительность времени, в течение которого копия записи будет кэшироваться на сервере, и измеряется в секундах. Поскольку серверы будут обновлять запись (с исходного сервера) каждый раз после TTL, TTL также может указывать частоту кэширования записи. Это означает, что чем ниже значение TTL, тем чаще будет обновляться запись.