Как проверить txt запись в dns: Проверка DNS-записей домена утилитой dig, проверка PTR, MX, A, NS, TXT, SOA, CNAME от Hoster.ru

Виды проверок — Let’s Encrypt

Последнее обновление: 8 дек. 2020 г. | Вся документация

Внимание! Английская версия сайта была обновлена, перевод неактуален (13 февр. 2023 г.) Просмотреть на английском

Когда вы запрашиваете новый сертификат у Let’s Encrypt, наши серверы проверяют права на доменные имена в сертификате, используя “испытания” (или “проверки”), согласно стандарту ACME. Проверки выполняются с помощью ACME-клиента и не требуют дополнительной настройки, но для сложных конфигураций будет полезным узнать о проверках чуть больше. Если нет уверенности, какую именно проверку применять — используйте настройки по-умолчанию для вашего ACME-клиента, или проверку HTTP-01.

Этот тип проверки используется чаще всего. Let’s Encrypt выдаёт ACME-клиенту токен, а ACME-клиент записывает этот токен в файл на web-сервере по пути

http://YOUR_DOMAIN/. well-known/acme-challenge/TOKEN. В этом файле содержится сам токен, плюс отпечаток ключа вашего аккаунта. Как только ACME-клиент сообщит Let’s Encrypt, что файл готов, Let’s Encrypt будет пытаться получить этот файл по URL (возможно, несколько раз, с различных адресов). Если полученный ответ будет верным, проверка считается успешной, и сертификат для выбранного домена готов к использованию. Если проверка прошла неудачно, требуется повторить попытку с новым сертификатом.

Реализация проверки HTTP-01 разрешает редиректы запросов, общим числом не более 10. Редиректы принимаются только на адреса, начинающиеся с “http:” или “https:”, и только на порты 80 или 443. Редиректы на IP-адреса не принимаются. Если редирект выполнялся на URL c HTTPS, то сертификат не считается подтверждённым (т.к. проверка для новых сертификатов, может обнаружить самоподписанные или просроченные сертификаты).

Проверка HTTP-01 выполняется только с использованием порта 80. Произвольный порт для проверки снижает надёжность, и потому запрещён стандартом ACME.

Плюсы:

• Упрощённая автоматизация процесса, не требующая дополнительных знаний по настройке доменов
• Выпуск сертификатов для доменов хостинг-провайдеров, привязанных по CNAME.
• Совместим с уже настроенными web-серверами.

Минусы:

• Не работает, если ваш провайдер блокирует порт 80 (это редко, но это делают некоторые провайдеры).
• Не подходит для сертификатов с подстановкой (wildcard-сертификатов).
• Для каждого web-сервера требуется свой файл.

Эта проверка требует подтверждения прав на домен с помощью специальной TXT-записи для доменного имени. Это сложнее в настройке, чем для проверки HTTP-01, но покрывает сценарии использования, недоступные для проверки HTTP-01. Кроме того, проверка DNS-01 разрешает выпускать сертификаты с подстановкой (wildcard-сертификаты). После того, как Let’s Encrypt передаёт ACME-клиенту токен, клиент создаёт содержимое TXT-записи на основе токена и ключа аккаунта, и записывает её в

_acme-challenge. YOUR_DOMAIN. Далее, Let’s Encrypt запрашивает TXT-запись в DNS-зоне домена. Если значения совпадают — сертификат готов к использованию!

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

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

Let’s Encrypt придерживается стандартов DNS для поиска TXT-записи при проверке DNS-01, поэтому можно задействовать записи CNAME или NS для делегирования права ответа за другие DNS-зоны. Например настроив субдомен _acme-challenge для специального сервера валидации. Или, если DNS-провайдер медленно обновляется, и вы хотите использовать более производительный сервер.

