Перейти к содержимому
davidka.net > 💻 🧠 Код 1001 > 📑 Шпаргалки > 🖧 Полный, исчерпывающий гид по DNS-записям: от основ до DNSSEC и автоматизации.

🖧 Полный, исчерпывающий гид по DNS-записям: от основ до DNSSEC и автоматизации.

DNS (Domain Name System) — это фундаментальная система, на которой держится весь современный интернет. Это не просто «телефонная книга», а сложная, распределенная база данных, которая переводит человекочитаемые имена (например, google.com) в технические идентификаторы, такие как IP-адреса, почтовые сервера, политики безопасности и даже географические координаты. Неправильная настройка DNS — одна из самых частых причин недоступности сайтов, проблем с доставкой почты и уязвимостей безопасности.

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

In Questo Articolo
  1. 1. Терминология
  2. 2. Подробный разбор всех типов записей
  3. 3. Практические рекомендации и тонкости настройки
  4. 4. Полные шаблоны зонных файлов (BIND style)
  5. 5. Пошаговая настройка почтового домена (PTR, SPF, DKIM, DMARC)
  6. 6. Команды для проверки и отладки DNS
  7. 7. Безопасность и best practices
  8. 8. Частые ошибки и как их избежать
  9. 9. Чек-лист перед продакшн-релизом или миграцией
  10. 10. Дополнительные примеры и пояснения полей
  11. 11. Полезные сценарии
  12. 12. Готовый JSON для импорта в панель провайдера

1. Терминология

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

  • DNS (Domain Name System): Система доменных имен. Глобальная распределенная база данных, преобразующая доменные имена в IP-адреса и другую связанную информацию.
  • Доменное имя (Domain Name): Человекочитаемый адрес в интернете, например, example.com. Состоит из меток, разделенных точками.
  • FQDN (Fully Qualified Domain Name): Полное доменное имя, однозначно определяющее узел в иерархии DNS. Всегда заканчивается точкой, обозначающей корень DNS (например, www.example.com.).
  • Зона (Zone): Административная единица в DNS. Часть пространства имен, которой управляет один авторитетный сервер (или группа серверов). Обычно соответствует домену или поддомену.
  • Зонный файл (Zone File): Текстовый файл, хранящийся на DNS-сервере, который содержит все записи для конкретной зоны. Использует синтаксис, определенный в стандарте BIND.
  • Запись (Record / Resource Record, RR): Основная единица данных в DNS. Каждая запись имеет тип, имя, значение и TTL.
  • Тип записи (Record Type): Определяет, какую информацию содержит запись (например, A, MX, TXT). Каждому типу соответствует уникальный числовой код (например, 1 для A, 15 для MX).
  • TTL (Time To Live): Время жизни записи. Указывается в секундах. Определяет, как долго резолверы и другие DNS-серверы могут кешировать запись перед тем, как запросить ее снова у авторитетного сервера.
  • Резолвер (Resolver): DNS-клиент или сервер, который получает запрос от приложения (например, браузера) и выполняет необходимые запросы для получения ответа. Может быть рекурсивным (выполняет полную цепочку запросов) или нерекурсивным.
  • Авторитетный сервер (Authoritative Server): DNS-сервер, который хранит оригинальные записи для определенной зоны и отвечает за них. Отвечает на запросы, используя данные из зонного файла.
  • Рекурсивный сервер (Recursive Server): Сервер, который получает запрос от клиента и, если у него нет ответа в кеше, выполняет цепочку запросов, начиная с корневых серверов, чтобы найти авторитетный сервер и получить ответ.
  • Корневой сервер (Root Server): Один из 13 групп серверов (обозначаемых буквами от a.root-servers.net. до m.root-servers.net.), которые являются отправной точкой для разрешения любого доменного имени. Они знают, где находятся серверы для доменов верхнего уровня (TLD).
  • TLD (Top-Level Domain): Домен верхнего уровня. Последняя часть доменного имени (например, .com, .org, .ru, .io).
  • Регистратор (Registrar): Компания, через которую регистрируются доменные имена. Управляет информацией о делегировании (какие NS-серверы обслуживают домен) в родительской зоне (например, в зоне .com для домена example.com).
  • Регистрант (Registrant): Владелец доменного имени.
  • Делегирование (Delegation): Процесс передачи управления поддоменом (или доменом) от родительской зоны дочерней. Осуществляется с помощью NS-записей в родительской зоне.
  • Glue Record (Клеевая запись): A или AAAA запись, которая публикуется у регистратора для сервера имен, чье доменное имя находится внутри делегируемой зоны. Необходима для разрыва циклической зависимости.
  • SOA (Start of Authority): Запись, содержащая административную информацию о зоне, включая основной сервер, контакт администратора и параметры, управляющие передачей зоны вторичным серверам.
  • Серийный номер (Serial Number): Поле в записи SOA, которое указывает версию зоны. Вторичные серверы используют его для определения необходимости обновления.
  • Прямое разрешение (Forward Resolution): Процесс преобразования доменного имени в IP-адрес (например, example.com → 192.0.2.1).
  • Обратное разрешение (Reverse Resolution): Процесс преобразования IP-адреса в доменное имя (например, 192.0.2.1 → example.com). Управляется через зоны in-addr.arpa (для IPv4) и ip6.arpa (для IPv6).
  • Кеш (Cache): Временное хранилище DNS-записей на резолвере или DNS-сервере для ускорения последующих запросов.
  • Кеширование (Caching): Процесс сохранения DNS-записей в кеше.
  • Отрицательное кеширование (Negative Caching): Кеширование информации о том, что запрашиваемая запись не существует.
  • RFC (Request for Comments): Официальный документ, описывающий стандарты, протоколы и процедуры в интернете. Все основные аспекты DNS описаны в серии RFC.
  • BIND (Berkeley Internet Name Domain): Самая распространенная реализация DNS-сервера. Синтаксис его зонных файлов стал де-факто стандартом.
  • MTA (Mail Transfer Agent): Почтовый сервер, отвечающий за передачу электронной почты (например, Postfix, Exim, Sendmail).
  • FCrDNS (Forward-Confirmed Reverse DNS): Механизм проверки, при котором IP-адрес имеет PTR-запись, которая разрешается в доменное имя, а это доменное имя, в свою очередь, имеет A-запись, ведущую обратно к исходному IP-адресу. Критически важен для репутации почтовых серверов.
  • DNSSEC (Domain Name System Security Extensions): Набор расширений, добавляющих криптографическую подпись к DNS-записям для обеспечения их подлинности и целостности.
  • DANE (DNS-based Authentication of Named Entities): Стандарт, позволяющий привязывать TLS-сертификаты к DNS-именам с помощью записей TLSA. Требует включения DNSSEC.
  • CAA (Certification Authority Authorization): Механизм, позволяющий владельцу домена указать, какие центры сертификации (CA) имеют право выпускать для него сертификаты.
  • SPF (Sender Policy Framework): Механизм, позволяющий владельцу домена указать, какие серверы имеют право отправлять почту от его имени.
  • DKIM (DomainKeys Identified Mail): Механизм, позволяющий подписывать исходящие письма цифровой подписью, которую получатель может проверить с помощью публичного ключа, опубликованного в DNS.
  • DMARC (Domain-based Message Authentication, Reporting & Conformance): Политика, определяющая, как почтовые серверы должны обрабатывать письма, не прошедшие проверки SPF или DKIM, и настраивающая отправку отчетов владельцу домена.
  • ALIAS / ANAME: Нестандартные типы записей, предлагаемые некоторыми DNS-провайдерами. Позволяют создавать псевдонимы для корневого домена (apex), что невозможно с помощью стандартного CNAME.
  • CNAME Flattening: Технология, используемая некоторыми DNS-провайдерами. При запросе CNAME на apex-домене сервер автоматически разрешает цепочку CNAME и возвращает конечные A/AAAA записи клиенту, избегая нарушения RFC.

2. Подробный разбор всех типов записей

Все примеры приведены в формате BIND-style zone-file. Имена, заканчивающиеся точкой (например, example.com.), являются FQDN (Fully Qualified Domain Name). TTL (Time To Live) указывается в секундах и определяет, как долго запись может кешироваться резолверами.

A — Address Record (IPv4)

  • Назначение: Связывает доменное имя с 32-битным IPv4-адресом. Самая базовая и часто используемая запись.
  • Формат: имя TTL IN A IPv4-адрес
  • Пример:
    example.com. 3600 IN A 192.0.2.1 www.example.com. 3600 IN A 192.0.2.1
  • Когда используется: Для указания IP-адреса веб-сервера, API, игрового сервера или любого другого сервиса, доступного по IPv4.
  • Проверка: dig +short example.com A
  • Лучшие практики:
    • Для корневого домена (apex, @) использование A-записи — стандартная и корректная практика.
    • TTL следует выбирать в зависимости от стабильности IP-адреса. Для стабильных адресов — 3600 (1 час) или 86400 (1 день). Перед миграцией — уменьшить до 300 (5 минут).

AAAA — IPv6 Address Record

  • Назначение: Аналог A-записи, но для 128-битных IPv6-адресов. Критически важен для будущего интернета.
  • Формат: имя TTL IN AAAA IPv6-адрес
  • Пример:
    example.com. 3600 IN AAAA 2001:db8::1
  • Когда используется: Для обеспечения доступности сервиса по протоколу IPv6.
  • Проверка: dig +short example.com AAAA

CNAME — Canonical Name Record

  • Назначение: Создает псевдоним (алиас) для доменного имени. Любой запрос к CNAME автоматически преобразуется в запрос к его целевому (каноническому) имени.
  • Формат: имя TTL IN CNAME цель.
  • Пример:
    www.example.com. 3600 IN CNAME example.com. blog.example.com. 3600 IN CNAME blog-hosting.example.net.
  • Важные ограничения:
    • Конфликт записей: Для одного и того же имени нельзя одновременно иметь CNAME и любую другую запись (A, MX, TXT и т.д.). Это нарушение RFC.
    • Apex-домен: Стандарт RFC запрещает использование CNAME для корневого домена (например, example.com.), так как он уже содержит NS и SOA записи. Для решения этой проблемы DNS-провайдеры (Cloudflare, AWS Route 53) предлагают нестандартные расширения: ALIAS или ANAME, которые на лету разрешают алиас в A/AAAA записи.
  • Практическое применение: Подключение CDN (делаем www CNAME на адрес CDN), использование SaaS-платформ (блог, магазин).
  • Проверка: dig +short www.example.com CNAME

MX — Mail Exchange Record

  • Назначение: Указывает серверы, которые принимают входящую почту для домена. Запись содержит приоритет: чем меньше число, тем выше приоритет.
  • Формат: имя TTL IN MX приоритет почтовый_сервер.
  • Пример:example.com. 3600 IN MX 10 mail1.example.com. example.com. 3600 IN MX 20 mail2.example.com.
    • Почта будет сначала отправляться на mail1.example.com.. Если он недоступен, MTA (Mail Transfer Agent) попробует mail2.example.com..
  • Ключевые требования:
    • Почтовый сервер (mail1.example.com.) должен иметь свою A или AAAA запись.
    • Для IP-адреса почтового сервера обязательно должна быть настроена PTR-запись, и она должна соответствовать имени сервера, указанному в MX. Это критически важно для репутации сервера и доставки почты.
  • Проверка: dig +short example.com MX

TXT — Text Record

  • Назначение: Хранит произвольные текстовые данные. Широко используется для политик безопасности электронной почты (SPF, DKIM, DMARC), верификации владения доменом (Google, Microsoft, Yandex) и других целей.
  • Формат: имя TTL IN TXT "текст"
  • Примеры:
    • SPF (Sender Policy Framework): Определяет, какие серверы имеют право отправлять почту от имени домена. example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all"
      • ip4:192.0.2.0/24 — разрешает всю подсеть.
      • include:_spf.google.com — включает правила из зоны Google (для Gmail).
      • ~all — «мягкий» отказ для всех остальных (softfail). -all — строгий отказ (fail).
    • DKIM (DomainKeys Identified Mail): Публикует открытый ключ для проверки цифровой подписи, добавленной к исходящим письмам. Обычно создается для поддомена вида селектор._domainkey.домен. default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."
      • v=DKIM1 — версия.
      • k=rsa — тип ключа.
      • p=... — сам открытый ключ в формате base64.
    • DMARC (Domain-based Message Authentication, Reporting & Conformance): Задает политику обработки писем, не прошедших проверки SPF или DKIM, и настраивает отправку отчетов. _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"
      • p=reject — отклонять письма, не прошедшие проверку.
      • rua=mailto:... — адрес для агрегированных отчетов.
      • ruf=mailto:... — адрес для отчетов о конкретных сбоях (forensic).
      • pct=100 — применять политику ко 100% писем.
    • Верификация: example.com. 3600 IN TXT "google-site-verification=abc123..."
  • Заметки:
    • Если текстовая строка длиннее 255 байт, ее можно разбить на несколько частей в зонном файле, заключив каждую в кавычки. DNS-сервер автоматически их склеит.
      example.com. IN TXT ("v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; " "pct=100; fo=1")
  • Проверка: dig +short example.com TXT

NS — Name Server Record

  • Назначение: Указывает DNS-серверы, которые являются авторитетными для данной зоны. Эти записи — основа для делегирования управления доменом.
  • Формат: имя TTL IN NS сервер_имен.
  • Пример:
    example.com. 3600 IN NS ns1.example.net. example.com. 3600 IN NS ns2.example.net.
  • Важные моменты:
    • Записи NS в зоне должны точно совпадать с серверами имен, указанными у регистратора домена.
    • Glue Records: Если сервер имен (например, ns1.example.com.) находится внутри той же зоны, которую он обслуживает (example.com.), возникает циклическая зависимость. Чтобы ее разорвать, у регистратора необходимо добавить «клеевые» (glue) записи — A или AAAA записи для этих серверов имен.
  • Проверка: dig +short example.com NS

