RFC 8499 | Терминология DNS

Аннотация

Система доменных имен (DNS) определяется буквально десятками различных RFC. Терминология, используемая разработчиками и разработчиками протоколов DNS и операторами систем DNS, иногда менялась в течение десятилетий, прошедших с момента ее определения. Этот документ дает текущие определения для многих терминов, используемых в DNS в одном документе.

Этот документ устарел RFC 7719 и обновляет RFC 2308.
Скачать оригинальный документ на английском языке RFC 8499 PDF

 

Оглавление

1. Введение
2. Имена
3. Коды ответа DNS
4. Транзакции DNS
5. Ресурсные записи
6. DNS-серверы и клиенты
7. Зоны
8. Подстановочные знаки
9. Модель регистрации
10. Общие положения DNSSEC
11. Государства DNSSEC
12. Вопросы безопасности
13. Соображения IANA
14. Ссылки
14.1. Нормативные ссылки
14.2. Информационные ссылки
Приложение А. Определения, обновленные в этом документе
Приложение B. Определения, впервые определенные в этом документе
Индекс
Подтверждения
Адреса авторов

 

Статус этой заметки

Эта памятка документирует лучшую текущую практику Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о ППГ доступна в Разделе 2 RFC 7841.

Информацию о текущем статусе этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу https://www.rfc-editor.org/info/rfc8499.

 

Уведомление об авторских правах

Copyright (c) 2019 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ППГ 78 и Правовые положения IETF Trust в отношении документов IETF (https://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя текст упрощенной лицензии BSD, как описано в разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.

 

1. Введение

Система доменных имен (DNS) — это простой протокол запроса-ответа, сообщения которого в обоих направлениях имеют одинаковый формат. (Раздел 2 дает определение «общедоступного DNS», которое часто имеют в виду, когда люди говорят «DNS».) Протокол и формат сообщения определены в [RFC1034] и [RFC1035]. В этих RFC определены некоторые термины, а в более поздних документах определены другие. Некоторые термины из [RFC1034] и [RFC1035] имеют несколько иное значение, чем в 1987 году.

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

Другие организации иногда определяют термины, связанные с DNS, по-своему. Например, WHATWG определяет «домен» в <https://url.spec.whatwg.org/>. У Консультативного комитета системы корневых серверов (RSSAC) есть хорошая лексика [RSSAC026].

Большинство перечисленных здесь определений представляют собой согласованное определение сообщества DNS — как разработчиков протоколов, так и операторов. Некоторые определения отличаются от более ранних RFC, и эти различия отмечены. В этом документе, где согласованное определение совпадает с определением в RFC, этот RFC цитируется. Там, где согласованное определение несколько изменилось, упоминается RFC, но дается новое отдельное определение. См. Приложение A для списка определений, которые обновляет этот документ.

Важно отметить, что во время разработки этого документа стало ясно, что некоторые связанные с DNS термины интерпретируются разными экспертами DNS совершенно по-разному. Кроме того, некоторые термины, которые определены в ранних RFC DNS, теперь имеют определения, которые в целом согласованы, но отличаются от первоначальных определений. Следовательно, этот документ является существенным пересмотром [RFC7719].

Обратите внимание, что не существует единого согласованного определения «DNS». Это можно рассматривать как некоторую комбинацию из следующих: часто используемая схема именования объектов в Интернете; распределенная база данных, представляющая имена и определенные свойства этих объектов; архитектура, обеспечивающая распределенное обслуживание, устойчивость и слабую согласованность для этой базы данных; и простой протокол запроса-ответа (как упомянуто ниже), реализующий эту архитектуру. Раздел 2 определяет «глобальный DNS» и «частный DNS» как способ справиться с этими различными определениями.

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

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

 

2. Имена

Система именования — Naming system

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

• Состав имен
• Формат имен
• Администрирование имен
• Типы данных, которые могут быть связаны с именами
• Типы метаданных для имен
• Протокол для получения данных от имени
• Контекст для разрешения имени

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

Доменное имя — Domain name

Упорядоченный список из одной или нескольких меток.

Обратите внимание, что это определение не зависит от RFC DNS ([RFC1034] и [RFC1035]), и это определение также применимо к системам, отличным от DNS. [RFC1034] определяет «пространство доменных имен» с использованием математических деревьев и их узлов в теории графов, и это определение имеет тот же практический результат, что и определение здесь. Любой путь ориентированного ациклического графа может быть представлен доменным именем, состоящим из меток его узлов, упорядоченных по убыванию расстояния от корня (-ов) (что является нормальным соглашением в DNS, включая этот документ). Доменное имя, последняя метка которого определяет корень графа, полностью определено; другие доменные имена, чьи метки образуют строгий префикс полного доменного имени, относятся к его первому пропущенному узлу.

Также обратите внимание, что в разных документах IETF и не-IETF термин «доменное имя» использовался по-разному. Более ранние документы обычно используют «доменное имя» для обозначения «имен, которые соответствуют синтаксису в [RFC1035]», но, возможно, с дополнительными правилами, такими как «и могут быть или будут разрешены в глобальном DNS» или «но» только с использованием формата презентации «.

Метка — Label

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

Глобальный DNS — Global DNS

Используя краткий набор аспектов, перечисленных в «Системе именования», глобальный DNS можно определить следующим образом. Большинство правил здесь взяты из [RFC1034] и [RFC1035], хотя термин «глобальный DNS» до сих пор не был определен.

Состав имен: имя в глобальном DNS имеет одну или несколько меток. Длина каждой метки составляет от 0 до 63 октетов включительно. В полностью определенном доменном имени последняя метка в упорядоченном списке имеет длину 0 октетов; это единственная метка, длина которой может быть 0 октетов, и она называется «корневая» или «корневая метка». Доменное имя в глобальной DNS имеет максимальную общую длину 255 октетов в проводном формате; корень представляет один октет для этого вычисления. (Многоадресная DNS [RFC6762] допускает имена до 255 байтов плюс завершающий нулевой байт на основе другой интерпретации RFC 1035 и того, что включено в 255 октетов.)

Формат имен — Format of names

Имена в глобальном DNS являются доменными именами. Существует три формата: проводной формат, формат презентации и общий дисплей.

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

Формат представления имен в глобальном DNS представляет собой список меток, упорядоченных по убыванию расстояния от корня, закодированный как ASCII, с «.» символ между каждой меткой. В формате представления полное доменное имя включает корневую метку и соответствующую точку-разделитель. Например, в формате презентации полное доменное имя с двумя некорневыми метками всегда отображается как «example.tld». вместо «example.tld». [RFC1035] определяет метод для отображения октетов, которые не отображаются в ASCII.

Общий формат отображения используется в приложениях и произвольном тексте. Это то же самое, что и формат представления, но с отображением корневой метки и символа «.» прежде чем это необязательно и редко делается. Например, в обычном формате отображения полное доменное имя с двумя некорневыми метками обычно отображается как «example.tld» вместо «example.tld». Имена в общем формате отображения обычно пишутся так, что направленность системы письма представляет метки, уменьшая расстояние от корня (так, как на английском языке, так и на языке программирования C метка корня или домена верхнего уровня (TLD) в упорядоченном порядке). список самый правый, но на арабском языке он может быть самым левым, в зависимости от местных соглашений).

Администрирование имен  — Administration of names

Администрация определяется делегированием (см. Определение «делегирование» в разделе 7). Политики администрирования корневой зоны в глобальном DNS определяются рабочим сообществом по именам, которое собирается в интернет-корпорации по присвоению имен и номеров (ICANN). Оперативное сообщество по именам выбирает оператор функций IANA для глобальной корневой зоны DNS. На момент написания этой статьи оператором были публичные технические идентификаторы (PTI). (См. <Https://pti.icann.org/> для получения дополнительной информации о PTI, управляющем функциями IANA.) Серверы имен, обслуживающие корневую зону, предоставляются независимыми корневыми операторами. Другие зоны в глобальном DNS имеют свои собственные политики для администрирования.

Типы данных, которые могут быть связаны с именами: имя может иметь ноль или более записей ресурсов, связанных с ним. Существует множество типов записей ресурсов с уникальными структурами данных, определенными во многих различных RFC и в реестре IANA по адресу [IANA_Resource_Registry].

Типы метаданных для имен. Любое имя, опубликованное в DNS, отображается как набор записей ресурсов (см. Определение «RRset» в разделе 5). Некоторые имена сами по себе не имеют данных, связанных с ними в DNS, но в любом случае они «появляются» в DNS, поскольку они образуют часть более длинного имени, с которым связаны данные (см. Определение «пустых нетерминалов» «в разделе 7).

Протокол для получения данных от имени: Протокол, описанный в [RFC1035].

Контекст для разрешения имени: глобальная корневая зона DNS, распределенная PTI.

Частный DNS — Private DNS

Имена, которые используют протокол, описанный в [RFC1035], но не полагаются на глобальную корневую зону DNS или имена, которые в общем случае не доступны в Интернете, но используют протокол, описанный в [RFC1035]. Система может использовать как глобальную DNS, так и одну или несколько частных DNS-систем; например, см. «Разделенный DNS» в Разделе 6.

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

Многоадресный DNS (mDNS) — Multicast DNS (mDNS)

Многоадресный DNS (mDNS) предоставляет возможность выполнять DNS-подобные операции на локальной линии связи в отсутствие любого обычного одноадресного DNS-сервера. Кроме того, многоадресный DNS определяет часть пространства имен DNS как свободную. для локального использования, без необходимости вносить какую-либо ежегодную плату и без необходимости устанавливать делегирование или иным образом настраивать обычный DNS-сервер для ответа на эти имена ». (Цитируется из [RFC6762], аннотация). Несмотря на то, что он использует совместимый проводной формат, mDNS, строго говоря, отличается от протокола DNS. Кроме того, если в приведенной выше цитате написано «часть пространства имен DNS», было бы яснее сказать «часть пространства имен домена». Имена в mDNS не предназначены для поиска в DNS.

Локально обслуживаемая DNS-зона — Locally served DNS zone

Локально обслуживаемая DNS-зона является частным случаем частного DNS. Имена разрешаются с использованием протокола DNS в локальном контексте. [RFC6303] определяет поддомены IN-ADDR.ARPA, которые являются локально обслуживаемыми зонами. Разрешение имен через локально обслуживаемые зоны может привести к неоднозначным результатам. Например, одно и то же имя может разрешать разные результаты в разных локально обслуживаемых контекстах зоны DNS. Контекст для локально обслуживаемой зоны DNS может быть явным, например, перечисленным в [RFC6303] и [RFC7793], или неявным, например определенным локальной администрацией DNS и неизвестным клиенту разрешения.

Полное доменное имя (FQDN) — Fully-Qualified Domain Name (FQDN)

часто это просто ясный способ сказать то же самое, что и «доменное имя узла», как описано выше. Однако этот термин неоднозначен. Строго говоря, полное доменное имя должно включать каждую метку, включая метку нулевой длины корня: такое имя будет написано «www.example.net». (обратите внимание на завершающую точку). Но поскольку каждое имя в конечном итоге разделяет общий корень, имена часто пишутся относительно корня (например, «www.example.net») и по-прежнему называются «полностью определенными». Этот термин впервые появился в [RFC819]. В этом документе имена часто пишутся относительно корня.

Потребность в термине «полное доменное имя» возникает из-за существования частично определенных доменных имен, которые являются именами, в которых одна или несколько последних меток в упорядоченном списке опущены (например, доменное имя «www» относительно «example.net» обозначает «www.example.net»). Такие относительные имена понимаются только в контексте.

Имя хоста — Host name

Этот термин и его эквивалент, «имя хоста», широко используются, но не определены в [RFC1034], [RFC1035], [RFC1123] или [RFC2181]. Изначально DNS был развернут в среде таблиц хостов, как описано в [RFC952], и вполне вероятно, что этот термин неофициально последовал из определения, приведенного там. Со временем определение, похоже, изменилось. «Имя хоста» часто означает доменное имя, которое следует правилам в Разделе 3.5 [RFC1034], который также называется «предпочтительным синтаксисом имени». (В этом синтаксисе каждый символ в каждой метке представляет собой букву, цифру или дефис). Обратите внимание, что любая метка в доменном имени может содержать любое значение октета; Имена хостов, как правило, считаются доменными именами, где каждая метка соответствует правилам в «предпочтительном синтаксисе имени» с поправкой о том, что метки могут начинаться с цифр ASCII (эта поправка взята из Раздела 2.1 [RFC1123]).

Люди также иногда используют термин «имя хоста» для обозначения только первой метки полного доменного имени, такого как «принтер» в «printer.admin.example.com». (Иногда это формализуется в конфигурации в операционных системах.) Кроме того, люди иногда используют этот термин для описания любого имени, которое относится к машине, и они могут включать метки, которые не соответствуют «предпочтительному синтаксису имени».

Домен верхнего уровня (TLD) — Top-Level Domain (TLD)

Домен верхнего уровня — это зона, которая находится на один уровень ниже корневого, например «com» или «jp». С точки зрения DNS, в TLD нет ничего особенного. Большинство из них также являются зонами, ориентированными на делегирование (определенные в Разделе 7), и существуют серьезные политические проблемы, связанные с их работой. ДВУ часто делятся на подгруппы, такие как домены верхнего уровня с кодом страны (нДВУ), родовые домены верхнего уровня (рДВУ) и другие; разделение является вопросом политики и выходит за рамки этого документа.

Интернационализированное доменное имя (IDN) — Internationalized Domain Name (IDN)

Протокол интернационализированных доменных имен для приложений (IDNA) является стандартным механизмом для обработки доменных имен с не-ASCII символами в приложениях в DNS. Текущий стандарт на момент написания этой статьи, обычно называемый «IDNA2008», определен в [RFC5890], [RFC5891], [RFC5892], [RFC5893] и [RFC5894]. В этих документах определены многие специфические для IDN термины, такие как «метка LDH», «метка A» и «метка U». [RFC6365] определяет больше терминов, которые относятся к интернационализации (некоторые из которых относятся к IDN); В [RFC6055] гораздо более подробно обсуждаются IDN, включая некоторую новую терминологию.

Субдомен — Subdomain

Домен — это субдомен другого домена, если он содержится в этом домене. Это отношение можно проверить, посмотрев, заканчивается ли имя субдомена именем содержащего домена». (Цитируется из [RFC1034], раздел 3.1). Например, в имени хоста «nnn.mmm.example.com» оба «mmm.example.com» и «nnn.mmm.example.com» являются поддоменами «example». .com». Обратите внимание, что сравнения здесь сделаны на целых ярлыках; то есть «ooo.example.com» не является поддоменом «oo.example.com».

Псевдоним — Alias

Владелец записи ресурса CNAME или поддомен владельца записи ресурса DNAME (записи DNAME определены в [RFC6672]). Смотрите также «каноническое имя».

Каноническое имя — Canonical name

Запись ресурса CNAME «идентифицирует имя своего владельца как псевдоним и указывает соответствующее каноническое имя в разделе RDATA RR». (Цитируется из [RFC1034], раздел 3.6.2) Такое использование слова «канонический» связано с математическим понятием «каноническая форма».

CNAME

«Традиционно называть [владельца] записи CNAME« CNAME ». Это прискорбно, поскольку« CNAME »является аббревиатурой от« канонического имени »и [владельцем] записи CNAME. это, безусловно, не каноническое имя «. (Цитируется из [RFC2181], раздел 10.1.1. Цитируемый текст был изменен с «метки» на «владельца».)

 

3. Коды ответа DNS

Некоторые из кодов ответов (RCODE), которые определены в [RFC1035], получили свои собственные сокращенные имена. Все RCODE перечислены в [IANA_Resource_Registry], хотя в этом списке используется заглавная буква, а в большинстве документов используются все заглавные буквы. Некоторые из общих имен для значений, определенных в [RFC1035], описаны в этом разделе. Этот раздел также включает дополнительный RCODE и общее определение. Официальный список всех RCODE находится в реестре IANA.

NOERROR: этот RCODE отображается как «Нет ошибки» в Разделе 4.1.1 [RFC1035].

FORMERR: этот RCODE отображается как «Ошибка формата. Сервер имен не смог интерпретировать запрос» в Разделе 4.1.1 [RFC1035].

SERVFAIL: этот RCODE отображается как «Ошибка сервера — серверу имен не удалось обработать этот запрос из-за проблемы с сервером имен» в разделе 4.1.1 [RFC1035].

NXDOMAIN: этот RCODE отображается как «Ошибка имени […], этот код означает, что имя домена, на которое есть ссылка в запросе, не существует». в разделе 4.1.1 [RFC1035]. [RFC2308] установил NXDOMAIN как синоним ошибки имени.

NOTIMP: этот RCODE отображается как «Не реализовано — сервер имен не поддерживает запрашиваемый тип запроса» в Разделе 4.1.1 [RFC1035].

REFUSED: Это RCODE отображается как «Отказано» — сервер имен отказывается выполнять указанную операцию по причинам политики. Например, сервер имен может не захотеть предоставлять информацию конкретному запрашивающему, или сервер имен может не захотеть выполнять конкретная операция (например, передача зоны) для конкретных данных. » в разделе 4.1.1 [RFC1035].

NODATA: «Псевдо RCODE, который указывает, что имя является допустимым для данного класса, но [нет] записей данного типа. Ответ NODATA должен быть выведен из ответа». (Цитируется из [RFC2308], раздел 1) «NODATA обозначается ответом с RCODE, установленным в NOERROR, и отсутствием соответствующих ответов в разделе« Ответ ». В разделе« Права доступа »будет содержаться запись SOA, или там не будет записей NS. » (Цитируется из [RFC2308], раздел 2.2). Обратите внимание, что рефералы имеют формат, аналогичный ответам NODATA; [RFC2308] объясняет, как их различать.

Термин «NXRRSET» иногда используется как синоним для NODATA. Однако это ошибка, учитывая, что NXRRSET — это определенный код ошибки, определенный в [RFC2136].

Отрицательный ответ — Negative response

Ответ, который указывает, что определенный набор RR не существует или чей RCODE указывает, что сервер имен не может ответить. В разделах 2 и 7 [RFC2308] подробно описаны типы отрицательных ответов.

 

4. Транзакции DNS

Заголовок DNS-сообщения — это его первые 12 октетов. Многие из полей и флагов на диаграммах в разделах 4.1.1–4.3.3 [RFC1035] упоминаются своими именами на каждой диаграмме. Например, коды ответа называются «RCODE», данные для записи называются «RDATA», а достоверный бит ответа часто называется «флагом AA» или «битом AA».

Класс — Class

Класс «идентифицирует семейство протоколов или экземпляр протокола». (Цитируется из [RFC1034], раздел 3.6) «DNS помечает все данные как классом, так и типом, чтобы мы могли разрешить параллельное использование различных форматов для данных типа адрес». (Цитируется из [RFC1034], раздел 2.2). На практике класс почти для каждого запроса — «IN» (Интернет). Существуют некоторые запросы для «CH» (класс Chaos), но они обычно предназначены для получения информации о самом сервере, а не для адреса другого типа.

QNAME

Наиболее часто используемое грубое определение заключается в том, что QNAME — это поле в разделе «Вопрос» запроса. «Стандартный запрос задает имя целевого домена (QNAME), тип запроса (QTYPE) и класс запроса (QCLASS) и запрашивает соответствующие RR». (Цитируется из [RFC1034], раздел 3.7.1) Строго говоря, определение взято из [RFC1035], раздел 4.1.2, где QNAME определено в отношении раздела «Вопрос». Это определение, по-видимому, применяется последовательно: обсуждение обратных запросов в разделе 6.4.1 относится к «имени владельца запроса RR и его TTL», поскольку обратные запросы заполняют раздел «Ответ» и оставляют раздел «Вопрос» пустым. (Обратные запросы не рекомендуются в [RFC3425]; поэтому соответствующие определения не приводятся в этом документе.)

Однако у [RFC2308] есть альтернативное определение, которое ставит QNAME в ответ (или серию ответов) вместо запроса. Он определяет QNAME как «… имя в разделе запроса ответа или, где это разрешается в CNAME или цепочке CNAME, поле данных последнего CNAME. Последнее CNAME в этом смысле — это то, которое содержит значение который не разрешает другой CNAME. » Это определение имеет определенную внутреннюю логику из-за способа подстановки CNAME и определения CNAME. Если сервер имен не находит RRset, который соответствует запросу, но находит то же имя в том же классе, что и запись CNAME, тогда сервер имен «включает запись CNAME в ответ и перезапускает запрос с указанным именем домена. в поле данных записи CNAME. » (Цитируется из [RFC1034], раздел 3.6.2) Это делается явным образом в алгоритме разрешения, описанном в разделе 4.3.2 в [RFC1034], который говорит: «Измените QNAME на каноническое имя в CNAME RR и вернитесь к шаг 1 «в случае CNAME RR. Поскольку запись CNAME явно объявляет, что имя владельца канонически названо тем, что находится в RDATA, существует способ просмотреть новое имя (то есть имя, которое было в RDATA в записи CNAME RR) как также QNAME.

Однако это создает некоторую путаницу, поскольку ответ на запрос, который приводит к обработке CNAME, содержит в разделе отображаемых вопросов один QNAME (имя в исходном запросе) и второй QNAME, который находится в поле данных последнего CNAME. Путаница возникает из-за итеративного / рекурсивного режима разрешения, который в конечном итоге возвращает ответ, который на самом деле не должен иметь того же имени владельца, что и QNAME, содержащийся в исходном запросе.

Чтобы устранить эту потенциальную путаницу, полезно различать три значения:

• QNAME (оригинал): имя, фактически отправленное в разделе «Вопрос» в исходном запросе, которое всегда отображается в (окончательном) ответе в разделе «Вопрос», когда бит QR установлен в 1.
• QNAME (в силе): фактически разрешенное имя, которое является либо именем, которое было запрошено, либо именем, полученным в цепном ответе CNAME.
• QNAME (окончательный вариант): имя фактически разрешено, это либо имя, которое было запрошено, либо фамилия в цепном ответе CNAME.

Обратите внимание, что поскольку определение в [RFC2308] на самом деле относится к другому понятию, чем то, что было в [RFC1034], было бы лучше, если бы [RFC2308] использовал другое имя для этого понятия.

В общем случае сегодня QNAME почти всегда означает то, что определено выше как «QNAME (оригинал)».

 

Рефералы — Referrals

Тип ответа, при котором сервер, сигнализирующий о том, что он (не полностью) является полномочным для ответа, предоставляет запрашивающему преобразователю альтернативное место для отправки своего запроса. Рефералы могут быть частичными.

Направление возникает, когда сервер не выполняет рекурсивное обслуживание при ответе на запрос. Он появляется на шаге 3 (b) алгоритма в [RFC1034], раздел 4.3.2.

Существует два типа реферального ответа. Первый — это нисходящий переход (иногда описываемый как «ответ делегирования»), где сервер является полномочным для некоторой части QNAME. Раздел полномочий RDATA RRset содержит серверы имен, указанные в разрезе упомянутой зоны. При нормальной работе DNS такой ответ требуется для того, чтобы найти имена под делегацией. Само использование «реферал» означает этот вид реферала, и многие люди считают, что это единственный законный вид реферала в DNS.

Вторым является восходящий реферал (иногда называемый «корневым рефералом»), где сервер не является полномочным для какой-либо части QNAME. Когда это происходит, упомянутая зона в разделе полномочий обычно является корневой зоной («.»). При нормальной работе DNS такой ответ не требуется для разрешения или для правильного ответа на любой запрос. Не требуется, чтобы какой-либо сервер отправлял восходящих рефералов. Некоторые люди считают восходящих рефералов признаком неверной конфигурации или ошибки. Восходящие рефералы всегда нуждаются в каком-то определителе (например, «вверх» или «корень») и никогда не идентифицируются просто словом «реферал».

Ответ, имеющий только реферал, содержит пустой раздел ответов. Он содержит NS RRset для упомянутой зоны в разделе Полномочий. Он может содержать RR, которые предоставляют адреса в дополнительном разделе. Бит АА чист.

В случае, когда запрос соответствует псевдониму, и сервер не является полномочным для цели псевдонима, но является полномочным для какого-либо имени выше цели псевдонима, алгоритм разрешения выдаст ответ, который содержит оба достоверных ответа для псевдоним и реферал. Такой частичный ответ и ответ реферала содержит данные в разделе Ответ. У этого есть NS RRset для упомянутой зоны в разделе Полномочий. Он может содержать RR, которые предоставляют адреса в дополнительном разделе. Бит AA установлен, потому что первое имя в разделе «Ответ» соответствует QNAME, и сервер является ответственным за этот ответ (см. [RFC1035], раздел 4.1.1).

 

5. Ресурсные записи

РР

Аббревиатура для записи ресурса. (См. [RFC1034], раздел 3.6.)

RRset

Набор записей ресурсов «с одинаковой меткой, классом и типом, но с разными данными» (согласно [RFC2181], раздел 5). Также написано как «RRSet» в некоторых документах. В качестве пояснения «тот же ярлык» в этом определении означает «то же имя владельца». Кроме того, в [RFC2181] говорится, что «TTL всех RR в RRSet должны быть одинаковыми».

Обратите внимание, что записи ресурсов RRSIG не соответствуют этому определению. [RFC4035] говорит:

• RRset МОЖЕТ иметь несколько RRIG RR, связанных с ним. Обратите внимание, что поскольку RRSIG RR тесно связаны с наборами RR, подписи которых они содержат, RRIG RR, в отличие от всех других типов DNS RR, не образуют RRsets. В частности, значения TTL среди RRIG RR с общим именем владельца не соответствуют правилам RRset, описанным в [RFC2181].

Мастер-файл — Master file

«Мастер-файлы — это текстовые файлы, содержащие RR в текстовой форме. Поскольку содержимое зоны может быть выражено в виде списка RR, мастер-файл чаще всего используется для определения зоны, хотя его можно использовать. перечислить содержимое кэша. » (Цитируется из [RFC1035], раздел 5). Мастер-файлы иногда называют «файлами зон».

Формат представления — Presentation format

Текстовый формат, используемый в основных файлах. Этот формат показан, но формально не определен в [RFC1034] или [RFC1035]. Термин «формат представления» впервые появляется в [RFC4034].

EDNS

Механизмы расширения для DNS, определенные в [RFC6891]. Иногда называется «EDNS0» или «EDNS (0)» для обозначения номера версии. EDNS позволяет клиентам и серверам DNS указывать размеры сообщений, превышающие исходное ограничение в 512 октетов, расширять пространство кода ответа и предоставлять дополнительные параметры, которые влияют на обработку запроса DNS.

OPT

Псевдо-RR (иногда называемый «мета-RR»), который используется только для хранения управляющей информации, относящейся к последовательности вопросов и ответов конкретной транзакции. (Определение перефразировано из [RFC6891], раздел 6.1.1.) Используется EDNS.

Владелец — Owner

«Доменное имя, в котором находится RR». (Цитируется из [RFC1034], раздел 3.6) Часто встречается в термине «имя владельца».

Имена полей SOA — SOA field names

Документы DNS, включая определения здесь, часто ссылаются на поля в RDATA записи ресурса SOA по имени поля. «SOA» означает «начало зоны власти». Эти поля определены в разделе 3.3.13 [RFC1035]. Имена (в порядке их появления в SOA RDATA): MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE и MINIMUM. Обратите внимание, что значение поля MINIMUM обновлено в Разделе 4 [RFC2308]; новое определение состоит в том, что поле MINIMUM является только «TTL, который будет использоваться для отрицательных ответов». Этот документ имеет тенденцию использовать имена полей вместо терминов, которые описывают поля.

TTL

Максимальное время жизни записи ресурса. «Значение TTL — это число без знака с минимальным значением 0 и максимальным значением 2147483647. То есть максимум 2 ^ 31 — 1. При передаче это значение должно быть закодировано в менее значимых 31 битах 32-битное поле TTL с самым старшим или знаковым битом, установленным в ноль. » (Цитируется из [RFC2181], раздел 8) (Обратите внимание, что [RFC1035] ошибочно заявил, что это целое число со знаком; это было исправлено в [RFC2181].)

TTL «определяет интервал времени, в течение которого запись ресурса может быть кэширована, прежде чем снова обратиться к источнику информации». (Цитируется из [RFC1035], раздел 3.2.1) В разделе 4.1.3 того же документа говорится: «временной интервал (в секундах), в течение которого запись ресурса может быть кэширована до ее удаления». Несмотря на то, что TTL каждой записи ресурса в RRset определен для записи ресурса, он должен быть одинаковым ([RFC2181], раздел 5.2).

Причина, по которой TTL является максимальным временем жизни, заключается в том, что оператор кэша может решить сократить время жизни для оперативных целей, например, если существует политика запрета значений TTL для определенного числа. Известно, что некоторые серверы игнорируют TTL на некоторых наборах RR (например, когда авторитетные данные имеют очень короткий TTL), даже если это противоречит рекомендации в RFC 1035. RRset может быть сброшен из кэша до окончания интервала TTL в этот момент значение TTL становится неизвестным, поскольку RRset, с которым он был связан, больше не существует.

Существует также концепция «TTL по умолчанию» для зоны, которая может быть параметром конфигурации в программном обеспечении сервера. Это часто выражается значением по умолчанию для всего сервера и значением по умолчанию для зоны с использованием директивы $ TTL в файле зоны. Директива $ TTL была добавлена в формат мастер-файла [RFC2308].

Независимый от класса — Class independent

Тип записи ресурса, синтаксис и семантика которого одинаковы для каждого класса DNS. Тип записи ресурса, который не является независимым от класса, имеет разные значения в зависимости от класса DNS записи или значение не определено для некоторого класса. Большинство типов записей ресурсов определены для класса 1 (IN, Интернет), но многие не определены для других классов.

Адресные записи — Address records

Записи, тип которых A или AAAA. [RFC2181] неофициально определяет их как «(A, AAAA и т. Д.)». Обратите внимание, что новые типы адресных записей могут быть определены в будущем.

6. DNS-серверы и клиенты

В этом разделе определяются термины, используемые для систем, которые действуют как DNS-клиенты, DNS-серверы или оба. В предыдущих RFC DNS-серверы иногда называют «серверами имен», «серверами имен» или просто «серверами». Формального определения «DNS-сервер» не существует, но RFC, как правило, предполагают, что это интернет-сервер, который прослушивает запросы и отправляет ответы с использованием протокола DNS, определенного в [RFC1035], и его преемников.

Важно отметить, что термины «DNS-сервер» и «сервер имен» требуют контекста для понимания предоставляемых услуг. Как авторитетные серверы, так и рекурсивные распознаватели часто называют «DNS-серверами» и «серверами имен», даже если они выполняют разные роли (но могут быть частью одного и того же программного пакета).

Для терминологии, специфичной для общедоступной системы корневых серверов DNS, см. [RSSAC026]. В этом документе определены такие термины, как «корневой сервер», «оператор корневого сервера» и термины, которые зависят от способа обслуживания корневой зоны общедоступной DNS.

Распознаватель — Resolver

Программа, «которая извлекает информацию из серверов имен в ответ на запросы клиентов». (Цитируется из [RFC1034], раздел 2.4). Средство распознавания выполняет запросы для имени, типа и класса и получает ответы. Логическая функция называется «разрешением». На практике этот термин обычно относится к определенному типу распознавателя (некоторые из которых определены ниже), и понимание использования термина зависит от понимания контекста.

Связанным термином является «разрешение», которое формально не определено в [RFC1034] или [RFC1035]. Вмененное определение может быть «задавать вопрос, который состоит из доменного имени, класса и типа, и получать какой-то ответ». Точно так же вмененное определение «разрешения» может быть «ответом, полученным от решения».

Заглушка распознавателя — Stub resolver

Распознаватель, который не может выполнить все разрешение самостоятельно. Решатели-заглушки, как правило, зависят от рекурсивного преобразователя для выполнения функции фактического разрешения. Решатели-заглушки обсуждаются, но никогда полностью не определяются в Разделе 5.3.1 [RFC1034]. Они полностью определены в разделе 6.1.3.1 [RFC1123].

Итеративный режим — Iterative mode

Режим разрешения сервера, который получает запросы DNS и отвечает с помощью обращения к другому серверу. Раздел 2.3 [RFC1034] описывает это как «Сервер направляет клиента к другому серверу и позволяет клиенту выполнять запрос». Средство распознавания, которое работает в итеративном режиме, иногда называют «итеративным преобразователем». См. Также «итеративное разрешение» далее в этом разделе.

Рекурсивный режим — Recursive mode

Режим разрешения сервера, который получает запросы DNS и либо отвечает на эти запросы из локального кэша, либо отправляет запросы на другие серверы, чтобы получить окончательные ответы на исходные запросы. Раздел 2.3 [RFC1034] описывает это как «первый сервер выполняет запрос клиента на другом сервере». Раздел 4.3.1 [RFC1034] гласит: «в [рекурсивном] режиме сервер имен выступает в качестве распознавателя и возвращает либо ошибку, либо ответ, но не рефералы». В том же разделе также сказано:

• Рекурсивный режим возникает, когда запрос с набором RD поступает на сервер, который готов предоставить рекурсивный сервис; клиент может проверить, был ли использован рекурсивный режим, проверив, что в ответе установлены RA и RD.

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

Рекурсивный распознаватель — Recursive resolver

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

[RFC4697] попытался провести различие между рекурсивным и итеративным распознавателем.

Рекурсивный запрос — Recursive query

Запрос с битом Recursion Desired (RD), установленным в 1 в заголовке. (См. Раздел 4.1.1 [RFC1035].) Если рекурсивная служба доступна и запрашивается битом RD в запросе, сервер использует свой преобразователь для ответа на запрос. (См. Раздел 4.3.2 [RFC1034].)

Нерекурсивный запрос — Non-recursive query

Запрос с битом Recursion Desired (RD), установленным в 0 в заголовке. Сервер может отвечать на нерекурсивные запросы, используя только локальную информацию: ответ содержит либо ошибку, либо ответ, либо ссылку на какой-либо другой сервер, «ближе» к ответу. (См. Раздел 4.3.1 [RFC1034].)

Итеративное разрешение — Iterative resolution

Серверу имен может быть представлен запрос, на который может ответить только другой сервер. Два основных подхода к решению этой проблемы: «рекурсивный», при котором первый сервер выполняет запрос от имени клиента на другом сервере, и «итеративный», при котором сервер направляет клиента на другой сервер и позволяет клиенту продолжить запрос там. (См. Раздел 2.3 [RFC1034].)

В итеративном разрешении клиент многократно делает нерекурсивные запросы и следует рефералам и / или псевдонимам. Алгоритм итеративного разрешения описан в разделе 5.3.3 [RFC1034].

Полный распознаватель — Full resolver

Этот термин используется в [RFC1035], но там не определен. RFC 1123 определяет «распознаватель с полным набором услуг», который может быть, а может и не быть тем, что имел в виду «полный распознаватель» в [RFC1035]. Этот термин не определен должным образом ни в одном RFC.

Полнофункциональный распознаватель — Full-service resolver

Раздел 6.1.3.1 [RFC1123] определяет этот термин для обозначения распознавателя, который работает в рекурсивном режиме с кэшем (и отвечает другим требованиям).

Заправка — Priming

«Процесс поиска списка корневых серверов из конфигурации, в которой перечислены некоторые или все предполагаемые IP-адреса некоторых или всех этих корневых серверов». (Цитируется из [RFC8109], раздел 2). Чтобы работать в рекурсивном режиме, распознаватель должен знать адрес хотя бы одного корневого сервера. Заправка чаще всего выполняется из параметра конфигурации, который содержит список доверенных серверов для корневой зоны.

Корневые подсказки — Root hints

«Операторам, которые управляют рекурсивным распознавателем DNS, обычно требуется настроить« файл корневых ссылок ». Этот файл содержит имена и IP-адреса официальных серверов имен для корневой зоны, поэтому программное обеспечение может запустить процесс разрешения DNS. Для многих программных продуктов этот список встроен в программное обеспечение ». (Цитируется из [IANA_RootFiles]) Этот файл часто используется при заполнении.

Отрицательное кэширование — Negative caching

«Хранение знаний о том, что что-то не существует, не может или не дает ответа». (Цитируется из [RFC2308], раздел 1)

Официальный сервер — Authoritative server

«Сервер, который знает содержимое зоны DNS из локальных знаний и, таким образом, может отвечать на запросы об этой зоне, не запрашивая другие серверы». (Цитируется из [RFC2182], раздел 2). Официальный сервер назван в записи NS («сервер имен») в зоне. Это система, которая отвечает на запросы DNS с информацией о зонах, для которых она была настроена на ответ с флагом AA в заголовке ответа, установленным на 1. Это сервер, который имеет полномочия на одну или несколько зон DNS. Обратите внимание, что уполномоченный сервер может ответить на запрос без делегирования полномочий родительской зоны этому серверу. Авторитетные серверы также предоставляют «рефералов», как правило, делегированным от них дочерним зонам; эти рефералы имеют бит AA, установленный на 0, и поставляются с реферальными данными в Органе и (при необходимости) в дополнительных разделах.

Только для доверенных серверов — Authoritative-only server

Сервер имен, который обслуживает только достоверные данные и игнорирует запросы на рекурсию. Он «обычно не генерирует никаких собственных запросов. Вместо этого он отвечает на нерекурсивные запросы от итеративных распознавателей, ищущих информацию в зонах, которые он обслуживает». (Цитируется из [RFC4697], раздел 2.4). В этом случае «игнорирует запросы на рекурсию» означает «отвечает на запросы на рекурсию ответами, указывающими, что рекурсия не была выполнена».

Передача зоны — Zone transfer

Действие клиента, запрашивающего копию зоны, и уполномоченный сервер отправляет необходимую информацию. (Описание зон см. В разделе 7.) Существуют два стандартных стандартных способа переноса зон: механизм AXFR («полномочный перенос») для копирования полной зоны (описан в [RFC5936] и IXFR («инкрементный перенос»). «) механизм для копирования только тех частей зоны, которые изменились (описано в [RFC1995]). Многие системы используют нестандартные методы для переноса зоны за пределы протокола DNS.

Подчиненный сервер — Slave server

см. «Вторичный сервер».

Вторичный сервер — Secondary server

«Официальный сервер, который использует передачу зоны для извлечения зоны». (Цитируется из [RFC1996], раздел 2.1). Вторичные серверы также обсуждаются в [RFC1034]. [RFC2182] описывает вторичные серверы более подробно. Хотя ранние RFC DNS, такие как [RFC1996], называли это «ведомым», текущее общее использование перешло к тому, чтобы называть его «вторичным».

Главный сервер — Master server

см. «Основной сервер».

Основной сервер — Primary server

«Любой полномочный сервер, настроенный в качестве источника передачи зоны для одного или нескольких [вторичных] серверов». (Цитируется из [RFC1996], раздел 2.1) Или, более конкретно, [RFC2136] называет его «авторитетным сервером, настроенным в качестве источника данных AXFR или IXFR для одного или нескольких [вторичных] серверов». Первичные серверы также обсуждаются в [RFC1034]. Хотя ранние RFC DNS, такие как [RFC1996], называли это «основным», текущее общее использование сместилось на «основной».

Основной мастер — Primary master

«Основной мастер назван в поле SOA MNAME зоны и, возможно, NS RR». (Цитируется из [RFC1996], раздел 2.1) [RFC2136] определяет «основной мастер» как «Главный сервер в корне графа зависимостей AXFR / IXFR. Основной мастер назван в поле SOA MNAME зоны и, необязательно, NS RR . По определению существует только один основной главный сервер на зону. »

Идея основного мастера используется только в [RFC1996] и [RFC2136]. Современная интерпретация термина «основной мастер» — это сервер, который является полномочным для зоны и получает свои обновления для зоны из конфигурации (например, из основного файла) или из транзакций UPDATE.

Стелс-сервер — Stealth server

Это «как подчиненный сервер, за исключением того, что не указано в NS RR для зоны». (Цитируется из [RFC1996], раздел 2.1)

Скрытый мастер — Hidden master

Скрытый сервер, который является основным сервером для передачи зон. «В этом случае главный сервер имен, который обрабатывает обновления, недоступен для обычных хостов в Интернете; он не указан в NS RRset». (Цитируется из [RFC6781], раздел 3.4.3) Более ранний RFC, [RFC4641], сказал, что имя скрытого мастера «появляется в поле MNAME SOR RRs», хотя в некоторых настройках имя вообще не появляется в общедоступный DNS. Скрытый мастер также может быть вторичным сервером для самой зоны.

Пересылка — Forwarding

Процесс, когда один сервер отправляет DNS-запрос с битом RD, установленным в 1, на другой сервер для разрешения этого запроса. Пересылка является функцией DNS-преобразователя; это отличается от просто слепо ретранслирующих запросов.

[RFC5625] не дает конкретного определения для пересылки, но подробно описывает, какие функции должна поддерживать система, которая пересылает. Пересылаемые системы иногда называют «DNS-прокси», но этот термин еще не определен (даже в [RFC5625]).

Пересылка — Forwarder

Раздел 1 [RFC2308] описывает пересылку как «сервер имен, используемый для разрешения запросов вместо прямого использования авторитетной цепочки серверов имен». В [RFC2308] далее говорится: «Сервер пересылки обычно либо имеет лучший доступ к Интернету, либо поддерживает больший кэш, который может использоваться многими распознавателями». Это определение, по-видимому, указывает на то, что серверы пересылки обычно запрашивают только у уполномоченных серверов. В настоящее время, однако, серверы пересылки часто стоят между преобразователями заглушек и рекурсивными серверами. В [RFC2308] ничего не говорится о том, является ли сервер пересылки только для итераций или может ли он быть средством полного обслуживания.

Распознаватель, реализующий политику — Policy-implementing resolver

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

Открытый распознаватель — Open resolver

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

Разделенный DNS — Split DNS

Термины «split DNS» и «split-horizon DNS» давно используются сообществом DNS без формального определения. Как правило, они относятся к ситуациям, когда DNS-серверы, которые являются полномочными для определенного набора доменов, предоставляют частично или полностью разные ответы в этих доменах в зависимости от источника запроса. Результатом этого является то, что доменное имя, которое является условно глобально уникальным, тем не менее, имеет разные значения для разных пользователей сети. Иногда это может быть результатом конфигурации «просмотра», описанной ниже.

Раздел 3.8 [RFC2775] дает соответствующее определение, которое является слишком конкретным, чтобы быть в целом полезным.

Представление — View

Конфигурация для DNS-сервера, которая позволяет ему предоставлять разные ответы в зависимости от атрибутов запроса, например для «разделенного DNS». Обычно представления различаются по IP-адресу источника запроса, но могут также основываться на IP-адресе назначения, типе запроса (например, AXFR), рекурсивном и т. Д. Представления часто используются для предоставления большего количества имен или разных адресов для запросов «внутри» защищенной сети, чем для «вне» этой сети. Представления не являются стандартизированной частью DNS, но они широко применяются в серверном программном обеспечении.

Пассивный DNS — Passive DNS

Механизм сбора данных DNS путем хранения ответов DNS от серверов имен. Некоторые из этих систем также собирают DNS-запросы, связанные с ответами, хотя это вызывает некоторые проблемы конфиденциальности. Пассивные базы данных DNS могут использоваться для ответа на исторические вопросы о зонах DNS, например, какие значения присутствовали в определенный момент времени в прошлом или когда имя было обнаружено первым. Пассивные базы данных DNS позволяют искать сохраненные записи по ключам, отличным от только имени и типа, например, «найти все имена, которые имеют записи A определенного значения».

Anycast

«Практика предоставления определенного адреса службы, доступного в нескольких отдельных, автономных местоположениях, так что отправленные дейтаграммы направляются в одно из нескольких доступных местоположений». (Цитируется из [RFC4786], раздел 2). См. [RFC4786] для более подробной информации о Anycast и других терминах, специфичных для его использования.

Экземпляр — Instance

«Когда anycast-маршрутизация используется для того, чтобы несколько серверов имели один и тот же IP-адрес, каждый из этих серверов обычно называют« экземпляром »». Далее говорится: «Экземпляр сервера, такого как корневой сервер, часто называют« экземпляром Anycast »». (Цитируется из [RSSAC026])

DNS-сервер с поддержкой конфиденциальности — Privacy-enabling DNS server

«DNS-сервер, который реализует DNS по TLS [RFC7858] и может дополнительно реализовать DNS по DTLS [RFC8094]». (Цитируется из [RFC8310], раздел 2). Другие типы DNS-серверов также могут рассматриваться как обеспечивающие конфиденциальность, например, те, которые используют DNS по HTTPS [RFC8484].

7. Зоны

В этом разделе определяются термины, которые используются при обсуждении зон, которые обслуживаются или извлекаются.

Зона — Zone

«Достоверная информация организована в единицы, называемые зонами, и эти зоны могут автоматически распространяться на серверы имен, которые предоставляют избыточную услугу для данных в зоне». (Цитируется из [RFC1034], раздел 2.4)

Дочерний объект — Child

«Зарегистрированный объект, который имеет делегирование домена от Родителя». (Цитируется из [RFC7344], раздел 1.1)

Родитель — Parent

«Домен, в котором зарегистрирован ребенок». (Цитируется из [RFC7344], раздел 1.1) Ранее «родительский сервер имен» был определен в [RFC0882] как «сервер имен, который имеет полномочия на место в пространстве имен доменов, которое будет содержать новый домен». (Обратите внимание, что [RFC0882] был устаревшим в [RFC1034] и [RFC1035].) [RFC819] также содержит некоторое описание отношений между родителями и детьми.

Происхождение — Origin

Есть два разных использования этого термина:

• (a) «Доменное имя, которое появляется в верхней части зоны (чуть ниже разреза, который отделяет зону от ее родителя) … Имя зоны совпадает с именем домена в источнике зоны. » (Цитируется из [RFC2181], раздел 6). В наши дни это понятие «происхождение» и «вершина» (определено ниже) часто используются взаимозаменяемо.
• (b) Доменное имя, в пределах которого данное относительное доменное имя появляется в файлах зон. Обычно рассматривается в контексте «$ ORIGIN», который является управляющей записью, определенной в [RFC1035], раздел 5.1, как часть формата основного файла. Например, если для $ ORIGIN установлено значение «example.org.», То строка главного файла для «www» фактически является записью для «www.example.org.».

Apex

Точка в дереве у владельца SOA и соответствующего авторитетного NS RRset. Это также называется «вершина зоны». [RFC4033] определяет его как «имя на стороне ребенка в разрезе зоны». «Вершина» может рассматриваться как теоретико-информационное описание древовидной структуры, а «происхождение» — это название того же понятия, когда оно реализовано в файлах зон. Однако это различие не всегда поддерживается, и можно найти применения, которые тонко противоречат этому определению. [RFC1034] использует термин «верхний узел зоны» в качестве синонима «вершины», но этот термин широко не используется. В наши дни первое чувство «происхождение» (выше) и «вершина» часто используются взаимозаменяемо.

Срез зоны — Zone cut

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

«Зоны разделены« срезами зон ». Каждый срез зоны отделяет« дочернюю »зону (под срезом) от« родительской »зоны (над срезом)». (Цитируется из [RFC2181], раздел 6; обратите внимание, что это едва ли не демонстративное определение.) В разделе 4.2 документа [RFC1034] используются «срезы» вместо «срез зоны».

Делегирование — Delegation

Процесс, с помощью которого создается отдельная зона в пространстве имен под вершиной данного домена. Делегирование происходит, когда NS RRset добавляется в родительскую зону для дочернего источника. Делегирование по своей сути происходит при срезе зоны. Термин также обычно является существительным: новая зона, которая создается актом делегирования.

Достоверные данные — Authoritative data

«Все RR прикреплены ко всем узлам от верхнего узла зоны до конечных узлов или узлов над разрезами вокруг нижнего края зоны». (Цитируется из [RFC1034], раздел 4.2.1). Обратите внимание, что это определение может непреднамеренно привести к включению любых записей NS, которые появляются в зоне, даже тех, которые не могут быть действительно авторитетными, потому что под разрезом зоны есть идентичные записи NS NS. , Это показывает неоднозначность в понятии достоверных данных, поскольку записи NS родительской стороны достоверно указывают на делегирование, даже если они сами не являются достоверными данными.
[RFC4033], раздел 2, определяет «авторитетный RRset», который относится к достоверным данным, но имеет более точное определение.

Хромое делегирование — Lame delegation

«Хромое делегирование существует [sic], когда серверу имен делегируется ответственность за предоставление сервиса имен для зоны (посредством записей NS), но не выполняется сервис имен для этой зоны (обычно потому, что он не настроен как первичный или вторичный для зона).» (Цитируется из [RFC1912], раздел 2.8). Другое определение состоит в том, что неудачное делегирование «… происходит, когда сервер имен указан в записях NS для некоторого домена, и фактически он не является сервером для этого домена. Таким образом, запросы отправлены не на те серверы, которые ничего не знают (по крайней мере, не так, как ожидалось) о запрашиваемом домене. Более того, иногда эти хосты (если они существуют!) даже не запускают серверы имен ». (Цитируется из [RFC1713], раздел 2.3)

Склеенные записи — Glue records

«… [Ресурсные записи], которые не являются частью достоверных данных [зоны] и являются адресными записями адресов для серверов [name] [в подзонах]. Эти записи необходимы только в том случае, если имя сервера имен «ниже» среза и используются только как часть реферального ответа. » Без клея «мы можем столкнуться с ситуацией, когда NS RR говорят нам, что для того, чтобы узнать адрес сервера имен, мы должны связаться с сервером по адресу, который мы хотим узнать». (Цитируется из [RFC1034], раздел 4.2.1)

Более позднее определение состоит в том, что «клей» включает в себя любую запись в файле зоны, которая не является частью этой зоны, включая записи сервера имен делегированных подзон (записи NS), записи адреса, которые сопровождают эти записи NS (A, AAAA и т. Д.) и любые другие случайные данные, которые могут появиться. » (Цитируется из [RFC2181], раздел 5.4.1)

Хотя сегодня иногда используется клей, имея в виду это более широкое определение, контекст, окружающий определение в [RFC2181], предполагает, что он предназначен для применения клея в самом документе, а не обязательно за его пределами.

Bailiwick

«In-bailiwick» — это модификатор, описывающий сервер имен, имя которого является поддоменом или (редко) совпадает с источником в зоне, в которой содержится делегирование на сервер имен. Серверы имен in-bailiwick могут иметь склеенные записи в своей родительской зоне (используя первое из определений «склеенных записей» в приведенном выше определении). (Слово «судебный пристав» означает район или территорию, где юрисдикция судебного пристава или полицейского).

Имена «in-bailiwick» подразделяются на два типа имен для серверов имен: имена «in-domain» и имена «sibling domain».

• In-domain: модификатор, описывающий сервер имен, имя которого подчинено или (редко) совпадает с именем владельца записей ресурсов NS. Имя сервера имен в домене должно иметь склеенные записи, иначе разрешение имен не удается. Например, делегирование для «child.example.com» может иметь «доменное» имя сервера имен «ns.child.example.com».
• Родственный домен: имя сервера имен, которое подчинено или (редко) совпадает с источником зоны и не подчиняется или совпадает с именем владельца записей ресурсов NS. Склеивать записи для родственных доменов разрешено, но не обязательно. Например, делегирование для «child.example.com» в зоне «example.com» может иметь «одноуровневое» имя сервера имен «ns.another.example.com».

«Out-of-bailiwick» является антонимом «in-bailiwick». Это модификатор для описания сервера имен, чье имя не подчинено или не совпадает с источником зоны. Склеивать записи для серверов имен, не входящих в систему, бесполезно. В следующей таблице приведены примеры типов делегирования.

Корневая зона — Root zone

Зона дерева на основе DNS, вершиной которого является метка нулевой длины. Также иногда называется «корень DNS».

Пустые нетерминалы (ENT) — Empty non-terminals (ENT)

«Доменные имена, которые не имеют записей ресурсов, но имеют поддомен, которые имеют». (Цитируется из [RFC4592], раздел 2.2.2) Типичный пример — записи SRV: в имени «_sip._tcp.example.com» вполне вероятно, что «_tcp.example.com» не имеет RRsets, но это «_sip._tcp.example.com» имеет (как минимум) набор SRV RRset.

Зона делегирования — Delegation-centric zone

Зона, состоящая в основном из делегаций в дочерних зонах. Этот термин используется в отличие от зоны, которая может иметь некоторые делегирования дочерним зонам, но также имеет много записей ресурсов данных для самой зоны и / или для дочерних зон. Этот термин используется в [RFC4956] и [RFC5155], но он не определен ни в одном документе.

Окклюзивное имя — Occluded name

«Добавление точки делегирования посредством динамического обновления приведет к тому, что все подчиненные доменные имена будут находиться в подвешенном состоянии, все еще являясь частью зоны, но недоступной для процесса поиска. Добавление записи ресурса DNAME оказывает такое же влияние. Подчиненные имена называются «окклюзированными». (Цитируется из [RFC5936], раздел 3.5)

Fast flux DNS

Это «происходит, когда домен [найден] в DNS с использованием записей A для нескольких IP-адресов, с каждым из которых связано очень короткое значение времени жизни (TTL). Это означает, что домен разрешается на различные IP-адреса в течение короткого периода времени. » (Цитируется из [RFC6561], раздел 1.1.5, с опечаткой, исправленной). В дополнение к законному использованию, DNS-сервер fast flux может использоваться для доставки вредоносных программ. Поскольку адреса меняются так быстро, сложно определить все хосты. Следует отметить, что этот метод также работает с записями AAAA, но такое использование не часто наблюдается в Интернете на момент написания этой статьи.

Обратный DNS, обратный поиск — Reverse DNS, reverse lookup

«Процесс преобразования адреса в имя обычно известен как« обратный поиск », а зоны IN-ADDR.ARPA и IP6.ARPA поддерживают« обратный DNS »». (Цитируется из [RFC5855], раздел 1)

Прямой поиск — Forward lookup

«Преобразование имени хоста в адрес». (Цитируется из [RFC3493], раздел 6)

arpa

Домен области адресов и параметров маршрутизации: «Домен arpa был первоначально создан как часть первоначального развертывания DNS, чтобы обеспечить механизм перехода от таблиц хостов, которые были распространены в ARPANET, а также как дом для домен обратного сопоставления IPv4. В 2000 году аббревиатура была переименована в «Область параметров адреса и маршрутизации» в надежде уменьшить путаницу с более ранним именем сети ». (Цитируется из [RFC3172], раздел 2) .arpa — это «инфраструктурный домен», домен, «роль которого заключается в поддержке операционной инфраструктуры Интернета». (Цитируется из [RFC3172], раздел 2). См. [RFC3172] для более подробной истории этого имени.

Имя службы — Service name

«Имена служб являются уникальным ключом в реестре имени службы и номера порта транспортного протокола. Это уникальное символическое имя для службы также может использоваться для других целей, таких как записи DNS SRV». (Цитируется из [RFC6335], раздел 5)

 

8. Подстановочные знаки

Подстановочный знак — Wildcard

[RFC1034] определил «подстановочный знак», но таким образом, который оказался непонятным для разработчиков. Расширенное обсуждение подстановочных знаков, включая более четкие определения, см. В [RFC4592]. Особый режим предоставляется РР с именами владельцев, начинающимися с метки «*». «Такие RR называются« подстановочными знаками ». Подстановочные знаки RR можно рассматривать как инструкции для синтеза RR». (Цитируется из [RFC1034], раздел 4.3.3)

Метка звездочки — Asterisk label

«Первый октет — это нормальный тип и длина метки для метки длиной в 1 октет, а второй октет — представление ASCII [RFC20] для символа« * ». Описательное имя метки, равное этому значению является «звездочкой». » (Цитируется из [RFC4592], раздел 2.1.1)

Доменное имя с подстановочными знаками — Wildcard domain name

«Доменное имя с подстановочными знаками» определяется по начальной (т. Е. Самой левой или наименее значимой) метке в двоичном формате: 0000 0001 0010 1010 (двоичный) = 0x01 0x2a (шестнадцатеричный). (Цитируется из [RFC4592], раздел 2.1.1) Второй октет в этой метке является ASCII-представлением для символа «*».

Ближайший кодировщик — Closest encloser

«Самый длинный существующий предок имени». (Цитируется из [RFC5155], раздел 1.3). Более раннее определение: «Узел в дереве зон существующих доменных имен, который имеет наибольшее количество меток, соответствующих имени запроса (последовательно, начиная с корневой метки вниз). Каждое совпадение представляет собой ‘ label match ‘и порядок меток одинаков. » (Цитируется из [RFC4592], раздел 3.3.1)

Ближайший доказуемый кодировщик — Closest provable encloser

Самый длинный предок имени, о котором можно доказать, что он существует. Обратите внимание, что он отличается только от ближайшего кодировщика в зоне отказа». (Цитируется из [RFC5155], раздел 1.3). См. Раздел 10 для получения дополнительной информации об отказе от участия.

Следующее более близкое имя — Next closer name

«Имя на одну метку длиннее, чем ближайший доказуемый кодировщик имени». (Цитируется из [RFC5155], раздел 1.3)

Источник синтеза — Source of Synthesis

Источник синтеза определен в контексте процесса запроса как это доменное имя с подстановочными знаками, которое немедленно нисходит от ближайшего кодировщика, при условии, что это доменное имя с подстановочными знаками существует. Сразу же убывает »означает, что источник синтеза имеет имя формы: <метка звездочки>. <ближайший кодировщик>. » (Цитируется из [RFC4592], раздел 3.3.1)

9. Модель регистрации

Реестр — Registry

Административная операция зоны, которая позволяет регистрировать имена в этой зоне. Люди часто используют этот термин для обозначения только тех организаций, которые осуществляют регистрацию в больших зонах, ориентированных на делегирование (например, ДВУ); но формально тот, кто решает, какие данные попадают в зону, является реестром для этой зоны. Это определение «реестра» с точки зрения DNS; для некоторых зон политики, определяющие, что может происходить в зоне, определяются зонами, которые являются подчиненными, а не оператором реестра.

Регистрант — Registrant

Физическое или юридическое лицо, от имени которого в реестре зарегистрировано имя в зоне. Во многих зонах реестр и владелец регистрации могут быть одним и тем же объектом, но в TLD они часто не являются.

Регистратор — Registrar

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

EPP

Расширяемый протокол обеспечения (EPP), который обычно используется для передачи регистрационной информации между реестрами и регистраторами. EPP определен в [RFC5730].

WHOIS

Протокол, указанный в [RFC3912], часто используемый для запросов к базам данных реестра. Данные WHOIS часто используются для связи регистрационных данных (таких как контакты управления зонами) с доменными именами. Термин «данные WHOIS» часто используется как синоним базы данных реестра, хотя эта база данных может обслуживаться различными протоколами, в частности RDAP. Протокол WHOIS также используется с данными реестра IP-адресов.

RDAP

Протокол доступа к регистрационным данным, определенный в [RFC7480], [RFC7481], [RFC7482], [RFC7483], [RFC7484] и [RFC7485]. Протокол RDAP и формат данных предназначены для замены WHOIS.

Оператор DNS — DNS operator

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

Открытый суффикс — Public suffix

«Домен, который контролируется общедоступным реестром». (Цитируется из [RFC6265], раздел 5.3). Общим определением для этого термина является домен, в котором субдомены могут быть зарегистрированы третьими сторонами и для которых не следует устанавливать файлы cookie HTTP (которые подробно описаны в [RFC6265]). В доменном имени нет указания, является ли это общедоступным суффиксом; это может быть определено только с помощью внешних средств. Фактически, и домен, и поддомен этого домена могут быть общедоступными суффиксами.

В имени домена нет ничего, что указывало бы, является ли оно общедоступным суффиксом. Одним из ресурсов для определения общедоступных суффиксов является общедоступный список суффиксов (PSL), поддерживаемый Mozilla (http://publicsuffix.org/).

Например, во время публикации этого документа домен «com.au» указан как открытый суффикс в PSL. (Обратите внимание, что этот пример может измениться в будущем.)

Обратите внимание, что термин «общедоступный суффикс» является спорным в сообществе DNS по многим причинам, и в будущем он может значительно измениться. Одним из примеров сложности называния домена общедоступным суффиксом является то, что назначение может со временем меняться при изменении политики регистрации зоны, как, например, в случае с доменом верхнего уровня «uk» в 2014 году.

Подчиненный и подчиненный — Subordinate and Superordinate

Эти термины введены в [RFC5731] для использования в модели регистрации, но не определены там. Вместо этого они приведены в примерах. «Например, имя домена« example.com »имеет отношение подчиненного к имени узла ns1.example.com». Например, узел ns1.example1.com является подчиненным узлом домена example1.com, но это не подчиненный хост домена example2.com. » (Цитируется из [RFC5731], раздел 1.1). Эти термины являются строго способами ссылки на отношения двух доменов, где один является поддоменом другого.

10. Общие положения DNSSEC

Большинство терминов DNSSEC определены в [RFC4033], [RFC4034], [RFC4035] и [RFC5155]. Термины, которые вызвали путаницу в сообществе DNS, выделены здесь.

DNSSEC-осведомленный и DNSSEC-неосведомленный — DNSSEC-aware and DNSSEC-unaware

Эти два термина, которые используются в некоторых RFC, не были формально определены. Однако в разделе 2 [RFC4033] определяются многие типы распознавателей и валидаторов, в том числе «не проверяющий преобразователь заглушки с поддержкой безопасности», «не проверяющий преобразователь заглушки», «сервер имен с поддержкой безопасности», «рекурсивное имя с поддержкой безопасности» сервер «,» распознаватель безопасности с поддержкой «,» распознаватель заглушки с учетом безопасности «и» игнорирующее безопасность «что-нибудь» («non-validating security-aware stub resolver», «non-validating stub resolver», «security-aware name server», «security-aware recursive name server», «security-aware resolver», «security-aware stub resolver», and «security-oblivious ’anything’»).

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

Зона со знаком — Signed zone

«Зона, RRsets которой подписаны и которая содержит правильно сконструированный DNSKEY, подпись записи ресурса (RRSIG), Next Secure (NSEC) и (необязательно) записи DS». (Цитируется из [RFC4033], раздел 2). В других контекстах было отмечено, что сама зона на самом деле не подписана, но все соответствующие наборы RR в зоне подписаны. Тем не менее, если зона, которая должна быть подписана, содержит наборы RR, которые не подписаны (или отключены), эти наборы RR будут рассматриваться как поддельные, поэтому вся зона должна обрабатываться каким-либо образом.

Следует также отметить, что со времени публикации [RFC6840] записи NSEC больше не требуются для подписанных зон: подписанная зона может вместо этого включать записи NSEC3. [RFC7129] предоставляет дополнительные исходные комментарии и некоторый контекст для механизмов NSEC и NSEC3, используемых DNSSEC для предоставления аутентифицированных ответов отказа в существовании. NSEC и NSEC3 описаны ниже.

Зона без подписи — Unsigned zone

В разделе 2 [RFC4033] это определяется как «зона, которая не подписана». Раздел 2 [RFC4035] определяет это как «зону, которая не включает в себя эти записи [правильно построенный DNSKEY, подпись записи ресурса (RRSIG), Next Secure (NSEC) и (необязательно) записи DS] в соответствии с правилами в этом разделе … »В конце Раздела 5.2 [RFC4035] имеется важное примечание, в котором определяется дополнительная ситуация, в которой зона считается неподписанной:« Если распознаватель не поддерживает ни один из алгоритмов, перечисленных в аутентифицированном DS RRset, тогда распознаватель не сможет проверить путь аутентификации к дочерней зоне. В этом случае распознаватель ДОЛЖЕН обращаться с дочерней зоной, как если бы она была без знака. »

NSEC

«Запись NSEC позволяет распознавателю, осведомленному о безопасности, аутентифицировать отрицательный ответ для несуществования имени или типа с теми же механизмами, которые используются для аутентификации других ответов DNS». (Цитируется из [RFC4033], раздел 3.2) Короче говоря, запись NSEC обеспечивает аутентифицированное отрицание существования.

«В записи ресурса NSEC перечислены две отдельные вещи: имя следующего владельца (в каноническом порядке зоны), которое содержит достоверные данные, или точка делегирования NS RRset, и набор типов RR, присутствующих в имени владельца NSEC RR». (Цитируется из Раздела 4 RFC 4034)

NSEC3

Как и запись NSEC, запись NSEC3 также обеспечивает аутентифицированное отрицание существования; однако записи NSEC3 уменьшают перечисление зон и поддерживают возможность отказа. Записи ресурсов NSEC3 требуют соответствующих записей ресурсов NSEC3PARAM. Записи ресурсов NSEC3 и NSEC3PARAM определены в [RFC5155].

Обратите внимание, что в [RFC6840] говорится, что [RFC5155] «теперь считается частью семейства документов безопасности DNS, как описано в разделе 10 [RFC4033]». Это означает, что некоторые определения из более ранних RFC, в которых говорится только о записях НСЕК, вероятно, следует рассматривать как о НСЕК и НСЕК3.

Отказ — Opt-out

«Флаг отказа указывает, может ли этот RR NSEC3 охватывать неподписанные делегации». (Цитируется из [RFC5155], раздел 3.1.2.1) Отказ от участия решает высокую стоимость обеспечения безопасности делегации в небезопасной зоне. При использовании Opt-Out для имен, которые являются небезопасным делегированием (и пустыми нетерминалами, которые получены только из небезопасных делегаций), не требуется запись NSEC3 или соответствующие ей записи RRSIG. Отказные записи NSEC3 не могут доказать или опровергнуть существование небезопасных делегаций. (Адаптировано из [RFC7129], раздел 5.1)

Небезопасное делегирование — Insecure delegation

«Подписанное имя, содержащее делегирование (NS RRset), но без DS RRset, означающее делегирование в неподписанную подзону». (Цитируется из [RFC4956], раздел 2)

Перечисление зоны — Zone enumeration

«Практика обнаружения полного содержимого зоны с помощью последовательных запросов». (Цитируется из [RFC5155], раздел 1.3) Это также иногда называют «зонной ходьбой». Перечисление зоны отличается от предположения о содержании зоны, когда гадатель использует большой словарь возможных меток и отправляет для них последовательные запросы или сопоставляет содержимое записей NSEC3 с таким словарем.

Валидация. Валидация в контексте DNSSEC относится к одному из следующих:

• Проверка достоверности подписей DNSSEC,
• Проверка достоверности ответов DNS, таких как те, которые включают аутентифицированный отказ в существовании, или
• Создание цепочки аутентификации от привязки доверия к ответу DNS или отдельным наборам DNS RR в ответе.

Первые два определения, приведенные выше, рассматривают только достоверность отдельных компонентов DNSSEC, таких как достоверность RRSIG или достоверность доказательства NSEC. Третье определение рассматривает компоненты всей цепочки аутентификации DNSSEC; таким образом, он требует «сконфигурированного знания по меньшей мере одного аутентифицированного DNSKEY или DS RR» (как описано в [RFC4035], раздел 5).

[RFC4033], Раздел 2, говорит, что «Проверка заглушки с поддержкой безопасности … выполняет проверку подписи» и использует доверительный якорь «в качестве отправной точки для построения цепочки аутентификации для подписанного ответа DNS»; таким образом, он использует первое и третье определения выше. Процесс проверки записи ресурса RRSIG описан в [RFC4035], раздел 5.3.

[RFC5155] относится к проверке ответов по всему документу в контексте хешированного аутентифицированного отказа в существовании; это использует второе определение выше.

Термин «аутентификация» используется взаимозаменяемо с «валидацией» в смысле третьего определения, приведенного выше. [RFC4033], раздел 2, описывает цепочку, связывающую доверительный якорь с данными DNS как «цепочку аутентификации». Ответ считается подлинным, если «все наборы RR в разделах Ответ и Полномочия ответа [считаются] подлинными» (цитируется по [RFC4035]). Данные или ответы DNS, которые считаются подлинными или проверенными, имеют статус безопасности: «безопасный» ([RFC4035], раздел 4.3; [RFC4033], раздел 5). «Аутентификация как ключей, так и данных DNS является вопросом локальной политики, которая может расширять или даже переопределять расширения протокола [DNSSEC] …» (Цитируется из [RFC4033], раздел 3.1)

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

Проверка распознавателя — Validating resolver

Рекурсивный сервер имен с поддержкой безопасности, распознаватель безопасности и преобразователь заглушки с учетом безопасности, который применяет по крайней мере одно из определений проверки (см. Выше) в зависимости от контекста разрешения. По той же причине, по которой общий термин «распознаватель» иногда является неоднозначным и должен оцениваться в контексте (см. Раздел 6), «проверка распознавателя» является контекстно-зависимым термином.

Ключ подписи ключа (KSK) — Key signing key (KSK)

Ключи DNSSEC, которые «только подписывают набор apex DNSKEY RRset в зоне». (Цитируется из [RFC6781], раздел 3.1)

Ключ подписи зоны (ZSK) — Zone signing key (ZSK)

«Ключи DNSSEC, которые можно использовать для подписи всех наборов RR в зоне, для которой требуются подписи, кроме набора DNSKEY RRset.» (Цитируется из [RFC6781], раздел 3.1). Также обратите внимание, что иногда ZSK используется для подписи набора RK DNSKEY apex.

Комбинированный ключ подписи (CSK) — Combined signing key (CSK)

«В тех случаях, когда различие между KSK и ZSK не проводится, т. Е. Когда ключи играют роль как KSK, так и ZSK, мы говорим о схеме подписания одного типа». (Цитируется из [RFC6781], раздел 3.1). Это иногда называют «комбинированным ключом подписи» или «CSK». Это операционная практика, а не протокол, который определяет, является ли конкретный ключ ZSK, KSK или CSK.

Безопасная точка входа (SEP) — Secure Entry Point (SEP)

Флаг в DNSKEY RDATA, который «можно использовать для различения ключей, которые предназначены для использования в качестве безопасной точки входа в зону при построении цепочек доверия, т. Е. Они есть (будут) указывает на родительские записи DS DS или настроен как якорь доверия …. Поэтому предлагается установить флаг SEP для ключей, которые используются в качестве KSK, а не для ключей, которые используются в качестве ZSK, тогда как в тех случаях, когда различие между KSK и ZSK не проводится (т. е. для схемы подписи одного типа), предлагается установить флаг SEP на всех ключах ». (Цитируется из [RFC6781], раздел 3.2.3). Обратите внимание, что флаг SEP является только подсказкой, и его наличие или отсутствие не может использоваться для дисквалификации данного RR DNSKEY от использования в качестве KSK или ZSK во время проверки.

Первоначальное определение СЭП было в [RFC3757]. Это определение ясно указывает на то, что СЭП является ключом, а не просто ключом к ключу. Аннотация [RFC3757] гласит: «С помощью записи ресурса (RR) лица, подписывающего делегацию (RR), была введена концепция открытого ключа, действующего как защищенная точка входа (SEP). Во время обмена открытыми ключами с родителем существует необходимо отличать ключи SEP от других открытых ключей в наборе записей ресурсов KEY (DNSKEY) системы доменных имен. Бит флага в RR DNSKEY определен, чтобы указать, что DNSKEY должен использоваться в качестве SEP. » Это определение SEP как ключа было сделано устаревшим [RFC4034], а определение из [RFC6781] соответствует [RFC4034].

Якорь доверия — Trust anchor

«Сконфигурированный хэш DNSKEY RR или DS RR DNSKEY RR. Проверяющий распознающий распознаватель использует этот открытый ключ или хеш в качестве отправной точки для построения цепочки аутентификации для подписанного ответа DNS. В общем, проверяющий распознаватель придется получать начальные значения своих якорей доверия с помощью некоторых безопасных или доверенных средств вне протокола DNS. » (Цитируется из [RFC4033], раздел 2)

Политика DNSSEC (DP) — DNSSEC Policy (DP)

Утверждение, которое «устанавливает требования и стандарты безопасности, которые должны быть реализованы для зоны, подписанной DNSSEC». (Цитируется из [RFC6841], раздел 2)

Практическое заявление DNSSEC (DPS) — DNSSEC Practice Statement (DPS)

«Документ с описанием практики, который может поддерживать и быть дополнительным документом к Политике DNSSEC (если таковой существует), и в нем говорится, как управление данной зоной реализует процедуры и средства контроля на высоком уровне». (Цитируется из [RFC6841], раздел 2)

Модуль аппаратного обеспечения безопасности (HSM) — Hardware security module (HSM)

специализированный аппаратный модуль, который используется для создания ключей для подписей и для подписи сообщений без раскрытия секретного ключа. В DNSSEC HSM часто используются для хранения закрытых ключей для KSK и ZSK, а также для создания подписей, используемых в записях RRSIG через определенные промежутки времени.

Программное обеспечение для подписи — Signing software

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

11. Государства DNSSEC

Проверяющий распознаватель может определить, что ответ находится в одном из четырех состояний: безопасное, небезопасное, поддельное или неопределенное. Эти состояния определены в [RFC4033] и [RFC4035], хотя определения в этих двух документах немного отличаются. В этом документе не предпринимается никаких усилий для согласования определений в двух документах и не принимается во внимание необходимость их согласования.

Раздел 5 [RFC4033] гласит:

Проверяющий распознаватель (validating resolver) может определить следующие 4 состояния:

• Безопасный (Secure): проверяющий распознаватель имеет привязку доверия, цепочку доверия и может проверять все подписи в ответе.
• Небезопасный (Insecure): проверяющий распознаватель имеет привязку доверия, цепочку доверия и, в какой-то момент делегирования, подписанное доказательство отсутствия записи DS. Это указывает на то, что последующие ветви в дереве доказуемо небезопасны. Проверяющий распознаватель может иметь локальную политику, помечающую части пространства домена как незащищенные.
• Поддельный (Bogus): проверяющий распознаватель имеет привязку доверия и безопасное делегирование, указывающее, что вспомогательные данные подписаны, но по какой-то причине ответ не проходит проверку: отсутствуют подписи, просрочены подписи, подписи с неподдерживаемыми алгоритмами, отсутствуют данные, которые, по словам соответствующих РР НСЕК, должны присутствовать и так далее.
• Неопределенный (Indeterminate): нет привязки доверия, которая указала бы, что определенная часть дерева безопасна. Это режим работы по умолчанию.

Раздел 4.3 [RFC4035] гласит:

Защитный распознаватель должен уметь различать четыре случая:

• Безопасный (Secure): RRset, для которого распознаватель может построить цепочку подписанных DNSREY и DS RR из надежного привязки безопасности к RRset. В этом случае RRset должен быть подписан и подлежит проверке подписи, как описано выше.
• Небезопасный (Insecure): RRset, для которого распознаватель знает, что у него нет цепочки подписанных RR DNSKEY и DS от какой-либо доверенной начальной точки до RRset. Это может произойти, когда целевой набор RR находится в неподписанной зоне или в потомке [sic] неподписанной зоны. В этом случае RRset может быть или не быть подписанным, но распознаватель не сможет проверить подпись.
• Поддельный (Bogus): набор RR, для которого резолвер считает, что он должен иметь возможность установить цепочку доверия, но для которого он не может этого сделать, либо из-за подписей, которые по какой-то причине не могут быть проверены, либо из-за отсутствия данных, которые релевантны DNSSEC RR указывают, должны присутствовать. Этот случай может указывать на атаку, но также может указывать на ошибку конфигурации или некоторую форму повреждения данных.
• Неопределенный (Indeterminate): RRset, для которого распознаватель не может определить, должен ли RRset быть подписан, так как распознаватель не может получить необходимые RSS DNSSEC. Это может произойти, когда распознаватель безопасности не может связаться с серверами имен с поддержкой безопасности для соответствующих зон.

12. Вопросы безопасности

Эти определения не изменяют никаких соображений безопасности для DNS.

13. Соображения IANA

В этом документе нет действий IANA.

14. Ссылки

14.1. Нормативные ссылки

[IANA_RootFiles] IANA, «Root Files», <https://www.iana.org/domains/root/files>.

[RFC0882] Mockapetris, P., «Domain names: Concepts and facilities», RFC 882, DOI 10.17487/RFC0882, November 1983,
<https://www.rfc-editor.org/info/rfc882>.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC1123] Braden, R., Ed., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989,
<https://www.rfc-editor.org/info/rfc1123>.

[RFC1912] Barr, D., «Common DNS Operational and Configuration Errors», RFC 1912, DOI 10.17487/RFC1912, February 1996,
<https://www.rfc-editor.org/info/rfc1912>.

[RFC1996] Vixie, P., «A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)», RFC 1996, DOI 10.17487/RFC1996,
August 1996, <https://www.rfc-editor.org/info/rfc1996>.

[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, «Dynamic Updates in the Domain Name System (DNS UPDATE)», RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.

[RFC2181] Elz, R. and R. Bush, «Clarifications to the DNS Specification», RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.

[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, «Selection and Operation of Secondary DNS Servers», BCP 16, RFC 2182, DOI 10.17487/RFC2182, July 1997,
<https://www.rfc-editor.org/info/rfc2182>.

[RFC2308] Andrews, M., «Negative Caching of DNS Queries (DNS NCACHE)», RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for the DNS Security Extensions», RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.

[RFC4592] Lewis, E., «The Role of Wildcards in the Domain Name System», RFC 4592, DOI 10.17487/RFC4592, July 2006,
<https://www.rfc-editor.org/info/rfc4592>.

[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, «DNS Security (DNSSEC) Hashed Authenticated Denial of Existence», RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>.

[RFC5358] Damas, J. and F. Neves, «Preventing Use of Recursive Nameservers in Reflector Attacks», BCP 140, RFC 5358, DOI 10.17487/RFC5358, October 2008,
<https://www.rfc-editor.org/info/rfc5358>.

[RFC5730] Hollenbeck, S., «Extensible Provisioning Protocol (EPP)», STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.

[RFC5731] Hollenbeck, S., «Extensible Provisioning Protocol (EPP) Domain Name Mapping», STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009,
<https://www.rfc-editor.org/info/rfc5731>.

[RFC5855] Abley, J. and T. Manderson, «Nameservers for IPv4 and IPv6 Reverse Zones», BCP 155, RFC 5855, DOI 10.17487/RFC5855,
May 2010, <https://www.rfc-editor.org/info/rfc5855>.

[RFC5936] Lewis, E. and A. Hoenes, Ed., «DNS Zone Transfer Protocol (AXFR)», RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.

[RFC6561] Livingood, J., Mody, N., and M. O’Reirdan, «Recommendations for the Remediation of Bots in ISP Networks», RFC 6561, DOI 10.17487/RFC6561, March 2012,
<https://www.rfc-editor.org/info/rfc6561>.

[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, «DNSSEC Operational Practices, Version 2», RFC 6781, DOI 10.17487/RFC6781, December 2012,
<https://www.rfc-editor.org/info/rfc6781>.

[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., «Clarifications and Implementation Notes for DNS Security (DNSSEC)», RFC 6840, DOI 10.17487/RFC6840, February 2013,
<https://www.rfc-editor.org/info/rfc6840>.

[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, «A Framework for DNSSEC Policies and DNSSEC Practice Statements», RFC 6841, DOI 10.17487/RFC6841, January 2013,
<https://www.rfc-editor.org/info/rfc6841>.

[RFC6891] Damas, J., Graff, M., and P. Vixie, «Extension Mechanisms for DNS (EDNS(0))», STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.

[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, «Automating DNSSEC Delegation Trust Maintenance», RFC 7344, DOI 10.17487/RFC7344, September 2014,
<https://www.rfc-editor.org/info/rfc7344>.

[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, «DNS Terminology», RFC 7719, DOI 10.17487/RFC7719, December
2015, <https://www.rfc-editor.org/info/rfc7719>.

[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, «Usage Profiles for DNS over TLS and DNS over DTLS», RFC 8310, DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>.

14.2. Информационные ссылки

[IANA_Resource_Registry] IANA, «Resource Record (RR) TYPEs», <https://www.iana.org/assignments/dns-parameters/>.

[RFC819] Su, Z. and J. Postel, «The Domain Naming Convention for Internet User Applications», RFC 819, DOI 10.17487/RFC0819, August 1982,
<https://www.rfc-editor.org/info/rfc819>.

[RFC952] Harrenstien, K., Stahl, M., and E. Feinler, «DoD Internet host table specification», RFC 952, DOI 10.17487/RFC0952,
October 1985, <https://www.rfc-editor.org/info/rfc952>.

[RFC1713] Romao, A., «Tools for DNS debugging», FYI 27, RFC 1713, DOI 10.17487/RFC1713, November 1994,
<https://www.rfc-editor.org/info/rfc1713>.

[RFC1995] Ohta, M., «Incremental Zone Transfer in DNS», RFC 1995, DOI 10.17487/RFC1995, August 1996,
<https://www.rfc-editor.org/info/rfc1995>.

[RFC2775] Carpenter, B., «Internet Transparency», RFC 2775, DOI 10.17487/RFC2775, February 2000,
<https://www.rfc-editor.org/info/rfc2775>.

[RFC3172] Huston, G., Ed., «Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain («arpa»)», BCP 52, RFC 3172, DOI 10.17487/RFC3172,
September 2001, <https://www.rfc-editor.org/info/rfc3172>.

[RFC3425] Lawrence, D., «Obsoleting IQUERY», RFC 3425, DOI 10.17487/RFC3425, November 2002,
<https://www.rfc-editor.org/info/rfc3425>.

[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, «Basic Socket Interface Extensions for IPv6», RFC 3493, DOI 10.17487/RFC3493, February 2003,
<https://www.rfc-editor.org/info/rfc3493>.

[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, «Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag», RFC 3757, DOI 10.17487/RFC3757, April
2004, <https://www.rfc-editor.org/info/rfc3757>.

[RFC3912] Daigle, L., «WHOIS Protocol Specification», RFC 3912, DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>.

[RFC4641] Kolkman, O. and R. Gieben, «DNSSEC Operational Practices», RFC 4641, DOI 10.17487/RFC4641, September 2006,
<https://www.rfc-editor.org/info/rfc4641>.

[RFC4697] Larson, M. and P. Barber, «Observed DNS Resolution Misbehavior», BCP 123, RFC 4697, DOI 10.17487/RFC4697,
October 2006, <https://www.rfc-editor.org/info/rfc4697>.

[RFC4786] Abley, J. and K. Lindqvist, «Operation of Anycast Services», BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <https://www.rfc-editor.org/info/rfc4786>.

[RFC4956] Arends, R., Kosters, M., and D. Blacka, «DNS Security (DNSSEC) Opt-In», RFC 4956, DOI 10.17487/RFC4956, July
2007, <https://www.rfc-editor.org/info/rfc4956>.

[RFC5625] Bellis, R., «DNS Proxy Implementation Guidelines», BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<https://www.rfc-editor.org/info/rfc5625>.

[RFC5890] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework», RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.

[RFC5891] Klensin, J., «Internationalized Domain Names in Applications (IDNA): Protocol», RFC 5891, DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/info/rfc5891>.

[RFC5892] Faltstrom, P., Ed., «The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)», RFC 5892, DOI 10.17487/RFC5892, August 2010,
<https://www.rfc-editor.org/info/rfc5892>.

[RFC5893] Alvestrand, H., Ed. and C. Karp, «Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)», RFC 5893, DOI 10.17487/RFC5893, August 2010,
<https://www.rfc-editor.org/info/rfc5893>.

[RFC5894] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale», RFC 5894, DOI 10.17487/RFC5894, August 2010,
<https://www.rfc-editor.org/info/rfc5894>.

[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, «IAB Thoughts on Encodings for Internationalized Domain Names», RFC 6055, DOI 10.17487/RFC6055, February 2011,
<https://www.rfc-editor.org/info/rfc6055>.

[RFC6265] Barth, A., «HTTP State Management Mechanism», RFC 6265, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.

[RFC6303] Andrews, M., «Locally Served DNS Zones», BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011,
<https://www.rfc-editor.org/info/rfc6303>.

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, «Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name  and Transport Protocol Port Number Registry», BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.

[RFC6365] Hoffman, P. and J. Klensin, «Terminology Used in Internationalization in the IETF», BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011,
<https://www.rfc-editor.org/info/rfc6365>.

[RFC6672] Rose, S. and W. Wijngaards, «DNAME Redirection in the DNS», RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>.

[RFC6762] Cheshire, S. and M. Krochmal, «Multicast DNS», RFC 6762, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.

[RFC7129] Gieben, R. and W. Mekking, «Authenticated Denial of Existence in the DNS», RFC 7129, DOI 10.17487/RFC7129,
February 2014, <https://www.rfc-editor.org/info/rfc7129>.

[RFC7480] Newton, A., Ellacott, B., and N. Kong, «HTTP Usage in the Registration Data Access Protocol (RDAP)», RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>.

[RFC7481] Hollenbeck, S. and N. Kong, «Security Services for the Registration Data Access Protocol (RDAP)», RFC 7481, DOI 10.17487/RFC7481, March 2015,
<https://www.rfc-editor.org/info/rfc7481>.

[RFC7482] Newton, A. and S. Hollenbeck, «Registration Data Access Protocol (RDAP) Query Format», RFC 7482, DOI 10.17487/RFC7482, March 2015,
<https://www.rfc-editor.org/info/rfc7482>.

[RFC7483] Newton, A. and S. Hollenbeck, «JSON Responses for the Registration Data Access Protocol (RDAP)», RFC 7483, DOI 10.17487/RFC7483, March 2015,
<https://www.rfc-editor.org/info/rfc7483>.

[RFC7484] Blanchet, M., «Finding the Authoritative Registration Data (RDAP) Service», RFC 7484, DOI 10.17487/RFC7484, March
2015, <https://www.rfc-editor.org/info/rfc7484>.

[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, «Inventory and Analysis of WHOIS Registration Objects», RFC 7485, DOI 10.17487/RFC7485, March 2015,
<https://www.rfc-editor.org/info/rfc7485>.

[RFC7793] Andrews, M., «Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry», BCP 163, RFC 7793, DOI 10.17487/RFC7793, May 2016,
<https://www.rfc-editor.org/info/rfc7793>.

[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, «Specification for DNS over Transport Layer Security (TLS)», RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.

[RFC8094] Reddy, T., Wing, D., and P. Patil, «DNS over Datagram Transport Layer Security (DTLS)», RFC 8094, DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>.

[RFC8109] Koch, P., Larson, M., and P. Hoffman, «Initializing a DNS Resolver with Priming Queries», BCP 209, RFC 8109, DOI 10.17487/RFC8109, March 2017,
<https://www.rfc-editor.org/info/rfc8109>.

[RFC8484] Hoffman, P. and P. McManus, «DNS Queries over HTTPS (DoH)», RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.

[RSSAC026] Root Server System Advisory Committee (RSSAC), «RSSAC Lexicon», 2017,
<https://www.icann.org/en/system/files/files/rssac-026-14mar17-en.pdf>.

Приложение А. Определения, обновленные в этом документе

Следующие определения из RFC обновляются этим документом:

• Экспедитор в [RFC2308]
• QNAME в [RFC2308]
• Безопасная точка входа (SEP) в [RFC3757]; обратите внимание, однако, что этот RFC уже устарел (см. [RFC4033], [RFC4034], [RFC4035]).

Приложение B. Определения, впервые определенные в этом документе

Следующие определения впервые определены в этом документе:

• о «Псевдоним» в разделе 2
• о «Апекс» в разделе 7
• о «Арпа» в разделе 7
• о «Бейливик» в разделе 7
• o «Независимый от класса» в Разделе 5
• o «Зона делегирования» в разделе 7
• o «Делегирование» в разделе 7
• o «Оператор DNS» в разделе 9
• o «DNSSEC-осведомлен» в Разделе 10
• o «DNSSEC-не знает» в разделе 10
• o «Экспедиция» в разделе 6
• o «Полный распознаватель» в разделе 6
• o «Полное доменное имя» в разделе 2
• o «Глобальный DNS» в разделе 2
• o «Модуль аппаратной безопасности (HSM)» в разделе 10
• o «Имя хоста» в разделе 2
• o «IDN» в разделе 2
• o «In-bailiwick» в разделе 7
• o «Итеративное разрешение» в разделе 6
• o «Метка» в разделе 2
• o «Локально обслуживаемая зона DNS» в разделе 2
• o «Система именования» в разделе 2
• o «Отрицательный ответ» в Разделе 3
• o «нерекурсивный запрос» в разделе 6
• o «Открытый распознаватель» в разделе 6
• o «Вне тюрьмы» в разделе 7
• o «Пассивный DNS» в разделе 6
• o «Средство реализации политики» в Разделе 6
• o «Формат презентации» в разделе 5
• o «Заправка» в разделе 6
• o «Частный DNS» в разделе 2
• o «Рекурсивный резольвер» в разделе 6
• o «Рефералы» в Разделе 4
• o «Регистрант» в Разделе 9
• o «Регистратор» в разделе 9
• o «Реестр» в разделе 9
• o «Корневая зона» в разделе 7
• o «Безопасная точка входа (SEP)» в разделе 10
• o «Программное обеспечение для подписи» в Разделе 10
• o «Сплит DNS» в разделе 6
• o «Заглушка» в Разделе 6
• o «Подчиненный» в разделе 8
• o «Начальник» в разделе 8
• o «ДВУ» в разделе 2
• o «Проверка разрешения» в Разделе 10
• o «Валидация» в разделе 10
• o «Вид» в разделе 6
• o «Зональный перевод» в разделе 6

Индекс

A
Address records 16
Alias 9
Anycast 22
Apex 23
Asterisk label 27
Authoritative data 24
Authoritative server 19
Authoritative-only server 19
arpa: Address and Routing Parameter Area Domain 26
C
CNAME 10
Canonical name 9
Child 22
Class 11
Class independent 16
Closest encloser 27
Closest provable encloser 27
Combined signing key (CSK) 33
D
DNS operator 29
DNSSEC Policy (DP) 34
DNSSEC Practice Statement (DPS) 34
DNSSEC-aware and DNSSEC-unaware 30
Delegation 24
Delegation-centric zone 26
Domain name 5

E
EDNS 14
EPP 28
Empty non-terminals (ENT) 26
F
FORMERR 10
Fast flux DNS 26
Forward lookup 26
Forwarder 21
Forwarding 20
Full resolver 18
Full-service resolver 18
Fully-qualified domain name (FQDN) 8
G
Global DNS 5
Glue records 24
H
Hardware security module (HSM) 34
Hidden master 20
Host name 8
I
IDN 9
In-bailiwick 25
Insecure delegation 31
Instance 22
Internationalized Domain Name 9
Iterative mode 17
Iterative resolution 18
K
Key signing key (KSK) 33
L
Label 5
Lame delegation 24
Locally served DNS zone 8
M
Master file 14
Master server 19
Multicast DNS 7
mDNS 7

N
NODATA 10
NOERROR 10
NOTIMP 10
NS 19
NSEC 31
NSEC3 31
NXDOMAIN 10
Naming system 4
Negative caching 19
Negative response 11
Next closer name 28
Non-recursive query 18
O
OPT 14
Occluded name 26
Open resolver 21
Opt-out 31
Origin 23
Out-of-bailiwick 25
Owner 15
P
Parent 23
Passive DNS 22
Policy-implementing resolver 21
Presentation format 14
Primary master 20
Primary server 20
Priming 18
Privacy-enabling DNS server 22
Private DNS 7
Public suffix 29
Q
QNAME 11
R
RDAP 29
REFUSED 10
RR 14
RRset 14
Recursive mode 17
Recursive query 18
Recursive resolver 17
Referrals 13
Registrant 28

Registrar 28
Registry 28
Resolver 16
Reverse DNS, reverse lookup 26
Root hints 18
Root zone 26
S
SERVFAIL 10
SOA 14
SOA field names 14
Secondary server 19
Secure Entry Point (SEP) 33
Service name 27
Signed zone 30
Signing software 34
Slave server 19
Source of Synthesis 28
Split DNS 21
Split-horizon DNS 21
Stealth server 20
Stub resolver 17
Subdomain 9
Subordinate 29
Superordinate 29
T
TLD 9
TTL 15
Trust anchor 34
U
Unsigned zone 30
V
Validating resolver 33
Validation 32
View 21
W
WHOIS 28
Wildcard 27
Wildcard domain name 27

Z
Zone 22
Zone cut 23
Zone enumeration 31
Zone signing key (ZSK) 33
Zone transfer 19

Благодарности

Ниже приведен раздел «Благодарности» в RFC 7719.

Авторы выражают благодарность всем авторам связанных с DNS RFC, которые продолжают этот. Комментарии Тони Финча, Стефана Борцмейера, Найла О’Рейли, Колма Маккартай, Рэя Беллиса, Джона Кристоффа, Роберта Эдмондса, Пола Воутерса, Шумона Хука, Пола Эберсмана, Дэвида Лоуренса, Маттиса Меккинга, Кейси Деккио, Боба Гарольда, Эд Льюиса, Джона Кленсин, Дэвид Блэк и многие другие в рабочей группе DNSOP помогли сформировать RFC 7719.

Большая часть основных изменений между RFC 7719 и этим документом произошла в результате активного обсуждения рабочей группы DNSOP. Конкретные люди, которые предоставили материал для этого документа, включают: Боба Гарольда, Дика Фрэнкса, Эвана Ханта, Джона Дикинсона, Марка Эндрюса, Мартина Хоффмана, Пола Викси, Питера Коха, Дуэйна Уэсселса, Эллисон Мэнкин, Джовэйн Моуру, Рони Эвена, Дана Ромаскану и Владмир Кунат.

Адреса авторов

Paul Hoffman
ICANN

Email: paul.hoffman@icann.org

Andrew Sullivan

Email: ajs@anvilwalrusden.com

---

Kazunori Fujiwara
Japan Registry Services Co., Ltd.
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065
Japan

Phone: +81 3 5215 8451
Email: fujiwara@jprs.co.jp