Для большинства DNS-провайдеров характерен “период обновления данных”, показывающий, сколько времени пройдёт с момента изменения DNS-записи до обновления всех DNS-серверов провайдера. Этот период сложно оценить, особенно когда DNS-провайдеры применяют anycast. В этом случае, в зависимости от геолокации, вы и Let’s Encrypt будете взаимодействовать с разными серверами, и получать различные результаты. Лучшие DNS API дают вам возможность автоматически проверять полноту распространения обновления. Если DNS-провайдер такой информации не даёт, придётся настроить ACME-клиент на длительное (не менее часа) ожидание перед запуском валидации.

Для одного и того же доменного имени допускается несколько TXT-записей. Например, когда требуется одновременно выполнить проверку и для обычного сертификата, и для wildcard-сертификата. Удаляйте неактуальные TXT-записи, т.к. из-за большого размера ответа сервера при проверке Let’s Encrypt признает проверку неудачной.

Плюсы:

• Подходит для сертификатов с подстановкой (wildcard-сертификатов).
• Работает в случае нескольких web-серверов.

Минусы:

• Хранение учётной записи для API на web-сервере достаточно рискованно.
• У Вашего провайдера DNS может не быть API для управления.
• У DNS API может не быть методов оценки период обновления записей.

Проверка была описана в черновиках протокола ACME. Согласно ей, вначале выполняется TLS handshake на порте 443, и посылается специальный SNI заголовок для поиска сертификата, содержащего токен. Проверка TLS-SNI-01 отключена в марте 2019 по причине недостаточной безопасности.

Разработана после признания проверки TLS-SNI-01 устаревшей, как отдельный стандарт. Как и TLS-SNI-01, проверка TLS-ALPN-01 выполняется через TLS handshake на порте 443. Но в данном случае применяется специальный протокол ALPN, чтобы на запросы валидации отвечали только серверы, знающие о таком типе проверки. Кроме того, становится возможным использовать SNI-поле, совпадающее с именем домена, для которого проводится валидация, для увеличения надёжности проверки.

Эта проверка не подходит для массового использования. Скорее, она предназначена для владельцев TLS-концевых обратных прокси-серверов, для выполнения проверки типа HTTP-01, но внутри слоя TLS, для разделения ответственности. Как правило, это относится к большим хостинг-провайдерам, но распространённые web-серверы типа Apache и Nginx, однажды, поддержат протокол ALPN (а Caddy уже поддерживает).

Плюсы:

• Будет работать, даже если порт 80 закрыт.
• Может быть выполнена исключительно на слое TLS.

Минусы:

• Пока не поддерживается Apache, Nginx или Certbot, и, возможно, не будет поддерживаться.
• • Как и для проверки HTTP-01, настраивать нужно ответ от каждого web-сервера.
• Этот метод не может быть использован для проверки доменов по шаблонам.

Проверка распространения DNS — Nslookup Tool

Hostname: Type: AAAAAAFSDBCAACERTCNAMEDHCIDDNAMEDNSKEYDSIPSECKEYLOCMXNAPTRNSNSECNSEC3PARAMPTRRPRRSIGSOASPFSRVSSHFPTXTTXT-DKIMTXT-DMARCTXT-SPFURI

Try the new Global DNS Propagation Checker