SOA — Start of Authority Record

  • Назначение: Главная служебная запись DNS-зоны. Содержит информацию об основном сервере, администраторе, а также параметры, управляющие синхронизацией между основным и вторичными серверами.
  • Формат:
    имя TTL IN SOA первичный_сервер. email_администратора. ( серийный_номер ; Serial интервал_обновления ; Refresh интервал_повтора ; Retry срок_годности ; Expire мин_TTL ) ; Minimum TTL
  • Пример:
    example.com. 3600 IN SOA ns1.example.net. admin.example.com. ( 2025092201 ; Serial (YYYYMMDDNN) 7200 ; Refresh (2 часа) 3600 ; Retry (1 час) 1209600 ; Expire (14 дней) 86400 ) ; Minimum TTL (1 день)
  • Пояснения полей:
    • Serial: Версия зоны. Крайне важно увеличивать это число при каждом изменении зоны. Вторичные серверы сравнивают свой Serial с Serial на первичном сервере и, если он меньше, запрашивают обновление. Рекомендуемый формат: YYYYMMDDNN (год, месяц, день, номер редакции за день).
    • Refresh: Интервал (в секундах), через который вторичные серверы должны проверять первичный сервер на наличие обновлений.
    • Retry: Интервал, через который вторичный сервер должен повторить попытку, если первая попытка обновления не удалась.
    • Expire: Время (в секундах), после которого вторичный сервер перестанет отвечать на запросы, если не сможет связаться с первичным сервером. Зона считается «устаревшей».
    • Minimum TTL: Изначально задавал минимальный TTL для всех записей в зоне. Сейчас чаще используется как TTL для негативного кеширования (как долго кешировать ответ «запись не найдена»).
  • Проверка: dig +short example.com SOA

PTR — Pointer Record (Reverse DNS)

  • Назначение: Обеспечивает обратное разрешение — преобразует IP-адрес в доменное имя. Управляется владельцем IP-адреса (ISP, хостинг-провайдер), а не владельцем домена.
  • Формат для IPv4: IP-адрес записывается в обратном порядке, и к нему добавляется суффикс .in-addr.arpa..
    • IP 192.0.2.5 → 5.2.0.192.in-addr.arpa.
  • Формат для IPv6: Каждая 4-битная часть (nibble) адреса записывается в обратном порядке, и добавляется суффикс .ip6.arpa..
    • IPv6 2001:db8::1 → 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
  • Пример (IPv4):
    5.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.
  • Практическое значение: Критически важно для почтовых серверов. Большинство почтовых систем проверяют, чтобы PTR-запись IP-адреса отправителя совпадала с именем, которое сервер представляет в команде HELO/EHLO. Несоответствие — частая причина попадания писем в спам.
  • Проверка: dig -x 192.0.2.5 +short или host 192.0.2.5

SRV — Service Record

  • Назначение: Указывает расположение серверов для конкретных сервисов, включая протокол и порт. Позволяет клиентам автоматически находить нужный сервер.
  • Формат имени:_сервис._протокол.домен.
    • Сервис: sip, xmpp-server, _minecraft и т.д.
    • Протокол: tcp, udp.
  • Формат записи: имя TTL IN SRV приоритет вес порт цель.
  • Пример:
    _sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com. _minecraft._tcp.example.com. 3600 IN SRV 5 0 25565 mc1.example.com.
  • Пояснения полей:
    • Priority (Приоритет): Чем меньше число, тем выше приоритет. Клиент сначала попытается подключиться к серверу с наименьшим приоритетом.
    • Weight (Вес): Используется для балансировки нагрузки между серверами с одинаковым приоритетом. Вероятность выбора сервера пропорциональна его весу. Если все веса одинаковы, выбор происходит случайно.
    • Port (Порт): Порт, на котором работает сервис.
    • Target (Цель): FQDN сервера, на который следует направить запрос. Этот сервер должен иметь A или AAAA запись.
  • Применение: VoIP (SIP), мгновенные сообщения (XMPP), игры (Minecraft), каталоги (LDAP).
  • Проверка: dig +short _sip._tcp.example.com SRV

CAA — Certification Authority Authorization

  • Назначение: Позволяет владельцу домена указать, какие центры сертификации (CA) имеют право выпускать SSL/TLS-сертификаты для этого домена. Это важный механизм безопасности, предотвращающий несанкционированный выпуск сертификатов.
  • Формат: имя TTL IN CAA флаги тег значение
  • Пример:
    example.com. 3600 IN CAA 0 issue "letsencrypt.org" example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
  • Пояснения:
    • Флаги: Обычно 0. Флаг 128 (critical) означает, что CA, не понимающий этот тег, должен отказаться от выпуска сертификата.
    • Теги:
      • issue: Разрешает указанному CA выпускать сертификаты. Пустое значение (;) запрещает выпуск всем.
      • issuewild: Разрешает выпуск wildcard-сертификатов (*.example.com).
      • iodef: URL (обычно mailto: или http(s):) для отправки отчетов о попытках нарушения политики CAA.
  • Проверка: dig +short example.com CAA

NAPTR — Naming Authority Pointer Record

  • Назначение: Используется для сложных правил переписывания (rewriting) имен и URI. Чаще всего применяется в телекоммуникационных системах (ENUM для преобразования телефонных номеров в SIP URI) и для динамического обнаружения сервисов.
  • Формат: имя TTL IN NAPTR порядок предпочтение флаги сервис регулярное_выражение замена.
  • Пример (упрощенный для ENUM):
    4.3.2.1.5.5.5.1.e164.arpa. IN NAPTR 100 10 "U" "E2U+sip" "!^.*$!sip:info@example.com!" .
  • Пояснения:
    • Order (Порядок): Обрабатывается от меньшего к большему.
    • Preference (Предпочтение): Аналог weight в SRV для записей с одинаковым order.
    • Flags: U означает, что результат — URI (например, sip:).
    • Service: Тип сервиса (например, E2U+sip — преобразование в SIP URI).
    • Regexp: Регулярное выражение для преобразования входной строки.
    • Replacement: Альтернатива регулярному выражению (обычно пустая, если используется regexp).
  • Применение: Сложные сценарии маршрутизации в VoIP, ENUM.

