Для выдачи сертификата необходимо разместить запись в зоне dns формы

Обновлено: 25.11.2024

Инструмент acme-dns-certbot используется для подключения Certbot к стороннему DNS-серверу, где записи проверки сертификата могут быть установлены автоматически через API при запросе сертификата. Преимущество этого заключается в том, что вам не нужно интегрировать Certbot напрямую с вашей учетной записью поставщика DNS, а также вам не нужно предоставлять ему неограниченный доступ к вашей полной конфигурации DNS, что выгодно для безопасности.

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

В этом руководстве вы будете использовать хук acme-dns-certbot, чтобы Certbot выдал сертификат Let’s Encrypt с использованием проверки DNS.

Предпосылки

Для выполнения этого руководства вам потребуется:

Сервер Ubuntu 18.04, настроенный в соответствии с начальной настройкой сервера с Ubuntu 18.04, включая пользователя без полномочий root.

Доменное имя, для которого вы можете приобрести сертификат TLS, включая возможность добавления записей DNS. В этом конкретном примере мы будем использовать your-domain и subdomain.your-domain, а также *. your-domain для подстановочного сертификата. Однако при необходимости это можно настроить для другого домена, субдоменов или подстановочных знаков.

Подготовив их, войдите на свой сервер как пользователь без полномочий root, чтобы начать.

Шаг 1 — Установка Certbot

На этом шаге вы установите Certbot — программу, используемую для выпуска сертификатов Let’s Encrypt и управления ими.

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

Начните с добавления репозитория Certbot:

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

Далее установите пакет Certbot:

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

Это выведет что-то похожее на следующее:

На этом шаге вы установили Certbot. Затем вы загрузите и установите хук acme-dns-certbot.

Шаг 2 — Установка acme-dns-certbot

Теперь, когда базовая программа Certbot установлена, вы можете загрузить и установить acme-dns-certbot, что позволит Certbot работать в режиме проверки DNS.

Начните с загрузки копии скрипта:

После завершения загрузки пометьте скрипт как исполняемый:

Затем отредактируйте файл с помощью вашего любимого текстового редактора и измените первую строку, чтобы принудительно использовать Python 3:

Добавьте 3 в конец первой строки:

Это необходимо для того, чтобы скрипт использовал последнюю поддерживаемую версию Python 3, а не устаревшую версию Python 2.

После завершения сохраните и закройте файл.

Наконец, переместите скрипт в каталог Certbot Let’s Encrypt, чтобы Certbot мог его загрузить:

На этом шаге вы загрузили и установили перехватчик acme-dns-certbot. Затем вы можете начать процесс установки и работать над выпуском своего первого сертификата.

Шаг 3 — Настройка acme-dns-certbot

Чтобы начать использовать acme-dns-certbot, вам необходимо выполнить первоначальную настройку и выдать хотя бы один сертификат.

Для начала запустите Certbot, чтобы принудительно выдать сертификат с использованием проверки DNS. Это запустит скрипт acme-dns-certbot и запустит процесс первоначальной настройки:

Вы используете аргумент --manual, чтобы отключить все функции автоматической интеграции Certbot. В этом случае вы просто выдаете необработанный сертификат, а не устанавливаете его автоматически в службу.

Вы настраиваете Certbot на использование ловушки acme-dns-certbot с помощью аргумента --manual-auth-hook. Вы запускаете аргумент --preferred-challenges, чтобы Certbot отдавал предпочтение проверке DNS.

Вы также должны указать Certbot сделать паузу перед попыткой проверки сертификата, что вы делаете с аргументом --debug-challenges. Это позволяет вам установить записи DNS CNAME, необходимые для acme-dns-certbot, которые рассматриваются позже на этом шаге. Без аргумента --debug-challenges Certbot не остановился бы, поэтому у вас не было бы времени внести необходимые изменения в DNS.

