RFC 8324 | Конфиденциальность DNS, авторизация, специальное использование, кодирование, символы, сопоставление и корневая структура: время для другого взгляда?

Аннотация

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

Скачать оригинальный документ на английском языке RFC 8324 PDF

 

Оглавление

1. Введение
2. Предпосылки и гипотеза
3. Бородавки и напряженность с текущим DNS
3.1. Многопрофильные запросы
3.2. Соответствие Часть I: Чувствительность к регистру в ярлыках и другие аномалии
3.3. Соответствие части II: не-ASCII («интернационализированные») доменные имена
3.4. Соответствие части III: синонимы, эквивалентные имена и варианты меток
3.5. Конфиденциальность запроса
3.6. Альтернативные пространства имен для публичного использования в структуре DNS: проблема CLASS
3.7. Слабая синхронизация
3.8. Частные пространства имен и специальные имена
3.9. Альтернативные кодировки запросов или ответов
3.10. Распределение и управление корневыми серверами
3.11. Идентификаторы в сравнении с брендами и другие удобные названия
3.12. Единая иерархия с централизованно управляемым корнем
3.13. Новые протоколы приложений, новые требования и эволюция DNS
3.13.1. Расширения
3.13.2. Расширения и давление развертывания — TXT RRTYPE
3.13.3. Периоды и проблемы сокращения зоны
3.14. Масштабирование репутации и другой вспомогательной информации
3.15. Напряженность между транспортом, масштабированием и содержанием
4. Требование обратного просмотра
5. Масштаб Интернета, поддержка функций и пошаговое развертывание
6. Поиск и DNS — историческая справка
7. Вопросы безопасности
8. Ссылки
8.1. Нормативные ссылки
8.2. Информационные ссылки
Благодарности
Адрес автора

 

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

Этот документ не является спецификацией Internet Standards Track; опубликовано в ознакомительных целях.

Это вклад в серию RFC, независимо от любого другого потока RFC. Редактор RFC решил опубликовать этот документ по своему усмотрению и не делает никаких заявлений о его ценности для внедрения или развертывания. Документы, одобренные для публикации редактором RFC, не являются кандидатами на какой-либо уровень Интернет-стандарта; см. раздел 2 RFC 7841.

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

 

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

Авторское право (c) Траст IETF 2018 года и лица, указанные в качестве авторов документа. Все права защищены.

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

 

1. Введение

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

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

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

Хотя этот документ не предполагает глубоких технических или эксплуатационных знаний о DNS, он предполагает некоторые знания и, по крайней мере, общее знакомство с концепциями RFC 1034 [RFC1034] и RFC 1035 [RFC1035] и терминологией, обсуждаемой в RFC 7719 [RFC7719] и в других местах. Хотя некоторые содержащиеся в нем комментарии могут быть взяты как подсказки или примеры различных способов осмысления проблем проектирования, в нем не предпринимается попыток изучить, а тем более предложить учебник по системам альтернативного именования или технологиям баз данных.

Возможно, стоит отметить, что, хотя перспектива иная и прошло более десятка лет, многие из вопросов, обсуждаемых в этом документе, были проанализированы и описаны (большинство из них с более подробными объяснениями) в докладе Национального исследовательского совета США 2005 года. [СРН-Signposts].

Читатели должны отметить, что несколько ссылок на устаревшие документы. Это было сделано, потому что они предназначены для показа документов и дат, которые вводили конкретные функции или концепции. Когда текущие версии предназначены, они ссылаются.

 

2. Предпосылки и гипотеза

Система доменных имен (DNS) [RFC1034] была разработана, начиная с начала 1980-х годов [RFC0799] [RFC0881] [RFC0882] [RFC0883] с основной целью замены плоской, централизованно управляемой системы таблиц хостов [RFC0810] [RFC0952] [RFC0953] с иерархической, административно распределенной системой. Проект DNS включал в себя некоторые функции, которые после первоначальной реализации и развертывания были признаны неработоспособными и либо заменены (например, подход к почтовому получателю (MD) и пересылке почты (MF) [RFC0882], которые были заменены подходом MX [RFC0974] ]), заброшен (например, механизм для использования локальных частей электронной почты в качестве меток, описанных в RFC 1034, раздел 3.3) или устарел (например, WKS RR TYPE [RFC1123]). Новые идеи и требования выявили ряд других особенностей, некоторые из которых были менее развиты, чем другие. Конечно, оригинальные дизайнеры не могли предвидеть все, что ожидалось от DNS за последние 30 лет.

В последние годы спрос на новые и расширенные услуги и использование DNS, в свою очередь, привел к предложениям о расширениях DNS или изменениях различного рода. Некоторые из них были приняты, в том числе модель для согласования расширенной функциональности [RFC2671] (широко известная как EDNS (0)) и для поддержки IPv6 [RFC3596], другие были признаны неосуществимыми, а другие продолжают рассматриваться. Некоторые примеры последних двух категорий обсуждаются ниже. Было также высказано предположение, что некоторые особенности исходной спецификации DNS, такие как свойство CLASS и типы меток, настолько плохо определены, что их следует считать устаревшими [Sullivan-Class].

В отличие от более ранних изменений, таких как механизмы интернационализированных доменных имен для приложений (IDNA), для лучшего включения меток, не относящихся к ASCII, без изменения самой структуры DNS [RFC3490] [RFC5890], некоторые недавние предложения требуют или настоятельно рекомендуют изменения в API, форматах или интерфейсах. программами, которые должны получать информацию из DNS или интерпретировать эту информацию. Различия между архитектурой DNS и требованиями, которые подразумевают эти предложения, позволяют предположить, что, возможно, пришло время прекратить исправлять DNS или пытаться расширять его небольшими шагами. Вместо этого нам следует подумать о том, чтобы перенести какую-то текущую или предлагаемую функциональность в другое место или разработать новую систему, которая лучше отвечает сегодняшним потребностям и стратегии перехода к ней.

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

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

 

3. Бородавки и напряженность с текущим DNS

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

 

3.1. Многопрофильные запросы