TLSA — TLSA Certificate Association Record (DANE)

  • Назначение: Привязывает TLS-сертификат (или его часть) к DNS-имени с помощью записи в DNS. Это часть стандарта DANE (DNS-based Authentication of Named Entities). Требует включения DNSSEC для обеспечения доверия, иначе запись можно подделать.
  • Формат имени: _порт._протокол.имя.
  • Формат записи: имя TTL IN TLSA использование селектор тип_сопоставления данные
  • Пример:
    _443._tcp.www.example.com. 3600 IN TLSA 3 1 1 d2abde...f21
  • Пояснения полей:
    • Usage (Использование):
      • 3 (DANE-EE): Сертификат конечной точки (end entity). Самый распространенный.
      • 1 (PKIX-EE): Сертификат конечной точки, должен быть подписан доверенным CA.
      • 2 (DANE-TA): Доверенный (trusted) сертификат удостоверяющего центра.
      • 0 (PKIX-TA): Сертификат CA, должен быть в цепочке доверия.
    • Selector (Селектор):
      • 0: Полный сертификат.
      • 1: Только открытый ключ сертификата.
    • Matching Type (Тип сопоставления):
      • 0: Точные данные (не используется).
      • 1: SHA-256 хеш.
      • 2: SHA-512 хеш.
    • Data: Хеш сертификата или его открытого ключа в hex-формате.
  • Применение: Повышение безопасности TLS, особенно в средах, где нельзя доверять публичным CA.
  • Проверка: dig +short _443._tcp.www.example.com. TLSA

Записи DNSSEC (DNSKEY, DS, RRSIG, NSEC, NSEC3)

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

  • Общий принцип: Зона подписывается приватным ключом. Публичный ключ публикуется в записи DNSKEY. Для создания цепочки доверия хеш этого ключа (DS-запись) публикуется в родительской зоне (например, для example.com — в зоне .com). Клиенты, поддерживающие DNSSEC, могут проверить подпись (RRSIG) каждой записи, используя открытый ключ, и убедиться в ее подлинности.
  • DNSKEY: Публичный ключ зоны.
    • Пример:example.com. 3600 IN DNSKEY 257 3 13 AwEAAa3d...9QAB
      • 257 — флаги (257 = KSK, 256 = ZSK).
      • 3 — протокол (всегда 3).
      • 13 — алгоритм (13 = ECDSA/SHA256).
      • Последнее поле — ключ в base64.
  • DS (Delegation Signer): Хеш открытого ключа (DNSKEY) дочерней зоны, который публикуется в родительской зоне для создания цепочки доверия.
    • Пример:example.com. 3600 IN DS 54517 13 2 84C8...D34F
      • 54517 — Key Tag (идентификатор ключа).
      • 13 — Алгоритм.
      • 2 — Тип дайджеста (SHA-256).
      • Последнее поле — хеш в hex.
  • RRSIG (Resource Record Signature): Цифровая подпись для набора DNS-записей.
    • Пример (подпись для A-записи):example.com. 3600 IN RRSIG A 13 2 3600 20251001000000 20250901000000 54517 example.com. oNvL...7Q==
      • A — тип записей, которые подписаны.
      • 13 — алгоритм.
      • 2 — количество меток в имени.
      • 3600 — оригинальный TTL.
      • 20251001000000 — время окончания действия подписи.
      • 20250901000000 — время начала действия подписи.
      • 54517 — Key Tag подписавшего ключа.
      • example.com. — имя подписавшего.
      • Последнее поле — подпись в base64.
  • NSEC / NSEC3: Используются для аутентификации отрицательных ответов (доказательство того, что записи с таким именем или типом не существует). NSEC3 дополнительно хеширует имена для защиты от «выгуливания зоны» (zone walking).
  • Включение DNSSEC: Это отдельный, сложный процесс:
    1. Генерация пар ключей (KSK и ZSK) на DNS-сервере.
    2. Публикация DNSKEY записей в зоне.
    3. Генерация DS-записи из KSK.
    4. Публикация DS-записи у регистратора домена (в родительской зоне).
    5. Включение подписывания зоны на DNS-сервере (автоматическая генерация RRSIG, NSEC/NSEC3).
    6. Тестирование с помощью dig +dnssec и онлайн-инструментов (например, Verisign DNSSEC Debugger).
  • Проверка:
    • dig +dnssec example.com A (покажет RRSIG для A-записи, если DNSSEC включен и работает).
    • dig +short example.com DNSKEY
    • dig +short example.com DS

SSHFP — SSH Public Key Fingerprint

  • Назначение: Публикует хеш (отпечаток) SSH-ключа хоста в DNS. Клиенты SSH могут использовать эту запись для автоматической проверки подлинности сервера при первом подключении, предотвращая атаки «человек посередине» (MITM). Рекомендуется использовать с DNSSEC для гарантии подлинности записи.
  • Формат: имя TTL IN SSHFP алгоритм тип_дайджеста отпечаток
  • Пример:
    example.com. 3600 IN SSHFP 4 2 356a192b7913b04c54574d18c28d46e6395428ab
  • Пояснения:
    • Алгоритм:
      • 1 — RSA
      • 2 — DSA
      • 3 — ECDSA
      • 4 — ED25519
    • Тип дайджеста:
      • 1 — SHA-1
      • 2 — SHA-256
    • Отпечаток: Хеш открытого ключа в hex-формате.
  • Генерация: На сервере можно сгенерировать запись командой: ssh-keygen -r example.com
  • Проверка: dig +short example.com SSHFP

Редкие и служебные записи

  • HINFO (Host Information): Хранит информацию о типе процессора и операционной системе хоста. Не рекомендуется к использованию, так как раскрывает потенциально чувствительную информацию о системе.
    • Пример: server1.example.com. 3600 IN HINFO "Intel Xeon" "Ubuntu 22.04"
  • LOC (Location): Хранит географические координаты (широта, долгота, высота) хоста.
    • Пример: example.com. 3600 IN LOC 55 45 21.000 N 37 37 03.000 E 15m
  • RP (Responsible Person): Указывает контактное лицо, ответственное за зону. Email указывается в формате hostname (точка вместо @).
    • Пример: example.com. 3600 IN RP admin.example.com. txt-record.example.com.
  • SPF (устаревшая): Раньше существовала как отдельный тип записи, но сейчас полностью заменена TXT. Не следует использовать.
    • Пример (не использовать): example.com. IN SPF "v=spf1 ..."

3. Практические рекомендации и тонкости настройки

  • Управление TTL:
    • Стандартное значение: 3600 секунд (1 час) — хороший баланс между производительностью (кеширование) и гибкостью.
    • Перед миграцией: За 24-72 часа до планируемого изменения (например, смены IP-адреса) уменьшите TTL для соответствующих записей до 300 секунд (5 минут). Это сократит время распространения изменений.
    • После миграции: Когда изменения стабилизируются, верните TTL к более высокому значению (например, 3600 или 86400) для уменьшения нагрузки на DNS-серверы.
  • SOA Serial:
    • Обязательно увеличивайте серийный номер при каждом изменении зоны. Если этого не сделать, вторичные серверы не узнают об обновлениях.
    • Рекомендуемый формат: YYYYMMDDNN (например, 2024051701). Это наглядно и позволяет легко отслеживать, когда было последнее изменение.
  • CNAME на Apex (корневом домене):
    • Проблема: Стандарт RFC запрещает CNAME на apex-домене (например, example.com.), потому что он конфликтует с другими обязательными записями (NS, SOA).
    • Решение: Используйте функции, предоставляемые вашим DNS-провайдером:
      • ALIAS/ANAME: Нестандартные типы записей, которые ведут себя как CNAME, но разрешаются на стороне DNS-сервера провайдера в A/AAAA записи для ответа клиенту. Это позволяет использовать алиасы на apex.
      • CNAME Flattening: Технология (например, в Cloudflare), при которой CNAME на apex автоматически «выравнивается» — DNS-сервер возвращает A/AAAA записи целевого хоста вместо CNAME.
  • Glue Records:
    • Когда нужны: Если ваши серверы имен (например, ns1.example.com.) находятся в той же зоне, которую они обслуживают (example.com.).
    • Что делать: У регистратора домена найдите раздел для настройки glue-записей и добавьте A (и/или AAAA) записи для ваших серверов имен. Это разрывает циклическую зависимость.
  • Настройка PTR для почты:
    • Требование: IP-адрес вашего почтового сервера должен иметь PTR-запись, которая разрешается в его полное доменное имя (FQDN, например, mail.example.com.).
    • Согласованность: Имя, которое почтовый сервер передает в команде HELO/EHLO, должно совпадать с именем из PTR-записи, а это имя, в свою очередь, должно иметь A-запись, ведущую обратно к тому же IP-адресу. Это называется «Forward-Confirmed Reverse DNS» (FCrDNS) и критически важно для репутации.
    • Где настраивать: У вашего хостинг-провайдера или владельца IP-адреса, а не в DNS-зоне вашего домена.
  • Разбиение длинных TXT-записей:
    • Если строка в TXT-записи превышает 255 байт, ее необходимо разбить на несколько частей в зонном файле. Каждая часть заключается в кавычки, и DNS-сервер автоматически их объединит.
    • Пример:
      example.com. IN TXT ( "v=DMARC1; p=reject; rua=mailto:dmarc@example.com,mailto:dmarc@thirdparty.com; " "ruf=mailto:forensics@example.com; fo=1; adkim=s; aspf=s; pct=100" )

4. Полные шаблоны зонных файлов (BIND style)

Ниже приведены готовые шаблоны для трех распространенных сценариев. Замените example.com, example.net, IP-адреса и ключи на свои значения.

a) Простой сайт (статический, без почты)

$TTL 3600
@   IN SOA ns1.hosting.net. hostmaster.example.com. (
        2025092201 ; serial (YYYYMMDDNN)
        7200       ; refresh (2 hours)
        3600       ; retry (1 hour)
        1209600    ; expire (14 days)
        86400 )    ; minimum TTL (1 day)

; Authoritative Name Servers
@       IN NS   ns1.hosting.net.
@       IN NS   ns2.hosting.net.

; Web Server (IPv4 and IPv6)
@       IN A    192.0.2.10
@       IN AAAA 2001:db8::10

; WWW subdomain (alias to apex)
www     IN CNAME @

; Security: Restrict Certificate Authorities
@       IN CAA  0 issue "letsencrypt.org"
@       IN CAA  0 iodef "mailto:security@example.com"

b) Сайт + собственный почтовый сервер

$TTL 3600
@   IN SOA ns1.example.net. admin.example.com. (
        2025092201 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        86400 )    ; minimum

; Name Servers
@       IN NS   ns1.example.net.
@       IN NS   ns2.example.net.

; --- Web Section ---
@       IN A    192.0.2.10
www     IN CNAME @

; --- Mail Section ---
; A record for the mail server
mail    IN A    192.0.2.20

; MX record pointing to the mail server
@       IN MX   10 mail.example.com.

; --- Email Authentication ---
; SPF: Allow mail server IP and Google Workspace
@       IN TXT  "v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all"

; DKIM: Public key for 'default' selector
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."

; DMARC: Policy to quarantine failures and send reports
_dmarc  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

; --- Security ---
@       IN CAA  0 issue "letsencrypt.org"

c) Сайт + CDN + Почта + DNSSEC (комплексный пример)

$TTL 300 ; Lower TTL for flexibility with CDN
@   IN SOA ns1.example.net. hostmaster.example.com. (
        2025092201 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        3600 )     ; minimum (also used for negative caching)

; Name Servers
@       IN NS   ns1.example.net.
@       IN NS   ns2.example.net.

; --- Web Section (with CDN) ---
; Apex domain: Use ALIAS/ANAME (provider-specific) to point to origin or CDN edge
; If your provider supports ALIAS:
; @     IN ALIAS origin.examplehost.net.
; If using CNAME flattening for apex (e.g., Cloudflare):
@       IN A    192.0.2.10 ; Temporary or fallback IP, often managed by provider

; WWW subdomain: CNAME to CDN provider
www     IN CNAME cdn-provider.example.net.

; --- Mail Section ---
mail    IN A    192.0.2.20
@       IN MX   10 mail.example.com.

; --- Email Authentication ---
@       IN TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."
_dmarc  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:abuse@example.com; pct=100"

; --- Security ---
@       IN CAA  0 issue "letsencrypt.org"
@       IN CAA  0 issuewild "letsencrypt.org"
@       IN CAA  0 iodef "mailto:security@example.com"

; --- DNSSEC (Example keys - REPLACE WITH YOURS) ---
; DNSKEY records (usually auto-generated by DNS server when signing is enabled)
@       IN DNSKEY 257 3 13 ( ; KSK
        AwEAAbOv...QAB )
@       IN DNSKEY 256 3 13 ( ; ZSK
        AwEAAa3d...9QAB )

; RRSIG records are automatically generated by the DNS server during signing and are not manually added to the zone file.
; NSEC/NSEC3 records are also automatically generated.

; --- Additional Services (Example) ---
; SRV record for SIP service
_sip._tcp IN SRV 10 50 5060 sip1.example.com.

5. Пошаговая настройка почтового домена (PTR, SPF, DKIM, DMARC)

Настройка почты — это комплексная задача. Следуйте этим шагам для обеспечения максимальной доставляемости и защиты от спама.

Шаг 1: Настройка A/AAAA для почтового сервера
Убедитесь, что ваш почтовый сервер имеет запись A (и желательно AAAA).

mail.example.com. 3600 IN A 192.0.2.20

Шаг 2: Настройка MX-записей
Укажите, что почта для example.com должна доставляться на mail.example.com..

example.com. 3600 IN MX 10 mail.example.com.

Шаг 3: Настройка PTR (обратного DNS)
Это самый важный и часто упускаемый шаг. Обратитесь к вашему хостинг-провайдеру или владельцу IP-адреса (192.0.2.20) и запросите настройку PTR-записи, чтобы она указывала на mail.example.com..

  • Проверка: dig -x 192.0.2.20 +short должен вернуть mail.example.com..

Шаг 4: Настройка SPF (через TXT)
Определите, какие серверы могут отправлять почту от имени example.com. Включите свой сервер и любые сторонние сервисы (Gmail, SendGrid и т.д.).

example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.20 include:_spf.google.com -all"
  • Начните с ~all (softfail) для тестирования, затем перейдите на -all (hard fail).

Шаг 5: Настройка DKIM

  1. Сгенерируйте пару ключей (приватный и публичный) на вашем почтовом сервере (MTA). Выберите «селектор» (например, default, 202405).
  2. Настройте MTA на подпись исходящих писем с использованием приватного ключа и выбранного селектора.
  3. Опубликуйте публичный ключ в DNS в виде TXT-записи для поддомена селектор._domainkey.example.com..
    default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."

Шаг 6: Настройка DMARC
Определите политику обработки писем, не прошедших SPF/DKIM, и настройте получение отчетов.

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"
  • Стратегия развертывания:
    1. Начните с p=none — письма не блокируются, вы только получаете отчеты.
    2. Анализируйте отчеты, исправляйте ошибки в SPF/DKIM.
    3. Перейдите на p=quarantine — подозрительные письма попадают в спам.
    4. Перейдите на p=reject — подозрительные письма отклоняются.

Дополнительные советы:

  • Убедитесь, что имя в команде HELO/EHLO, которую ваш почтовый сервер отправляет при подключении, совпадает с именем из PTR-записи (mail.example.com.).
  • Используйте онлайн-инструменты для проверки конфигурации: mail-tester.com, mxtoolbox.com, dmarcian.com.

6. Команды для проверки и отладки DNS

Инструменты командной строки — незаменимы для администратора.

  • dig (Domain Information Groper) — самый мощный и рекомендуемый инструмент.
    • Базовые запросы:
      • dig +short example.com A — получить только IPv4-адрес.
      • dig +short example.com AAAA — получить только IPv6-адрес.
      • dig +short example.com MX — получить MX-записи.
      • dig +short example.com TXT — получить TXT-записи (SPF, DKIM, DMARC).
      • dig +short www.example.com CNAME — получить CNAME.
      • dig +short _sip._tcp.example.com SRV — получить SRV-запись.
    • Обратный DNS:
      • dig -x 192.0.2.1 +short — получить PTR для IP.
    • Трассировка делегирования:
      • dig +trace example.com — показывает весь путь от корневых серверов до авторитетных серверов вашей зоны. Отлично подходит для диагностики проблем с делегированием.
    • Запрос к конкретному серверу:
      • dig @ns1.example.net example.com SOA — запросить SOA-запись у конкретного сервера имен.
    • Проверка DNSSEC:
      • dig +dnssec example.com A — выполнить запрос с флагом DO (DNSSEC OK) и показать RRSIG-записи, если они есть.
      • dig +short example.com DNSKEY — получить DNSKEY-записи.
      • dig +short example.com DS — получить DS-запись (из родительской зоны).
    • Проверка TLSA (DANE):
      • dig +short _443._tcp.www.example.com. TLSA
    • Проверка SSHFP:
      • dig +short example.com SSHFP
  • nslookup — старый, но все еще встречающийся инструмент.
    • nslookup -type=MX example.com
    • nslookup -type=TXT example.com
    • nslookup 192.0.2.1 (для PTR)
  • host — простой и удобный для базовых запросов.
    • host -t A example.com
    • host -t MX example.com
    • host -t TXT example.com
    • host 192.0.2.1 (для PTR)
    • host -t sshfp example.com

7. Безопасность и best practices

  • DNSSEC: Включите DNSSEC для критически важных доменов. Это защищает ваших пользователей от поддельных DNS-ответов. Начните с тестового домена, чтобы освоить процедуру (генерация ключей, публикация DS у регистратора). Используйте онлайн-валидаторы для проверки.
  • CAA: Всегда настраивайте CAA-записи. Это простой и эффективный способ предотвратить выпуск сертификатов для вашего домена неавторизованными центрами сертификации. Укажите только тех CA, которыми вы пользуетесь (например, letsencrypt.org).
  • Управление ключами DKIM: Регулярно (например, раз в год) генерируйте новые пары ключей DKIM. Опубликуйте новый публичный ключ в DNS, настройте MTA на использование нового селектора, а через несколько недель (убедившись, что все старые письма с подписью старого ключа обработаны) удалите старую TXT-запись.
  • Конфиденциальность: Не публикуйте HINFO-записи, так как они раскрывают информацию об оборудовании и ПО, что может быть полезно злоумышленникам.
  • ANY-запросы: Многие публичные DNS-резолверы (например, Google Public DNS, Cloudflare) больше не обрабатывают ANY-запросы из-за их использования в DDoS-атаках. Не полагайтесь на них.

8. Частые ошибки и как их избежать

  1. CNAME конфликтует с другими записями: Нельзя иметь CNAME и, например, A или MX для одного и того же имени. Решение: Пересмотрите структуру зоны. Используйте A-записи или ALIAS/ANAME для apex.
  2. Отсутствие PTR для почтового сервера: Это главная причина, по которой почта попадает в спам. Решение: Всегда настраивайте PTR у вашего хостинг-провайдера.
  3. Неизменяемый SOA Serial: Если не увеличивать серийный номер, вторичные серверы не узнают об обновлениях. Решение: Всегда увеличивайте Serial после любого изменения в зоне. Автоматизируйте этот процесс, если возможно.
  4. Неправильное форматирование длинных TXT-записей: Если строка длиннее 255 байт и не разбита на части, она может быть обрезана или вызвать ошибку. Решение: Всегда разбивайте длинные строки в TXT-записях, заключая каждую часть в кавычки.
  5. Неправильный DS при включении DNSSEC: Если DS-запись, опубликованная у регистратора, не соответствует вашему DNSKEY, зона станет «недоверенной», и клиенты с включенным DNSSEC не смогут получить из нее записи. Решение: Тщательно следуйте инструкциям вашего DNS-сервера и регистратора. Дважды проверяйте хеши.
  6. Высокий TTL перед миграцией: Если TTL большой (например, 86400), после смены IP-адреса пользователи будут попадать на старый адрес в течение суток. Решение: Всегда снижайте TTL за день-два до запланированной миграции.
  7. CNAME на apex-домене: Прямое использование CNAME для example.com. нарушает RFC и может вызвать непредсказуемое поведение. Решение: Используйте ALIAS/ANAME или CNAME flattening, предоставляемые вашим DNS-провайдером.

9. Чек-лист перед продакшн-релизом или миграцией