Не забудьте заменить каждое доменное имя, которое вы хотите использовать, используя аргументы -d. Если вы хотите выдать подстановочный сертификат, убедитесь, что вместо звездочки ( * ) используется обратная косая черта ( \ ).

После выполнения стандартных шагов Certbot вы получите сообщение, похожее на следующее:

Вам потребуется добавить необходимую запись DNS CNAME в конфигурацию DNS для вашего домена.Это делегирует управление субдоменом _acme-challenge службе DNS ACME, что позволит acme-dns-certbot установить необходимые записи DNS для проверки запроса сертификата.

Если вы используете DigitalOcean в качестве провайдера DNS, вы можете установить запись DNS в панели управления:

Рекомендуется установить TTL (срок жизни) примерно на 300 секунд, чтобы обеспечить быстрое распространение любых изменений в записи.

После того как вы настроили запись DNS, вернитесь в Certbot и нажмите ENTER, чтобы подтвердить запрос сертификата и завершить процесс выдачи.

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

Вы запустили acme-dns-certbot в первый раз, настроили необходимые записи DNS и успешно выпустили сертификат. Далее вы настроите автоматическое продление сертификата.

Шаг 4. Использование acme-dns-certbot

На этом последнем шаге вы будете использовать acme-dns-certbot для выпуска дополнительных сертификатов и обновления существующих.

Во-первых, теперь, когда вы успешно выдали хотя бы один сертификат с помощью acme-dns-certbot, вы можете продолжать выдавать сертификаты для тех же DNS-имен, не добавляя еще одну запись DNS CNAME. Однако если вы хотите приобрести сертификат для другого субдомена или совершенно нового доменного имени, вам будет предложено добавить еще одну запись CNAME.

Например, вы можете выпустить еще один автономный групповой сертификат без повторной проверки:

Однако, если вы попытаетесь выпустить сертификат для субдомена, вам будет предложено добавить запись CNAME для субдомена:

Это покажет выходные данные, аналогичные начальной настройке, которую вы выполнили на шаге 3:

Теперь, когда вы можете использовать acme-dns-certbot для выдачи сертификатов, стоит подумать и о процессе обновления.

Когда срок действия ваших сертификатов подходит к концу, Certbot может автоматически продлить их для вас:

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

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

Вы можете запустить пробный запуск с помощью стандартной команды обновления, но с аргументом --dry-run:

В результате будет выведено что-то похожее на следующее, что обеспечит правильную работу процесса продления:

На этом последнем шаге вы выпустили еще один сертификат, а затем протестировали процесс автоматического продления в Certbot.

Заключение

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

Обязательно следите за репозиторием acme-dns-certbot на предмет любых обновлений скрипта, так как всегда рекомендуется запускать последнюю поддерживаемую версию.

Если вам интересно узнать больше о acme-dns-certbot, вы можете просмотреть документацию по проекту acme-dns, который является серверным элементом acme-dns-certbot:

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

Кроме того, вы можете углубиться в технические детали проверки ACME DNS, ознакомившись с соответствующим разделом официального документа RFC, в котором описывается, как работает этот процесс:

Хотите узнать больше? Присоединяйтесь к сообществу DigitalOcean!

Присоединяйтесь к нашему сообществу DigitalOcean, насчитывающему более миллиона разработчиков, бесплатно! Получайте помощь и делитесь знаниями в нашем разделе "Вопросы и ответы", находите руководства и инструменты, которые помогут вам расти как разработчику и масштабировать свой проект или бизнес, а также подписывайтесь на интересующие вас темы.

Система доменных имен (DNS) — это служба каталогов для ресурсов, подключенных к сети. Ваш провайдер DNS поддерживает базу данных, содержащую записи, определяющие ваш домен. Когда вы выбираете проверку DNS, ACM предоставляет вам одну или несколько записей CNAME, которые необходимо добавить в эту базу данных. Эти записи содержат уникальную пару "ключ-значение", которая служит доказательством того, что вы контролируете домен.

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

