Список типов DNS-записей от A до Z: повседневные, которые есть в любой зоне, записи DNSSEC и безопасности, специализированные (VoIP, Kerberos, поиск сервисов), служебные псевдотипы, которые выводят утилиты, и устаревшие, которые ещё встречаются в старых файлах зон. Для каждого типа: номер и RFC, назначение, пример в синтаксисе файла зоны, типичные ошибки и способ проверки.
Частые типы проверяются вживую через DNS Lookup. Если запрос не возвращает ответ вовсе, а не возвращает неверные данные, статус ошибки разобран в справочнике кодов ошибок DNS.
Ничего не найдено.
Сопоставляет имени IPv4-адрес: www.example.com. 300 IN A 192.0.2.10. Несколько A-записей на одном имени дают простой round-robin. Типичные ошибки: частный адрес (10.x, 192.168.x) в публичном DNS, апекс без A-записи после переезда хостинга и такой длинный TTL, что миграция доходит до всех только через сутки. Проверка — DNS Lookup.
Сопоставляет имени IPv6-адрес: www.example.com. 300 IN AAAA 2001:db8::10. Публикуйте, только если сервис действительно отвечает по IPv6. AAAA на хост, который там не слушает, заставляет IPv6-клиентов ждать таймаута, прежде чем перейти на IPv4. Запись проверит DNS Lookup, обратное имя — PTR Lookup.
Указывал серверы баз данных ячеек AFS и сервисы DCE/NCA. Сегодня почти не используется; RFC 5864 рекомендует для AFS записи SRV. Можно удалить, если его не читает старая инсталляция AFS.
Это не настоящий тип записи: ALIAS нет в реестре IANA. DNS-провайдеры предлагают его, чтобы обойти правило «CNAME нельзя ставить на апекс зоны». Сервер провайдера сам разрешает цель и отвечает обычными A/AAAA, поэтому резолверы никакого «ALIAS» не видят. Названия разные (ALIAS, ANAME, CNAME flattening). Работает только у того провайдера, который это предлагает, и не переносится трансфером зоны. Подробнее: CNAME, A и ALIAS.
Тип запроса, а не публикуемая запись: «пришли все записи этого имени». Из-за злоупотреблений ответами ANY в атаках с усилением RFC 8482 разрешает серверам отвечать минимально (часто одной записью HINFO). Не используйте ANY для получения списка записей; запрашивайте каждый нужный тип отдельно.
Список адресных префиксов («address prefix list»), например APL 1:192.0.2.0/24 !1:192.0.2.128/25. Экспериментальный и практически не используется. Некоторые резолверы и провайдеры его вовсе не поддерживают.
Типы запросов трансфера зоны: AXFR копирует всю зону, IXFR — только изменения с указанного серийного номера SOA. Вторичные серверы синхронизируются с основным именно так. Разрешайте их только своим вторичным серверам, по IP и желательно с ключом TSIG; открытый AXFR отдаёт любому всю зону, включая внутренние имена. NODA проверяет это (проверка AXFR / Zone Transfer).
Указывает, какие удостоверяющие центры могут выпускать сертификаты для домена: example.com. CAA 0 issue "letsencrypt.org", плюс issuewild для wildcard и iodef для отчётов о нарушениях. УЦ обязаны проверять её перед выпуском. Действует и на поддомены, если у них нет своей CAA. Типичная ошибка: добавить CAA для одного УЦ и забыть тот, которым пользуется ваш CDN или почтовый провайдер, — у него потом молча не продлится сертификат. Проверка — DNS Lookup, кто реально выпускал — поиск в CT-журналах.
Публикуется дочерней зоной, чтобы сообщить родителю, какую DS-запись она хочет. Реестры и регистраторы с поддержкой сканируют CDS/CDNSKEY и обновляют DS автоматически, убирая ручной шаг при ротации ключей. Особое значение (CDS 0 0 0 00) просит родителя удалить DS и безопасно отключить DNSSEC. Полезно, только если ваш реестр или регистратор это сканирует.
Хранит сертификат или список отзыва (X.509, PGP и другие) в DNS. Используется редко: типичные случаи с доверием через DNSSEC покрывают TLSA, SMIMEA и OPENPGPKEY. Встречается в старых схемах распространения PGP-ключей.
Делает одно имя псевдонимом другого: www.example.com. CNAME example.net. Резолвер затем ищет цель. У имени с CNAME не может быть других записей, поэтому CNAME нельзя ставить на апекс зоны (там нужны SOA и NS) и нельзя совмещать с MX или TXT. Длинные цепочки замедляют каждый запрос. Не направляйте MX или NS на CNAME (RFC 2181 §10.3). Подробнее: CNAME, A и ALIAS.
Позволяет дочерней зоне попросить родителя автоматически скопировать её NS-записи или glue — как CDS делает для DS. Поддержка у реестров пока ограничена. Полезна в основном, если вы часто меняете NS и ваш реестр это поддерживает.
Записывается DHCP-серверами, которые динамически обновляют DNS, чтобы зафиксировать, какому клиенту принадлежит имя, и не дать двум клиентам бороться за него. Встречается в установках Windows/ISC DHCP с динамическим DNS; вручную не редактируется.
DNSSEC Lookaside Validation: временное решение, публиковавшее якоря доверия вне родительской зоны, пока корень и TLD не были подписаны. Основной реестр DLV закрыт в 2017 году, RFC 8749 перевёл DLV в статус Historic. Удалите остатки конфигурации DLV из резолверов.
Перенаправляет целое поддерево: old.example. DNAME new.example. делает так, что a.old.example разрешается как a.new.example — для всех имён ниже (но не для самого old.example). Применяется при переименовании доменов и переносе обратных зон IPv6. Для старых резолверов серверы синтезируют CNAME. Если переписанное имя превысит 255 байт, ответ — YXDOMAIN.
Открытые DNSSEC-ключи зоны. Флаг 257 обозначает ключ подписи ключей (KSK, на него указывает DS у родителя), 256 — ключ подписи зоны (ZSK). Резолверы проверяют этими ключами подписи RRSIG. Сами по себе ключи зону не защищают: без соответствующей DS у родителя валидаторы их игнорируют. Предпочтительны алгоритмы 13 (ECDSA P-256) или 15 (Ed25519). Цепочку проверит DNSSEC Checker.
Публикуется в родительской зоне (обычно через регистратора) и содержит хэш ключа подписи ключей дочерней зоны. Именно эта связь делает DNSSEC дочерней зоны доверенным. Используйте тип дайджеста 2 (SHA-256). Классический сбой: смена DNS-провайдера, когда у регистратора осталась старая DS, — все валидирующие резолверы отвечают SERVFAIL. Удалите или замените DS до или во время переезда. Проверка — DNSSEC Checker.
Изначально описывал процессор и ОС хоста. Сейчас публикация этого считается утечкой информации, поэтому используется редко. Вернулся в одной роли: серверы по RFC 8482 отвечают на запросы ANY синтетической записью HINFO (например, "RFC8482" ""). Если вы её видите, всё в порядке.
Публикует идентификатор Host Identity Protocol (открытый ключ) и rendezvous-серверы хоста. Используется только в развёртываниях HIP, которые редки за пределами исследований и некоторых промышленных сетей.
Сообщает клиенту, как подключаться, ещё до подключения: поддерживаемые протоколы (alpn="h3,h2"), альтернативные точки, подсказки IP и ключи Encrypted ClientHello. example.com. HTTPS 1 . alpn="h3,h2" позволяет браузеру сразу идти по HTTP/3. Приоритет 0 — режим псевдонима, который, в отличие от CNAME, работает на апексе зоны. SVCB — общая форма для других протоколов. Большинство CDN публикуют её автоматически.
Публикует открытый ключ IPsec и шлюз для хоста, используется для оппортунистического шифрования. Доверять ему можно только в зоне, подписанной DNSSEC. Встречается редко.
DNSSEC-записи первого поколения. RFC 3755 заменил их на DNSKEY и RRSIG для подписи зон. Транзакционные подписи SIG(0) ещё встречаются в немногих схемах динамического обновления, но в современной подписанной зоне KEY/SIG быть не должно.
Указывает хост обмена ключами для домена — по аналогии с MX, для согласования ключей IPsec. Информационный RFC, практически не используется.
Указывает физическое расположение хоста: широта, долгота, высота и точность: LOC 40 26 57 N 79 58 12 W 300m. Cloudflare поддерживает, большинство других — нет. Помните, что это публично: не публикуйте расположение того, что хотите скрыть.
Исходные почтовые и сервисные записи 1987 года, заменённые MX (RFC 974) и с тех пор практически не используемые. WKS («well-known services») перечислял открытые порты и тоже устарел. Если они остались в старом ПО или файле зоны, удалите их.
Указывает, какие серверы принимают почту для домена, с приоритетом (меньший пробуют первым): example.com. MX 10 mx1.example.com. Цель — имя хоста с записями A/AAAA, не IP и не CNAME. Без MX отправители используют A-запись домена. Домен, не принимающий почту, должен публиковать «нулевой» MX (MX 0 ., RFC 7505) и нулевой SPF. Проверка — проверка SPF / DKIM / DMARC и DNS Lookup.
Правило перезаписи для Dynamic Delegation Discovery (DDDS): сопоставляет имени сервис и следующее имя или URI для поиска, часто дальше идёт SRV. Встречается в SIP/VoIP и ENUM (номера телефонов в DNS, в зоне e164.arpa). Поле regex легко испортить; проверяйте всю цепочку NAPTR → SRV → A.
Перечисляет авторитативные NS зоны. Существует в двух местах: в родительской зоне (делегирование, задаётся у регистратора) и в самой зоне. Списки должны совпадать. Используйте минимум два NS, лучше в разных сетях; имени NS внутри обслуживаемой зоны нужен glue у родителя. Частая поломка — оставшийся после смены провайдера NS, который отвечает REFUSED. Делегирование и согласованность проверит NODA, сами записи — DNS Lookup.
Подписанное в DNSSEC доказательство того, что имени или типа не существует: каждая NSEC называет следующее существующее имя в зоне. Побочный эффект: любой может пройти по цепочке и получить список всех имён зоны («zone walking»). Если это важно, используйте NSEC3 или подход «black lies» / compact denial, который применяют многие провайдеры подписи.
Как NSEC, но доказывает отсутствие имени через хэши имён, что затрудняет обход зоны (но не исключает: хэши можно подобрать офлайн). NSEC3PARAM публикует параметры хэширования. RFC 9276 предписывает 0 дополнительных итераций и пустую соль: больше итераций нагружают процессор резолверов без реальной защиты, а при больших значениях резолверы могут считать зону небезопасной (EDE 27). Текущее значение покажет dig NSEC3PARAM example.com.
Публикует открытый OpenPGP-ключ пользователя в DNS под хэшем локальной части адреса: <sha256-локальной-части>._openpgpkey.example.com. Имеет смысл только в зоне, подписанной DNSSEC. Большинство развёртываний вместо этого используют Web Key Directory (WKD) через HTTPS.
Псевдозапись, которая переносит EDNS(0) в запросе или ответе: размер UDP-пакета, бит DNSSEC OK (DO) и опции вроде cookies, client subnet и расширенных ошибок DNS. В файле зоны не встречается никогда. dig показывает её как «OPT PSEUDOSECTION». Неправильная обработка OPT старыми серверами и файрволами — обычная причина FORMERR.
Сопоставляет адрес обратно имени, в зоне in-addr.arpa (IPv4) или ip6.arpa (IPv6): 10.2.0.192.in-addr.arpa. PTR mail.example.com. Обратная зона принадлежит владельцу блока IP — обычно хостинг-провайдеру, поэтому PTR задают в его панели, а не в DNS вашего домена. Почтовому серверу нужен PTR, совпадающий с прямой A/AAAA-записью и именем HELO. Проверка — PTR Lookup.
Указывает «ответственное лицо» домена — почтовый ящик и ссылку на TXT. Сегодня публикуется редко, в основном потому, что привлекает спам; ту же задачу решают поле RNAME в SOA и контакты RDAP.
Подпись DNSSEC над одним набором записей с временем начала и окончания действия. Подписывающее ПО пересоздаёт их по расписанию; если подпись остановилась, зона работает, пока подписи не истекут, а затем перестаёт работать везде, где включена проверка (EDE 7). Набор записей без RRSIG в подписанной зоне тоже не проходит проверку (EDE 10). Запрос — dig +dnssec; сроки покажет DNSSEC Checker.
Публикует сертификат S/MIME для адреса почты в том же формате, что TLSA, под <хэш>._smimecert.example.com. Позволяет почтовым клиентам найти сертификат получателя и доверять ему через DNSSEC. Поддержка в клиентах пока слабая.
Заголовочная запись зоны, ровно одна, на апексе: основной NS (MNAME), почтовый ящик ответственного (RNAME, первая точка означает @), серийный номер и таймеры refresh/retry/expire для вторичных серверов. Последнее поле задаёт, сколько резолверы кэшируют ответ «не существует» (RFC 2308), поэтому новое имя какое-то время может оставаться NXDOMAIN. Увеличивайте серийный номер при каждом изменении, иначе вторичные серверы его не заберут; обычно используют формат даты YYYYMMDDnn. Согласованность SOA между NS проверит NODA.
Отдельный тип записи для SPF, который так и не прижился. RFC 7208 (2014) его убрал: SPF живёт в TXT-записи, начинающейся с v=spf1, а записи типа 99 получатели игнорируют. Если провайдер всё ещё предлагает тип «SPF», используйте TXT. Создать и проверить TXT-вариант поможет генератор SPF-записи.
Указывает, где работает сервис: _sip._tcp.example.com. SRV 10 60 5060 sip1.example.com. (приоритет, вес, порт, цель). Используется SIP, XMPP, LDAP, Kerberos, Active Directory, Minecraft, Matrix и другими. В имени должны быть обе метки, _service._proto; цель — имя хоста с A/AAAA, не CNAME. Цель . означает «сервис здесь не предоставляется». Проверка — DNS Lookup.
Публикует отпечаток SSH-ключа хоста, чтобы клиент мог проверить сервер при первом подключении вместо вопроса «are you sure?». OpenSSH использует это при VerifyHostKeyDNS yes, но доверяет только ответу, проверенному DNSSEC. Записи генерируются на сервере командой ssh-keygen -r host.example.com.
DANE: привязывает TLS-сертификат или ключ к имени сервиса, под _port._proto.host, например _25._tcp.mail.example.com. TLSA 3 1 1 <sha256>. Используется в основном для SMTP между почтовыми серверами, где защищает от понижения шифрования и поддельных сертификатов. Требует зоны, подписанной DNSSEC. Обновите TLSA до смены ключа, иначе доставка почты к вам сломается. Сертификат проверит SSL Checker.
Метазаписи, которые существуют только внутри сообщения и никогда в зоне. TSIG подписывает DNS-сообщение общим секретом (обычно HMAC-SHA256) для аутентификации трансферов зон, NOTIFY и динамических обновлений между серверами. TKEY согласует такие ключи. У обеих сторон должны совпадать имя ключа, алгоритм и секрет, а часы — расходиться не больше допустимого; иначе будут BADSIG, BADKEY или BADTIME.
Произвольный текст: используется для SPF (v=spf1 …), ключей DKIM (selector._domainkey), DMARC (_dmarc) и токенов подтверждения домена для Google, Microsoft и других. Каждая строка ограничена 255 символами; длинные значения делят на несколько строк в кавычках, которые получатель склеивает без пробелов. Типичные ошибки: две SPF-записи (недопустимо), «умные» кавычки, вставленные из документа, и токены подтверждения, оставленные спустя годы. SPF/DKIM/DMARC проверит проверка SPF / DKIM / DMARC.
Сопоставляет имени сервиса URI, с приоритетом и весом, как у SRV: _ftp._tcp.example.com. URI 10 1 "ftp://ftp.example.com/pub". Используется Kerberos (MIT, для поиска KDC) и некоторыми другими протоколами. У DNS-провайдеров поддерживается не везде.
Дайджест всей зоны на апексе, позволяющий получателю проверить, что полная копия цела и не изменена, независимо от способа передачи. Корневая зона публикует его с 2023 года. Полезен для зон, распространяемых файлами (например, локальные копии корня, RFC 8806).
Номера типов — по реестру IANA DNS Parameters; определяющий RFC указан в каждой записи. Оценить DNS домена целиком можно в NODA.