Используйте этот список для финальной проверки перед запуском или переносом сайта/сервиса.

  • [ ] Основные записи: A/AAAA для всех ключевых хостов (веб, почта) настроены и ведут на правильные IP-адреса.
  • [ ] Почта: MX-записи настроены и указывают на хосты, имеющие A/AAAA записи.
  • [ ] Обратный DNS: PTR-записи для всех IP-адресов почтовых серверов настроены и корректны (проверено через dig -x).
  • [ ] SPF: TXT-запись SPF настроена, включает все разрешенные источники и имеет правильный механизм завершения (-all или ~all).
  • [ ] DKIM: Публичный ключ опубликован в DNS, MTA настроен на подпись писем. Проверена подпись на тестовом письме.
  • [ ] DMARC: TXT-запись DMARC опубликована. Для нового развертывания рекомендуется начать с p=none.
  • [ ] Серверы имен: NS-записи в зоне совпадают с серверами, указанными у регистратора. Настроены glue-записи, если необходимо.
  • [ ] SOA Serial: Серийный номер был увеличен после всех последних изменений.
  • [ ] CAA: Настроены CAA-записи для ограничения выпуска сертификатов.
  • [ ] TTL: TTL был уменьшен заранее (если планировалась миграция).
  • [ ] Проверка: Выполнены проверки с помощью dig +trace, dig MX, dig TXT и онлайн-инструментов (например, MXToolbox).
  • [ ] DNSSEC (если включен): DS-запись корректно добавлена у регистратора, проверки DNSSEC проходят успешно.
  • [ ] Резервное копирование: Экспорт текущей зоны сохранен.
  • [ ] План отката: Четко прописаны шаги для отката изменений в случае сбоя.
  • [ ] Мониторинг: Настроены системы мониторинга для отслеживания доступности DNS-серверов и изменений в зоне.

10. Дополнительные примеры и пояснения полей

  • SRV — Глубокое погружение:_xmpp-client._tcp.example.com. 3600 IN SRV 5 20 5222 xmpp1.example.com. _xmpp-client._tcp.example.com. 3600 IN SRV 5 30 5222 xmpp2.example.com. _xmpp-client._tcp.example.com. 3600 IN SRV 10 100 5222 backup.example.com.
    • Клиент сначала обратится к серверам с приоритетом 5 (xmpp1 и xmpp2).
    • Между xmpp1 и xmpp2 выбор будет происходить пропорционально их весу: xmpp1 имеет 40% шанс (20/(20+30)), xmpp2 — 60% (30/(20+30)).
    • Сервер backup.example.com. (приоритет 10) будет использоваться только если оба сервера с приоритетом 5 недоступны.
  • TLSA — Расшифровка примера:_443._tcp.www.example.com. IN TLSA 3 1 1 d2abde...f21
    • 3 (DANE-EE): Клиент должен использовать именно этот сертификат (или его открытый ключ), независимо от цепочки доверия CA.
    • 1 (Selector): В записи хранится хеш не всего сертификата, а только его открытого ключа. Это удобнее, так как при перевыпуске сертификата с тем же ключом менять TLSA-запись не нужно.
    • 1 (Matching Type): Используется хеш SHA-256.
  • SSHFP — Расшифровка примера:
    example.com. IN SSHFP 4 2 356a192b7913b04c54574d18c28d46e6395428ab
    • 4: Алгоритм — ED25519 (современный и безопасный).
    • 2: Тип дайджеста — SHA-256.
    • 356a19...28ab: SHA-256 хеш открытого ключа ED25519.

11. Полезные сценарии

  • Подключение сайта к CDN:
    1. Обычно CDN-провайдер просит сделать CNAME для поддомена (например, www) на их адрес (например, example.cdnprovider.com).
    2. Если вы хотите использовать CDN для корневого домена (example.com), используйте функцию ALIAS/ANAME или CNAME flattening вашего DNS-провайдера.
    3. Убедитесь, что CDN правильно настроен для работы с вашим SSL-сертификатом (часто CDN берет на себя терминацию SSL). Учет CAA-записей в этом случае важен.
  • Перемещение хоста (миграция):
    1. За 48-72 часа до миграции: Уменьшите TTL для A/AAAA записей вашего сайта до 300 секунд.
    2. Подождите: Дождитесь, пока старый TTL «пропагируется» (пройдет срок, равный старому TTL, например, 3600 секунд).
    3. В день миграции: Измените A/AAAA записи, указав новые IP-адреса.
    4. Проверка: Используйте dig +short example.com A с разных публичных DNS (Google 8.8.8.8, Cloudflare 1.1.1.1) для проверки распространения изменений.
    5. После стабилизации (через 24-48 часов): Увеличьте TTL обратно до оптимального значения (например, 3600).

12. Готовый JSON для импорта в панель провайдера

Ниже приведен расширенный JSON-шаблон, содержащий практически все типы записей, рассмотренные в этом гиде. Этот формат является обобщенным и может потребовать адаптации под конкретный API вашего DNS-провайдера (Cloudflare, AWS Route 53, DigitalOcean и т.д.).

{
  "zone": "example.com",
  "records": [
    {
      "type": "A",
      "name": "@",
      "value": "192.0.2.10",
      "ttl": 3600
    },
    {
      "type": "AAAA",
      "name": "@",
      "value": "2001:db8::10",
      "ttl": 3600
    },
    {
      "type": "CNAME",
      "name": "www",
      "value": "example.com.",
      "ttl": 3600
    },
    {
      "type": "MX",
      "name": "@",
      "value": "mail.example.com.",
      "priority": 10,
      "ttl": 3600
    },
    {
      "type": "MX",
      "name": "@",
      "value": "backup-mail.example.com.",
      "priority": 20,
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "@",
      "value": "v=spf1 ip4:192.0.2.20 include:_spf.google.com -all",
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "default._domainkey",
      "value": "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQA...",
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "_dmarc",
      "value": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "value": "ns1.example.net.",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "value": "ns2.example.net.",
      "ttl": 3600
    },
    {
      "type": "SOA",
      "name": "@",
      "primary_ns": "ns1.example.net.",
      "admin_email": "admin.example.com.",
      "serial": 2025092201,
      "refresh": 7200,
      "retry": 3600,
      "expire": 1209600,
      "minimum": 86400,
      "ttl": 3600
    },
    {
      "type": "PTR",
      "name": "20.2.0.192.in-addr.arpa.",
      "value": "mail.example.com.",
      "ttl": 3600
    },
    {
      "type": "SRV",
      "name": "_sip._tcp",
      "target": "sipserver.example.com.",
      "port": 5060,
      "priority": 10,
      "weight": 60,
      "ttl": 3600
    },
    {
      "type": "CAA",
      "name": "@",
      "value": "letsencrypt.org",
      "flags": 0,
      "tag": "issue",
      "ttl": 3600
    },
    {
      "type": "CAA",
      "name": "@",
      "value": "mailto:security@example.com",
      "flags": 0,
      "tag": "iodef",
      "ttl": 3600
    },
    {
      "type": "TLSA",
      "name": "_443._tcp.www",
      "usage": 3,
      "selector": 1,
      "matching_type": 1,
      "value": "d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971",
      "ttl": 3600
    },
    {
      "type": "SSHFP",
      "name": "@",
      "algorithm": 4,
      "digest_type": 2,
      "value": "356a192b7913b04c54574d18c28d46e6395428ab",
      "ttl": 3600
    },
    {
      "type": "HINFO",
      "name": "server1",
      "cpu": "Intel Xeon",
      "os": "Ubuntu 22.04 LTS",
      "ttl": 3600
    },
    {
      "type": "LOC",
      "name": "@",
      "latitude": "55.7558 N",
      "longitude": "37.6176 E",
      "altitude": 150,
      "ttl": 3600
    },
    {
      "type": "RP",
      "name": "@",
      "mbox": "admin.example.com.",
      "txt": "Technical Support",
      "ttl": 3600
    },
    {
      "type": "NAPTR",
      "name": "4.3.2.1.5.5.5.1.e164.arpa.",
      "order": 100,
      "preference": 10,
      "flags": "U",
      "service": "E2U+sip",
      "regexp": "!^.*$!sip:info@example.com!",
      "replacement": ".",
      "ttl": 3600
    },
    {
      "type": "DS",
      "name": "@",
      "key_tag": 54517,
      "algorithm": 13,
      "digest_type": 2,
      "digest": "84C84478D00A57973FC5D3E32F7E2BF539FB697D2660874C6D33A3313872D34F",
      "ttl": 3600
    },
    {
      "type": "DNSKEY",
      "name": "@",
      "flags": 257,
      "protocol": 3,
      "algorithm": 13,
      "public_key": "AwEAAbOv...QAB",
      "ttl": 3600
    },
    {
      "type": "DNSKEY",
      "name": "@",
      "flags": 256,
      "protocol": 3,
      "algorithm": 13,
      "public_key": "AwEAAa3d...9QAB",
      "ttl": 3600
    }
  ]
}


