Как подтвердить право собственности на домен с помощью записи dns
Обновлено: 03.07.2024
DNS (система доменных имен) – это «телефонная книга» Интернета. В качестве номера телефона в ней выступает IP-адрес, а в качестве наименований контактов — домены. В такую книгу можно внести не только «телефонный номер», но и дополнительную информацию о контакте («е-mail», «место работы» и т.п.).
Информация о домене хранится на DNS-серверах. Чтобы внести её в систему DNS, нужно прописать ресурсные записи. С их помощью серверы делятся сведениями о доменах с другими серверами. Пока не прописаны ресурсные записи для домена, его нет в «телефонной книге» Интернета. Следовательно, работа сайта или почты на нём невозможна. Прежде чем приступать к указанию ресурсных записей, нужно делегировать домен, то есть прописать для него DNS-серверы. Вы можете сделать это по инструкции: Как прописать DNS-серверы для домена в Личном кабинете. Затем переходите к ресурсным записям. Изменения вступят в силу после обновления DNS-серверов (обычно до 24 часов).
Основные ресурсные записи: записи типа A, CNAME, MX, TXT и SPF. С общей информацией по добавлению ресурсных записей вы можете познакомиться в статье: Настройка ресурсных записей в Личном кабинете.
Запись A
Запись A (address) — одна из ключевых ресурсных записей Интернета. Она нужна для связи домена с IP-адресом сервера. Пока не прописана А-запись, ваш сайт не будет работать.
Когда вы вводите название сайта в адресную строку браузера, именно по А-записи DNS определяет, с какого сервера нужно открывать ваш сайт.
Примеры записи A:
где 123.123.123.123 — IP-адрес нужного вам сервера.
Запись CNAME
Примеры записи CNAME:
Запись MX
MX-запись что это? Это запись, отвечающая за сервер, через который будет работать почта. Записи MX критически важны для работы почты. Благодаря им отправляющая сторона «понимает», на какой сервер нужно отправлять почту для вашего домена.
Примеры записи MX:
Запись TXT
TXT (Text string) — запись, которая содержит любую текстовую информацию о домене. Записи TXT используются для различных целей: подтверждения права собственности на домен, обеспечения безопасности электронной почты, а также подтверждения SSL-сертификата. Часто применяется для проверок на право владения доменом при подключении дополнительных сервисов, а также как контейнер для записи SPF и ключа DKIM. Можно прописывать неограниченное количество TXT-записей, если они не конфликтуют друг с другом.
Запись SPF
SPF-запись (Sender Policy Framework) содержит информацию о списке серверов, которые имеют право отправлять письма от имени заданного домена. Позволяет избежать несанкционированного использования. Настройка SPF прописывается в TXT-записи для домена.
Пример записи SPF:
где 123.123.123.123 — IP-адрес нужного вам сервера.
» и «-», для параметра «all» существуют ещё ключи:
- «+» — принимать почту,
- «?» — воспринимать письмо нейтрально.
Записи NS, PTR, SOA являются служебными и, как правило, настраиваются автоматически.
Запись NS
NS-запись (Authoritative name server) указывает на DNS-серверы, которые отвечают за хранение остальных ресурсных записей домена. Количество NS записей должно строго соответствовать количеству всех обслуживающих его серверов. Критически важна для работы службы DNS.
Запись PTR
Запись SOA
SOA (Start of Authority) — начальная запись зоны, которая указывает, на каком сервере хранится эталонная информация о доменном имени. Критически важна для работы службы DNS. Подробнее о том, что такое SOA-запись и как её проверить, вы можете узнать в статье.
Подтвердив права на управление сайтом, вы получите доступ к информации об индексировании страниц сайта роботом Яндекса. Эти данные могут содержать конфиденциальную информацию, поэтому Яндекс должен убедиться в том, что у вас есть право на управление сайтом. Для подтверждения прав нужно внести изменения на сайт.
Владелец сайта может измениться. Поэтому Яндекс периодически проверяет наличие изменений, подтверждающих право на управление сайтом. Если при очередной проверке эти изменения не будут обнаружены, то сайт вновь перейдет в разряд «неподтвержденных» .
Проверка прав может занимать до 24 часов.
Подтверждение прав на сайт
Если у вас несколько сайтов, то подтвердить права необходимо для каждого сайта в отдельности. Если необходимо подтвердить права на поддомены сайта, вы можете воспользоваться упрощенной схемой.
Добавьте сайт в Вебмастер и на странице Настройки → Права доступа выберите способ подтверждения:
Создайте HTML-файл с заданным уникальным именем и содержимым, и разместите его в корневом каталоге вашего сайта.
Убедитесь, что файл содержит только указанный выше код. Если в HTML-файл автоматически добавляется дополнительный контент, например, элементы дизайна, проверьте настройки вашего сервера. Если вам не удается создать файл с указанным содержимым, используйте другой способ подтверждения прав.
Если сайт работает по IPv4 и IPv6, убедитесь, что по всем IP-адресам сайт отвечает корректно.\n
Добавьте в HTML-код главной страницы сайта (в элемент head ) специальный метатег.
Перейдите на главную страницу вашего сайта и убедитесь, что метатег появился в HTML-коде страницы в элементе head . Для этого в меню браузера нужно выбрать Исходный код страницы . На некоторых сайтах метатег может обновляться несколько минут.
Если сайт работает по IPv4 и IPv6, убедитесь, что по всем IP-адресам сайт отвечает корректно.
Добавьте в DNS-записи сайта запись типа TXT, содержащую указанное уникальное значение.
Проверьте, что адрес сайта в Вебмастере, для которого вы подтверждаете права, совпадает с адресом сайта, для которого создаете DNS-запись. Например, адреса с префиксом www и без него считаются разными сайтами. Записи могут обновляться достаточно долго.
Если сайт работает по IPv4 и IPv6, убедитесь, что по всем IP-адресам сайт отвечает корректно.
Когда DNS-записи обновятся, нажмите кнопку Проверить .Также вы можете получить права на управление сайтом от другого пользователя с помощью делегирования прав. Таким образом, права на сайт могут получить несколько человек. Список пользователей, подтвердивших права, отображается на странице Настройки → Права доступа .
Если вы не можете воспользоваться ни одним из указанных способов, но имеете непосредственное отношение к сайту, обратитесь к сотруднику, который отвечает за поддержку сайта.
Упрощенное подтверждение прав
Чтобы добавить в Вебмастер сайт и его поддомены, нужно подтвердить права на основной домен и на его поддомены. Для подтверждения прав на основной домен воспользуйтесь одним из способов (с помощью HTML-файла, метатега и т. д.), на поддомены — используйте код, сформированный для основного домена. Рассмотрим пример подтверждения прав с помощью HTML-файла:
Добавьте в корневой каталог сайта HTML-файл с кодом подтверждения, сформированный в Вебмастере. Добавьте в корневой каталог поддомена HTML-файл, сформированный для основного домена.Аналогично можно подтвердить права на поддомен с помощью метатега и TXT-записи в DNS.
Упрощенное подтверждение прав недоступно при делегировании — если права на управление основным доменом сайта были вам делегированы другим пользователем, то при добавлении поддоменов в сервис вам необходимо подтвердить права на управление отдельно для каждого поддомена.
Смена способа подтверждения прав
В Вебмастере перейдите на страницу Права доступа и выберите сайт.Делегирование прав
После подтверждения прав на управление сайтом, вы можете передать права другим пользователям Вебмастера. Пользователь, которому вы делегируете права, сможет использовать все возможности сервиса без ограничений.
Перейдите на страницу Настройки → Права доступа . В блоке Делегирование прав введите логин пользователя для выбранного сайта.Пользователь, которому делегировали права, должен войти в Вебмастер со своим Яндекс ID и добавить сайт. После этого права подтвердятся автоматически.
Вы можете отменить права на управление сайтом другим пользователем. Если вы делегировали права другому пользователю, а затем ваши права были отменены, то права у другого пользователя продолжат действовать.
Чтобы предоставить вам доступ к почте для доменов, нам необходимо удостовериться, что у вас есть права на управление этим доменом. Подтвердить свои права на домен можно с помощью HTML-файла, мета-тега, DNS-проверки или переноса DNS. Вы можете выбрать один из этих способов.
HTML-файл
Этот способ можно использовать только, если есть сайт с хостингом и работающим доменом.
Чтобы подтвердить домен с помощью HTML-файла:
Мета-тег
Этот способ можно использовать только, если есть сайт с хостингом и работающим доменом.
Чтобы подтвердить домен с помощью мета-тега:
- Перейдите во вкладку «Мета-тег» на странице подтверждения домена.
- Скопируйте мета-тег с персональным кодом.
- Добавьте его, перед закрывающим тэгом </head> на главной странице вашего сайта.
- Вернитесь во вкладку «Meта-тег» на странице подтверждения домена и нажмите «Подтвердить».
Обратите внимание, значения на скриншотах даны для примера. Вы должны следовать инструкциям, которые отображаются у вас на вкладке «HTML-файл».
DNS-проверка
Этот способ можно использовать, даже если сайта нет.
Чтобы подтвердить домен с помощью DNS-проверки:
Если список пустой или вы не видите домен в списке, вам сначала необходимо подключить DNS-хостинг.
- Имя: @
- Type: TXT
- Text: текст, указанный на вкладке «DNS-проверка» на странице подтверждения домена
Перенос DNS
Данный способ можно использовать даже при отсутствии сайта.
Для подтверждения своих прав на домен:
Обратите внимание, значения, представленные на скриншотах, даны для примера! Вы должны использовать те значения, которые отображаются у вас на вкладке «Перенос DNS»!
От переводчика: Это перевод статьи от EFF
A Technical Deep Dive: Securing the Automation of ACME DNS Challenge Validation.
Автор оригинальной статьи: Joona Hoikkala.
Дата оригинальной публикации: 23 февраля 2018
Ранее в этом месяце, Let's Encrypt (бесплатный, автоматизированный, открытый центр сертификации, который EFF помог запустить два года назад) преодолел важный рубеж: выдачу более 50 миллионов активных сертификатов. И это число будет продолжать расти, потому что через несколько недель Let's Encrypt также начнет выдавать wildcard-сертификаты, о которых просили многие системные администраторы.
Что такое wildcard-сертификат?
Однако, одна из ключевых идей Let's Encrypt заключается в том, что получение сертификата должно быть автоматическим процессом. Но, чтобы автоматизировать его, программное обеспечение, запрашивающее сертификат, также должно будет иметь возможность изменять записи DNS для этого домена. В целях реализации этой возможности программное обеспечение также должно иметь доступ к учетным данным для службы DNS (например, логин и пароль или криптографический токен), а эти учетные данные должны храниться там, где происходит автоматизированное получение сертификата.
Во многих случаях это означает, что если машина обрабатывающая процесс получения компрометируется, то же происходит и с учетными данными DNS, в этом то и заключается реальная опасность. В оставшейся части этого поста мы совершим глубокое погружение в компоненты, участвующие в этом процессе, и в то какие варианты делают его более безопасным.
Как работает проверка владения доменом?
На высоком уровне проверка владения доменом работает, как и все остальные автоматические проверки, которые являются частью протокола ACME, — протокола, который может использовать центр сертификации (CA), например Let's Encrypt, и клиентское программное обеспечение, например Certbot, для обмена информацией о том, какой сертификат запрашивает сервер, и как сервер должен подтвердить право собственности на соответствующее доменное имя.
Во время проверки владения доменом пользователь запрашивает сертификат из CA с помощью клиентского программного обеспечения ACME, такого как Certbot, который поддерживает данный тип проверки. Когда клиент запрашивает сертификат, CA запрашивает у клиента подтверждение права собственности на домен, путем добавления конкретной TXT-записи в свою зону DNS. Более подробно: CA отправляет уникальный случайный токен ACME-клиенту, и тот, кто имеет контроль над доменом, должен поместить этот токен как TXT-запись в свою зону DNS, в предопределенный поддомен с именем "_acme-challenge" того домена, контроль над которым пытается доказать пользователь.
Например, если Вы пытаетесь проверить домен для *.eff.org, поддомен проверки будет "_acme-challenge.eff.org". Когда значение токена добавляется в зону DNS, клиент сообщает CA продолжить проверку владения, после чего CA будет выполнять DNS-запрос к авторитетным серверам для домена. Если авторитетные DNS-серверы ответят DNS-записью, содержащей правильный токен проверки владения, право собственности на домен будет доказано, и процесс выдачи сертификата может быть продолжен.
DNS служба контролирует цифровую идентичность
Угрозы, связанные с DNS-зоной делает столь опасными, то, что DNS — это то, на что полагаются браузеры пользователей, чтобы знать, с каким IP-адресом они должны связаться, пытаясь достичь вашего домена. Это относится ко всем службам, использующим разрешаемое имя под вашим доменом, от электронной почты до веб-служб.
Когда DNS скомпрометирован, злоумышленник может легко перехватить все подключения, направленные к вашей электронной почте или другой защищенной службе, прекратить шифрование TLS (поскольку теперь они могут подтвердить право собственности на домен и получить для них свои действительные сертификаты), дешифровать данные и прочесть их, а затем повторно зашифровать данные и передать их на ваш сервер. Для большинства людей это было бы очень трудно обнаружить.
Отдельные и ограниченные привилегии
Строго говоря, для того, чтобы ACME-клиент делал обновления в автоматическом режиме, этот клиент должен иметь доступ только к учетным данным, которые могут обновлять TXT-записи для поддоменов "_acme-challenge". К сожалению, большинство программных продуктов DNS и поставщиков услуг DNS не предлагают подробные средства контроля доступа, которые позволяют ограничить эти привилегии, или просто не предоставляют API для автоматизации этого за пределами основных обновлений или транзакций DNS-зоны. Это оставляет возможные методы автоматизации непригодными или небезопасными.
Есть простой способ, который может помочь маневрировать мимо таких ограничений: использовать CNAME-запись. CNAME-записи по существу действуют как ссылки на другую запись DNS. Let's Encrypt проследует по цепочке CNAME-записей и разрешит токен проверки владения для последней записи в цепочке.
Способы смягчения проблемы
Даже используя CNAME-записи, основная проблема заключается в том, что ACME-клиенту по-прежнему будет нужен доступ к учетным данным, которые позволят ему изменить некоторую DNS-запись. Существуют различные способы смягчения этой основной проблемы с различными уровнями сложности и последствиями для безопасности в случае компрометации.
В следующих разделах этот пост представляет некоторые из этих методов, пытаясь объяснить возможные последствия того, что учетные данные будут скомпрометированы. За одним исключением, все они используют CNAME-записи.
Разрешить обновления только для TXT-записей
Первый способ — создать набор учетных данных с привилегиями, которые позволяют обновлять TXT-записи.
В случае компрометации этот метод ограничивает последствия для злоумышленника способностью выдавать сертификаты для всех доменов в зоне DNS (поскольку они могут использовать учетные данные DNS для получения собственных сертификатов), а также прерывание доставки почты. Воздействие на доставку почты происходит из TXT-записей, специфичных для почты, а именно SPF, DKIM и его расширения ADSP и DMARC. Их компрометация также облегчит доставку фишинговых писем, выдающих себя за отправителя из скомпрометированного домена.
Использовать «throwaway» домен подтверждения
Второй способ — вручную создать CNAME-записи для поддомена "_acme-challenge" и указать ими на домен проверки, который будет находиться в зоне, контролируемой другим набором учетных данных.
Например, если Вы хотите получить сертификат для покрытия «yourdomain.tld» и «www.yourdomain.tld», вам придется создать две CNAME-записи — "_ acme-challenge.yourdomain.tld" и "_acme-challenge.www.yourdomain.tld" — а также указать ими на внешний домен для проверки. Домен, используемый для проверки владения, должен быть во внешней зоне DNS или в поддиапазонной зоне DNS, которая имеет свой собственный набор учетных данных для управления. (DNS-зона субделегата определяется с помощью NS-записей и фактически делегирует полный контроль над частью зоны внешнему источнику.)
Эффект компрометации для этого метода довольно ограничен. Поскольку фактические сохраненные учетные данные предназначены для внешней зоны DNS, злоумышленник, получивший учетные данные, получит только возможность выдавать сертификаты для всех доменов, указывающих на записи в этой зоне. Однако, выяснение того, какие домены на самом деле указывают туда, тривиально: злоумышленнику просто нужно будет прочитать журналы прозрачности сертификатов и проверить, имеют ли домены в этих сертификатах магический поддомен, указывающий на уязвимую зону DNS.
Ограниченный доступ к зоне DNS
Если ваше программное обеспечение или поставщик DNS позволяет создавать разрешения, привязанные к поддомену (гранулированные привилегии), это может помочь вам смягчить всю проблему.
К сожалению, на момент публикации был найден единственный поставщик, который дает данные привилегии — это Microsoft Azure DNS. У Dyn предположительно также есть гранулированные привилегии, но мы не смогли найти более низкий уровень привилегий в их сервисе помимо «Обновление записей», которые все еще оставляют зону полностью уязвимой.
Route53 и, возможно, другие позволяют своим пользователям создавать зону субделегата, новые учетные данные пользователя, указывать NS-записи в новую зону и указывать поддомены проверки _acme-challenge для них с использованием CNAME-записей. Нужно много работы для того, чтобы корректно сделать распределение привелегий, используя этот метод, так как нужно пройти все эти шаги для каждого домена, для которого необходимо использовать проверку владения.
Использовать ACME-DNS
Дисклеймер: программное обеспечение, описанное ниже, написано автором (оригинальной статьи — прим. переводчика), и оно используется в качестве примера функций, необходимых для эффективного управления учетными данными, нужными для автоматизации проверки владения доменом через DNS безопасным образом.
Последний метод — это часть программного обеспечения под названием ACME-DNS, написанная для борьбы именно с обсуждаемой проблемой, и она может полностью устранить её. Единственный недостаток заключается в том, что этот метод добавляет еще один компонент в вашу инфраструктуру, который надо поддерживать, а также требует открыть DNS-порт (53) для общего доступа в интернет.
- /register — эта конечная точка создает новый поддомен для использования, сопровождаемый именем пользователя и паролем. В качестве необязательного параметра конечная точка регистра принимает список диапазонов CIDR для «белых» обновлений.
- /update — эта конечная точка используется для обновления текущего токена проверки владения доменом на сервере.
Единственные учетные данные, сохраненные локально, будут для ACME-DNS, и они хороши только для обновления точных TXT-записей для поддоменов проверки для доменов в поле. Это эффективно ограничивает влияние возможной компрометации для злоумышленника до способности выдавать сертификаты для этих доменов.
Вывод
Чтобы устранить проблемы с проверкой владения доменом через ACME DNS, обсуждались такие предложения, как assisted-DNS в рабочей группе ACME IETF, но в настоящее время эти проблемы все еще остаются без разрешения. Поскольку единственный способ ограничить воздействие компрометации — это ограничить права доступа учетных записей DNS-зоны до изменения определенных TXT-записей, текущие возможности для надежной реализации автоматизации проверки владения доменом незначетельны.
Единственным устойчивым вариантом было бы заставить программное обеспечение DNS и поставщиков услуг либо внедрять методы для создания более мелкомасштабных учетных данных зоны, либо предоставлять совершенно новый тип учетных данных для этого специфического варианта использования.
Читайте также: