Разное

Dns txt: Страница не найдена | REG.RU

11.06.2021

Содержание

Использовать DNS TXT в качестве метода DCV

Использовать DNS TXT в качестве метода DCV | docs.digicert.com It looks like your browser has JavaScript disabled. Some site features might not work unless you enable JavaScript.

Выполните следующие инструкции для проверки статуса вашего заказа сертификата DV, а затем для выбора метода подтверждения действительности сообщений DNS TXT, подтверждающих управление доменом в заказе.

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

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

  1. В меню на боковой панели вашей учетной записи CertCentral нажмите Сертификаты > Заказы.

  1. На странице «Заказы» воспользуйтесь фильтрами и функциями расширенного поиска для поиска заказа сертификата DV.

  1. В столбце «Заказ №» находящегося на рассмотрении заказа нажмите на ссылку с номером заказа.

  1. На странице данных «Заказ №», в разделе «Статус заказа» проверьте статус проверки заказа (ожидает ли заказ завершения проверки домена?).

  1. В разделе «Вам необходимо» нажмите ссылку Подтвердить управление доменом.

  1. В окне «Подтвердить управление доменом» в раскрывающемся списке

    Метод подтверждения DCV выберите опцию DNS TXT (рекомендуется).

  1. Создать запись DNS TXT для домена

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

    1. В поле Копировать данное произвольное действительное значение для вставки в поле записи TXT скопируйте произвольное значение.
      Если ваш заказ включает несколько доменов, добавьте эту произвольное значение в запись DNS TXT каждого домена.
      Примечание: Срок действия произвольного значения истекает через тридцать дней.
    2. Перейдите на сайт вашего провайдера DNS и создайте новую запись TXT.
    3. В поле «Значение TXT» вставьте произвольное значение, скопированное из своей учетной записи CertCentral.
    4. Поле Узел
      1. Базовый домен (например,[yourdomain].com)
        Вы проверяете достоверность базового домена? Оставьте поле «Узел» пустым или добавьте символ @ (в зависимости от требований вашего провайдера DNS).
      2. Субдомен (например,[your.domain].com)
        Вы проверяете достоверность субдомена? В поле «Узел» добавьте субдомен, достоверность которого вы проверяете.
    5. В поле типа записи (или в другом аналогичном поле) выберите TXT.
    6. Выберите значение времени жизни (TTL) либо используйте значение по умолчанию, установленное вашим провайдером DNS.
    7. Сохраните запись.

Ваш заказ включает несколько доменов? Сначала создайте запись DNS TXT для каждого домена в заказе перед тем, как запустить проверку. Если в каких-либо доменах отсутствует запись DNS TXT, содержащая произвольное значение, предоставленное DigiCert, “проверка” завершится неудачно.

  1. Проверка записи DNS TXT

    1. В меню на боковой панели вашей учетной записи CertCentral нажмите Сертификаты > Заказы.
    2. На странице «Заказы» в столбце «Заказ №» для заказа сертификата DV нажмите ссылку с номером заказа.
    3. На странице данных «Заказ №» в разделе статуса заказа в поле «Вам необходимо» нажмите на ссылку Подтвердить управление доменом.
    4. В окне «Подтвердить управление доменом» нажмите Проверить.

  1. Операция выполнена! Вы завершили проверку управления доменом.

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

×

Как подтвердить право собственности на домен (с помощью HTML-страницы или записи DNS) | Сертификаты SSL

Примечание. При подтверждении права собственности на домен мы не переходим по ссылкам на другие веб-сайты.

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

МетодПринцип работы
‌‌с помощью страницы HTML;‌Загрузите HTML-страницу с указанным контентом в определенный каталог на веб-сайте, для которого используется доменное имя
‌‌с помощью записи DNS. ‌‌Создать указанную нами запись TXT в файле зоны вашего доменного имени (DNS).

Способ подтверждения зависит от типа запрашиваемого сертификата:

Тип сертификатаHTMLDNS
Стандартный✓✓
Делюкс✓✓
Расширенная проверка✓✓
Универсальный—✓
Единый сертификат связи✓✓

Перейти по одной из следующих ссылок для получения указаний на основе информации, отправленной вам по электронной почте.

Страница HTML

Вы получите от нас электронное письмо с уникальным кодом: «Ваш уникальный код для этих способов: [УникальныйКод]».

  1. С помощью такой программы, как Notepad или TextEdit, создайте файл с именем godaddy.html.
  2. Скопируйте уникальный код и только уникальный код в этот файл. Например, если ваш уникальный код — 12345, содержимое нового HTML-файла должно быть следующим:

    12345

  3. В каталоге верхнего уровня веб-сайта, для которого используется доменное имя, создайте папку с именем /.well-known/pki-validation/. Как правило, это корневой каталог веб-сайта, например coolexample.com. Подробную информацию вы найдете в статье Что такое корневой каталог моего веб-сайта?. Примечание. Если вы используете сервер Windows, папку нужно назвать /.well-known./, а не /.well-known/.
  4. Поместите новый HTML-файл в каталог pki-validation. После того как вы поместите файл в это расположение, URL-адрес файла станет примерно следующим:
    http://coolexample.com/.well-known/pki-validation/godaddy.html    .
  5. Убедитесь, что вы можете получить доступ к файлу godaddy.html в веб-браузере, а затем выполните инструкции из раздела Проверка владения именем домена этой статьи.

Если сертификат SSL предназначен для корневого домена, HTML-файл должен находиться по адресу http://coolexample.com/.well-known/pki-validation/godaddy.html. Адрес http://www.coolexample.com/.well-known/pki-validation/godaddy.html работать не будет.

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

Запись DNS

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

Запись TXT можно создать только в той компании, серверы имен которой используются вашим доменом. Если ваш домен использует наши серверы имен, обратитесь к статье Как управлять файлами зоны DNS.

Для создания записи TXT воспользуйтесь следующей информацией:

ПолеЧто ввести
Имя (хост)Введите @. Если для DNS не используется хостинг GoDaddy, оставьте это поле пустым.
ЗначениеПолностью введите значение TXT, которое мы отправили вам по электронной почте.

Создав запись DNS, выполните инструкции в разделе Проверка владения именем домена этой статьи.

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

Как подтвердить владение доменным именем
  1. Войдите в свой аккаунт GoDaddy.
  2. Щелкните Сертификаты SSL.
  3. Выберите Управление около сертификата, который хотите использовать.
  4. Нажмите кнопку Проверить мое обновление.

Для подтверждения может потребоваться 5-10 минут.

Что дальше

  • Если сертификат SSL предназначен для основного доменного имени веб-сайта, размещенного на хостинге GoDaddy, мы установим его автоматически.
  • Если сервер размещен на другом хостинге, вам потребуется скачать сертификат SSL самостоятельно.

Как добавить MX, TXT, CNAME, A и др. записи на DNS-серверы?

Если вы хотите использовать DNS-серверы вашего хостинга:

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

 

Если вы хотите использовать DNS-серверы регистратора (ns1.r01.ru, ns2.r01.ru):

  1. Авторизуйтесь в панели управления, перейдите в раздел Домены / Международные домены и выберите интересующий домен, нажав на него.
  2. Нажмите на иконку «Редактирование» (или «Смена DNS-серверов» для международных доменов) — открывшейся форме выберите опцию «Разместить первичный и вторичный DNS-серверы на серверах Регистратора» и сохраните изменения. Как правило они вступают в силу через 1-15 мин.
  3. После вступления в силу изменений на странице управления доменом нажмите на синюю иконку «Управление DNS-зоной на серверах Регистратора«. Здесь нужно выбрать тип записи, указать ее данные — хост (имя субдомена) и значение (имя домена или IP-адрес на который будет указывать запись).

NOTE:

  • если вы хотите создать запись для самого домена (без www) — поле «Хост» оставьте пустым (символ @ указывать не нужно).
  • если вы также хотите привязать поддомен www — дополнительно создайте еще одну аналогичную запись для этого субдомена, указав его в поле «Хост»
  • если вы хотите дополнительно привязать все поддомены — создайте также запись с символом звездочки (*) в поле Хост.
  • CNAME-запись можно создать только для субдомена, если вы хотите привязать сам домен — можно создать A-запись указывающую на IP-адрес хостинг-сервера.

 

Если вы хотите использовать сторонние DNS-серверы (например, бесплатные или платные сервисы, такие как: DNS-хостинг Яндекса, Cloudflare, DNS Made Easy и т.д.):

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

Configuring DNS Service Discovery — Служба поддержки Apple

You can advertise a single webpage to local devices by adding just five records to your authoritative DNS server’s zone file. Advertising additional pages requires just three more records each. You must have write access to your zone files.

Note: You may want to set a short DNS TTL (time-to-live) so you can test and make changes without having to wait a long time for the updates to propagate.

; 1. Domain Enumeration;; These records invite devices to browse this domain.; (The '@' sign means "the current domain" --; i.e. the domain being described by this zone file.) b._dns-sd._udp IN PTR @ ; b = browse domainlb._dns-sd._udp IN PTR @ ; lb = legacy browse domain; (domain that will be used for devices that don’t specify a domain to browse) ; 2. List of named service entities;; These records list the named 'http' service entities you want devices; to be able to discover. You can use upper-case, punctuation,; UTF-8 rich text, etc., in service names, but certain punctuation; like spaces and dots needs to be escaped with a backslash in the; name server zone file (because that file’s content is sent as raw data, not escaped). _http._tcp PTR New\ User\ Information\ Page._http._tcp ; 3. SRV & TXT records describing each service entity named above;; These records tell devices how to access the named 'http' service entities; listed above. In the example below, fill in the correct host name.; If it’s a fully qualified host name, it needs to end with a dot, as shown.; If it’s a partial host name relative to the current zone (e.g. just "nu-info",; with the remainder of the name being implicit) then don’t end it with a dot.; The "path=/xxx" in the TXT record tells the web browser the specific; page on the server it should request in its "HTTP GET" command.; Often, but not always, the path will be just "/".New\ User\ Information\ Page._http._tcp SRV 0 0 80 nu-info.example.com. TXT path=/

Published Date: December 14, 2020

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

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

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

