Список типов записей DNS
(Перенаправлено с записи AAAA )
Этот список типов записей DNS представляет собой обзор записей ресурсов (RR), допустимых в файлах зон системы доменных имен (DNS). Он также содержит псевдо-RR.
Записи ресурсов
[ редактировать ]| Тип | Идентификатор типа (десятичный) | Определение RFC | Описание | Функция |
|---|---|---|---|---|
| А | 1 | RFC 1035 [1] | Адресная запись | Возвращает 32-битный адрес IPv4 , который чаще всего используется для сопоставления имен хостов с IP-адресом хоста, но он также используется для DNSBL , хранения масок подсети в RFC 1101 и т. д. |
| АААА | 28 | RFC 3596 [2] | IPv6 запись адреса | Возвращает 128-битный IPv6- адрес, который чаще всего используется для сопоставления имен хостов с IP-адресом хоста. |
| АФСДБ | 18 | RFC 1183 | Запись в базе данных AFS | Расположение серверов баз данных ячейки AFS . Эта запись обычно используется клиентами AFS для связи с ячейками AFS за пределами их локального домена. Подтип этой записи используется устаревшей файловой системой DCE/DFS . |
| АПЛ | 42 | RFC 3123 | Список префиксов адресов | Укажите списки диапазонов адресов, например, в формате CIDR , для различных семейств адресов. Экспериментальный. |
| САА | 257 | RFC 6844 | Авторизация центра сертификации | Авторизация центра сертификации DNS , ограничивающая допустимые центры сертификации для хоста/домена. |
| CDNSKEY | 60 | RFC 7344 | Дочерняя копия записи DNSKEY для передачи родительскому | |
| CDS | 59 | RFC 7344 | Детский ДС | Дочерняя копия записи DS для передачи родительскому |
| СЕРТ | 37 | RFC 4398 | Запись сертификата | Хранит PKIX , SPKI , PGP и т. д. |
| CNAME | 5 | RFC 1035 [1] | Запись канонического имени | Псевдоним одного имени к другому: поиск DNS будет продолжен путем повторной попытки поиска с новым именем. |
| CSYNC | 62 | RFC 7477 | Синхронизация между детьми и родителями | Укажите механизм синхронизации между дочерней и родительской зонами DNS. Типичным примером является объявление одних и тех же записей NS в родительской и дочерней зонах. |
| ДХИД | 49 | RFC 4701 | Идентификатор DHCP | Используется вместе с опцией FQDN для DHCP. |
| ДЛВ | 32769 | RFC 4431 | Запись проверки DNSSEC Lookaside | Для публикации якорей доверия DNSSEC вне цепочки делегирования DNS. Использует тот же формат, что и запись DS. RFC 5074 описывает способ использования этих записей. |
| ДИМЯ | 39 | RFC 6672 | Запись имени делегации | Псевдоним имени и всех его подимен, в отличие от CNAME, который является псевдонимом только для точного имени. Как и в случае с записью CNAME, поиск DNS будет продолжен путем повторной попытки поиска с новым именем. |
| DNSKEY | 48 | RFC 4034 | Запись DNS-ключа | Ключевая запись, используемая в DNSSEC . Использует тот же формат, что и запись KEY. |
| ДС | 43 | RFC 4034 | Подписант делегации | Запись, используемая для идентификации ключа подписи DNSSEC делегированной зоны. |
| EUI48 | 108 | RFC 7043 | MAC-адрес (EUI-48) | 48-битный расширенный уникальный идентификатор IEEE. |
| EUI64 | 109 | RFC 7043 | MAC-адрес (EUI-64) | 64-битный расширенный уникальный идентификатор IEEE. |
| ИНФО | 13 | RFC 8482 | Информация о хосте | Предоставление ответов минимального размера на DNS-запросы с QTYPE=ANY |
| БЕДРО | 55 | РФК 8005 | Протокол идентификации хоста | Метод разделения ролей идентификатора конечной точки и локатора IP-адресов. |
| HTTPS | 65 | RFC 9460 | HTTPS-привязка | RR, который повышает производительность для клиентов, которым необходимо разрешить множество ресурсов для доступа к домену. |
| IPSECKEY | 45 | RFC 4025 | Ключ IPsec | Ключевая запись, которую можно использовать с IPsec. |
| КЛЮЧ | 25 | РФК 2535 [3] и RFC 2930 [4] | Ключевая запись | Используется только для SIG(0) (RFC 2931) и TKEY (RFC 2930). [5] RFC 3445 исключил их использование для ключей приложений и ограничил их использование DNSSEC. [6] RFC 3755 определяет DNSKEY как замену DNSSEC. [7] RFC 4025 определяет IPSECKEY как замену IPsec. [8] |
| КХ | 36 | РФК 2230 | Запись обменника ключей | Используется в некоторых криптографических системах (кроме DNSSEC) для идентификации агента управления ключами для соответствующего доменного имени. Обратите внимание, что это не имеет ничего общего с безопасностью DNS. Это информационный статус, а не соответствие стандартам IETF. Он всегда имел ограниченное применение, но все еще используется. |
| МЕСТО | 29 | РФК 1876 | Запись местоположения | Указывает географическое местоположение, связанное с доменным именем. |
| МХ | 15 | RFC 1035 [1] и RFC 7505 | Запись обмена почтой | Список серверов обмена почтой, принимающих электронную почту для домена |
| НАПТР | 35 | RFC 3403 | Указатель полномочий по именованию | Позволяет перезаписывать доменные имена на основе регулярных выражений, которые затем можно использовать в качестве URI , дополнительных доменных имен для поиска и т. д. |
| НС | 2 | RFC 1035 [1] | Запись сервера имен | Делегирует зону DNS для использования данных авторитетных серверов имен. |
| НСЕК | 47 | RFC 4034 | Следующая безопасная запись | Часть DNSSEC, используемая для доказательства отсутствия имени. Использует тот же формат, что и (устаревшая) запись NXT. |
| НСЕК3 | 50 | RFC 5155 | Далее Защищенная запись версии 3 | Расширение DNSSEC, позволяющее доказать отсутствие имени без разрешения обхода зоны. |
| NSEC3PARAM | 51 | RFC 5155 | Параметры NSEC3 | Запись параметров для использования с NSEC3 |
| ОПЕНГПКЕЙ | 61 | RFC 7929 | Запись открытого ключа OpenPGP | Метод аутентификации именованных объектов на основе DNS (DANE) для публикации и поиска открытых ключей OpenPGP в DNS для определенного адреса электронной почты с использованием записи ресурса DNS OPENPGPKEY. |
| ПТР | 12 | RFC 1035 [1] | Запись ресурса PTR | Указатель на каноническое имя . В отличие от CNAME, обработка DNS останавливается и возвращается только имя. Чаще всего используется для реализации обратного поиска DNS , но есть и другие варианты использования, такие как DNS-SD . |
| РП | 17 | RFC 1183 | Ответственное лицо | Информация об ответственном(ых) лице(ах) за домен. Обычно адрес электронной почты, в котором @ заменен на расширение . |
| РРСИГ | 46 | RFC 4034 | DNSSEC-подпись | Подпись для набора записей, защищенного DNSSEC. Использует тот же формат, что и запись SIG. |
| СКАЗАТЬ | 24 | РФК 2535 | Подпись | Запись подписи, используемая в SIG(0) (RFC 2931) и TKEY (RFC 2930). [7] В RFC 3755 RRSIG обозначен как замена SIG для использования в DNSSEC. [7] |
| СМИМЕА | 53 | RFC 8162 [9] | Ассоциация сертификатов S/MIME [10] | Связывает сертификат S/MIME с именем домена для аутентификации отправителя. |
| СОА | 6 | RFC 1035 [1] и RFC 2308 [11] | Начало авторитетной записи [зоны] | Указывает достоверную информацию о зоне DNS , включая основной сервер имен, адрес электронной почты администратора домена, серийный номер домена и несколько таймеров, связанных с обновлением зоны. |
| СРВ | 33 | RFC 2782 | Поиск сервисов | Обобщенная запись местоположения службы, используемая для новых протоколов вместо создания записей для конкретных протоколов, таких как MX. |
| СШФП | 44 | RFC 4255 | Отпечаток открытого ключа SSH | Запись ресурса для публикации отпечатков пальцев открытого ключа хоста SSH в DNS, чтобы помочь в проверке подлинности хоста. RFC 6594 определяет ключи SSH ECC и хэши SHA-256. см . в реестре параметров RR IANA SSHFP Подробности . |
| СВКБ | 64 | RFC 9460 | Привязка службы | RR, который повышает производительность для клиентов, которым необходимо разрешить множество ресурсов для доступа к домену. |
| ОБЛИЦОВКА | 32768 | — | Доверительные органы DNSSEC | Часть предложения по развертыванию DNSSEC без подписанного корня DNS. см . в базе данных IANA и спецификации Weiler Подробности . Использует тот же формат, что и запись DS. |
| ТКЕЙ | 249 | РФК 2930 | Запись ключа транзакции | Метод предоставления ключевого материала для использования с TSIG , который зашифрован открытым ключом в сопроводительной записи KEY RR. [12] |
| ТЛСА | 52 | RFC 6698 | Ассоциация сертификатов TLSA | Рекорд для ДЕЙНА . RFC 6698 определяет: «Запись ресурса DNS TLSA используется для связи сертификата сервера TLS или открытого ключа с именем домена, в котором находится запись, образуя таким образом «ассоциацию сертификатов TLSA». |
| ТИГ | 250 | RFC 2845 | Подпись транзакции | Может использоваться для аутентификации динамических обновлений как поступающих от утвержденного клиента или для аутентификации ответов как поступающих от утвержденного рекурсивного сервера имен. [13] аналогично DNSSEC. |
| ТЕКСТ | 16 | RFC 1035 [1] | Текстовая запись | Первоначально для произвольного удобочитаемого текста в записи DNS. Однако с начала 1990-х годов эта запись чаще содержит машиночитаемые данные , такие как указанные в RFC 1464, оппортунистическое шифрование , Sender Policy Framework , DKIM , DMARC , DNS-SD и т. д. |
| ТИП | 256 | RFC 7553 | Единый идентификатор ресурса | Может использоваться для публикации сопоставлений имен хостов с URI. |
| КОШЕЛЕК | 262 | Документация | Криптовалютный адрес | Может использоваться для раскрытия адреса криптовалютного кошелька, связанного с доменным именем. |
| ЗОНЕМД | 63 | RFC 8976 | Дайджесты сообщений для зон DNS | Предоставляет криптографический дайджест сообщения по неактивным данным зоны DNS. |
Другие типы и псевдо-RR
[ редактировать ]Другие типы записей просто предоставляют некоторые типы информации (например, запись HINFO дает описание типа компьютера/ОС, используемого хостом), или другие возвращают данные, используемые в экспериментальных функциях. Поле «тип» также используется в протоколе для различных операций.
| Тип | Введите идентификатор. | Определение RFC | Описание | Функция |
|---|---|---|---|---|
| * | 255 | RFC 1035 [1] | Все кэшированные записи | Возвращает все записи всех типов, известные серверу имен. Если сервер имен не имеет никакой информации об имени, запрос будет перенаправлен дальше. Возвращенные записи могут быть неполными. Например, если для имени есть как A, так и MX, но сервер имен имеет в кэше только запись A, будет возвращена только запись A. Обычно обозначается как ANY (например, в dig , Windows nslookup и Wireshark ). В 2019 году RFC8482 [14] публикация стандартов привела к тому, что многие провайдеры DNS, включая Cloudflare , [15] чтобы предоставлять только минимальные ответы на «ЛЮБЫЕ» запросы вместо перечисления записей. |
| АКСФР | 252 | RFC 1035 [1] | Авторитетная передача зоны | Перенесите весь файл зоны с основного сервера имен на вторичные серверы имен. |
| IXFR | 251 | РФК 1996 г. | Поэтапная передача зоны | Запрашивает перенос данной зоны, но только отличия от предыдущего серийного номера. Этот запрос может быть проигнорирован и в ответ отправлен полный (AXFR), если авторитетный сервер не может выполнить запрос из-за конфигурации или отсутствия необходимых дельт. |
| ОПТ | 41 | RFC 6891 | Вариант | Это тип псевдозаписи, необходимый для поддержки EDNS . |
Устаревшие типы записей
[ редактировать ]Прогресс сделал некоторые из первоначально определенных типов записей устаревшими.Некоторые из записей, перечисленных в IANA, имеют ограниченное использование по разным причинам. Некоторые из них помечены в списке как устаревшие, некоторые относятся к очень малоизвестным службам, некоторые относятся к более старым версиям служб, а некоторые имеют специальные пометки о том, что они «неправильны».
| Тип | Введите идентификатор. (десятичный) | Определение RFC | Устарело | Описание |
|---|---|---|---|---|
| доктор медицинских наук | 3 | RFC 883 | RFC 973 | Записи назначения почты (MD) и пересылки почты (MF); MAILA — это не настоящий тип записи, а тип запроса, который возвращает записи MF и/или MD. RFC 973 заменил эти записи записью MX. |
| МФ | 4 | |||
| УРОВЕНЬ | 254 | |||
| МБ | 7 | RFC 883 | Формально не устарел. Вряд ли когда-либо будет принят (RFC 2505). | MB, MG, MR и MINFO — это записи для публикации списков рассылки подписчиков. MAILB — это код запроса, который возвращает одну из этих записей. Цель заключалась в том, чтобы MB и MG заменили команды SMTP VRFY и EXPN. MR должен был заменить ошибку SMTP «551 User Not Local». Позже RFC 2505 рекомендовал отключить VRFY и EXPN, что сделало MB и MG ненужными. Они были классифицированы как экспериментальные согласно RFC 1035. |
| МГ | 8 | |||
| МИСТЕР | 9 | |||
| МИНФО | 14 | |||
| ПОЧТАB | 253 | |||
| ВКС | 11 | RFC 883, RFC 1035 | Объявлен как «не заслуживающий доверия» в RFC 1123 (подробнее в RFC 1127). | Запись для описания известных сервисов, поддерживаемых хостом. На практике не используется. Текущая рекомендация и практика заключаются в том, чтобы определить, поддерживается ли служба по IP-адресу, попытавшись подключиться к нему. SMTP даже запрещено использовать записи WKS в обработке MX. [16] |
| Примечание: | 32 | RFC 1002 | Ошибки (из RFC 1002); номера теперь присвоены NIMLOC и SRV. | |
| НБСТАТ | 33 | |||
| НУЛЕВОЙ | 10 | RFC 883 | RFC 1035 | Устарело из-за RFC 1035. В RFC 883 определены «запросы завершения» (код операции 2 и, возможно, 3), которые использовали эту запись. Позже в RFC 1035 код операции 2 был переназначен на «статус», а код операции 3 зарезервирован. |
| А6 | 38 | RFC 2874 | RFC 6563 | Определен как часть раннего IPv6, но в RFC 3363 его статус понижен до экспериментального; позже рейтинг был понижен до исторического согласно RFC 6563. |
| НХТ | 30 | РФК 2065 | RFC 3755 | Часть первой версии DNSSEC (RFC 2065). NXT устарел из-за обновлений DNSSEC (RFC 3755). В то же время область применения KEY и SIG также была ограничена и не включала использование DNSSEC. |
| КЛЮЧ | 25 | |||
| СКАЗАТЬ | 24 | |||
| ИНФО | 13 | RFC 883 | Не устарел согласно RFC 8482. В настоящее время используется Cloudflare в ответ на запросы типа ANY. [17] | Запись предназначена для предоставления информации о типе процессора хоста и операционной системе. Он был предназначен для того, чтобы позволить протоколам оптимизировать обработку при общении с аналогичными узлами. |
| РП | 17 | RFC 1183 | RP может использоваться для определенной удобочитаемой информации относительно другой точки контакта для конкретного хоста, подсети или другой метки уровня домена, отличной от той, которая используется в записи SOA. | |
| Х25 | 19 | В настоящее время не используется ни одним известным приложением. | ||
| ISDN | 20 | В настоящее время не используется ни одним известным приложением. | ||
| РТ | 21 | В настоящее время не используется ни одним известным приложением. | ||
| НСАП | 22 | РФК 1706 | В настоящее время не используется ни одним известным приложением. | |
| НСАП-ПТР | 23 | В настоящее время не используется ни одним известным приложением. | ||
| ПХ | 26 | РФК 2163 | В настоящее время не используется ни одним известным приложением. | |
| ЭИД | 31 | — | Определен в Nimrod DNS интернет-проекте , но так и не получил статуса RFC. В настоящее время не используется ни одним известным приложением. | |
| НИМЛОК | 32 | — | ||
| АТМА | 34 | — | Определяется Комитетом Форума ATM. [18] | |
| АПЛ | 42 | RFC 3123 | Укажите списки диапазонов адресов, например, в формате CIDR , для различных семейств адресов. Экспериментальный. | |
| РАКОВИНА | 40 | — | Определен в Kitchen Sink интернет-проекте , но так и не получил статуса RFC. | |
| ГПОС | 27 | РФК 1712 | Более ограниченная ранняя версия записи LOC. | |
| УИНФО | 100 | — | Зарезервировано IANA, ни один RFC не документировал их [1] была прекращена , а поддержка BIND в начале 90-х. | |
| UID | 101 | — | ||
| ГИД | 102 | — | ||
| ЮНСПЕК | 103 | — | ||
| СПФ | 99 | RFC 4408 | RFC 7208 | Указывается как часть протокола SPF Framework в качестве альтернативы хранению данных SPF в записях TXT с использованием того же формата. Его поддержка была прекращена в RFC 7208 из-за повсеместного отсутствия поддержки. [19] [20] |
| НИНФО | 56 | — | Используется для предоставления информации о состоянии зоны. Запрошено для проекта IETF «Запись ресурса DNS статуса зоны (ZS)» в 2008 году. Срок действия истек без принятия. [21] | |
| RKEY | 57 | — | Используется для шифрования записей NAPTR. Запрошено для проекта IETF «Запись ресурса DNS RKEY» в 2008 году. Срок действия истек без принятия. [22] | |
| ТАЛИНК | 58 | — | Определен DNSSEC Trust Anchor History Service Интернет-проектом , но так и не получил статуса RFC. | |
| НЕТ | 104 | RFC 6742 | Не используется ни одним известным приложением и помечен как «экспериментальный». | |
| Л32 | 105 | |||
| Л64 | 106 | |||
| LP | 107 | |||
| МОЛИТВА | 259 | — | Определено DOA через DNS Internet Draft , но так и не получило статуса RFC. |
Ссылки
[ редактировать ]- ^ Перейти обратно: а б с д и ж г час я Пол Мокапетрис (ноябрь 1987 г.). «RFC 1035: Доменные имена – реализация и спецификация» . Сетевая рабочая группа IETF ( Internet Engineering Task Force ). п. 12.
- ^ «RFC 3596: Расширения DNS для поддержки IP версии 6» . Интернет-сообщество . Октябрь 2003 г. Архивировано из оригинала 14 апреля 2021 г.
- ^ RFC 2535, §3
- ^ RFC 3445, §1. «KEY RR был определен в RFC 2930...»
- ^ RFC 2931, §2.4. «SIG(0) с другой стороны, использует аутентификацию с открытым ключом, при которой открытые ключи хранятся в DNS как KEY RR, а закрытый ключ хранится у подписавшего».
- ^ RFC 3445, §1. «DNSSEC будет единственным допустимым подтипом для KEY RR…»
- ^ Перейти обратно: а б с RFC 3755, §3. «DNSKEY будет заменой KEY, с мнемоникой, указывающей, что эти ключи не предназначены для использования приложением, согласно RFC3445. RRSIG (Resource Record SIGnature) заменит SIG, а NSEC (Next SECure) заменит NXT. Эти новые типы полностью заменяют старые типы, за исключением SIG(0) RFC2931 и TKEY RFC2930, которые продолжат использовать SIG и KEY».
- ^ RFC 4025, Аннотация. «Эта запись заменяет функциональность подтипа № 4 записи ресурса KEY, которая устарела согласно RFC 3445».
- ^ Хоффман, П.; Шлайтер, Дж. (май 2017 г.). «RFC 8162 — Использование безопасного DNS для связывания сертификатов с доменными именами для S/MIME» . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC8162 . Проверено 17 октября 2018 г.
- ^ «Параметры системы доменных имен (DNS)» . Управление по присвоению номеров в Интернете . Сентябрь 2018 года . Проверено 17 октября 2018 г.
- ^ Минимальное поле записи SOA переопределено как TTL ответа NXDOMAIN в RFC 2308.
- ^ RFC 2930, §6. «... ключевой материал отправляется в поле ключевых данных записи TKEY RR, зашифрованной открытым ключом в сопроводительной записи KEY RR RFC 2535».
- ^ RFC 2845, аннотация
- ^ Дж. Эбли, Afilias, О. Гудмундссон, М. Майковски, Cloudflare Inc., Э. Хант, ISC (январь 2019 г.). «RFC 8482: Предоставление ответов минимального размера на DNS-запросы с QTYPE=ANY» . Ietf Datatracker . Рабочая группа по интернет-инжинирингу .
{{cite news}}: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ «Что произошло дальше: отказ от ЛЮБОГО» . Облачная вспышка . 16 марта 2019 года . Проверено 19 сентября 2021 г.
- ^ RFC 1123, разделы 2.2, 5.2.12, 6.1.3.6
- ^ «Что произошло дальше: отказ от ЛЮБОГО» . Облачная вспышка . 13 апреля 2016 года . Проверено 9 марта 2019 г.
- ^ «Система имен банкоматов, версия 2.0» (PDF) . Технический комитет Форума АТМ. Июль 2000 г. Архивировано из оригинала (PDF) 14 марта 2019 г. Проверено 14 марта 2019 г.
- ^ Кучерави, М. (июль 2012 г.). «История проблемы RRTYPE» . Решение проблемы структуры политики отправителей (SPF) и экспериментов с идентификаторами отправителей . IETF . сек. А. дои : 10.17487/RFC6686 . РФК 6686 . Проверено 31 августа 2013 г.
- ^ Киттерман, С. (апрель 2014 г.). «Тип записи DNS SPF» . Структура политики отправителей (SPF) для авторизации использования доменов в электронной почте, версия 1 . IETF . сек. 3.1. дои : 10.17487/RFC7208 . РФК 7208 . Проверено 26 апреля 2014 г.
- ^ Рид, Джим (4 июля 2008 г.). «draft-reid-dnsext-zs-01 — запись ресурса DNS статуса зоны (ZS)» . Ietf Datatracker . IETF . Проверено 9 марта 2019 г.
- ^ Рид, Джим; Шлитер, Якоб; Тиммс, Бен (4 июля 2008 г.). «draft-reid-dnsext-rkey-00 — запись ресурса DNS RKEY» . Ietf Datatracker . IETF . Проверено 9 марта 2019 г.
Дальнейшее чтение
[ редактировать ]- «Параметры системы доменных имен (DNS)» . Проверено 14 августа 2018 г.
- «Основы DNS – Справка администратора G Suite» . Проверено 8 ноября 2018 г.