Без необходимости повторной проверки вы можете запросить дополнительные сертификаты ACM для своего полного доменного имени (FQDN) до тех пор, пока запись CNAME остается на месте. То есть вы можете создавать заменяющие сертификаты с тем же доменным именем или сертификаты, которые охватывают разные поддомены. Поскольку токен проверки CNAME работает для любого региона AWS, вы можете повторно создать один и тот же сертификат в нескольких регионах. Вы также можете заменить удаленный сертификат.

Вы можете остановить автоматическое продление, либо удалив сертификат из службы AWS, с которой он связан, либо удалив запись CNAME. Если Route 53 не является вашим провайдером DNS, обратитесь к своему провайдеру, чтобы узнать, как удалить запись. Если вашим провайдером является Route 53, см. раздел Удаление наборов записей ресурсов в Руководстве разработчика по Route 53. Дополнительные сведения об управляемом продлении сертификата см. в разделе Управляемое продление сертификатов ACM.

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

Как работают записи CNAME для ACM

Этот раздел предназначен для клиентов, которые не используют Route 53 в качестве поставщика DNS.

Если вы не используете Route 53 в качестве поставщика DNS, вам необходимо вручную ввести записи CNAME, предоставленные ACM, в базу данных вашего поставщика, обычно через веб-сайт. Записи CNAME используются для ряда целей, в том числе в качестве механизмов перенаправления и в качестве контейнеров для метаданных поставщика. Для ACM эти записи обеспечивают первоначальную проверку владения доменом и постоянное автоматическое продление сертификата.

В следующей таблице показаны примеры записей CNAME для шести доменных имен. Пара "Имя записи-значение записи" каждой записи служит для аутентификации владения доменным именем.

Значения x после символа подчеркивания ( _ ) представляют собой длинные случайные строки, сгенерированные ACM. Например,

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

для той же записи.

Если ваш провайдер DNS не поддерживает значения CNAME с символом подчеркивания в начале, см. раздел Устранение неполадок при проверке DNS.

Когда вы запрашиваете сертификат и указываете проверку DNS, ACM предоставляет информацию CNAME в следующем формате:

Имя домена – это полное доменное имя, связанное с сертификатом. Имя записи однозначно идентифицирует запись, выступая в качестве ключа пары "ключ-значение". Значение записи служит значением пары "ключ-значение".

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

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

Настройка проверки DNS

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

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

В списке сертификатов выберите идентификатор сертификата со статусом Ожидает проверки, который вы хотите настроить. Откроется страница сведений о сертификате.

В разделе "Домены" выполните одну из следующих двух процедур:

(Необязательно) Подтвердите с помощью Route 53.

Активная кнопка «Создать записи в Route 53» появляется, если выполняются следующие условия:

Вы используете Route 53 в качестве поставщика DNS.

У вас есть разрешение на запись в зону, размещенную на Route 53.

Ваше полное доменное имя не еще не проверено.

Если вы на самом деле используете Route 53, но кнопка «Создать запись в Route 53» отсутствует или отключена, см. Консоль ACM не отображает кнопку «Создать запись в Route 53».

Нажмите кнопку «Создать записи в Route 53», затем выберите «Создать записи». Страница состояния сертификата должна открыться с баннером состояния, сообщающим об успешно созданных записях DNS.

Ваш новый сертификат может продолжать отображать статус Ожидает проверки до 30 минут.

Вы не можете программно запросить, чтобы ACM автоматически создал вашу запись в Route 53. Однако вы можете сделать вызов AWS CLI или API к Route 53, чтобы создать запись в базе данных DNS Route 53. Дополнительные сведения о наборах записей Route 53 см. в разделе Работа с наборами записей ресурсов.

(Необязательно) Если вы не используете Route 53 в качестве поставщика DNS, вы должны получить информацию CNAME и добавить ее в свою базу данных DNS. Это можно сделать одним из двух способов:

Скопируйте компоненты CNAME, отображаемые в разделе "Домены". Эту информацию необходимо добавить в базу данных DNS вручную.

Либо выберите Экспорт в CSV. Информация в полученном файле должна быть добавлена вручную в вашу базу данных DNS.

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

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

Для завершения проверки домена с использованием метода DNS вам потребуется добавить запись CNAME или TXT в зависимости от того, у какого поставщика вы приобрели SSL. Sectigo (ранее Comodo) использует для проверки только записи CNAME, а DigiCert/Symantec/GeoTrust/Thawte/RapidSSL могут использовать для проверки только записи TXT.

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

Обратите внимание. Распространение записи TXT или CNAME в Интернете может занять от 24 до 48 часов. Это относится ко всем обновлениям DNS и находится вне нашего контроля. Хотя это нетипично, чтобы стать общедоступным, требуется так много времени, но это возможно.

Используйте эти инструкции, только если у вас есть сертификат Sectigo (ранее Comodo).

Обратите внимание. Если этот метод вам не подходит и вы хотите попробовать другой метод подтверждения ( На основе файла или на основе электронной почты), прокрутите вниз страницу сведений о заказе в своей учетной записи и выберите «Изменить метод утверждающего», чтобы выбрать другой вариант. Инструкции для выбранного варианта появятся в вашем аккаунте.

Как проверить, готов ли ваш CNAME!

В поле поиска введите значение, которое вы поместили в поле имени хоста (значение с символом "_"), выберите CNAME в раскрывающемся меню, а затем выберите "Поиск".
Если вы видите значение «Указывает на» для записи CNAME в результатах поиска вместе с зелеными галочками, значит, ваша запись CNAME распространяется, и система поставщика должна вскоре выпустить ваш SSL.

Дальнейшие шаги

Если вы приобрели сертификат DV, вскоре после того, как вы получите подтверждение права собственности на домен, вы получите свой сертификат. После получения вы сможете установить SSL на свой сервер. Чтобы получить помощь по установке SSL-сертификата, нажмите здесь.
Если вы приобрели сертификат OV или EV, вам необходимо выполнить шаги проверки вашей организации, чтобы получить файлы сертификата. Чтобы получить помощь в этом, ознакомьтесь с нашей статьей поддержки для сертификатов OV здесь и нашей статьей поддержки для сертификатов EV здесь.
Если прошло более 15 минут с тех пор, как вы могли увидеть значение Points To для своей записи CNAME с помощью онлайн-инструмента, но вы все еще не получили свой сертификат, прокрутите вниз страницу сведений о заказе в своей учетной записи и выберите "Изменить". Настройки утверждения», а затем выберите «Сохранить» (без внесения каких-либо изменений в настройки утверждения). Это побудит систему поставщика повторить попытку вашей записи CNAME, и ваш сертификат должен быть выдан. Пожалуйста, подождите еще 15 минут, прежде чем обращаться в службу поддержки за помощью с вашим заказом.

Используйте эти инструкции, только если у вас есть сертификат DigiCert/Symantec/Thawte/GeoTrust/RapidSSL.

Войдите в панель управления хостингом вашего домена (обычно это регистратор вашего домена).
Найдите и выберите DNS Zone Manager для нужного домена.
Выберите параметр, чтобы создать новую запись TXT.
В поле "Имя хоста" или "Псевдоним" либо оставьте его пустым, либо поместите символ @.
В поле Значение TXT укажите уникальное значение, отображаемое на странице сведений о заказе в вашей учетной записи.
Установите для TTL значение 3 600 или минимально возможное значение.
Нажмите "Сохранить" и дождитесь распространения записи (т. е. 15 минут).

В этой статье объясняются основные понятия доменов, зон 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-запросы, превышающие эти ограничения, отбрасываются.

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