DNS не поддерживает изящные запросы. Текущий случай, когда эта проблема поднимается, включает попытки найти решения, которые возвращают адреса как TYPE A (IPv4), так и типа AAA (IPv6). Первоначально проблема была замечена с «QTYPE = MAILA» [RFC0882] для исходных RRTYPE для MA и MD, и этот опыт убедительно свидетельствует о том, что необходимо очень тщательно продумать эффекты кэширования (и, возможно, дополнительные изменения DNS). Другие решения могут показаться одинаково или более правдоподобными. Их, в том числе «два типа адресов», вероятно, объединяет то, что они иллюстрируют нагрузку на систему и что изменение DNS для обработки этих нагрузок не является простым или, вероятно, не будет проблемным.

 

3.2. Соответствие Часть I: Чувствительность к регистру в ярлыках и другие аномалии

Спецификации DNS предполагают, что метки являются октетными строками, а октеты с высоким нулевым битом имеют семибитовые коды ASCII в оставшихся битах. Они требуют, чтобы, когда имя домена, используемое в запросе, совпадало с именем домена, хранящимся в базе данных, эти символы ASCII интерпретировались независимо от регистра, то есть буквы верхнего и нижнего регистра считались эквивалентными (цифры и символы). не затрагиваются) [RFC4343]. Для не-ASCII-октетов, то есть октетов в метках с включенным первым битом, нет никаких предположений об используемом кодировании символов, тем более каких-либо правил относительно эквивалентности регистра символов — строки должны сравниваться путем сопоставления последовательных битов. Несмотря на то, что текущая модель для обработки не-ASCII (то есть, «интернационализированных») меток доменных имен (IDN) [RFC5890] (см. Раздел 3.3 ниже) кодирует информацию, так что DNS напрямую не затрагивается, понятие, что некоторые символы в метках обрабатываются без учета регистра, и то, что другие чувствительны к регистру (или что верхний регистр должен быть полностью запрещен, как это делает IDNA), вызвало много путаницы и обиды. Эти опасения и жалобы о непоследовательном поведении и неправильном обращении (или неоптимальной обработке) падежных отношений для некоторых языков не были смягчены повторными объяснениями того, что отношения между «украшенными» строчными символами и их эквивалентами в верхнем регистре часто чувствительны к языку и локальность и, следовательно, не является детерминированной с информацией, доступной для DNS-серверов.

 

3.3. Соответствие части II: не-ASCII («интернационализированные») доменные имена

Совершенно независимо от проблемы чувствительности к регистру, одним из фундаментальных свойств Unicode [Unicode] является то, что некоторые абстрактные символы могут быть представлены несколькими способами, например, одной предварительно составленной кодовой точкой или базовой кодовой точкой, за которой следует один или более кодовых точек, которые указывают комбинирующие символы. Хотя нормализацию Unicode можно использовать для устранения многих (но не всех) этих различий для целей сравнения (сопоставления), ее лучше применять во время сопоставления, а не путем изменения одной строки в другую. Первая версия IDNA («IDNA2003») сделала выбор изменить строки во время обработки для хранения или извлечения [RFC3490] [RFC3491]; вторая («IDNA2008») требовала, чтобы все строки были нормализованы и чтобы символы в верхнем регистре вообще не допускались [RFC5891]. Ни один из них не является оптимальным, хотя бы потому, что независимо от того, где они изменяются, если они вообще изменяются, преобразование самих строк подразумевает, что входная строка в приложении может не совпадать со строкой, используемой при обработке, и, возможно, позднее отображаться.

Почти наверняка было бы предпочтительным и более совместимым с рекомендациями Unicode, использовать нормализацию (и, возможно, другие методы, если они уместны) во время сопоставления, а не изменять строки вообще, даже если был еще только один алгоритм сопоставления, т.е. Нормализация была добавлена ​​к существующему сворачиванию дела только в ASCII. Однако даже обсуждение нормализации в Юникоде [Unicode-UAX15] указывает на то, что существуют особые, зависящие от языка случаи (наиболее часто цитируемый пример — «i» без точек (U + 0131)). DNS не только не имеет никакой информации о языках, которые могли бы использоваться в алгоритме отображения, но, поскольку существует требование, чтобы для всей системы был только один алгоритм отображения, эту информацию нельзя было использовать, даже если бы она была имеется в наличии. Можно представить себе систему-преемника, которая будет использовать информацию, хранящуюся в узлах в иерархии, для указания различных правил сопоставления для вспомогательных узлов (или эквивалентных схем для неиерархических систем). Не ясно, будет ли это хорошей идеей, но это, конечно, невозможно с DNS, как мы его знаем.

 

3.4. Соответствие части III: синонимы, эквивалентные имена и варианты меток

Когда начальные этапы работы над IDNs начали завершаться, стало очевидно, что природа и развитие человеческого языка и систем письма требуют трактовать одни имена как «такие же, как» другие. Первый важный пример этого — относительно недавняя попытка упростить китайскую письменность, тем самым создавая различие между «упрощенным» и «традиционным» китайским языком, хотя значение символов оставалось одинаковым почти во всех случаях (в так называемых идеографические наборы символов, символы имеют значение, а не исключительно представляющие звуки). Совместными усилиями соответствующих реестров национальных доменов верхнего уровня (ccTLD) и некоторых других заинтересованных сторон был выработан ряд рекомендаций по решению проблем с этим сценарием [RFC3743] и введено понятие «вариантных» символов и доменных имен.

Однако, когда имена рассматриваются как имеющие значения, а не просто как мнемонику, особенно когда они представляют бренды или эквивалент, или когда написание для определенного письменного языка не полностью стандартизировано, требования рассматривать различные строки как точные эквиваленты очевидны и неизбежны , В качестве тривиального примера на английском языке широко понимается, что «colour» и «color» представляют одно и то же слово, поэтому это означает, что, если они используются в качестве меток DNS в доменных именах, все остальные метки которых идентичны, два доменные имена должны рассматриваться как идентичные? Примеры для других языков или систем письма, особенно те, в которых некоторые или все маркировки, которые различают символы или слова по звуку или тональности или которые изменяют произношение слов, являются необязательными, часто более многочисленны и более проблематичны, чем национальные правописания в английском языке, но их труднее объяснить тем, кто не знаком с этими другими языками или системами письма (и их трудно проиллюстрировать в интернет-проектах и ​​RFC только для ASCII). Хотя аппроксимации возможны, DNS не может удовлетворить это требование: не только механизмы псевдонимов (CNAME, DNAME и различные предложения для более новых и различных типов псевдонимов [DNS-псевдонимы] [DNS-BNAME]) не обеспечивают достаточно сильную привязку , но возможность использовать эти псевдонимы из поддерева, контролируемого одним административным объектом, к другому из другого подразумевает, что у владельца (в смысле DNS или регистратора-регистратора) конкретного имени имеется небольшая или никакая возможность контролировать синонимы для него. Некоторые из этих проблем могут быть решены на уровне приложений, например, путем перенаправления в веб-протоколах, но использование такого подхода, который является важной характеристикой подхода «если оба имени принадлежат одному владельцу, все в порядке», приводит к имена обрабатываются противоречивыми способами в разных протоколах.

Другой способ взглянуть на часть этой проблемы (и, в некоторой степени, на ту, которая обсуждалась выше в разделе 3.3), заключается в том, что эти предполагаемые эквивалентности и желаемые преобразования зависят от контекста, но процесс разрешения DNS не является [RFC6912].

Подобные проблемы возникают, когда люди замечают, что некоторых персонажей легко принять за других, и это может стать причиной путаницы и атак пользователя. Обычно цитируемые примеры включают символы «a» латинского и кириллического алфавита, которые являются идентичными [CACM-Homograph], символы во многих сценариях, которые выглядят как открытые круги или вертикальные или горизонтальные линии, и даже буква латинского алфавита «l» и Европейская цифра «1», но примеры имеются и в других сценариях и комбинациях сценариев. Наиболее распространенное предлагаемое решение в контексте DNS состояло в том, чтобы рассматривать эти случаи, а также те, которые связаны с орфографическими вариациями, как «варианты» (но варианты, отличные от системы для китайских иероглифов, упомянутых выше), и либо запретить все, кроме одного (или несколько) возможных меток из DNS (возможно, по принципу «первым пришел — первым обслужен») или убедитесь, что любой набор таких строк, которые делегированы как назначенные одному и тому же владельцу (см. выше). Ни одно из решений не является полностью удовлетворительным: если исключить все, кроме одной строки, пользователи, которые угадывают другую форму, возможно, пытаясь транскрибировать символы из письменной или печатной формы, не находят то, что ищут, и, как указано выше, «одного и того же владельца» достаточно только при тщательно разработанной и управляемой поддержке протокола приложений, а иногда и не тогда.

Некоторые из этих вопросов более подробно обсуждаются в отчете ICANN [ICANN-VIP].

 

3.5. Конфиденциальность запроса

В последние годы растет озабоченность тем, что DNS-запросы происходят в открытом тексте в общедоступном Интернете и что, если эти запросы могут быть перехвачены, они могут предоставить много информации об интересах и контактах, которые могут поставить под угрозу личную конфиденциальность. Хотя ряд предложений, в том числе минимизация имени запроса [RFC7816] и запуск DNS по зашифрованному туннелю [RFC7858], были сделаны для смягчения этой проблемы, похоже, что все они имеют общие свойства исправлений безопасности, а не встроенную защиту или механизмы конфиденциальности. Хотя опыт может доказать обратное, если (и если) они широко развернуты, то, похоже, что ни одна из них не является столь же удовлетворительной, как могла бы быть разработана система с секретностью запросов. Более общие учебники по этому вопросу появились недавно [Huston2017a].

 

3.6. Альтернативные пространства имен для публичного использования в структуре DNS: проблема CLASS

Стандарты DNS включают спецификацию значения CLASS, которое «идентифицирует семейство протоколов или экземпляр протокола» (RFC 1034, раздел 3.6 и другие). В то время как CLASS эффективно использовался в первые дни DNS для управления различными семействами протоколов в одной и той же административной среде, недавние попытки использовать его для разделения пространства имен DNS другими способами, например, для имен не-ASCII (частично для решения проблем) в разделах 3.2 и 3.3) или использование механизмов DNS для совершенно разных пространств имен выявили фундаментальные проблемы с механизмом [класс Салливана]. Возможно, самой фундаментальной из этих проблем является разногласие относительно того, предполагалось ли существование нескольких КЛАССОВ в данной зоне (с записями в RRSET), или же разные классы подразумевают разные зоны. Различные реализации делают разные предположения [Faltstrom-2004] [Vixie-20170704]. Эти проблемы привели к тому, что рекомендации были исключены полностью [класс Салливана], но обсуждения списка IETF и рабочих групп в середине 2017 года дали понять, что нет четкого консенсуса по этому вопросу.

 

3.7. Слабая синхронизация

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

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

Однако ряд недавних идей об использовании DNS для хранения данных, для которых важные изменения происходят очень быстро, в значительной степени несовместимы с плохой синхронизацией. Попытки использовать очень короткое (или нулевое) время обновления (в записях SOA для ведомых обновлений от мастеров) и TTL (для кэшей) для имитации почти одновременного обновления могут работать до определенного момента, но, по-видимому, создают очень большие нагрузки на серверы и механизмы распространения. которые не были рассчитаны на такой стиль работы. Аналогичные наблюдения могут быть сделаны относительно попыток использовать расширение NOTIFY [RFC1996] или динамическое, «серверное продвижение», обновление, а не традиционные механизмы DNS. Хотя механизмы NOTIFY и push обычно обеспечивают время обновления и механизмы обновления быстрее, чем указанные в RFC 1034 и 1035, они подразумевают, что «главный» сервер должен знать идентичности (и иметь хорошую связь со всеми) своих подчиненных. Это побеждает, по крайней мере, некоторые из преимуществ, связанных с рабами-невидимками, особенно те, которые связаны с сокращением трафика запросов через Интернет. Эти механизмы ничего не делают для обновлений кэша: если серверы не отслеживают источник каждого запроса для имен, связанных с определенной зоной, а затем каким-либо образом уведомляют исходные системы запросов, единственная альтернатива хранению информации, которая может быть устаревшей, храниться в кэшах — это использовать очень короткие или нулевые TTL, поэтому кэшированные данные истекают почти сразу после сохранения (или вообще не сохраняются), что требует нового запроса к авторитетному серверу каждый раз, когда распознаватель пытается найти имя.

 

3.8. Частные пространства имен и специальные имена

Почти с тех пор, как DNS был впервые развернут, были ситуации, в которых желательно использовать DNS-подобные имена, и часто механизмы разрешения DNS или их модификации, с пространствами имен, для которых глобально доступное и согласованное разрешение с использованием общедоступного DNS невозможно. или нежелательно (и для которого использование CLASS не является подходящим механизмом). Необходимость изолировать имена и адреса в локальных сетях от общедоступного Интернета, как правило, с помощью подходов «раздельного горизонта», является одним из примеров этого требования, хотя часто и не признается таковым. Другой пример, вызвавший много споров, касается «специальных имен» — меток или псевдометок, часто в позициях TLD, которые указывают на то, что полное имя не должно подвергаться нормальному разрешению DNS или другой обработке [RFC6761] [RFC8244 ].

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

Если бы DNS был переработан и заменен, мы могли бы признать это требование как часть проекта и справиться с ним гораздо лучше, чем сегодня.

 

3.9. Альтернативные кодировки запросов или ответов

DNS определяет форматы для запросов и ответов на данные, основываясь на современном уровне техники и лучших практиках на момент ее разработки. Недавняя работа показала, что было бы существенным преимуществом поддерживать по крайней мере описание сообщений DNS в одном или нескольких альтернативных форматах, таких как JSON [Hoffman-DNS-JSON] [Hoffman-SimpleDNS-JSON]. Хотя эта работа была тщательно проделана, чтобы избежать необходимости вносить изменения в DNS, значительную часть аргумента в пользу наличия такого формата описания на основе JSON можно легко превратить в аргумент, что в случае пересмотра DNS этот формат может быть предпочтительнее, чем более прямая альтернатива наличию DNS-запросов и ответов в оригинальном виде.

 

3.10. Распределение и управление корневыми серверами

Модель DNS требует набора корневых серверов, которые содержат, как минимум, информацию о доменах верхнего уровня. За прошедшие годы это требование превратилось из технически довольно незначительной функции, обычно выполняемой в качестве услуги для более широкого интернет-сообщества и его пользователей и систем, в предмет, который является весьма спорным в отношении контроля над этими серверами, включая то, как они должны быть распределены и где они должны быть расположены. Несмотря на то, что был предложен ряд механизмов, последний из которых, в том числе делает информацию более локальной [RFC7706], и один (anycast [RFC7094]) активно используется для смягчения некоторых реальных и предполагаемых проблем, представляется очевидным, что DNS Преемник, разработанный для современного глобального Интернета и предполагаемых требований, мог бы решить эти проблемы технически более подходящим и менее спорным способом. Некоторое дополнительное обсуждение связанных с этим проблем появляется в недавней статье [Huston2017b].

 

3.11. Идентификаторы в сравнении с брендами и другие удобные названия

Ключевой элемент дизайна исходных систем именования сетевых объектов для ARPANET, в значительной степени унаследованный DNS, заключался в том, что имена, хотя и должны были быть мнемоническими, являлись идентификаторами, и их важность была очень различима и не подвержена неоднозначности. Это привело к ограничительным правилам о том, что может появиться в имени. Эти ограничения возникли из таблицы хостов и даже раньше [RFC0236] [RFC0247] и пришли к DNS (в основном через SMTP) в качестве «предпочтительного синтаксиса» (RFC 1034, раздел 3.5) или того, что мы сейчас часто называем буква-цифра- правило дефиса (LDH). Подобные правила, облегчающие использование идентификаторов, менее подверженные неоднозначности или снижающие вероятность возникновения помех синтаксису, часто встречаются в более формальных языках. Например, почти каждый язык программирования имеет ограничения на то, что может появляться в идентификаторе, и Unicode предоставляет общие рекомендации по составу идентификатора [Unicode-USA31]. Оба довольно ограничены по сравнению с количеством символов и общим числом строк, которые могут быть написаны с использованием этой системы кодирования символов.

Эта модель, которая первоначально запрещала метки, начинающиеся с цифр, чтобы избежать возможной путаницы с IP-адресами, начала выходить из строя в 1987 или 1988 году, когда компания под названием 3Com хотела использовать свое фирменное наименование в качестве метки в домене COM, и Правило было смягчено [RFC1123].

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

Таким образом, у нас есть два или, в зависимости от того, как считать, три очень разных варианта использования. Историческим является поддержка уникальных идентификаторов. Второе — это выражение идей и, если их рассматривать отдельно, представление названий брендов и продуктов. Поскольку они изначально связаны с различными ограничениями, приоритетами и критериями успеха, эти перспективы, в лучшем случае, слабо совместимы.

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

 

3.12. Единая иерархия с централизованно управляемым корнем

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

 

3.13. Новые протоколы приложений, новые требования и эволюция DNS

Новая работа, проделанная в других областях, привела к потребностям в новых функциях DNS, многие из которых связаны со значениями данных, которые требуют рекурсивной ссылки на DNS. Ранние типы записей, которые это делали, сопровождались ограничениями, которые снижали риск зацикливания ссылок или других трудностей. Например, в то время как MX RRTYPE имеет полностью определенное доменное имя в качестве своих данных, SMTP налагает ограничения «первичного имени», которые не позволяют используемому имени быть, например, CNAME. Хотя возможны циклы с CNAME, в разделе 3.6 RFC 1034 обсуждается, как избежать проблем и как их решать. Некоторые новые протоколы и соглашения могут вызвать больше стресса. Есть отдельные проблемы с дополнениями и с тем, как DNS был расширен, чтобы попытаться справиться с ними.

 

3.13.1. Расширения

Некоторые примеры расширений DNS для новых требований протокола, которые иллюстрируют или привели к усилению стресса, включают:

NAPTR: требует гораздо более сложных данных в DNS для поддержки ENUM (например, передачи голоса по IP (VoIP), в частности, SIP), включая информацию URI и, следовательно, рекурсивный или повторный поиск, чем любой из RRTYPE, изначально поддерживаемых. RRSET, связанный с этими записями, может стать довольно большим, потому что разделитель между различными записями является частью RDATA, а не тройкой {owner, class, type} (проблема, немного связанная с проблемой перегрузки TXT RRTYPE, обсуждаемой в разделе 3.13.2). Эта проблема, а также аналогичные для некоторых случаев ниже. может предположить, что любой будущий дизайн нуждается в другой модели TYPE, такой как систематические схемы для подтипов или некоторая явная иерархия в TYPE.

URI: имеет URI в качестве данных, обычно также требующих рекурсивного или повторного поиска.