6050991″ data-longitude=»-112.4052351″ data-countrycode=»US» data-location=»Финикс, США» data-isp=»Level 3 Communications»> 8588377″ data-longitude=»2.2775177″ data-countrycode=»FR» data-location=»Париж, Франция» data-isp=»Celeste SAS»> 9911532″ data-longitude=»16.1601597″ data-countrycode=»SE» data-location=»Катринехольм, Швеция» data-isp=»Internet Border Technologies AB»> 9385466″ data-longitude=»116.1172791″ data-countrycode=»CN» data-location=»Пекин, Китай» data-isp=»CNNIC»> 1390006″ data-longitude=»101.6168155″ data-countrycode=»MY» data-location=»Куала-Лумпур, Малайзия» data-isp=»TIME dotCom Berhad»> 0878858″ data-longitude=»34.7622266″ data-countrycode=»IL» data-location=»Тель-Авив, Израиль» data-isp=»Bezeq International»> 0594838″ data-longitude=»31.2234451″ data-countrycode=»EG» data-location=»Каир, Египет» data-isp=»Etisalat Misr»> 8535258″ data-longitude=»13.2140642″ data-countrycode=»AO» data-location=»Луанда, Ангола» data-isp=»GameZone Angola»>

	Вашингтон, США Abovenet
	Даллас, США Limestone Networks
	Финикс, США Level 3 Communications
	Чикаго, США Internap
	Ванкувер, Канада Peer
	Лондон, Великобритания Exponential-e
	Париж, Франция Celeste SAS
	Франкфурт, Германия Digital Ocean
	Барселона, Испания Vodafone Spain
	Милан, Италия Fastweb
	Катринехольм, Швеция Internet Border Technologies AB
	Екатеринбург, Россия Rostelecom
	Перт, Австралия Vocus
	Окленд, Новая Зеландия Vodafone
	Пекин, Китай CNNIC
	Гонконг, Китай Netvigator
	Осака, Япония OCN
	Сеул, Республика Корея Korea Telecom
	Куала-Лумпур, Малайзия TIME dotCom Berhad
	Бангкок, Таиланд KSC Commercial Internet
	Нью-Дели, Индия Bharti Broadband
	Дубай, ОАЭ Emirates
	Тель-Авив, Израиль Bezeq International
	Мехико, Мексика BTU Comunicacion SA de CV
	Рио-де-Жанейро, Бразилия Mundivox LTDA
	Буэнос-Айрес, Аргентина NSS S. A.
	Лима, Перу Claro Peru
	Сантьяго, Чили Telefonica Empresas
	Богота, Колумбия Level 3 Colombia S.A.
	Каракас, Венесуэла Telefonica Venezolana
	Каир, Египет Etisalat Misr
	Йоханнесбург, ЮА́Р VO Connect
	Лагос, Нигерия Spectranet
	Шерага, Алжир Algerian Research Network
	Луанда, Ангола GameZone Angola

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

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

DNS propagation checker support A, AAAA, AFSDB, CAA, CERT, CNAME, DHCID, DNAME, DNSKEY, DS, IPSECKEY, LOC, MX, NAPTR, NS, NSEC, NSEC3PARAM, PTR, RP, RRSIG, SOA, SPF, SRV, SSHFP, TXT, TXT-DKIM, TXT-DMARC, TXT-SPF, URI, DNS record types.

Как использовать Nslookup для проверки записи DNS TXT

Возможность получения записей DNS TXT очень полезна во многих сценариях. В этом посте мы рассмотрим проверку записи подтверждения домена TXT для Office 365, а также для Sender Protection Framework.

В дополнение к записи MX у нас также есть возможность подтвердить право собственности на домен для Office 365 с помощью записи TXT. Почему мы хотим вручную проверять эти записи TXT Office 365? Вместо того, чтобы запускать HCW вслепую и получать множественные сбои, мы можем проверить наличие правильной записи. Это может помочь предотвратить MaxUriReached: один и тот же URI не может быть прикреплен к другому AppId в течение одного дня. Ошибка , которая обсуждается в KB 3027942.

При настройке Sender Protection Framework (SPF) нам необходимо создать, а затем добавить запись SPF во внешний DNS. файл зоны для данного домена. В настоящее время это тип TXT. Это позволяет внешним почтовым серверам использовать запись SPF и принимать разумные решения в зависимости от того, кем является отправитель.

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

Как упоминалось в разделе Как проверить запись SRV автообнаружения Exchange с помощью Nslookup, существует два способа запуска nslookup — интерактивный и неинтерактивный. Неинтерактивность хороша, когда вы знаете, что хотите запросить только один фрагмент данных. Interactive позволяет выполнять несколько запросов с использованием одного экземпляра nslookup, а параметры можно включать и выключать по мере необходимости.

Использование Nslookup — NonInteractive