Когда вы запрашиваете новый сертификат у 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 (редко, но интернет-провайдеры блокируют этот адрес)
  • Let’s Encrypt не разрешает использовать эту проверку для сертификатов с подстановкой (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-серверов.

Минусы:

  • У DNS-провайдера может не быть своего API.
  • Хранение учётной записи для 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-сервера.

Добавление записи TXT | Name.com

Запись TXT — это запись ресурса, обычно используемая для целей проверки и проверки электронной почты. Записи проверки электронной почты обычно представлены в двух формах — DKIM и SPF, которые настроены как TXT для проверки и аутентификации электронной почты. Если вам предлагается настроить DKIM и SPF, вы должны выбрать TXT .

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

Ваш провайдер предоставит ваши записи, и форматирование довольно простое с длинной строкой текста, которая входит в раздел ответов.

Пример записи TXT (проверка Google):

Примечание: Если вы хотите настроить запись DNS с помощью Name.com, важно отметить, что вам необходимо использовать наши серверы имен, поэтому name.com управляет вашим DNS и размещает его. Домены, зарегистрированные на Name.com, по умолчанию используют наши серверы имен, но для того, чтобы указать ваш домен на наши серверы имен или убедиться, что они указаны правильно, см. Наше руководство по серверам имен по умолчанию.

Если вы используете серверы имен, выполните следующие действия:

  1. Войдите в свою учетную запись Name.com.
  2. Нажмите кнопку МОИ ДОМЕНЫ , расположенную в правом верхнем углу.
  3. Щелкните имя домена, для которого хотите создать запись TXT.
  4. Щелкните Управление записями DNS .
  5. Здесь вы добавите желаемую запись TXT, предоставленную вашим хостом.
  • Выберите TXT в раскрывающемся меню Тип .
  • Если предоставлен поддомен или хост, введите его в поле Host .
  • Введите или скопируйте + вставьте значение (строку) в поле Ответ .
  • Оставьте TTL как 300 (по умолчанию)
  • Нажмите кнопку Добавить запись .

После создания записей домен должен работать в течение 24 часов.

Как я могу добавить запись TXT к своим записям DNS? — База знаний

Если вы находитесь в процессе добавления нового разрешенного корневого домена в свою учетную запись KnowBe4, приведенная ниже информация предоставит рекомендации по добавлению записи TXT в ваши записи DNS.

Перейти к:
Зачем нужно добавлять запись TXT?
Перед началом работы
Создание записи TXT

Поиск и устранение неисправностей

Зачем добавлять запись TXT?

Добавление записи TXT в записи DNS вашего домена позволит KnowBe4 подтвердить, что вы владеете и поддерживаете домен.

После выполнения инструкций в этой статье подтвердите домен в списке Разрешенных доменов в настройках учетной записи, выполнив следующие действия.

  1. На консоли KnowBe4 щелкните свой адрес электронной почты в правом верхнем углу и выберите Настройки учетной записи .
  2. Перейдите в раздел Информация об организации своих настроек.
  3. Щелкните ссылку Allowed Domains . На открывшейся странице перечислены все ваши разрешенные в настоящее время корневые домены.

Наверх

Перед началом работы

Прежде чем вы сможете создать запись TXT, вам необходимо:

  • Иметь возможность изменять записи DNS для домена вашей организации или обращаться к назначенному сотруднику в вашей организации, который может.
  • Укажите хоста / регистратора домена, если вы этого еще не знаете.
  • Получите уникальную запись TXT, которая будет применяться для всех разрешенных доменов в вашей учетной записи KnowBe4.
    • Чтобы получить запись TXT, следуйте инструкциям по добавлению корневого домена. Шаг 6 предоставит вам запись TXT, которую вам нужно будет добавить в свои записи DNS.

Наверх

Создание записи TXT

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

Инструкции по записи TXT для конкретных регистраторов доменов

Инструкции для этого могут отличаться в зависимости от регистратора домена или хоста. Ниже мы включили ссылки на различных популярных регистраторов доменов (все ссылки открываются в новом окне).

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

Пример шагов с использованием Cloudflare

Ниже приведены инструкции по добавлению записи TXT в домен Cloudflare.

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

  1. Войдите в свою учетную запись Cloudflare и выберите домен, который вы хотите добавить в свою учетную запись KnowBe4.
  2. Выберите DNS .
  3. Щелкните раскрывающееся меню, показанное ниже, и выберите TXT .
  4. Добавьте символ @ в поле Name (или Hostname).
  5. Щелкните поле Click, чтобы настроить поле и добавить свою уникальную запись TXT, полученную на шаге 6 добавления корневого домена:
  6. Сохраните ваши настройки.
  7. Разрешить обновление новых настроек. Затем подтвердите свой новый корневой домен в разделе «Разрешенные домены» в настройках вашей учетной записи.

Наверх

Поиск и устранение неисправностей

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

  1. Убедитесь, что ваша запись TXT была точной и соответствует той, которая указана в разделе «Разрешенные домены» в настройках вашей учетной записи.
  2. Обратитесь к своему регистратору домена за конкретными инструкциями или помощью по добавлению записи TXT в записи DNS.
  3. При желании вы можете проверить правильность добавления записи TXT, просмотрев записи TXT для своего домена. Это можно сделать несколькими способами:
    • Найдите сайт, который поможет вам найти запись TXT. MXtoolbox является примером. См. Ниже:
  4. Убедитесь, что ваши записи TXT были обновлены вручную, с помощью командной строки:

Unix / Linux:

$ копать TXT yourdomain здесь.com

Windows:

c: \> nslookup -type = TXT yourdomainhere.com

Если ваши обновления были успешными, выходные данные этой записи должны включать ваш уникальный код записи TXT, указанный в разделе «Разрешенные домены» в настройках вашей учетной записи.

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

К началу

Проверка вашего домена — Совместное использование — Документация

Подтверждение владения доменом

Добавьте запись DNS TXT в свою запись DNS, чтобы подтвердить право собственности

Вкладка DNS Verification вашего выбранного домена содержит информацию TXT, которую вам необходимо добавить в свою запись DNS.

  1. Перейдите в раздел записи DNS вашего хоста домена.
  2. Добавьте запись TXT в свою запись DNS.
  3. Добавьте @ в поле Host (если это требуется хостом вашего домена).
  4. После того, как изменения распространятся на веб-серверы вашего домена, нажмите кнопку Verify в нижней части вкладки DNS Verification для выбранного домена.
    Примечание: Обычно это изменение происходит всего за несколько минут, однако в некоторых случаях для его завершения может потребоваться до 72 часов.
  5. Оставьте запись TXT в своей записи DNS, так как она может периодически проверяться в целях проверки.

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

Загрузите HTML-файл в свой веб-каталог и подтвердите право собственности на домен в Business Manager.

Вкладка HTML File Upload выбранного домена содержит проверочный HTML-файл, который необходимо загрузить на свой веб-сайт.

  1. Загрузите проверочный файл HTML.
  2. Загрузите файл в корневой каталог вашего веб-сайта.Вы сможете увидеть, что он загружается по ссылке, представленной на вкладке HTML File Upload .
  3. Когда это будет сделано, нажмите кнопку Verify в нижней части вкладки HTML File Verification для выбранного домена.
  4. Оставьте проверочный файл HTML в корневом каталоге вашего веб-сайта, так как он может периодически проверяться в целях проверки.

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

Добавьте метатег в раздел

на главной странице вашего домена

Вкладка Meta Tag Verification вашего выбранного домена содержит метатег, который необходимо добавить на домашнюю страницу вашего домена.

  1. Добавьте метатег, содержащий ваш проверочный код, в раздел в HTML-коде домашней страницы вашего домена.
  2. Убедитесь, что метатег отображается, посетив домашнюю страницу вашего домена и просмотрев исходный HTML-код.
  3. После подтверждения нажмите кнопку Verify внизу вкладки Meta Tag Verification для выбранного домена.
  4. Оставьте метатег на главной странице вашего домена, так как он может периодически проверяться в целях проверки.

Как ввести значения TXT в Google Cloud DNS

Блог> Как ввести значения TXT в Google Cloud DNS

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

Если вы не будете осторожны, Google удалит все пробелы из вашего ввода.Кроме того, при попытке ввести длинный текст, например открытый ключ DKIM, вы можете столкнуться с неописуемой ошибкой неверных данных записи .

Непонятные данные о недопустимой записи Ошибка

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

TL; DR: вам нужно разделить длинные значения на части по 255 символов и заключить ввод в двойные кавычки. Для этого вы можете использовать наш разделитель записей DNS.

Обе эти проблемы зарегистрированы в Google Issue Tracker, см. Здесь и здесь.

Как работают записи ресурсов

TXT

Как определено в RFC1035, запись ресурса DNS TXT содержит одну или несколько структур . — это структура, которая широко используется в DNS для передачи текстовых строк. Он состоит из байта длины, за которым следует количество текстовых символов.

Поскольку размер индикатора длины составляет всего 1 байт, максимальная длина составляет 255 символов (байтов).Это также причина того, что максимальная длина доменного имени составляет 255 символов.

Иногда требуется длина более 255 символов, поэтому запись ресурса TXT может содержать несколько структур . Клиент DNS должен объединить все части в одно значение, чтобы восстановить исходный текст. Между частями не должно быть пробелов.

Цитировать или не цитировать?

При использовании Google Cloud DNS первое, что вы можете заметить, это то, что Google хочет, чтобы вы заключили значение TXT в двойные кавычки, если оно содержит пробелы.Если вы не добавите кавычки, каждое слово в значении будет сохранено (и, таким образом, обслуживаться) как отдельный .

Google хочет, чтобы вы заключили строки в кавычки

Итак, если вы введете значение , это будет запись TXT без кавычек как данные TXT в Google Cloud DNS, Google фактически будет обслуживать 5 структур в записи ресурса TXT . Эти части будут объединены DNS-клиентом без пробелов.

Используя dig , мы видим результат:

  mailhardener.com. 300 IN TXT "thisisaTXTrecord"

Обратите внимание, что кавычки в результате добавлены dig для удобства чтения, их не было в ответе DNS-сервера.

Почти все другие поставщики услуг DNS предполагают, что вы хотите включить символы пробела, чтобы они не требовали от вас добавления кавычек.

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

Пробелы не всегда нужны

Для DKIM, DMARC, MTA-STS и SMTP TLS, сообщающих DNS-записи, вам фактически не нужны пробелы, и поэтому вам не нужны кавычки.

Возьмем, к примеру, эту запись DMARC:

  v = DMARC1; p = отклонить; rua = mailto: [email protected]

Пары ключ / значение разделяются точкой с запятой, любые пробелы игнорируются.

Таким образом, вы также можете записать это как:

  v = DMARC1; p = отклонить; rua = mailto: dmarc @ in. mailhardener.com

Обе конфигурации работают одинаково, хотя последняя менее читабельна.

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

Единственным исключением является SPF, потому что SPF фактически использует пробелы в качестве разделителя для правил сопоставления. При работе с SPF необходимо использовать кавычки. Опять же, обратите внимание, что это требование довольно специфично для Google Cloud DNS, другие поставщики услуг DNS могут не требовать эти кавычки, и их установка приведет к двойному цитированию.Всегда дважды проверяйте свои изменения с dig .

Неверная запись данных

Ошибка

При вставке длинной строки в интерфейс Google Cloud DNS вы можете столкнуться с неописуемой ошибкой недопустимые данные записи .

Непонятные данные о недопустимой записи Ошибка

Недопустимые данные записи Ошибка возвращается Google, если ввод данных TXT превышает 255 символов. Обычно это происходит с записями DKIM, поскольку они обычно довольно длинные.

Чтобы исправить это, вам нужно разделить строку на части из 255 символов.

Правильно, крупнейшая компания по автоматизации на планете хочет, чтобы вы вручную и побили свой рекорд в 255 байтовых частях. Они не сделают этого за вас. Практически любой другой поставщик услуг DNS автоматически разделит ваш ввод на несколько структур , но не Google.

Вы можете использовать наш разделитель записей DNS для разделения и цитирования записи DKIM в формате, подходящем для Google Cloud DNS.

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

Заключение

Веб-интерфейс Google Cloud DNS довольно сбивает с толку при работе с записями ресурсов типа TXT .

При работе с записями ресурсов TXT в Google Cloud DNS соблюдайте следующие правила:

  • Всегда указывать записи SPF
  • Вы должны разделить длинные значения (например, DKIM) на части из 255 символов
  • Цитирование записей отчетов DKIM, DMARC, MTA-STS и SMTP TLS является необязательным

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

Существует обращение в службу поддержки о поддержке ввода длинного текста в системе отслеживания проблем Google, и мы открыли запрос функции об удалении требования цитаты.

См. Также

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

Войти Сейчас

watson / dns-txt: кодирование / декодирование DNS-SD TXT-записи полей RDATA

Кодирует или декодирует поле RDATA в многоадресных записях TXT DNS. Для использования с обнаружением служб на основе DNS. Подробнее см. RFC. 6763.

Установка 

  npm установить dns-txt

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

 var txt = require ('dns-txt') ()

var obj = {
  foo: 1,
  бар: 2
}

var enc = txt.encode (obj) // <буфер 05 66 6f 6f 3d 31 05 62 61 72 3d 32>

текст.decode (enc) // {foo: '1', bar: '2'}

API

Кодер и декодер соответствуют RFC 6763.

Инициализировать

Модуль предоставляет функцию-конструктор, которую можно вызвать с помощью объект необязательных опций:

 var txt = require ('dns-txt') ({binary: true})

Возможные варианты:

  • двоичный — Если установлено значение true , все значения будут возвращены как Buffer объекты. По умолчанию все значения преобразуются в строки.Но согласно RFC значения могут быть любыми двоичными данными. Если вы ожидаете двоичные данные, используйте эту опцию.
txt.encode (obj, [буфер], [смещение])

Принимает объект типа ключ / значение и возвращает буфер с закодированным TXT. записывать. Если в качестве второго аргумента передается буфер, объект должен быть закодированы в этот буфер. В противном случае следует выделить новый буфер Если в качестве третьего аргумента передается смещение, объект должен быть закодировано с этим байтовым смещением. По умолчанию байтовое смещение составляет 0 .

Этот модуль не выполняет активную проверку пар ключ / значение, но сохраняет в соответствии с правилами:

  • Чтобы быть совместимым с RFC, каждый ключ должен соответствовать правилам, как указано в разделе 6.4.

  • Чтобы соответствовать RFC, каждое значение должно соответствовать правилам, как указано в разделе 6.5.

После кодирования txt.encode.bytes устанавливается равным количеству байтов, используемых для закодировать объект.

txt.декодировать (буфер, [смещение], [длина])

Берет буфер и возвращает декодированный объект ключ / значение. Если смещение переданный в качестве второго аргумента объект должен быть декодирован из этого байтовое смещение. По умолчанию байтовое смещение составляет 0 . Обратите внимание, что все ключи будут в нижнем регистре, и все значения будут объектами буфера.

После декодирования txt.decode.bytes устанавливается равным количеству байтов, используемых для расшифровать объект.

txt.encodingLength (obj)

Принимает один объект типа ключ / значение и возвращает количество байтов, которое задано. объект потребует, если он закодирован.

Лицензия

MIT

Анализ записей TXT DNS для поставщиков онлайн-услуг по отпечаткам пальцев

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

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

Ниже приведен обзор содержимого, если вы хотите пропустить его:

Процесс проверки прав собственности на домен

Когда компании или частные лица хотят использовать онлайн-сервис, связанный с одним из их доменов, необходимо подтвердить право собственности на этот домен.В зависимости от поставщика услуг этот процесс обычно называется «проверка домена» или «проверка домена».

Ниже в общих чертах показано, как обычно работает этот процесс:

  1. Компания создает учетную запись у поставщика онлайн-услуг.
  2. Компания предоставляет поставщику онлайн-услуг доменное имя, которое необходимо проверить.
  3. Поставщик онлайн-услуг отправляет электронное письмо, содержащее уникальный токен проверки домена (текстовое значение), зарегистрированному контактному лицу компании для домена.
  4. Затем компания создает запись DNS TXT для своего домена, содержащую токен проверки домена, который они получили по электронной почте от поставщика онлайн-услуг.
  5. Поставщик онлайн-услуг проверяет право собственности на домен, выполняя DNS-запрос, чтобы убедиться, что запись TXT, содержащая токен проверки домена, была создана.
  6. В большинстве случаев после завершения процесса проверки домена компания может удалить запись DNS TXT, содержащую токен проверки домена.

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

Примечание. Для проверки домена не всегда требуется запись DNS TXT. Некоторые поставщики онлайн-услуг просто запрашивают загрузку текстового файла, содержащего токен проверки домена, в корневой веб-сайт веб-сайта домена. Например, http: // mywebsite.com / validation_12345.txt. Google dorking может быть удобным способом найти эти экземпляры, если вы знаете, что ищете, но пока давайте сосредоточимся на записях DNS.

Анализ записей TXT для миллиона доменов

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

Выбор образца домена

Я начал с простого получения записей DNS TXT для 1 миллиона лучших сайтов Alexa.Я использовал немного более старый список, но для тех, кто хочет повторно добывать эту информацию, у Amazon есть услуга, которую вы можете использовать по адресу https://aws.amazon.com/alexa-top-sites/.

Инструменты для запроса записей TXT

Записи TXT

DNS можно легко просматривать с помощью таких инструментов, как nslookup, host, dig, massdns или инструментов, ориентированных на безопасность, таких как dnsrecon. В итоге я использовал базовый сценарий PowerShell для выполнения всех DNS-запросов, потому что PowerShell позволяет мне лениться. 😊 Это было немного медленно, но все же потребовалось меньше дня, чтобы собрать все записи TXT с 1 миллиона сайтов.

Ниже приведен базовый сценарий сбора, который я использовал. 

 # Импортировать список доменов
$ Domains = gc c: \ temp \ domains. txt

# Получить записи TXT для доменов
$ txtlist = $ Домены |
ForEach-Object {
    Resolve-DnsName -Type TXT $ _ -Verbose
}

# Отфильтровать большинство записей SPF
$ Results = $ txtlist | где type -like txt | выберите имя, тип, строки |
ForEach-Object {
    $ myname = $ _. имя
    $ _. строки |
    для каждого {
        
        $ object = Новый объект psobject
        $ объект | добавление участника примечание имя свойства $ myname
        $ объект | добавить-член noteproperty txtstring $ _
        if ($ _ -notlike "v = spf *")
        {
            $ объект
        }
    }
} | Имя объекта сортировки

# Сохранить результаты в CSV
$ Результаты | Export-CSV -NoTypeInformation dnstxt-records.csv

# Возвращаем результаты в консоль
$ Results

Быстрый и грязный анализ записей
Ниже представлен процесс высокого уровня, который я использовал после сбора информации:
  1. Удалены оставшиеся записи SPF
  2. Разобранные пары ключ-значение
  3. Сортированные и сгруппированные похожие ключи
  4. Определены поставщики услуг с помощью Google dorking и анализа документации
  5. Удалены совершенно уникальные ключи, которые нельзя было легко отнести к конкретному поставщику услуг.
  6. Поставщики услуг отнесены к категории
  7. Определены наиболее часто используемые категории поставщиков услуг на основе количества токенов проверки домена
  8. Определены наиболее часто используемые поставщики услуг на основе количества токенов проверки домена

Топ 5 категорий поставщиков услуг

После краткого анализа записей TXT DNS примерно для 1 миллиона доменов я составил список наиболее распространенных категорий онлайн-сервисов и поставщиков, которым требуется проверка домена.

Ниже приведены 5 лучших категорий:

МЕСТО КАТЕГОРИЯ
1 Поставщики облачных услуг с полным набором онлайн-сервисов, таких как Google, Microsoft, Facebook и Amazon, по-видимому, доминировали в верхней части списка.
2 Центры сертификации , такие как globalsign, были на втором месте.
3 Electronic Document Signing как Adobe sign и Docusign держатся на третьем месте.
4 Решения для совместной работы , такие как Webex, Citrix и Atlassian, в совокупности занимают четвертое место.
5 Маркетинг по электронной почте и аналитика веб-сайтов провайдеров, таких как Pardot и Salesforce, похоже, также доминировали в рейтингах, что неудивительно.


Существует множество других типов сервисов, от сервисов кэширования, таких как Cloudflare, до сервисов безопасности, таких как «Have I Been Pwned», но вышеперечисленные категории кажутся наиболее распространенными.Также стоит отметить, что я удалил записи SPF, потому что технически токенов проверки домена нет. Однако записи SPF — еще один богатый источник информации, который потенциально может привести к возможности спуфинга электронной почты, если ими не управлять. В любом случае, они выходили за рамки этого блога.

25 лучших поставщиков услуг

Ниже приведены 25 крупнейших поставщиков услуг, которых мне удалось отследить на основе их токенов проверки домена (записи TXT). Однако в общей сложности мне удалось указать авторство около 130.

СЧЕТ ПОСТАВЩИК КАТЕГОРИЯ ПРИМЕР ЖЕТОНА
149785 gmail.com Облачные службы google-site-verify = ZZYRwyiI6QKg0jVwmdIha68vuiZlNtfAJ90msPo1i7E
70797 Майкрософт Офис 365 Облачные службы мс = хэш
16028 facebook.com Облачные службы facebook-domain-verify = zyzferd0kpm04en8wn4jnu4ooen5ct
11486 globalsign. com Центр сертификации _globalsign-domain-verify = Zv6aPQO0CFgBxwOk23uUOkmdLjhc9qmcz-UnQcgXkA
5097 Корпоративные службы Adobe Электронная подпись, облачные службы adobe-idp-site-verify = ffe3ccbe-f64a-44c5-80d7-b010605a3bc4
4093 Простая электронная почта Amazon Облачные службы амазонок: ZW5WU + BVqrNaP9NU2 + qhUvKLdAYOkxWRuTJDksWHJi4 =
3605 globalsign.com Центр сертификации globalsign-domain-verify = zPlXAjrsmovNlSOCXQ7Wn0HgmO – GxX7laTgCizBTW
3486 atlassian services Сотрудничество atlassian-domain-verify = Z8oUd5brL6 / RGUMCkxs4U0P / RyhpiNJEIVx9HXJLr3uqEQ1eDmTnj1eq1ObCgY1i
2700 mailru- Облачные службы mailru-проверка: fa868a61bb236ae5
2698 яндекс.com Облачные службы яндекс-проверка = fb9a7e8303137b4c
2429 Пардо (Salesforce) Маркетинг и аналитика pardot_104652 _ * = b9b92faaea08bdf6d7d89da132ba50aaff6a4b055647ce7fdccaf95833d12c17
2098 docusign.com Электронная подпись docusign = ff4d259b-5b2b-4dc7-84e5-34dc2c13e83e
1468 webex Сотрудничество webexdomainverification.P7KF = bf9d7a4f-41e4-4fa3-9ccb-d26f307e6be4
1358 www.sendinblue.com Маркетинг и аналитика Sendinblue-код: faab5d512036749b0f69d906db2a7824
1005 zoho.com Эл. Почта zoho-verify = zb [порядковый номер] .zmverify.zoho. [Com | in]
690 dropbox.com Сотрудничество dropbox-domain-verify = zsp1beovavgv
675 webex. com Сотрудничество ciscocidomainverification = f1d51662d07e32cdf508fe2103f9060ac5ba2f9efeaa79274003d12d0a9a745
607 Spiceworks.com Безопасность проверка домена на рабочем месте = BEJd6oynFk3ED6u0W4uAGMguAVnPKY
590 haveibeenpwned.com Безопасность have-i-be-pwned-verify = faf85761f15dc53feff4e2f71ca32510
577 citrix.com Сотрудничество citrix-verify-code = ed1a7948-6f0d-4830-9014-d22f188c3bab
441 brave.com Сотрудничество храбрая книга-проверка = fb42f0147b2264aa781f664eef7d51a1be9196011a205a2ce100dc76ab9de39f
427 Adobe Sign / Document Cloud Электронная подпись Adobe-Sign-Verification = fe9cdca76cd809222e1acae2866ae896
384 Firebase (Google) Разработка и публикация firebase = солнечный добродетель-511
384 O365 Облачные службы mscid = veniWolTd6miqdmIAwHTER4ZDHPBmT0mDwordEu6ABR7Dy2SH8TjniQ7e2O + Bv5 + svcY7vJ + ZdSYG9aCOu8GYQ ==
381 погрузчик.io Безопасность loaderio = fefa7eab8eb4a9235df87456251d8a48

Автоматизация снятия отпечатков токена проверки домена

Чтобы немного упростить процесс, я написал функцию PowerShell под названием «Resolve-DnsDomainValidationToken». Вы можете просто предоставить ему домены, и он будет сканировать связанные записи DNS TXT на предмет известных поставщиков услуг на основе созданной мной библиотеки токенов проверки домена. В настоящее время он поддерживает параметры для одного домена, списка доменов или списка URL-адресов.

Resolve-DnsDomainValidationToken можно скачать ЗДЕСЬ.

Пример команды

Чтобы дать вам представление о том, как выглядят команды и выходные данные, я привел пример ниже. Целевой домен был выбран случайным образом из списка Alexa 1 Million. 

 # Загрузить Resolve-DnsDomainValidationToken в сеанс PowerShell
IEX (New-Object System.Net.WebClient) .DownloadString ("https://raw.githubusercontent.com/NetSPI/PowerShell/master/Resolve-DnsDomainValidationToken.ps1 ")

# Запускаем Resolve-DnsDomainValidationToken для сбора и отпечатка записей TXT
$ Results = Resolve-DnsDomainValidationToken -Verbose -Domain adroll.com

# Просмотр записей в консоли
$ Результаты

Для тех из вас, кто не любит играть в консоли, результаты также можно просмотреть с помощью Out-GridView. 

 # Просмотр записи вне сетки
$ Результаты | Out-GridView

Наконец, команда также автоматически создает два файла csv, которые содержат результаты:

  1. Dns_Txt_Records.csv содержит все найденные записи TXT.
  2. Dns_Txt_Records_Domain_Validation_Tokens.csv содержит те записи TXT, которые могут быть отпечатаны.

Как можно использовать жетоны проверки домена для зла?

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

Сценарии использования тестеров проникновения

    1. Службы, поддерживающие федеративную аутентификацию без MFA
      Это наш наиболее распространенный вариант использования.Изучив токены проверки домена, мы смогли определить поставщиков услуг, которые поддерживают федеративную аутентификацию, связанную с развертыванием Active Directory в компании. Во многих случаях они не настроены для многофакторной аутентификации (MFA). Типичные примеры включают Office 365, AWS, G Suite и Github.

      Pro Tip: После аутентификации в Azure вы можете быстро найти дополнительных целевых поставщиков услуг, которые поддерживают федеративную / управляемую аутентификацию, путем синтаксического анализа имен участников службы. Это можно сделать с помощью сценария Карла Get-AzureDomainInfo.ps1.

    2. Цели перехвата поддоменов
      Жетоны проверки домена могут выявить службы, поддерживающие поддомен, которые могут быть атакованы после того, как записи CNAME устареют. Для получения информации об общих техниках Патрик Худак написал здесь хороший обзор.
    3. Топливо для социальной инженерии
      Лучшее понимание технологий и поставщиков услуг, используемых организацией, может быть полезным при создании фишинговых кампаний по телефону и электронной почте.
    4. Общее измерение зрелости
      При просмотре токенов проверки домена для всех доменов, принадлежащих организации, можно получить общее представление об их уровне зрелости, и вы можете начать отвечать на некоторые основные вопросы, например:
      • Используют ли они сети распространения контента (CDN) для распространения и защиты контента своих веб-сайтов?
      • Используют ли они 3 rd сторонний маркетинг и аналитику? Если да, то кто? Как они настроены?
      • Обращаются ли они к поставщикам услуг, связанных с безопасностью? Какое покрытие они обеспечивают?
      • Кого они используют для выдачи сертификатов SSL / TLS? Как они используются?
      • Какие службы защиты почты они используют? Что это за конфигурации по умолчанию?
    5. Анализ маркеров проверки домена для конкретного поставщика онлайн-услуг может дать дополнительные сведения.Например,
      • Многие токены проверки домена представляют собой уникальные числовые значения, которые просто увеличиваются для каждого нового клиента. Анализируя значения по тысячам доменов, вы можете начать делать выводы, например, о том, как долго конкретный клиент использует поставщика услуг.
      • Некоторые из токенов проверки также включают хеши и зашифрованные значения base64, которые потенциально могут быть взломаны в автономном режиме для раскрытия информации.
    6. Реальные злоумышленники также могут попытаться напрямую скомпрометировать поставщиков услуг, а затем перейти на сайт / хранилище данных конкретной компании и т. Д.Типичный пример — провайдеры виртуального хостинга. Тестировщики на проникновение и красные команды не могут воспользоваться преимуществами этих типов сценариев, но если вы поставщик услуг, вы должны усердно применять изоляцию клиентов, чтобы избежать раскрытия этих векторов для злоумышленников.

Заключение

Анализ токенов проверки домена, обнаруженных в записях DNS TXT, — далеко не новая концепция, но я надеюсь, что библиотека отпечатков пальцев, запеченная в Resolve-DnsDomainValidationToken, поможет сэкономить время во время следующей красной команды, пентеста или внутреннего аудита.Удачи и взломайте ответственно!

Создание и добавление записи SPF TXT в свой DNS

В этой статье мы объясняем:

  • Что такое запись SPF
  • Как добавить запись SPF
  • Как создать запись SPF

У вас уже есть запись SPF, но вы не уверены, правильно ли она настроена? Воспользуйтесь нашим бесплатным SPF Surveyor, чтобы выполнить проверку SPF.

Запись SPF или Запись SPF TXT — это запись, которая является частью DNS вашего домена — аналогично записи DMARC.Он содержит список всех IP-адресов, которым разрешено отправлять электронную почту от имени вашего домена.

Когда отправитель пытается передать электронную почту на «принимающий» сервер для доставки, почтовый сервер проверяет, находится ли отправитель в списке разрешенных отправителей вашего домена. Если это так, значит, была установлена ​​связь между этим письмом и доменом электронной почты.

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

Чтобы добавить запись SPF, вам потребуется доступ к панели управления DNS для вашего домена. Если вы пользуетесь услугами хостинг-провайдера, процесс довольно прост, и вам следует обратиться к его сопроводительной документации. Если вы не уверены, вы можете обратиться за поддержкой к своему ИТ-провайдеру.

Примечание. Для вступления в силу новой записи SPF может потребоваться до 48 часов.

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

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

  • Начните с версии SPF v = spf1 . Это означает, что это запись SPF. Всегда будет v = spf1, поскольку другие версии SPF больше не выпускаются.
  • После тега версии SPF должны быть указаны все IP-адреса, которым разрешено отправлять электронную почту от имени вашего домена.
    Например: v = spf1 ip4: 40.113.200.201 ip6: 2001: db8: 85a3: 8d3: 1319: 8a2e: 370: 7348
  • Затем следует заявление «include», которое необходимо каждой сторонней организации, отправляющей электронную почту от вашего имени.
    Например: v = spf1 ip4: 40.113.200.201 ip6: 2001: db8: 85a3: 8d3: 1319: 8a2e: 370: 7348 include: thirdpartydomain.com
    Вы должны проконсультироваться с этими третьими сторонами, чтобы узнать, какой домен использовать как значение здесь. Кроме того, ESP обычно публикуют записи SPF для отправки доменов от вашего имени, поэтому вы также захотите проверить их у них.
  • Конец записи SPF — это тег «все». Это важно, потому что в нем указывается, какая политика и насколько строго ее следует применять, когда принимающий сервер обнаруживает сервер, который не указан (авторизован) в вашей записи SPF.
    Тег «all» имеет следующие основные параметры:
    -all — (сбой) неавторизованные сообщения электронной почты будут отклонены *.
    ~ все — (softfail) неавторизованные электронные письма будут приниматься, но отмечены *.
    + все — этот тег позволяет любому серверу отправлять электронную почту из вашего домена, поэтому мы настоятельно не рекомендуем этого делать.
    * Более подробную информацию о различиях между ошибкой и программной ошибкой можно найти здесь.
    Например: v = spf1 ip4: 40.113.200.201 ip6: 2001: db8: 85a3: 8d3: 1319: 8a2e: 370: 7348 include: thirdpartydomain.com ~ все .

Это базовый обзор того, что может содержать запись SPF. Здесь вы можете найти более подробный синтаксис SPF.

Для ваших доменов, которые не отправляют электронную почту (неактивные или припаркованные домены), рекомендуется опубликовать политику SPF, которая не включает никаких IP-адресов, чтобы предотвратить злоупотребление ею. Вот пример записи для не отправляющего домена: v = spf1 -all

Примечание. Записи SPF не могут содержать более 255 символов, а не может включать более десяти операторов включения , также известных как «поиск».”

Чтобы проверить и проверить свои записи SPF, зайдите в наш бесплатный опрос SPF. Если вы еще этого не сделали, вы можете подписаться на бесплатную пробную версию здесь и позволить нам помочь вам защитить ваши почтовые домены.

SPF расшифровывается как Sender Policy Framework и представляет собой бесплатную технологию аутентификации электронной почты, которая существует с 2003 года. Это способ проверки того, что почтовый сервер (IP-адрес) авторизован для отправки электронной почты для определенного домена; Наряду с DKIM, SPF является основой DMARC.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *