Internet Engineering Task Force (IETF) W. Kumari
Request for Comments: 9476 Google
Category: Standards Track P. Hoffman
ISSN: 2070-1721 ICANN
September 2023
The .alt Special-Use Top-Level Domain
Специальный домен верхнего уровня .alt
Аннотация
Этот документ резервирует метку домена верхнего уровня (Top-Level Domain или TLD) alt для использования вне контекста DNS. В документ также включены рекомендации и указания для разработчиков, создающих дополнительные пространства имён.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc9476.
Авторские права
Copyright (c) 2023. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
1. Введение
Многим протоколам Internet требуется именование сущностей (объектов). Широкое распространение получили имена в стиле DNS (последовательность меток, разделённых точками) даже в системах, не входящих в глобальную систему DNS, администрируемую IANA. Этот документ резервирует метку верхнего уровня alt (сокращение от alternative) как доменное имя специального назначения [RFC6761]. Эту метку можно применять в качестве последней (правой) части имени для указания того, что данное имя не имеет корня в глобальной DNS и его не следует преобразовывать по протоколу DNS.
Далее в документе метка верхнего уровня alt указывается как .alt в соответствии с принятой для имён DNS практикой.
Как указано в параграфе 3.1, агентство IANA добавило имя .alt в реестр Special-Use Domain Name в соответствии с документом <https://www.iana.org/domains/reserved>.
Описанные в документе методы предназначены для решения некоторых вопросов, рассмотренных в [RFC8244], где приведены дополнительные сведения о доменных именах специального назначения и связанных с ними вопросов.
В этом документе выбрано имя .alt, а не что-то вроде alt.arpa, чтобы использующим такие имена системам не нужно было беспокоиться о распознавании родителя имени при утечке имени в сеть Internet. Исторически некоторые системы желают использовать не связанные с DNS имена, чтобы они не были частью DNS и .alt подходит для этого.
1.1. Терминология
Этот документ предполагает знакомство с терминологией DNS [RFC8499] и определяет ряд дополнительных терминов.
DNS name – имя DNS
Доменные имена, предназначенные для распознавания через DNS в глобальном или ином контексте DNS.DNS context – контекст DNS
Пространство имён, привязанное к уникальному в глобальном масштабе корню DNS и администрируемое IANA. Это пространство или контекст обычного применения DNS.non-DNS context – отличный от DNS контекст
Любое другое (альтернативное) пространство имён.Pseudo-TLD – псевдо-TLD
Метка, присутствующая в полном доменном имени в позиции TLD и не относящаяся к глобальной системе DNS. Термин не является уничижительным.TLD
См. определение в разделе 2 [RFC8499].1.2. Уровни требований
Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
2. Пространство имён .alt
Этот документ резервирует метку .alt для использования в качестве неуправляемого (централизованно) пространства имён псевдо-TLD. Метку .alt можно применять в любом доменном имени как псевдо-TLD для обозначения того, что это пространство имён не относится к DNS и имена не следует искать в контексте DNS.
В этом документе .alt служит для представления псевдо-TLD в формате DNS, что соответствует суффиксу 0x03616c7400 в «проводном» формате DNS. Форматы сигналов в линии для других протоколов (не DNS) могут отличаться.
Поскольку имена в зоне .alt относятся к другому пространству имён, они не имеют значения (смысла) в обычном контексте DNS. Заглушкам (stub) и рекурсивным распознавателям DNS не нужно искать их в контексте DNS.
Распознаватели DNS, обслуживающие одновременно DNS и другие протоколы, могут рассматривать .alt подобно DNS-записи из реестра Transport-Independent Locally-Served DNS Zone, который является частью реестра IANA Locally-Served DNS Zones, за исключением того, что .alt всегда служит для обозначения имён, распознаваемых протоколами, отличными от DNS. Отметим, что этот документ не запрашивает добавления .alt в эти реестры, поскольку .alt в соответствии с этой спецификацией не является именем DNS.
Использование .alt в качестве псевдо-TLD не задаёт способ обработки имени протоколом, не относящимся к DNS. Для максимальной совместимости с имеющимися приложениями предлагается (но не требуется) не относящимся к DNS протоколам, которые используют .alt, следовать синтаксису DNS. Если такой протокол применяет в линии протокол, похожий на протокол DNS, он может (но не обязан) добавлять в конец имени пустую (null) метку. Документ не вносит каких-либо предложений в части работы с «проводным» форматом имён для протоколов, не относящихся к DNS.
Желающие создать новое альтернативное пространство имён могут сделать это, используя псевдо-TLD .alt. Этот документ не задаёт ни реестра, ни модели управления для пространства имён .alt, поскольку оно не управляется ни IETF, ни IANA. Не существует гарантии однозначного сопоставления между именами и механизмами их распознавания. Смягчение или разрешение конфликтов в пространствах имён иерархии .alt выходят за рамки этого документа и компетенции IETF. Пользователям рекомендуется учитывать связанные с этим риски при использовании таких имён.
Независимо от изложенных выше ожиданий, имена из псевдо-TLD .alt будут распространяться за пределы контекста, в котором они действуют. Опыт использования в течение десятилетий показывает, что такие имена появляются в рекурсивных распознавателях, а значит, и на корневых серверах глобальной системы DNS.
Отправка корневым серверам трафика, который будет заведомо вызывать отклик NXDOMAIN, например, запросов для имён с суффиксом .alt, ведёт к расходу ресурсов как на распознавателях, так и на корневых серверах. Кэширующие распознаватели, активно использующие кэширование с проверкой DNSSEC ([RFC8198]), могут смягчать эту проблему, синтезируя негативные отклики из кэшированных записей NSEC для имён в .alt. Аналогично, кэширующие распознаватели, применяющие минимизацию QNAME ([RFC9156]), будут сокращать объем трафика ненужного трафика на корневые серверы, поскольку негативные отклики будут возвращаться для всех имён иерархии .alt.
Развёрнутым проектам и протоколам, использующим псевдо-TLD, рекомендуется (но не требуется) перейти к псевдо-TLD .alt. Псевдо-TLD .alt резервируется для того, чтобы современные и будущие проекты аналогичного характера имели специальное место для создания альтернативных пространств имён, которые не будут конфликтовать с обычным контекстом DNS.
3. Взаимодействие с IANA
3.1. Реестр Special-Use Domain Name
Агентство IANA добавило имя .alt в реестр Special-Use Domain Name [RFC6761] со ссылкой на этот документ (RFC).
3.2. Резервирование доменных имён
Этот раздел создан для выполнения требований [RFC6761]. Поставленные в [RFC6761] вопросы в основном рассчитаны на систему распознавания DNS и некоторые из них не являются актуальными.
-
Пользователи могут (но не обязаны) считать имена из псевдо-TLD .alt имеющими особое значение.
-
Предполагается, что прикладные программы, использующие пространство имён в иерархии псевдо-TLD .alt, имеют свои правила обработки имён, возможно в специализированных интерфейсах API, библиотеках и/или прикладных программах. В прикладных программах, не предназначенных специально для использования имён из псевдо-TLD .alt, не ожидается распознавания таких имён как имеющих особое значение.
-
Предполагается, что разработчики API и библиотек, предназначенных для распознавания имён из псевдо-TLD .alt как имеющих особое значение, выполняют соответствующее преобразование (распознавание) таких имён. Конкретный механизм используемый в API и библиотеках для распознавания имён зависит от применяемой системы распознавания. В обычных API и библиотеках распознавания DNS не предполагается особая обработка имён из псевдо-TLD .alt.
-
Кэширующим серверам DNS не следует считать имена из псевдо-TLD .alt особыми и не следует применять для них специальную обработку.
-
Полномочным серверам DNS не следует считать имена из псевдо-TLD .alt особыми и не следует применять для них специальную обработку.
-
Операторы серверов DNS будут относиться к именам из псевдо-TLD .alt как к именам из прочих TLD, не относящихся к глобальной системе DNS. Операторы серверов DNS могут знать, что имена с суффиксом .alt не являются именами DNS, а запросы для этих имён проникают в контекст DNS. Такая информация может быть полезна для поддержки или отлаживания.
-
Реестры и регистраторы DNS не могут регистрировать имена из псевдо-TLD .alt, поскольку их не нет в корне глобальной системы DNS.
4. Вопросы приватности
Этот документ резервирует суффикс .alt в качестве индикатора того, что имя не относится к DNS. К сожалению, запросы для таких имён несомненно будут проникать в DNS. Это общая проблема альтернативных пространств имён, не ограничивающаяся именами с суффиксом .alt.
Например, example.alt может вызывать проблемы приватности для имён из этого пространства, попавших в Internet. Кроме того, если имя с суффиксом .alt достаточно уникально, долговечно и часто попадает в глобальную систему DNS, независимо от того, как оно создано, имя может действовать подобно web cookie со всеми вытекающими из этого последствиями для идентификации (в том числе, повторной).
5. Вопросы безопасности
Поскольку имена из псевдо-TLD .alt явно находятся вне контекста DNS, для них невозможно полагаться на соображения безопасности, связанные с DNS. Требуется соблюдать осторожность при сопоставлении псевдо-TLD с соответствующей системой распознавания (не DNS) для обеспечения защиты, предоставляемой этой системой.
6. Литература
6.1. Нормативные документы
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC6761] Cheshire, S. and M. Krochmal, “Special-Use Domain Names”, RFC 6761, DOI 10.17487/RFC6761, February 2013, <https://www.rfc-editor.org/info/rfc6761>.
[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8244] Lemon, T., Droms, R., and W. Kumari, “Special-Use Domain Names Problem Statement”, RFC 8244, DOI 10.17487/RFC8244, October 2017, <https://www.rfc-editor.org/info/rfc8244>.
6.2. Дополнительная литература
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, “Aggressive Use of DNSSEC-Validated Cache”, RFC 8198, DOI 10.17487/RFC8198, July 2017, <https://www.rfc-editor.org/info/rfc8198>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, “DNS Terminology”, BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, “DNS Query Name Minimisation to Improve Privacy”, RFC 9156, DOI 10.17487/RFC9156, November 2021, <https://www.rfc-editor.org/info/rfc9156>.
Благодарности
Спасибо Joe Abley, Mark Andrews, Erik Auerswald, Roy Arends, Ray Bellis, Vittorio Bertola, Marc Blanchet, John Bond, Stéphane Bortzmeyer, David Cake, Vint Cerf, David Conrad, Steve Crocker, Vladimir Cunat, Brian Dickson, Ralph Droms, Robert Edmonds, Patrik Fältström, Bernd Fix, Christian Grothoff, Olafur Gudmundsson, Ted Hardie, Bob Harold, Wes Hardaker, Geoff Huston, Joel Jaeggli, John C Klensin, Eliot Lear, Barry Leiba, Ted Lemon, Edward Lewis, John Levine, George Michaelson, Ed Pascoe, Libor Peltan, Jim Reid, Martin Schanzenbach, Ben Schwartz, Arturo Servin, Peter Thomassen, Paul Vixie, Duane Wessels, Paul Wouters, Suzanne Woolf за их отклики.
Работа над этим документом тянулась много лет и авторы хотели бы принести искренние извинения тем, кого забыли упомянуть.
Спасибо Rob Wilton, который был ответственным руководителем направления (Responsible AD) для этого документа.
Andrew Sullivan был автором документа с момента принятия (2015 г.) до версии 14 (2021 г.).
Адреса авторов
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America Email: warren@kumari.net Paul Hoffman ICANN Email: paul.hoffman@icann.orgПеревод на русский язык
1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.