Быстрый запрос для проверки записей TXT в домене Tailspintoys.ca может выглядеть так:

 NSLookup.exe -q=TXT Tailspintoys.ca 

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

Использование Nslookup для быстрой проверки записей TXT

Запустите nslookup в интерактивном режиме. Затем установите тип запроса TXT:

 set q=TXT 

Затем мы ищем записи TXT для данного домена. В этом случае мы ищем записи TXT, присутствующие в домене Tailspintoys.ca . Был использован общедоступный DNS-сервер Google, поэтому каждый может легко получить к нему доступ и выполнить шаги, описанные в этом посте. Вы найдете много открытых точек Wi-Fi, также использующих его.

Повторение теста для домена Wingtiptoys.ca показывает наличие дополнительных записей TXT. Возвращаются три записи TXT. Выделенная запись — это запись SPF, а запись, расположенная непосредственно над ней, — подтверждение владения доменом из Office 365.

Неавторизованный против авторитетного

Внимательный читатель заметит, что возвращенные запросы перечислены как неавторизованные. -авторитетный. Это выделено в красной рамке ниже.

Почему это? Большая желтая стрелка выше показывает, что мы запрашиваем DNS-сервер Google. Этот DNS-сервер не является авторитетным для зоны и выполнил рекурсивный запрос от нашего имени.

Если мы хотим связаться с авторитетным сервером напрямую, мы можем это сделать. Нам просто нужно знать, кто это. В целях резервирования в зоне DNS должно быть указано как минимум два авторитетных DNS-сервера. Хотя мы можем искать запись SOA, мы должны запросить запись сервера имен (NS).

Обратите внимание, что тип запроса теперь NS, что означает «Сервер имен».

Теперь мы знаем, что для домена tailspintoys.ca два полномочных DNS-сервера называются ns78.domaincontrol.com и ns77.domaincontrol.com, , мы можем запросить их напрямую. Адреса IPv4 для этих серверов имен:

.

ns77.domaincontrol.com 216.69.185.49

ns78.domaincontrol.com 208.109.255.49

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

Справочник по SPF

Для справки: у Microsoft есть несколько ресурсов SPF. Приведенный ниже мастер SPF помогает создать содержимое вашей записи SPF.

Обновление от 17 ноября 2016 г. Похоже, что мастер Microsoft SPF ушел в прошлое, как динозавры…..  Взгляните на некоторые другие инструменты…..

Все записи SPF состоят из трех частей: заявление о том, что это запись SPF, домены и IP-адреса, которые должны отправлять электронную почту, и правило принудительного применения. Вам нужны все три в действительной записи SPF. Вот пример наиболее распространенной записи SPF для Office 365:

TXT Name @ Values: v=spf1 include:spf. protection.outlook.com include:sharepointonline.com -all

Не копируйте указанную выше запись SPF в ваша DNS-зона. Вам необходимо спланировать правильное внедрение SPF.

 

Проблемы с DNS-запросами

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

Проблема №1 — Использование IPv4

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

Это было странно. Netmon никогда не лжет. Но когда я пронюхал трафик со своего ноутбука с Windows 10 и виртуальной машины Windows Server 2012 R2, в сети не было видно никаких пакетов.

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

 

Проблема №2. Не злите богов чувствительности к регистру

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

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

Большая желтая стрелка (достаточно большая??) показывает, что рабочая опция написана строчными буквами.

 

Проблема № 3. Остерегайтесь устройств кэширования

В нескольких местоположениях реализованы устройства кэширования DNS, которые могут соответствовать или не соответствовать стандартам RFC. Прискорбно и довольно часто обнаруживать, что некоторые устройства кэширования DNS вполне счастливо игнорируют TTL в записи DNS и кэшируют ее в течение нескольких дней. Да такое бывает. Возьмем приведенный ниже пример. Это написано из какого-то зала ожидания аэропорта в Канаде, который обслуживает Glenfiddich. Хотя количество потребляемого односолодового виски не имеет ничего общего с орфографическими ошибками в этом посте!

В приведенном ниже примере мы нацеливаемся на авторитетный сервер имен для домена tailspintoys. ca. Но обратите внимание, что мы получаем только неавторитетный ответ.

Сравните это с выполнением точно таких же команд с виртуальной машины в Azure без махинаций с DNS:

Это действительно авторитетные ответы!

 

Выпуск № 4. За рулем Дотти

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

Сравните приведенные выше запросы (подчеркнуты красным) с приведенным ниже снимком экрана. В чем разница? Обратите внимание, что в приведенном ниже запросе есть точка в конце запроса. Это говорит nslookup не добавлять суффикс домена.

В качестве альтернативы мы можем указать nslookup не добавлять суффикс DNS, указав параметр Nosearch . Это показано ниже, обратите внимание, что после поискового запроса «9» нет точки. 0005 outlook.office365.com ».

 

Cheers,

Rhoderick

Используйте метод проверки DNS TXT для подтверждения контроля домена

• Документация по продукту DigiCert
• Cert Central
• Управление сертификатами
• Поддерживаемые методы DCV для проверки доменов в OV/EV TLS Заказы сертификатов /SSL
• Используйте метод проверки DNS TXT для подтверждения контроля над доменом

Продемонстрируйте контроль над своим доменом с помощью записи DNS TXT

Проверьте статус вашего заказа на сертификат TLS/SSL и используйте метод DCV DNS TXT Record, чтобы продемонстрировать контроль над доменом в заказе. Дополнительные сведения см. в разделе Демонстрация контроля над доменами в заказе SSL-сертификата.

Примечание

Отправка доменов на проверку в процессе оформления заказа означает, что сертификаты не будут выдаваться до завершения проверки домена. Для немедленной выдачи сертификата по возможности отправьте домены на предварительную проверку. См. раздел Предварительная проверка домена: поддерживаемые методы DCV.

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

Шаг 1: Проверьте статус вашего отложенного заказа

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

1. В своей учетной записи CertCentral перейдите на страницу сведений о заказе Order # .

   1. В левом главном меню нажмите Сертификат > Заказы .

   2. На странице Orders в столбце Order # щелкните ссылку номера заказа сертификата.

2. На странице сведений о заказе № в разделе Статус заказа проверьте статус выдачи заказа (заказ ожидает завершения проверки домена или организации?).

   Уведомление

   После завершения проверки (домены и организация) раздел Статус заказа больше не отображается на странице сведений Заказ № .

Шаг 2. Используйте DNS TXT для демонстрации контроля над доменами ДВС для.

Уведомление

Если в заказе указано несколько доменов (SAN), каждый из них будет указан. Те, рядом с которыми стоит галочка, проверены. Те, рядом со значком часов, все еще нуждаются в проверке.

В окне Prove Control Over Domain в раскрывающемся списке DCV Method выберите DNS TXT Record .

Создайте запись DNS TXT

1. В поле Токен скопируйте свой уникальный токен. Чтобы скопировать значение в буфер обмена, щелкните один раз в текстовом поле.

   Примечание: Срок действия уникального токена истекает через 30 дней. Чтобы сгенерировать новый токен, нажмите кнопку Generate a New Token 9.ссылка 0032.

2. Перейдите на сайт вашего DNS-провайдера и создайте новую запись TXT.

3. В поле TXT Value вставьте уникальный токен, скопированный из вашей учетной записи DigiCert.

4. Относительно хоста Поле :

   1. Базовый домен (например, example.com)

      Если вы проверяете базовый домен, оставьте хост  пустое поле или используйте символ @ ( в зависимости от требований вашего провайдера DNS).

   2. Субдомен (например, my.example.com)

      В поле Хост введите субдомен, который вы проверяете.

5. В поле типа записи (или аналогичном) выберите TXT .

6. Выберите значение Time-to-Live ( TTL ) или используйте значение по умолчанию вашего DNS-провайдера.