Глобальный поиск TXT-записей
Изначально созданная в 1980-х годах как простая песочница для системных администраторов, позволяющая оставлять читаемые человеком заметки внутри файла зоны, запись TXT (Text) превратилась в один из самых структурно важных компонентов современной сетевой безопасности. Поскольку протокол DNS практически не применяет валидацию синтаксиса к TXT Payload-ам, разработчики и платформы безопасности используют эти записи для хранения произвольных машиночитаемых строк данных. Сегодня записи TXT в основном используются для строгих фреймворков аутентификации электронной почты, распространения криптографических ключей и автоматической проверки владения доменом.
Триада аутентификации Email: SPF, DKIM и DMARC
Если исходящие письма из вашего веб-приложения или корпоративного сервера отправляются прямо в папки со спамом, почти всегда виноваты неправильно настроенные записи TXT. Современные принимающие MTA (такие как Microsoft 365 или Gmail) требуют криптографического подтверждения личности через три конкретные политики TXT:
- SPF (Sender Policy Framework): Строго отформатированная строка TXT (например,
v=spf1 include:_spf.google.com ~all), действующая как публичный белый список (whitelist). Она разрешает определенным IP-блокам и сторонним сервисам отправки (таким как Mailgun или SendGrid) отправлять почту от имени домена. - DKIM (DomainKeys Identified Mail): TXT-запись, содержащая массивный открытый криптографический ключ, закодированный в Base64. Ваш исходящий почтовый сервер хэширует заголовки писем и подписывает их закрытым ключом. Принимающий сервер получает открытый ключ из этой записи TXT для математической проверки подписи, гарантируя, что Payload не был изменен при передаче.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): Уровень принудительного применения (Enforcement layer). Эта запись TXT инструктирует принимающие серверы, как обрабатывать сообщения, которые не прошли проверку SPF или DKIM, предписывая, применять ли политику
p=none(мониторинг),p=quarantine(отправка в спам) илиp=reject(полное отклонение).
Автоматическое владение доменом и Zero-Trust
Помимо электронной почты, записи TXT являются универсальным стандартом для подтверждения административного контроля над доменным именем. При интеграции домена с облачным провайдером (таким как Google Search Console, GitHub Pages или AWS SES) платформа генерирует случайный криптографический хеш. Требуя от администратора опубликовать этот хеш в виде записи TXT, провайдер с помощью автоматического запроса DNS подтверждает, что пользователь имеет root-доступ к инфраструктуре маршрутизации домена. Аналогично, протокол ACME, используемый Let's Encrypt, в значительной степени опирается на челлендж DNS-01, где развертывается временная запись TXT для авторизации выпуска wildcard SSL/TLS-сертификатов.
Лимиты байт и конкатенация строк
Техническое ограничение, с которым часто сталкиваются разработчики, — это лимит строки в 255 символов на один чанк (chunk) TXT в спецификации DNS. При публикации массивных Payload, таких как 2048-битные ключи RSA для DKIM, Payload превышает этот лимит в байтах. Для решения этой проблемы стандартное программное обеспечение DNS (например, BIND) автоматически разбивает длинную запись на несколько заключенных в кавычки строк (например, "строка1" "строка2"). Клиентский резолвер несет ответственность за бесшовную конкатенацию этих чанков обратно в процессе чтения.