Cloudflare:

{
  "zone_name": "example.com",
  "zone_type": "full",
  "records": [
    {
      "type": "A",
      "name": "@",
      "content": "192.0.2.10",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "AAAA",
      "name": "@",
      "content": "2001:db8::10",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "CNAME",
      "name": "www",
      "content": "example.com",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "MX",
      "name": "@",
      "content": "mail.example.com",
      "priority": 10,
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "@",
      "content": "v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all",
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "_dmarc",
      "content": "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "content": "ns1.example.net",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "content": "ns2.example.net",
      "ttl": 3600
    },
    {
      "type": "SRV",
      "name": "_sip._tcp",
      "data": {
        "target": "sipserver.example.com",
        "port": 5060,
        "priority": 10,
        "weight": 60
      },
      "ttl": 3600
    },
    {
      "type": "CAA",
      "name": "@",
      "data": {
        "flags": 0,
        "tag": "issue",
        "value": "letsencrypt.org"
      },
      "ttl": 3600
    },
    {
      "type": "TLSA",
      "name": "_443._tcp",
      "data": {
        "usage": 3,
        "selector": 1,
        "matching_type": 1,
        "certificate": "<hex-of-cert-hash>"
      },
      "ttl": 3600
    },
    {
      "type": "SSHFP",
      "name": "@",
      "data": {
        "algorithm": 4,
        "digest_type": 2,
        "fingerprint": "d6f8..."
      },
      "ttl": 3600
    },
    {
      "type": "HINFO",
      "name": "@",
      "data": {
        "cpu": "INTEL",
        "os": "Linux"
      },
      "ttl": 3600
    },
    {
      "type": "LOC",
      "name": "@",
      "data": {
        "latitude": "37.7749N",
        "longitude": "122.4194W",
        "altitude": 30
      },
      "ttl": 3600
    },
    {
      "type": "RP",
      "name": "admin",
      "data": {
        "mbox": "admin.example.com",
        "txt": "Responsible person for the domain"
      },
      "ttl": 3600
    },
    {
      "type": "NAPTR",
      "name": "_sip._tcp",
      "data": {
        "order": 100,
        "preference": 10,
        "flags": "U",
        "service": "SIP+D2U",
        "regexp": "",
        "replacement": "_sip._udp.example.com"
      },
      "ttl": 3600
    },
    {
      "type": "DS",
      "name": "@",
      "data": {
        "key_tag": 12345,
        "algorithm": 8,
        "digest_type": 2,
        "digest": "<hex-digest>"
      },
      "ttl": 3600
    },
    {
      "type": "DNSKEY",
      "name": "@",
      "data": {
        "flags": 256,
        "protocol": 3,
        "algorithm": 8,
        "public_key": "<base64-key>"
      },
      "ttl": 3600
    },
    {
      "type": "RRSIG",
      "name": "@",
      "data": {
        "type_covered": "A",
        "algorithm": 8,
        "labels": 1,
        "original_ttl": 3600,
        "signature_expiration": 1700000000,
        "signature_inception": 1690000000,
        "key_tag": 12345,
        "signer_name": "example.com",
        "signature": "<base64-signature>"
      },
      "ttl": 3600
    },
    {
      "type": "NSEC",
      "name": "@",
      "data": {
        "next_domain": "example.net",
        "types": ["A","AAAA","MX","TXT","NS"]
      },
      "ttl": 3600
    }
  ]
}

Route 53:

{
  "Comment": "Full DNS cheat sheet import",
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "A",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "192.0.2.10"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "AAAA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "2001:db8::10"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "www.example.com.",
        "Type": "CNAME",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "MX",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "10 mail.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "TXT",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_dmarc.example.com.",
        "Type": "TXT",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "NS",
        "TTL": 3600,
        "ResourceRecords": [
          {"Value": "ns1.example.net"},
          {"Value": "ns2.example.net"}
        ]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_sip._tcp.example.com.",
        "Type": "SRV",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "10 60 5060 sipserver.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "CAA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "0 issue \"letsencrypt.org\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_443._tcp.example.com.",
        "Type": "TLSA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "3 1 1 <hex-of-cert-hash>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "SSHFP",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "4 2 d6f8..."}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "HINFO",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"INTEL\" \"Linux\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "LOC",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "37.7749N 122.4194W 30m"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "admin.example.com.",
        "Type": "RP",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "admin.example.com Responsible person for the domain"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_sip._tcp.example.com.",
        "Type": "NAPTR",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "100 10 U SIP+D2U "" _sip._udp.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "DS",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "12345 8 2 <hex-digest>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "DNSKEY",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "256 3 8 <base64-key>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "RRSIG",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "A 8 1 3600 1700000000 1690000000 12345 example.com <base64-signature>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "NSEC",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "example.net A AAAA MX TXT NS"}]
      }
    }
  ]
}

Полная поддержка всех типов записей: A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, TLSA, SSHFP, HINFO, LOC, RP, NAPTR, DS, DNSKEY, RRSIG, NSEC. TTL и приоритеты уже заданы, можно адаптировать под нужды. Использует ResourceRecords для каждой записи, как требует AWS.
Прямой импорт через AWS CLI командой:

aws route53 change-resource-record-sets --hosted-zone-id ZONE_ID --change-batch file://dns_records.json

Планируйте изменения: Всегда снижайте TTL перед миграцией.

Тестируйте: Используйте dig, nslookup и онлайн-инструменты для проверки каждой настройки.

Безопасность прежде всего: Настройте SPF, DKIM, DMARC для почты. Включите CAA для контроля сертификатов. Рассмотрите возможность использования DNSSEC для критически важных доменов.

Документируйте: Ведите чек-листы и храните резервные копии зон.

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

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

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