Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье объясняются ключевые концепции доменов, зон DNS, записей DNS и наборов записей. Вы узнаете, как они поддерживаются в Azure DNS.
Доменные имена
Система доменных имен — это иерархия доменов. Иерархия начинается с root
домена, имя которого просто ".". Ниже приведены домены верхнего уровня, например 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, чтобы управлять записями. Дополнительные сведения см. в статье Делегирование домена в 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 есть имя и тип. Записи разделяются на разные типы в зависимости от данных, которые они содержат. Наиболее распространенный тип — запись A, которая сопоставляет имя с IPv4-адресом. Другой распространенный тип — запись MX, которая сопоставляет имя с почтовым сервером.
Azure DNS поддерживает все общие типы записей DNS: A, AAAA, CAA, CNAME, MX, NS, PTR, SOA, SRV и TXT. Обратите внимание, что записи SPF, представлены в виде записей TXT.
Дополнительные типы записей поддерживаются, если зона подписана с помощью расширений безопасности DNS (DNSSEC), таких как делегирующий подписывающий (DS) и записи ресурсов TLSA.
Типы записей ресурсов DNSSEC, такие как DNSKEY, RRSIG и NSEC3, добавляются автоматически при подписании зоны с помощью DNSSEC. Эти типы записей ресурсов DNSSEC нельзя создавать или изменять после подписывания зоны.
Наборы записей
В некоторых случаях необходимо создать несколько записей DNS с заданным именем и типом. Например, предположим, что веб-сайт www.contoso.com размещается по двум разным IP-адресам. Для этого веб-сайта требуются две разные записи A — по одной для каждого IP-адреса: Ниже приведен пример набора записей:
www.contoso.com. 3600 IN A 134.170.185.46
www.contoso.com. 3600 IN A 134.170.188.221
Azure DNS управляет всеми записями DNS, используя наборы записей. Набор записей (также называется набором записей ресурсов) — это коллекция записей DNS в зоне, которые имеют одно имя и принадлежат к одному типу. Большинство наборов записей содержат единственную запись. Однако примеры, подобные приведенному выше, в которых набор записей содержит несколько записей, не являются редкими.
Например, предположим, что вы уже создали в зоне contoso.com запись А www, указывающую на 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, используемое для представления критического флага с особым значением в соответствии с RFC6844.
-
Тег: строка ASCII, которая может быть одной из следующих:
- issue — если необходимо указать ЦС, которые могут выпускать сертификаты (всех типов);
- issuewild — если необходимо указать ЦС, который может выпускать сертификаты (только wildcard сертификаты);
- iodef — адрес электронной почты или имя узла, по которым ЦС может отправлять уведомления о запросах на несанкционированную выдачу сертификатов.
- Value. Значение для определенного выбранного тега.
Записи CNAME
Наборы записей типа CNAME не могут сосуществовать с другими наборами записей с тем же именем. Например, нельзя создать набор записей CNAME с относительным именем www
, а также запись A с относительным именем www
одновременно.
Поскольку вершина зоны (имя = '@') всегда будет содержать записи NS и SOA при создании зоны, невозможно создать запись CNAME на вершине зоны.
Это связано со стандартами DNS, а не ограничениями Azure DNS.
Записи NS
Набор записей NS в вершине зоны (имя @) создается автоматически с каждой зоной DNS и автоматически удаляется при удалении зоны. Его невозможно удалить отдельно.
Этот набор записей содержит имена серверов доменных имен Azure DNS, назначенные зоне. Вы можете добавить большее количество серверов доменных имен в этот набор записей NS для поддержки совместных доменов с несколькими поставщиками DNS. Вы также можете изменить срок жизни и метаданные для этого набора записей. Однако удаление или изменение предварительно заполненных серверов доменных имен Azure DNS запрещено.
Это ограничение распространяется только на запись NS, установленную на вершине зоны. Другие наборы записей NS в зоне (используемые для делегирования дочерних зон) можно создавать, изменять и удалять без ограничений.
Записи SOA
Набор записей SOA автоматически создается на вершине каждой зоны (имя = @) и автоматически удаляется при удалении зоны. Записи SOA нельзя создавать или удалять отдельно.
Вы можете изменить все свойства записи SOA, кроме host
свойства. Это свойство настраивается для использования в качестве ссылки на имя основного сервера имен, предоставленное Azure DNS.
Серийный номер зоны в записи SOA не обновляется автоматически при внесении изменений в записи зоны. Его можно обновить вручную, изменив запись SOA, если потребуется.
Примечание.
Azure DNS в настоящее время не поддерживает использование точки (.) перед записью "@" в записи почтового ящика hostmaster SOA. Например: [email protected]
(преобразовано в john.smith.contoso.xyz) и john\[email protected]
не допускается.
Записи 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 используются для сопоставления доменных имен с произвольными текстовыми строками. Они используются в разных приложениях, в частности в тех, которые относятся к конфигурации электронной почты, например инфраструктура политики отправителей (SPF) и DomainKeys Identified Mail (DKIM).
Стандарты DNS позволяют одной записи TXT содержать несколько строк, каждая из которых может содержать до 255 символов. Где используются несколько строк, они объединяются клиентами и обрабатываются как одна строка.
При вызове REST API Azure DNS необходимо указать каждую строку TXT отдельно. При использовании интерфейсов портал Azure, PowerShell или CLI следует указать одну строку для каждой записи. Эта строка автоматически делится на 255-символьные сегменты при необходимости.
Не следует путать несколько строк в записи DNS с несколькими записями типа TXT в наборе записей типа TXT. Набор записей типа TXT может содержать несколько записей, каждая из которых может содержать несколько строк. Azure DNS поддерживает общую длину строки до 4096 символов в каждом наборе записей TXT (во всех объединенных записях).
Записи DS
Запись подписывания делегирования (DS) — это тип записи ресурсов DNSSEC , используемый для защиты делегирования. Чтобы создать запись DS в зоне, необходимо сначала подписать зону с помощью DNSSEC.
Записи TLSA
Запись TLSA (Защита транспортного уровня) используется для связывания сертификата сервера TLS или открытого ключа с доменным именем, где находится эта запись. Запись TLSA связывает открытый ключ (сертификат сервера TLS) с доменным именем, обеспечивая дополнительный уровень безопасности для подключений TLS.
Чтобы эффективно использовать записи TLSA, DNSSEC необходимо включить в домене. Это гарантирует, что записи TLSA могут быть доверенными и правильно проверены
Теги и метаданные
Теги
Теги — это список пар "имя — значение", которые используются 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 использует теги Etag для безопасной обработки параллельных изменений одного ресурса. Теги ETag не связаны с тегами Azure Resource Manager. С каждым ресурсом DNS (зоной или набором записей) связан ETag. При извлечении ресурса также передается его значение Etag. При обновлении ресурса вы можете передать Etag, чтобы служба Azure DNS могла проверить, совпадает ли он с Etag, который хранится на сервере. Так как каждое обновление ресурса приводит к повторному созданию Etag, несовпадение Etag указывает на параллельное изменение. Etag также можно использовать при создании нового ресурса, чтобы убедиться, что такой ресурс ещё не существует.
По умолчанию PowerShell для Azure DNS использует теги Etag для блокировки одновременных изменений зон и наборов записей. С помощью необязательного параметра -Overwrite можно отключить проверки тегов Etag. В этом случае все одновременные изменения перезаписываются.
На уровне API REST службы Azure DNS теги Etag указываются с помощью заголовков HTTP. Их поведение описывается в следующей таблице:
Заголовок | Поведение |
---|---|
нет | PUT всегда завершается успешно (без проверки Etag) |
If-match <etag> | PUT завершается успешно, только если ресурс существует и ETag соответствует |
If-match * | PUT завершается успешно, только если ресурс существует |
If-none-match * | PUT завершается успешно, только если ресурс отсутствует |
Ограничения
При использовании Azure DNS применяются приведенные ниже ограничения по умолчанию.
Общедоступные зоны DNS
Ресурс | Ограничение |
---|---|
Общедоступные зоны DNS для каждой подписки | 250 1 |
Наборы записей на каждую общедоступную зону DNS | 10 000 1 |
Количество записей в наборе записей в общедоступной зоне DNS | 20 |
Число записей Alias для одного ресурса Azure | 20 |
1 Если вам нужно увеличить эти ограничения, обратитесь в Службу поддержки Azure.
Следующие шаги
- Чтобы начать работу с Azure DNS, узнайте, как создать зону DNS и записи DNS.
- Чтобы перенести имеющуюся зону DNS, узнайте, как импортировать и экспортировать файл зоны DNS.