Местоположение службы (SRV) и информация об учетных данных (включая Sender Policy Framework (SPF) и DomainKeys Identified Mail (DKIM)): требуют структурированных данных и, особенно для последних двух, значительно больше данных, чем большинство исходных RRTYPE.

URI / URL: раннее решение для Всемирной паутины о том, что ее механизм идентификации цифрового веб-контента (теперь известный как унифицированные идентификаторы ресурсов [RFC3986]) сделал это с помощью доменных имен и, следовательно, сетевого расположения информации или другого материала. Это, в свою очередь, потребовало от систем, предназначенных для повышения производительности сети, путем поиска и извлечения «ближайшей копии» (а не единственной копии, обозначенной URL-адресом) для перехвата DNS-запросов и ответа со значениями, которые не являются точно теми, которые хранятся для назначенного доменное имя в DNS или иной доступ к информации способом, не поддерживаемым самой DNS.

 

3.13.2. Расширения и давление развертывания — TXT RRTYPE

К сожалению (но неудивительно), и, несмотря на усилия IETF, направленные на облегчение ситуации [RFC6895], библиотеки поддержки DNS часто не спешат добавлять полную поддержку новых RRTYPE. Это препятствует развертыванию приложений, которые зависят от этих типов и которые должны явно запрашивать (запрашивать) их. И для ускорения развертывания, и, по крайней мере, до недавнего времени, чтобы избежать обременительных процедур утверждения IETF, многие разработчики приложений решили помещать критически важную для протокола информацию в записи с TXT RRTYPE, типом записи, который изначально предназначался для включения только информации, эквивалентной комментариям.

Это вызывает две проблемы. Во-первых, записи TXT, используемые таким образом, имеют тенденцию становиться длинными и сложными, что само по себе является проблемой, если кто-то пытается минимизировать TCP-соединения. Во-вторых, приложения, которые пытаются получить данные, не могут просто запросить соответствующий QTYPE; они должны получить все записи с помощью QTYPE TXT и проанализировать их, чтобы определить, какие из них представляют интерес. Это было бы проще, если бы был какой-то стандарт для того, как сделать этот анализ, но, по крайней мере частично, потому что явное предпочтение в дизайне DNS для различных RRTYPE для разных видов информации, такого стандарта не существует. (В 1993 году было предложено структурировать TXT DATA таким образом, чтобы решить эту проблему [RFC1464], но, по-видимому, оно никуда не ушло.)

С другой стороны, эта проблема несколько отличается от большинства других, описанных в этом документе, потому что (как IETF рекомендовал несколько раз) проблема легко решается в рамках текущей структуры DNS путем выделения и поддержки новых RRTYPE при необходимости, а не использования TXT как обходной путь (это не означает, что другие решения невозможны, либо с текущим DNS, либо с другим дизайном). Тогда проблема заключается в реализациях и / или механизмах, которые сдерживают или препятствуют быстрому развертыванию поддержки новых RRTYPE.

 

3.13.3. Периоды и проблемы сокращения зоны

Одна из характеристик DNS, которая плохо понимается неспециалистами, заключается в том, что символ точки («.», U + 002E) можно использовать четырьмя различными способами:

• В качестве разделителя меток в форме представления, который также обозначает «разрыв зоны» (граница делегирования). Например, foo.bar.example.com указывает владельца «foo» записей в зоне «bar.example.com».
• Как разделитель меток в форме представления, который не обозначает разрыв зоны. Например, foo.bar.example.com указывает владельца «foo.bar» записей в зоне «example.com».
• В качестве символа в метке, в том числе в качестве замены знака at («@»), когда адрес электронной почты появляется в записи SOA или в метке, обозначающей такой адрес (см. раздел 2 выше). Возможность встраивать точки в метки таким образом также привела к атакам, в которых, например, доменное имя, состоящее из меток «example» и «com», намеренно путают с одной меткой «example.com» со встроенным период.
• В конце полное доменное имя для обозначения корневой зоны, например, «example.com». (RFC 1034, раздел 3.1).

В общем, эти случаи нельзя различить, глядя на них. Третий является проблематичным по причинам, не связанным с DNS, например, «john.doe.example.net» можно интерпретировать как простое полное доменное имя или как запись для john@doe.example.net, john.doe@example.net, или даже (по крайней мере, в принципе) john.doe.example@net.

Различие между интерпретацией FQDN и первой электронной почтой, вероятно, не было важным, так как DNS изначально предназначался для использования. Однако, как только используются RRTYPE (кроме записей NS, которые определяют разрез зоны), которые чувствительны к границам между зонами, различия становятся важными для людей, отличных от администраторов соответствующих зон. DNSSEC [RFC4033] включает в себя один такой набор отношений. Это повышает важность вопросов о том, что должно происходить в родительской зоне, а что — в дочерних зонах, и насколько это важно, если записи NS в родительской зоне для дочерней зоны согласуются с записями и данными в дочерней зоне. Это также вызывает проблемы приложения и может вызвать вопросы об отношениях между регистраторами и одним или несколькими реестрами или, если они являются отдельными, операторами DNS.

 

3.14. Масштабирование репутации и другой вспомогательной информации

В первоначальном проекте администрирования DNS, отраженном в RFC 1591 [RFC1591] и в других местах, предполагалось, что все домены будут демонстрировать очень высокий уровень ответственности перед сообществом и за него и что этот уровень ответственности будет применяться в случае необходимости.

Более поздние решения, многие из которых связаны с коммерциализацией DNS, подорвали эти очень сильные предположения об ответственности реестра и подотчетности до такой степени, что многие считают, что решения о делегировании имен, идентификации владельцев регистрации и отношениях между именами являются вопросами » Остерегайтесь регистранта »и даже« Остерегайтесь пользователей и приложений ». Хотя некоторые недавние протоколы и предложения по крайней мере частично отражают эту первоначальную модель высокого уровня ответственности (см., Например, IDNA [RFC5890] и более недавнее обсуждение [Klensin-5891bis]), другие решения и действия, как правило, переносят ответственность на зарегистрироваться или попытаться избежать ответственности полностью. Один из возможных подходов к проблемам, особенно проблемам безопасности, которые становятся возможными благодаря этим новым тенденциям и связанной с ними среде, заключается в создании систем репутации, связанных с четко определенными административными границами и предупреждениями для пользователей, даже если эти системы репутации управляются сторонами, не связанными напрямую. связан с DNS.

РГ IETF DBOUND WG [IETF-DBOUND] рассмотрела способы более точного установления и документирования границ, чем простые зависимости от ДВУ, но не смогла выработать стандарт.

Подход, основанный на репутации ДВУ, был принят некоторыми веб-браузерами после того, как были введены IDNs и появилось все больше общих доменов верхнего уровня (gTLDs); этот подход основан на простом списке и не масштабируется до текущего размера DNS или даже корневого каталога DNS.

 

3.15. Напряженность между транспортом, масштабированием и содержанием

Первоначальный проект для DNS предусматривал простой протокол запросов и ответов, в котором и команда, и ответ могли быть легко сопоставлены в одном IP-пакете. Спецификация требований к хосту [RFC1123] требовала, чтобы все приложения DNS принимали UDP-запрос или ответ через UDP с 512 октетами полезной нагрузки DNS. TCP рассматривался как запасной вариант, когда ответ был больше этого предела в 512 октетов, и этот запасной вариант с использованием TCP в качестве транспортного протокола считался скорее исключением, чем правилом.

За прошедшие годы мы стали свидетелями роста общего предположения о размере максимальной единицы передачи (MTU) для всего Интернета в 1500 октетов, что сопровождалось предположением о том, что фрагментация UDP в целом жизнеспособна. Это подкрепляет принятие Механизмов расширения для DNS (EDNS (0)) [RFC6891], чтобы, среди прочего, указать размер буфера UDP, превышающий 512 октетов, и предложение в этой спецификации использовать 4096 в качестве подходящего компромисса для UDP. размер полезной нагрузки. Это оказалось удачным для расширений безопасности DNSSEC, где добавление учетных данных безопасности DNSSEC в ответах DNS [RFC4034] может привести к использованию больших ответов DNS. Однако это обнажает некоторую напряженность в отношении обработки фрагментации в IP, где было обнаружено, что фрагменты UDP фильтруются различными брандмауэрами. Кроме того, для IPv6 существуют факторы фильтрации диагностических сообщений ICMPv6 Packet Too Big и отбрасывания пакетов IPv6, которые содержат заголовки расширения [RFC7872]. В более общем смысле фрагментированные UDP-пакеты имеют более низкий уровень надежности, чем нефрагментированные TCP-пакеты.

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

 

4. Требование обратного просмотра

Требование для возможности обратного просмотра, то есть способности находить доменное имя по заданному адресу и, в принципе, найти владельца записи по любому из ее элементов данных, было признано в RFC 882. Эта функция была определена как необязательно, но переносится в RFC 1034 и 1035, но RFC 1034 явно устарел для поиска адреса к имени хоста (хотя RFC 1035 использует именно этот тип поиска в примере). Несмотря на обсуждение инвертированных форм базы данных в RFC 1035, обратный поиск редко, если вообще когда-либо, был реализован, по крайней мере, в его общей форме. Фундаментальные трудности с обратным поиском в форме, описанной в RFC 882, или в подходе «in-addr.arpa», упомянутом ниже, соответствуют проблемам, описанным в фундаментальных документах по управлению базами данных [Codd1970], но не были описаны в RFC 1035 или связанных с ним современные документы IETF.

Интересно поразмышлять над тем, сколько из текущих требований для обработки псевдонимов как интегрированного набора синонимов (например, для обработки вариантов) были бы рассмотрены, если бы обратный поиск мог надежно произвести владельцев записей CNAME.

В то же время, очевидно, было важно иметь какой-то механизм для разрешения адресов к именам. Он был предоставлен записями PTR RRTYPE в зоне IN-ADDR.ARPA с делегированием по границам октетов. Однако такой подход требовал, чтобы информация поддерживалась параллельно, в отдельных зонах, для сопоставления имени с адресом и адреса с именем. Это требование синхронизации для двух копий по существу одних и тех же данных было еще одной популярной темой в литературе по управлению базами данных за десятилетие или более до появления DNS и, как и ожидалось, привело к многочисленным несоответствиям и другим сбоям.

Введение бесклассовой междоменной маршрутизации (CIDR) [RFC1518] и адресов, зависящих от провайдера, еще более усложнило ситуацию, поскольку больше не было возможности делегировать администрирование записей обратного отображения для небольших сетей фактическим операторам этих сетей. , Интернет-провайдеры и другие агрегаторы часто не имели стимулов для ведения записей обратного отображения в соответствии с назначением оператором сетей доменных имен. Предложение использовать двоичные метки для решения этой проблемы [RFC2673] было отклонено несколько более чем через три года [RFC6891].

Независимо от того, сколько или мало вреда вызвало отсутствие общего средства обратного просмотра, и насколько эффективен подход «in-addr.arpa», обратный поиск остается средством, которое, как предполагалось, и было полезным в исходной схеме DNS но это никогда не было полностью реализовано.

 

5. Масштаб Интернета, поддержка функций и пошаговое развертывание

В дополнение к нагрузкам, вызванным новыми функциями, в том числе описанными в разделе 3.13, постепенное развертывание систем, использующих их, означает, что некоторые функции будут работать в одних средах, а другие — нет. Это было особенно проблематично со сложными, многозаписными возможностями, такими как DNSSEC, которые предоставляют или требуют специальных механизмов проверки, и с некоторыми расширениями EDNS (0) [RFC6891], которые требуют, чтобы и клиент, и сервер принимали определенные расширения. Когда во встроенных устройствах требуется функционирование DNS, развертывание новых функций по всему Интернету за разумный период времени практически невозможно.

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

 

6. Поиск и DNS — историческая справка

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

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

Стоит отметить, что хотя этот «поисковый» подход или какой-либо другой подход, который абстрагировал и отделил некоторые из проблем, определенных в разделе 3, от протокола DNS и базы данных, он не решает все из них. По крайней мере, некоторые элементы некоторых из этих проблем, такие как проблемы синхронизации, описанные в Разделе 3.7, и транспортные проблемы, описанные в Разделе 3.15, присущи структуре DNS, и, если мы не собираемся заменять DNS, нам лучше привыкнуть к ним.

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

Возможно, настало время пересмотреть подходы промежуточного уровня. Если это так, усилия должны изучить возможность использования этих подходов соответствующими пользовательскими приложениями, которые могут быть использованы для решения некоторых из проблем, указанных выше. Интернет и DNS значительно изменились с 2000-2003 годов. Некоторые из этих изменений обсуждаются в другом месте в этом документе; другие, включая перепрофилирование DNAME RRTYPE из поддержки переходов [RFC2672] в механизм общего назначения для псевдонимов поддеревьев [RFC6672] и добавление более тысячи новых TLD [IANA-TLD-registry], не являются, но тем не менее часть контекста для работы промежуточного уровня, которая не существовала в 2003 году.

 

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

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

8. Ссылки

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

[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>.

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

[CACM-Homograph] Gabrilovich, E. and A. Gontmakher, «The Homograph Attack», Communications of the ACM, Volume 45, Issue 2, pp. 128, DOI 10.1145/503124.503156, February 2002,
<http://www.cs.technion.ac.il/~gabr/papers/homograph_full.pdf>.

[Cerf2017] Cerf, V., «Desirable Properties of Internet Identifiers», IEEE Internet Computing, Volume 21, Issue 6, pp. 63-64, DOI 10.1109/MIC.2017.4180839, November/December 2017.

[Codd1970] Codd, E., «A Relational Model of Data for Large Shared Data Banks», Communications of the ACM, Volume 13, Issue 6, pp. 377-387, DOI 10.1145/362384.362685, June 1970,
<https://dl.acm.org/citation.cfm?id=362685>.

[DNS-Aliases] Woolf, S., Lee, X., and J. Yao, «Problem Statement: DNS Resolution of Aliased Names», Work in Progress, draft-ietf-dnsext-aliasing-requirements-01, March 2011.
<https://tools.ietf.org/html/draft-ietf-dnsext-aliasing-requirements-00>

[DNS-BNAME] Yao, J., Lee, X., and P. Vixie, «Bundled DNS Name Redirection», Work in Progress, draft-yao-dnsext-bname-06, May 2016.

[DNS-search] IETF, «Internet Resource Name Search Service (IRNSS)», 2003, <https://datatracker.ietf.org/wg/irnss/about/>.

[Faltstrom-2004] Faltstrom, P. and R. Austein, «Design Choices When Expanding DNS», Work in Progress, draft-ymbk-dns-choices-00, May 2004.

[Hoffman-DNS-JSON] Hoffman, P., «Representing DNS Messages in JSON», Work in Progress, draft-hoffman-dns-in-json-13, October 2017.

[Hoffman-SimpleDNS-JSON] Hoffman, P., «Simple DNS Queries and Responses in JSON», Work in Progress, draft-hoffman-simplednsjson-01, November 2017.

[Huston2017a] Huston, G. and J. Silva Dama, «DNS Privacy», The Internet Protocol Journal, Vol. 20, No. 1, March 2017, <http://ipj.dreamhosters.com/wp-content/uploads/issues/2017/ipj20-1.pdf>.

[Huston2017b] Huston, G., «The Root of the Domain Name System», The Internet Protocol Journal, Vol. 20, No. 2, pp. 15-25, June 2017, <http://ipj.dreamhosters.com/wp-content/uploads/2017/08/ipj20-2.pdf>.

[IANA-TLD-registry] Internet Assigned Numbers Authority (IANA), «Root Zone Database», <https://www.iana.org/domains/root/db>.

[ICANN-VIP] ICANN, «IDN Variant Issues Project: Final Integrated Issues Report Published and Proposed Project Plan for Next Steps is Now Open for Public Comment», February 2012,
<https://www.icann.org/news/announcement-2012-02-20-en>.

[IETF-DBOUND] IETF, «Domain Boundaries (dbound)», 2017, <https://datatracker.ietf.org/wg/dbound/about/>.

[Klensin-5891bis] Klensin, J. and A. Freytag, «Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations», Work in Progress, draft-klensin-idna-rfc5891bis-01, September 2017.

[Mockapetris-1988] Mockapetris, P. and K. Dunlap, «Development of the Domain Name System», SIGCOMM ’88 Symposium, pp. 123-133, available from ISI Reprint Series, ISI/RS-88-219 <ftp://ftp.isi.edu/isi-pubs/rs-88-219.pdf>, DOI 10.1145/52324.52338, August 1988, <http://dl.acm.org/citation.cfm?id=52338>.

[NRC-Signposts] National Research Council, Signposts in Cyberspace: The Domain Name System and Internet Navigation, ISBN 0-309-54979-5, 2005, <https://www.nap.edu/
catalog/11258/signposts-in-cyberspace-the-domain-namesystem-and-internet-navigation>.

[RFC0236] Postel, J., «Standard host names», RFC 236, DOI 10.17487/RFC0236, September 1971, <https://www.rfc-editor.org/info/rfc236>.

[RFC0247] Karp, P., «Proffered set of standard host names», RFC 247, DOI 10.17487/RFC0247, October 1971, <https://www.rfc-editor.org/info/rfc247>.

[RFC0799] Mills, D., «Internet name domains», RFC 799, DOI 10.17487/RFC0799, September 1981, <https://www.rfc-editor.org/info/rfc799>.

[RFC0810] Feinler, E., Harrenstien, K., Su, Z., and V. White, «DoD Internet host table specification», RFC 810, DOI 10.17487/RFC0810, March 1982, <https://www.rfc-editor.org/info/rfc810>.

[RFC0881] Postel, J., «Domain names plan and schedule», RFC 881, DOI 10.17487/RFC0881, November 1983, <https://www.rfc-editor.org/info/rfc881>.

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

[RFC0883] Mockapetris, P., «Domain names: Implementation specification», RFC 883, DOI 10.17487/RFC0883, November 1983, <https://www.rfc-editor.org/info/rfc883>.

[RFC0952] 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>.

[RFC0953] Harrenstien, K., Stahl, M., and E. Feinler, «Hostname Server», RFC 953, DOI 10.17487/RFC0953, October 1985, <https://www.rfc-editor.org/info/rfc953>.

[RFC0974] Partridge, C., «Mail routing and the domain system», STD 10, RFC 974, DOI 10.17487/RFC0974, January 1986, <https://www.rfc-editor.org/info/rfc974>.

[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>.

[RFC1464] Rosenbaum, R., «Using the Domain Name System To Store Arbitrary String Attributes», RFC 1464, DOI 10.17487/RFC1464, May 1993, <https://www.rfc-editor.org/info/rfc1464>.

[RFC1518] Rekhter, Y. and T. Li, «An Architecture for IP Address Allocation with CIDR», RFC 1518, DOI 10.17487/RFC1518, September 1993, <https://www.rfc-editor.org/info/rfc1518>.

[RFC1591] Postel, J., «Domain Name System Structure and Delegation», RFC 1591, DOI 10.17487/RFC1591, March 1994, <https://www.rfc-editor.org/info/rfc1591>.

[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>.

[RFC2671] Vixie, P., «Extension Mechanisms for DNS (EDNS0)», RFC 2671, DOI 10.17487/RFC2671, August 1999, <https://www.rfc-editor.org/info/rfc2671>.

[RFC2672] Crawford, M., «Non-Terminal DNS Name Redirection», RFC 2672, DOI 10.17487/RFC2672, August 1999, <https://www.rfc-editor.org/info/rfc2672>.

[RFC2673] Crawford, M., «Binary Labels in the Domain Name System», RFC 2673, DOI 10.17487/RFC2673, August 1999, <https://www.rfc-editor.org/info/rfc2673>.

[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, «Internationalizing Domain Names in Applications (IDNA)», RFC 3490, DOI 10.17487/RFC3490, March 2003, <https://www.rfc-editor.org/info/rfc3490>.

[RFC3491] Hoffman, P. and M. Blanchet, «Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)», RFC 3491, DOI 10.17487/RFC3491, March 2003, <https://www.rfc-editor.org/info/rfc3491>.

[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, «DNS Extensions to Support IP Version 6», STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003,
<https://www.rfc-editor.org/info/rfc3596>.

[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, «Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean», RFC 3743, DOI 10.17487/RFC3743, April 2004, <https://www.rfc-editor.org/info/rfc3743>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[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>.

[RFC4343] Eastlake 3rd, D., «Domain Name System (DNS) Case Insensitivity Clarification», RFC 4343, DOI 10.17487/RFC4343, January 2006, <https://www.rfc-editor.org/info/rfc4343>.

[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>.

[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>.

[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>.

[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>.

[RFC6895] Eastlake 3rd, D., «Domain Name System (DNS) IANA Considerations», BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/info/rfc6895>.

[RFC6912] Sullivan, A., Thaler, D., Klensin, J., and O. Kolkman, «Principles for Unicode Code Point Inclusion in Labels in the DNS», RFC 6912, DOI 10.17487/RFC6912, April 2013, <https://www.rfc-editor.org/info/rfc6912>.

[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, «Architectural Considerations of IP Anycast», RFC 7094, DOI 10.17487/RFC7094, January 2014, <https://www.rfc-editor.org/info/rfc7094>.

[RFC7706] Kumari, W. and P. Hoffman, «Decreasing Access Time to Root Servers by Running One on Loopback», RFC 7706, DOI 10.17487/RFC7706, November 2015, <https://www.rfc-editor.org/info/rfc7706>.

[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>.

[RFC7816] Bortzmeyer, S., «DNS Query Name Minimisation to Improve Privacy», RFC 7816, DOI 10.17487/RFC7816, March 2016, <https://www.rfc-editor.org/info/rfc7816>.

[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>.

[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, «Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World», RFC 7872, DOI 10.17487/RFC7872, June 2016, <https://www.rfc-editor.org/info/rfc7872>.

[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>.

[Sullivan-Class] Sullivan, A., «The DNS Is Not Classy: DNS Classes Considered Useless», Work in Progress, draft-sullivan-dns-class-useless-03, July 2016.

[Unicode] The Unicode Consortium, The Unicode Standard, Version 9.0.0, (Mountain View, CA: The Unicode Consortium, 2016. ISBN 978-1-936213-13-9), <http://www.unicode.org/versions/Unicode9.0.0/>.

[Unicode-UAX15] Davis, M. and K. Whistler, «Unicode Standard Annex #15: Unicode Normalization Forms», February 2016, <http://unicode.org/reports/tr15/>.

[Unicode-USA31] Davis, M., «Unicode Standard Annex #31: Unicode Identifier and Pattern Syntax», May 2016, <http://unicode.org/reports/tr31/>.

[Vixie-20170704] Vixie, P., «Subject: Re: new DNS classes», message to the IETF dnsop mailing list, 4 July 2017, <https://www.ietf.org/mail-archive/web/ietf/current/msg103486.html>.

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

Многие из проблем и идей, описанных в этом документе, отражают разговоры в течение многих лет, некоторые из которых уходят корнями в обсуждения «ключевых слов» и «поиска» DNS, которые проводились параллельно с разработкой IDNs. Беседы с Робом Остином, Кристиной Боргман, Каролиной Карвалью, Винтом Серфом, Лайманом Чапином, Назли Чоури, Патриком Фальтстромом, Джеффом Хьюстоном, Сяодуном Ли, Карен Лю, Карен Лю, Джервас Маркхэм, Якубом Мюллером, Эндрю Салливаном, Полом Туоми, Нико Уильямс, Сюзанна Вулф, Цзянькан Яо, другие участники «поиска DNS» примерно в 2003 году и рабочей группы ICANN SSAC по IDN, а также некоторые другие, имена которых были к сожалению забыты, имели особое значение как для содержания этого документа, так и для мотивация для написания, даже если они могут не согласиться с выводами, к которым я пришел, и не несут за них ответственности.

Многие из подразделов Раздела 3 были извлечены из комментариев, впервые сделанных в связи с недавними обсуждениями по электронной почте. Комментарии Сюзанны Вульф о более раннем черновом варианте были особенно важны, так как материал был разработан с предложениями Патрика Фальтстрома, особенно в разделе 3.13. Отзывы и предложения от нескольких из вышеперечисленных и от Стефана Борцмейера, Тони Финча, Боба Гарольда, Уоррена Кумари, Крейга Партриджа и Джорджа Садовски были чрезвычайно полезны для улучшения ясности и точности частей документа, особенно для более широкой аудитории. Крейг Партридж также предоставил большую часть материалов о запросах для нескольких типов. Джефф Хьюстон сделал несколько полезных комментариев и представил большую часть Раздела 3.15, а Билл Мэннинг указал на некоторые более широкие требования к целостности информации, а также управлению и операциям DNS.

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

Адрес автора

John C. Klensin
1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140
United States of America

Phone: +1 617 245 1457
Email: john-ietf@jck.com