RFC 3467 | Роль системы доменных имен (DNS)

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

Эта памятка содержит информацию для интернет-сообщества. Он не определяет интернет-стандарт любого вида. Распространение этой заметки не ограничено.

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

Оглавление

1. Введение и история
1.1 Контекст для разработки DNS
1.2 Обзор DNS и его роль в дизайне
1.3 Интернет и видимые доменные имена
1.4 Протоколы интернет-приложений и их эволюция
2. Признаки перегрузки DNS
3. Поиск, каталоги и DNS
3.1 Обзор
3.2 Некоторые детали и комментарии
4. Интернационализация
4.1 ASCII не только из-за английского
4.2 Подходы «ASCII-кодирования»
4.3 «Stringprep» и его сложности
4.4 Проблема стабильности Unicode
4.5 Аудитория, конечные пользователи и проблема пользовательского интерфейса
4.6 Визитные карточки и другое естественное использование естественных языков
4.7 Кодировки ASCII и предположение римской клавиатуры
4.8 Подходы внутри DNS для «многоязычных имен»
5. Поисковые системы: ключевые противоречия
6. Вопросы безопасности
7. Ссылки
7.1 Нормативные ссылки
7.2 Пояснительные и информативные ссылки
8. Благодарности
9. Адрес автора
10. Полное заявление об авторских правах

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

Copyright (C) Интернет-общество (2003). Все права защищены.

Аннотация

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

1. Введение и история

DNS был разработан как замена для более старой системы «таблицы хостов». Оба предназначались для предоставления имен для сетевых ресурсов на более абстрактном уровне, чем сетевые (IP) адреса (см., Например, [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]). В последние годы DNS стал удобной базой данных для Интернета со многими предложениями по добавлению новых функций. Только некоторые из этих предложений были успешными. Часто основной (или единственной) мотивацией для использования DNS является то, что он существует и широко используется, а не потому, что его существующая структура, средства и контент соответствуют конкретному применению данных. В этом документе рассматривается история DNS, включая изучение некоторых из этих более новых приложений. Затем утверждается, что процесс перегрузки часто неуместен. Вместо этого он предлагает, чтобы DNS был дополнен системами, лучше согласованными с предполагаемыми приложениями, и в общих чертах излагается структура и обоснование для одной такой системы.

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

Этот документ предполагает общее понимание терминологии RFC 1034 [RFC1034] или любого хорошего руководства по DNS (см., Например, [Albitz]).

1.1 Контекст для разработки DNS

В течение всего периода ARPANET после запуска и примерно в течение первого десятилетия работы Интернета список имен хостов и их сопоставление с адресами и с них велся в часто обновляемой «таблице хостов» [RFC625 ], [RFC811], [RFC952]. Сами имена были ограничены подмножеством ASCII [ASCII], выбранным, чтобы избежать неоднозначностей в печатной форме, чтобы обеспечить взаимодействие с системами, использующими другие кодировки символов (в частности, EBCDIC), и чтобы избежать позиций кода «национального использования» в ISO 646 [IS646 ]. Позднее эти ограничения стали называться «LDH» правилами для «буквенно-цифровых символов-дефисов», разрешенных символов. Таблица была просто списком с общим форматом, который в конечном итоге был согласован; Ожидалось, что сайты будут часто получать копии и устанавливать новые версии. Сами таблицы хостов были представлены для:

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

После нескольких лет использования подхода таблицы хостов сообщество пришло к выводу, что модель не масштабируется адекватно и что она не будет адекватно поддерживать новые варианты услуг. Был проведен ряд дискуссий и встреч, которые собрали несколько идей и неполных предложений. DNS был результатом этих усилий. Он продолжал развиваться в течение периода проектирования и первоначальной реализации, и ряд документов записывал изменения (см. [RFC819], [RFC830] и [RFC1034]).

Цели для DNS включали:

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

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

1.2 Обзор DNS и его роль в дизайне

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

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

В частности, несмотря на способность самих протоколов и структур данных приспосабливаться к любому двоичному представлению, используемые DNS-имена исторически были даже не неограниченным ASCII, а очень ограниченным его подмножеством, подмножеством, которое вытекает из исходных правил именования таблиц хоста. Выбор этого подмножества был частично обусловлен соображениями человеческого фактора, в том числе стремлением устранить возможные неясности в международном контексте. Следовательно, коды символов, которые имели международные различия в интерпретации, были исключены, знак подчеркивания и различия в регистре были исключены как вводящие в заблуждение (в случае подчеркивания, с дефисом) при написании или чтении людьми и т. Д. Эти соображения, по-видимому, очень похожи на те, которые привели к тому, что аналогичные ограниченные наборы символов используются в качестве элементов протокола во многих протоколах МСЭ и ISO (см. [X29]).

Другое предположение заключалось в том, что будет высокое соотношение физических хостов к доменам второго уровня и, в более общем плане, что система будет глубоко иерархической, с большинством систем (и имен) на третьем уровне или ниже и очень большой процент от общее количество имен, представляющих физические хосты. Существуют домены, которые следуют этой модели: многие университетские и корпоративные домены используют довольно глубокую иерархию, как и несколько ориентированных на страну доменов верхнего уровня («нДВУ»). Исторически сложилось, что «США». домен был отличным примером глубоко иерархического подхода. Однако к 1998 году сравнение нескольких попыток исследовать DNS показало количество записей SOA, которые приблизились (и, возможно, прошли) к числу отдельных хостов. С другой стороны, мы, похоже, движемся к ситуации, когда число делегированных доменов в Интернете приближается или превышает количество хостов, или, по крайней мере, количество хостов, способных предоставлять услуги другим пользователям в сети. Вероятно, это происходит из-за синонимов или псевдонимов, которые отображают большое количество имен на меньшее количество хостов. Хотя опыт, накопленный до этого времени, показал, что DNS достаточно надежен — учитывая современные машины в качестве серверов и текущие нормы пропускной способности — чтобы иметь возможность продолжать работать достаточно хорошо, когда эти исторические допущения не выполняются (например, при плоском, структура в .COM, содержащая более десяти миллионов делегированных поддоменов [COMSIZE]), все еще полезно помнить, что система могла бы быть спроектирована для оптимальной работы с плоской структурой (и очень большими зонами), а не с глубоко иерархической структурой и не было.

Точно так же, несмотря на некоторые ранние предположения о вводе имен людей и адресов электронной почты непосредственно в DNS (например, см. [RFC1034]), адреса электронной почты в Интернете сохранили первоначальный, до DNS, «пользователь (или почтовый ящик) на месте» концептуальный формат, а не плоский или строго разделенный точками. Местоположение, в этом случае, является ссылкой на хост. Единственным исключением, по крайней мере, в классе «IN», было одно поле записи SOA.

Как сама архитектура DNS, так и двухуровневые (имя хоста и имя почтового ящика) положения для электронной почты и аналогичных функций (например, см. Протокол finger [FINGER]) также предполагали относительно высокое соотношение пользователей и реальных хостов. Несмотря на то, что в RFC 1034 отмечено, что DNS должен был расти пропорционально количеству пользователей (раздел 2.3), никогда не было ясно, что DNS был серьезно спроектирован или может масштабироваться до порядка числа пользователей (или, в последнее время, продуктов или объектов документов), а не физических хостов.

Как и в случае с таблицей хостов до этого, DNS предоставил критическую уникальность для имен и универсальный доступ к ним как часть общих моделей «единого интернета» и «сквозной связи» (см. [RFC2826]). Тем не менее, есть много признаков того, что по мере развития новых видов использования и злоупотребления первоначальными предположениями (если не нарушались напрямую) система расширялась до или за пределы практических ограничений.

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

1.3 Интернет и видимые доменные имена

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

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

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

Дополнительные последствия все еще обнаруживаются и оцениваются.

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

1.4 Протоколы интернет-приложений и их эволюция

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

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

Есть много, возможно, очевидных примеров этого. Несмотря на многие известные недостатки и недостатки определения, протоколы «finger» и «whois» [WHOIS] не были заменены (несмотря на многочисленные попытки обновить или заменить последний [WHOIS-UPDATE]). Протокол Telnet и его многочисленные опции вытеснили протокол SUPDUP [RFC734], который, возможно, был намного лучше разработан для разнообразной совокупности сетевых узлов. Ряд попыток заменить протоколы электронной почты или передачи файлов моделями, которые их сторонники посчитали гораздо лучше, провалились. И совсем недавно и ниже уровня приложений есть основания полагать, что это сопротивление изменениям было одним из факторов, препятствующих развертыванию IPv6.

2. Признаки перегрузки DNS

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

Например:

  • o Хотя технические подходы, такие как более крупные и мощные серверы и большая пропускная способность, а также юридические / политические механизмы, такие как политики разрешения споров, возможно, не позволили проблемам стать критическими, DNS не оказался адекватно реагирующим на деловые и индивидуальные потребности в описании или идентифицировать вещи (такие как названия продуктов и имена людей), кроме строгих сетевых ресурсов.
  • o Хотя стеки были изменены для лучшей обработки нескольких адресов на физическом интерфейсе, а некоторые протоколы были расширены для включения имен DNS для определения контекста, DNS не особенно хорошо работает со многими именами, связанными с данным хостом (например, средствами веб-хостинга). с несколькими доменами на сервере).
  • o Усилия по добавлению имен, происходящих из языков или наборов символов, основанных на отличных от ASCII и англоязычных именах (см. ниже), или даже использования сложных названий компаний или продуктов без использования иерархии, создали очевидные требования к именам (ярлыкам). ) длиной более 63 октетов. Это требование, несомненно, со временем возрастет; хотя существуют обходные пути для размещения более длинных имен, они налагают свои собственные ограничения и вызывают свои собственные проблемы.
  • o Растущая коммерциализация Интернета и видимость доменных имен, которые предположительно совпадают с названиями компаний или продуктов, превратили DNS и DNS в поле битвы товарных знаков. Традиционная система товарных знаков (по крайней мере) в большинстве стран тщательно разграничивает области применения. Когда пространство сглаживается, без различия по географическому признаку или отраслевому сектору, вероятны конфликты не только между «Пицца Джо» (из Бостона) и «Пицца Джо» (из Сан-Франциско), но и между обоими и «Автосервисом Джо» ( Лос-Анджелес). Все трое хотели бы контролировать «Joes.com» (и предпочли бы, если бы это было разрешено правилами именования DNS, также обозначать его как «Joe’s.com» и оба разрешали одинаково) и могут требовать права на товарный знак, чтобы сделать это. поэтому, даже если конфликт или путаница не возникнут с традиционными принципами товарных знаков.
  • o Многие организации хотят иметь разные веб-сайты под одним и тем же URL и именем домена. Иногда это делается для создания локальных вариантов — компания Widget может захотеть представить другой материал британскому пользователю по сравнению с американским — и иногда это должно обеспечить более высокую производительность, предоставляя информацию с сервера, топологически ближайшего к пользователю. Если механизм разрешения имен должен обеспечивать эту функциональность, есть три возможных модели (которые могут быть объединены):

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

— принять атрибуты сайта клиента и использовать их в процессе поиска, или

— возвращать разные ответы в зависимости от местоположения или личности запрашивающего.

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

Эти и подобные им проблемы производительности или выбора контента, конечно, могут рассматриваться как не связанные с DNS вообще. Например, часто цитируемый альтернативный подход, связывающий эти проблемы с согласованием содержимого HTTP (см. [RFC2295]), требует, чтобы сначала было установлено соединение HTTP с некоторым «общим» или «основным» хостом, чтобы можно было согласовать предпочтения и Затем клиент перенаправил или отправил альтернативные данные. По крайней мере, с точки зрения улучшения производительности путем доступа к «более близкому» местоположению, как вначале, так и после этого, этот подход жертвует желаемым результатом до того, как клиент инициирует какое-либо действие. Можно даже утверждать, что некоторые характеристики общих подходов к согласованию контента — это обходные пути для неоптимального использования DNS в веб-URL.

  • Многие существующие и предлагаемые системы «поиска вещей в Интернете» требуют наличия реальной возможности поиска, при которой пользователю может быть сообщено о близких совпадениях (или некоторому пользовательскому агенту с соответствующим набором правил) и какие запросы могут быть неоднозначными или нечеткая. DNS, напротив, может вместить только один набор (довольно жестких) правил сопоставления. Предложения о разрешении использования различных правил в разных местах (например, сопоставление правил, относящихся к TLD или зоне), помогают выявить проблему. Но они не могут быть применены непосредственно к DNS, не отказываясь ни от желаемого уровня гибкости, ни от изоляции различных частей Интернета друг от друга (или обоих). Нечеткие или неоднозначные поиски желательны для разрешения имен, которые могут иметь вариации правописания, и для имен, которые могут быть преобразованы в различные наборы глифов в зависимости от контекста. Особенно, когда рассматривается интернационализация, проблемы с вариантами имен выходят за рамки простых различий в представлении символа или упорядочении строки. Вместо этого, чтобы избежать удивления пользователя и путаницы, необходимо учитывать отношения, такие как языки, которые могут быть написаны разными алфавитами, отношения кандзи-хирагана, упрощенный и традиционный китайский и т. Д. См. [Seng] для обсуждения и предложений по решению подмножества этих проблем. в контексте символов на основе китайских. Но этот документ, по существу, иллюстрирует сложность предоставления типа гибкого сопоставления, ожидаемого пользователями; вместо этого он пытается защитить себя от наихудших типов путаницы (и возможностей для мошенничества).
  • Исторический DNS и приложения, которые делают предположения о том, как он работает, создают значительный риск (или приводят к возникновению технических ошибок и вытекающих из этого странных ограничений), когда рассматривается возможность добавления механизмов для использования с различными многоязычными и многоязычными системами «интернационализации». См. Обсуждение IAB некоторых из этих вопросов [RFC2825] для получения дополнительной информации.
  • Чтобы обеспечить надлежащую функциональность для Интернета, DNS должен иметь единый уникальный корень (IAB предоставляет более подробное обсуждение этой проблемы [RFC2826]). Есть много желаний для локальной обработки имен или наборов символов, которые не могут быть адаптированы без нескольких корней (например, отдельный корень для многоязычных имен, предложенных в разное время MINC [MINC] и другими), или механизмов, которые будут иметь аналогичные эффекты с точки зрения фрагментации и изоляции Интернета.
  • Для некоторых целей желательно иметь возможность поиска не только записи индекса (метки или полные имена в случае DNS), но и их значений или целей (данные DNS). Можно, например, захотеть найти все имена хостов (и виртуальных хостов), которые заставляют почту направляться на данный сервер через записи MX. DNS не поддерживает эту возможность (см. Обсуждение в [IQUERY]), и ее можно смоделировать только путем извлечения всех соответствующих записей (возможно, путем переноса зоны, если источник разрешает это делать, но это разрешение становится все менее доступным) а затем поиск файла, созданного из этих записей.
  • Наконец, когда в DNS добавляются дополнительные типы личной или идентифицирующей информации, возникают проблемы с защитой этой информации. Увеличивается количество запросов на предоставление различной информации на основе учетных данных и авторизации источника запроса. Как и в случае информации, привязанной к местоположению или близости сайта (как обсуждалось выше), протоколы DNS делают предоставление этих дифференцированных услуг довольно трудным, если не невозможным.

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

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

3. Поиск, каталоги и DNS

3.1 Обзор

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

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

Следующие пункты иллюстрируют конкретные аспекты этого вывода.

  • Система каталогов не требует наложения определенных ограничений на длину имен.
  • Система каталогов может разрешить явную ассоциацию атрибутов, например языка и страны, с именем без необходимости использовать специальные кодировки для включения этой информации в метки DNS (или создания искусственной иерархии для этого).
  • Имеется значительный опыт (хотя и не очень успешный) в области нечеткого и «сингексного» (схожего звучания) сопоставления в системах каталогов. Более того, можно подумать о разных правилах сопоставления для разных областей и наборов названий, чтобы они могли быть адаптированы к местным культурным требованиям. В частности, может быть возможно иметь единственную форму имени в каталоге, но иметь большую гибкость в отношении того, какие запросы соответствуют этому имени (и даже имеют разные вариации в разных областях). Конечно, чем больше гибкости обеспечивает система, тем больше вероятность возникновения реальных или воображаемых конфликтов торговых марок. Но была бы возможность разработать структуру каталогов, которая бы умело решала эти проблемы, в то время как ограничения DNS почти наверняка делают невозможным общее и справедливое решение только для DNS.
  • Если система каталогов используется для перевода имен DNS, а затем имена DNS ищутся обычным способом, может оказаться возможным ослабить некоторые из ограничений, которые были традиционными (и, возможно, необходимыми) для DNS. Например, обратное сопоставление адресов с именами каталогов может не требоваться, даже если сопоставление адресов с именами DNS продолжает существовать, поскольку имена DNS будут (продолжать) однозначно идентифицировать хост.
  • Решения для многоязычных проблем транскрипции, которые распространены в «нормальной жизни» (например, двусторонние визитные карточки, чтобы быть уверенными, что получатели, пытающиеся связаться с человеком, могут получить доступ к латинизированным написаниям и цифрам, если исходный язык для них не понятен) легко обрабатывается в системе каталогов, вставляя оба набора записей.
  • Можно разработать систему каталогов, которая будет возвращать не одно имя, а набор имен в паре с информацией о местоположении в сети или другими атрибутами, устанавливающими контекст. Этот тип информации может быть весьма полезен при решении проблем «ближайшего (или лучшего) сервера для определенного именованного ресурса», которые представляют серьезную проблему для организаций, размещающих веб-сайты и другие сайты, доступ к которым осуществляется из самых разных мест и подсетей.
  • Названия, привязанные к странам и языкам, могут помочь управлять реалиями товарных знаков, в то время как, как обсуждалось в разделе 1.3 выше, использование DNS в значимых для товарных знаков контекстах, как правило, требует всемирного «выравнивания» системы товарных знаков.

Многие из этих проблем являются следствием другого свойства DNS: имена должны быть уникальными в Интернете. Необходимость иметь систему уникальных идентификаторов довольно очевидна (см. [RFC2826]). Однако если бы это требование было устранено в системе поиска или каталогов, которая была бы видна пользователям вместо DNS, многие сложные проблемы — как технического, так и политического характера — могли бы исчезнуть.

3.2 Некоторые детали и комментарии

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

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

Существует сильный исторический аргумент в пользу единой структуры каталогов (что подразумевает необходимость в механизмах регистрации, делегирования и т. Д.). Но отдельная структура не является строгим требованием, особенно если глубокий анализ случаев и проектные работы приводят к выводу, что обратное сопоставление с именами каталогов не является обязательным (см. Раздел 5). Если отдельная структура не нужна, то, в отличие от DNS, глобальная организация не будет требовать авторизации или делегирования операций для частей структуры.

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

Хотя приведенное выше обсуждение включает в себя очень общие комментарии об атрибутах, представляется, что потребуется лишь очень небольшое количество атрибутов. Список почти наверняка будет включать страну и язык для целей интернационализации. Может потребоваться «кодировка», если мы не можем согласовать набор символов и кодировку, хотя существуют веские аргументы в пользу простого использования ISO 10646 (также известного как Unicode или «UCS» (для универсального набора символов) [UNICODE], [IS10646] кодирования В обмене. Проблемы с товарными знаками могут мотивировать «коммерческие» и «некоммерческие» (или другие) атрибуты, если они будут полезны в обход проблем с товарными знаками, а также приложений к расположению ресурсов, например, предусмотренных для универсальных идентификаторов ресурсов (URI) [RFC2396 , RFC3305] или протокол определения местоположения службы [RFC2608], может приводить аргументы в пользу нескольких других атрибутов (как описано выше).

4. Интернационализация

Большая часть размышлений, лежащих в основе этого документа, была обусловлена ​​соображениями интернационализации DNS или, более конкретно, предоставления доступа к функциям DNS из языков и систем имен, которые не могут быть точно выражены в традиционном подмножестве DNS ASCII. Большая часть соответствующей работы была проделана в рабочей группе IETF «Интернационализированные доменные имена» (IDN-WG), хотя этот документ также опирается на обширные параллельные дискуссии на других форумах. В этом разделе содержится оценка того, что было изучено как «интернационализированный DNS» или «многоязычный DNS», и предлагаются дальнейшие шаги на основе этой оценки.

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

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

4.1 ASCII не только из-за английского

Правила имени хоста, выбранные в середине 70-х годов, были не просто «ASCII, потому что английский использует ASCII», хотя это было отправной точкой. Мы обнаружили, что почти любой другой сценарий (и даже ASCII, если мы разрешаем остальные символы, указанные в международной справочной версии ISO 646) более сложен, чем hostnamerestricted-ASCII (форма «LDH», см. Раздел 1.1). И ASCII недостаточно для полного представления английского языка — в этом языке есть несколько слов, которые правильно пишутся только с символами или диакритическими знаками, которых нет в ASCII. При более широком выборе сценариев в некоторых примерах отображение случаев работает от одного случая к другому, но не является обратимым. В других существуют соглашения об альтернативных способах представления символов (на языке, не только в кодировке символов), которые работают большую часть времени, но не всегда. И есть проблемы в кодировании: Unicode / 10646 предоставляет различные способы представления одного и того же символа (здесь намеренно используется «символ», а не «глиф»). И, в то же время, есть вопросы о том, совпадают ли два глифа, что может быть вопросом о функции расстояния, а не вопросом с двоичным ответом. Подход IETF к этим проблемам состоит в том, чтобы требовать предварительного сопоставления канонизации (см. Обсуждение «stringprep» ниже).

IETF сопротивлялся соблазнам либо попытаться указать совершенно новый набор кодированных символов, либо выбрать и выбрать символы Unicode / 10646 для каждого символа, а не с помощью четко определенных блоков. Хотя может показаться, что набор символов, предназначенный для удовлетворения специфических интернет-потребностей, был бы очень привлекательным, у IETF никогда не было опыта, ресурсов и представительства от критически важных сообществ, чтобы фактически взять на себя эту работу. Возможно, что еще более важно, новое усилие могло бы решить сделать некоторые из множества сложных компромиссов другими, чем комитет по Юникоду, создав код с несколько другими характеристиками. Но нет никаких доказательств того, что в результате получился бы код с меньшим количеством проблем и побочных эффектов. Гораздо более вероятно, что изменение компромисса по-другому просто приведет к другому набору проблем, которые будут одинаково или более сложными.

4.2 Подходы «ASCII-кодирования»

Хотя DNS может обрабатывать произвольные двоичные строки без известных внутренних проблем (см. [RFC2181]), некоторые ограничения налагаются требованием интерпретации текста без учета регистра ([RFC1034], [RFC1035]). Что еще более важно, большинство интернет-приложений предполагают ограниченный по имени хоста синтаксис «LDH», который указан в RFC таблицы хостов и как «разумный» в RFC 1035. Если эти предположения не выполняются, многие соответствующие реализации этих приложений могут демонстрировать поведение, которое сюрприз разработчиков и пользователей. Чтобы избежать этих потенциальных проблем, работа по интернационализации IETF была сосредоточена на «ASCII-совместимых кодировках» (ACE). Эти кодировки сохраняют соглашения LDH в самой DNS. Реализации приложений, которые не были обновлены, используют закодированные формы, в то время как более новые могут быть написаны, чтобы распознавать специальные кодировки и отображать их в символы не ASCII. Эти подходы, однако, не беспроблемны, даже если проблемы с интерфейсом человека игнорируются. Среди других проблем они полагаются на то, что в конечном счете является эвристическим, чтобы определить, следует ли рассматривать метку DNS как интернационализированное имя (то есть закодированное Unicode) или интерпретировать как фактическое имя LDH само по себе. И хотя все определения того, соответствует ли конкретный запрос хранимому объекту, традиционно делаются DNS-серверами, системы ACE в сочетании со сложностями международных сценариев и имен требуют, чтобы большая часть работы по сопоставлению была разделена на отдельный клиент с другой стороны, процесс канонизации или «подготовки» перед вызовом механизмов сопоставления DNS [STRINGPREP].

4.3 «Stringprep» и его сложности

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

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

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

  • снятие гласных на арабском или иврите
  • сопоставление одинаковых символов, таких как верхний регистр букв на греческом и верхний регистр букв на основе латинского алфавита
  • сопоставление традиционных и упрощенных китайских иероглифов, представляющих одни и те же слова,
  • сопоставление сербохорватских слов, написанных латинскими или кириллическими буквами

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

Даже если бы другая работа IDN-WG была полностью прекращена или если она потерпела бы неудачу на рынке, работа stringprep и nameprep будет по-прежнему чрезвычайно полезна как для выявления проблем и проблемных точек кода, так и для обеспечения разумного набора основные правила. Там, где проблемы остаются, они, возможно, связаны не с nameprep, а с введенным DNS требованием, чтобы его результаты, как и во всех других частях процесса сопоставления и сравнения, давали бинарный ответ «соответствует или не соответствует», а не, например, значение по шкале сходства, которое может быть оценено пользователем или управляемыми пользователем эвристическими функциями.

4.4 Проблема стабильности Unicode

ISO 10646 в основном определяет только кодовые точки, а не правила использования или сравнения символов. Это является частью давней традиции работы с тем, что сейчас является стандартом ISO / IEC JTC1 / SC2: они выполнили присвоение кодовых точек и, как правило, рассматривали способы использования символов как выходящие за их рамки. Следовательно, они не смогли эффективно решить более широкий круг вопросов интернационализации. Технический комитет Unicode (UTC), напротив, определил в приложениях и технических отчетах (см., Например, [UTR15]) некоторые дополнительные правила для канонизации и сравнения. Многие из этих правил и соглашений были учтены в работах «stringprep» и «nameprep», но не так просто сделать или определить их так, чтобы они были достаточно точными и постоянными, на которые могла бы положиться DNS.

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

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

Определение Unicode также развивается. Версия 3.2 появилась вскоре после начала работы над этим документом. Он добавил некоторые символы и функциональность и включил несколько незначительных несовместимых изменений кода. IETF добился соглашения об ограничениях на будущие изменения, но еще неизвестно, как это соглашение будет работать на практике. На данном этапе прогноз на самом деле кажется плохим, так как UTC выбрал для голосования недавнее возможное изменение, которое должно было быть запрещено соглашением (результат голосования не имеет значения, только то, что голосование было выдано, а не было предрешено заключение). Однако некоторые члены сообщества считают, что некоторые изменения между Unicode 3.0 и 3.1 и между 3.1 и 3.2, а также это недавнее голосование являются свидетельством нестабильности и что эти нестабильности лучше обрабатываются в системе, которая может быть более гибкой Об обработке символов, сценариев и вспомогательной информации, чем DNS.

Кроме того, поскольку влияние системы на интернационализацию в SC2 считается вне области применения, ИСО / МЭК JTC1 поручил некоторые из этих проблем своей SC22 / WG20 (рабочей группе по интернационализации в рамках подкомитета, которая занимается языками программирования, системами и средами). ). WG20 исторически вдумчиво и глубоко рассматривал вопросы интернационализации, но за последние годы его статус несколько раз подвергался сомнению. Однако отнесение этих вопросов к WG20 увеличивает риск возможных стандартов интернационализации ISO, которые определяют поведение, отличное от спецификаций UTC.

4.5 Аудитория, конечные пользователи и проблема пользовательского интерфейса

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

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

  • Если мы хотим сделать это проблемой в другой части структуры пользовательского интерфейса, нам нужно выяснить, к чему это приведет, чтобы получить подтверждение концепции нашего решения. В отличие от поставщиков, единственной [бизнес-моделью] которых является продажа или регистрация имен, IETF должна создавать решения, которые действительно работают в контексте приложений, как это видит конечный пользователь.
  • Принцип «они привыкнут к нашим соглашениям и адаптируются» — это хорошо, если мы пишем правила для языков программирования или API. Но обсуждаемые соглашения не являются частью полуматематической системы, они глубоко укоренились в культуре. Неважно, как часто англоговорящему американцу говорят, что Интернет требует правильного написания слова «цвет», он или она не будут убеждены. Заставить франкоязычного в Лионе использовать те же лексические соглашения, что и франкоязычного в Квебеке, чтобы учесть решения IETF, регистратора или реестра, маловероятно. «Монреаль» — это либо орфографическая ошибка или англицизация схожего слова с острым акцентом над буквой «е» (т. Е. С использованием символа Unicode U + 00E9 или одного из его эквивалентов). Но глобальное соглашение о правиле, которое определит, должны ли эти две формы совпадать — и это не удивит конечных пользователей и носителей одного или другого языка, — столь же маловероятно, как соглашение о том, является ли «орфографическая ошибка» или «англицизация» большая пародия.

В целом, неясно, что результат любого мыслимого процесса, подобного nameprep, будет достаточно хорошим для практического использования на уровне пользователя. При использовании людьми человеческих языков во многих случаях вещи, которые не совпадают, тем не менее интерпретируются как соответствующие. Норвежский / датский символ, который появляется в U + 00F8 (визуально, строчная буква «o» перегружена косой чертой) и «o-umlaut» немецкий символ, который появляется в U + 00F6 (визуально, строчная буква «o» с диарезом (или умлаутом)) явно отличаются, и ни одна из подходящих программ не должна давать «равного» сравнения. Но они больше похожи друг на друга, чем любой из них, например, «е». Люди могут мысленно вносить исправления в контексте, и делают это легко, и они могут быть удивлены, если компьютеры не могут сделать это. Хуже того, есть шведский символ, внешний вид которого идентичен немецкому o-umlaut, и который разделяет кодовую точку U + 00F6, но если языки известны и считаются звуки букв или значений слов, включая символ , на самом деле должно соответствовать норвежскому / датскому использованию U + 00F8.

В этом тексте используются примеры из латинского алфавита, потому что он написан на английском языке, и эти примеры относительно легко воспроизводить. Но один из важных уроков дискуссий об интернационализации доменных имен в последние годы заключается в том, что проблемы, аналогичные описанным выше, существуют почти на каждом языке и сценарии. У каждого есть свои особенности, и каждый набор особенностей связан с общими вопросами использования и культурными проблемами, которые очень знакомы в соответствующей группе и часто глубоко воспринимаются как культурные ценности. До тех пор, пока школьник в США может получить плохую оценку за тест на орфографию за использование совершенно правильного британского правописания, или у школьника во Франции или Германии может быть плохая оценка за отрыв от диакритического знака, существуют проблемы с соответствующим языком. , Точно так же, если детей в Египте или Израиле учат, что можно написать слово с гласными или без ударных или без знаков ударения, но если эти отметки включены, они должны быть правильными, или пользователь в Корее может быть обижен или удивленные последовательностями Jamo не по порядку, системы, основанные на посимвольной обработке и упрощенном сопоставлении, без контекстной информации, не будут удовлетворять потребности пользователей.

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

4.6 Визитные карточки и другое естественное использование естественных языков

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

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

4.7 Кодировки ASCII и предположение римской клавиатуры

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

4.8 Подходы внутри DNS для «многоязычных имен»

Из вышеупомянутых и других случаев выясняется, что ни одно из основанных на DNS решений для «многоязычных имен» не работает. Они опираются на слишком много предположений, которые кажутся неосуществимыми — что люди будут адаптировать глубоко укоренившиеся языковые привычки к соглашениям, установленным для облегчения жизни компьютеров; что мы можем принять решение «заморозить его сейчас, не нужно вносить изменения в этих областях» в отношении Unicode и nameprep; что ACE сгладит проблемы приложений, даже в средах, где нет возможности набирать или отображать глифы на основе римского алфавита (или когда пользовательский опыт таков, что такие глифы нельзя легко отличить друг от друга); что консорциум Unicode никогда не решит исправить ошибку таким образом, чтобы создать риск несовместимости DNS; что мы можем либо развернуть EDNS [RFC2671], либо что длинные имена не очень важны; что японские и китайские пользователи компьютеров (и другие) либо откажутся от своих локальных или основанных на IS 2022 решений для кодирования символов (для которых добавление большой части миллиона новых кодовых точек в Unicode почти наверняка необходимо, но, вероятно, недостаточно) , условие) или построить герметичные и полностью точные механизмы преобразования границ; что внеплановой или контекстной информации всегда будет достаточно для проблемы «сопоставить глиф со сценарием»; и так далее. В каждом случае вероятно, что около 80% или 90% случаев будут работать удовлетворительно, но маловероятно, что такие частичные решения будут достаточно хорошими. Например, предположим, что кто-то может правильно написать свое имя на 90%, или название компании соответствует правильно в 80% случаев, но другие 20% попыток идентифицируют конкурента: либо они могут считаться адекватными?

5. Поисковые системы: ключевые противоречия

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

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

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

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

Наконец, система отдельных каталогов и баз данных, в сочетании с удалением DNS-требования к уникальным именам, в значительной степени устранит необходимость в едином всемирном органе управления вершиной иерархии имен.

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

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

7. Ссылки

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

Нет

7.2 Пояснительные и информативные ссылки

[Albitz] Any of the editions of Albitz, P. and C. Liu, DNS and BIND, O’Reilly and Associates, 1992, 1997, 1998, 2001.

[ASCII] American National Standards Institute (formerly United States of America Standards Institute), X3.4, 1968, «USA Code for Information Interchange». ANSI X3.4-1968
has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet. Some time after ASCII was first formulated as a standard, ISO adopted international standard 646, which uses ASCII as a base. IS 646 actually contained two code tables: an «International Reference Version» (often referenced as ISO 646-IRV)
which was essentially identical to the ASCII of the time, and a «Basic Version» (ISO 646-BV), which designates a number of character positions for national use.

[CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, «Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy», RFC 1519, September 1993. Eidnes, H., de Groot, G. and P. Vixie, «Classless INADDR. ARPA delegation», RFC 2317, March 1998.

[COM-SIZE] Size information supplied by Verisign Global Registry Services (the zone administrator, or «registry operator», for COM, see [REGISTRAR], below) to ICANN, third quarter 2002.

[DNS-Search] Klensin, J., «A Search-based access model for the DNS», Work in Progress.

[FINGER] Zimmerman, D., «The Finger User Information Protocol», RFC 1288, December 1991. Harrenstien, K., «NAME/FINGER Protocol», RFC 742, December 1977.

[IAB-OPES] Floyd, S. and L. Daigle, «IAB Architectural and Policy Considerations for Open Pluggable Edge Services», RFC 3238, January 2002.

[IQUERY] Lawrence, D., «Obsoleting IQUERY», RFC 3425, November 2002.

[IS646] ISO/IEC 646:1991 Information technology — ISO 7-bit coded character set for information interchange

[IS10646] ISO/IEC 10646-1:2000 Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane and ISO/IEC 10646-2:2001 Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 2: Supplementary Planes

[MINC] The Multilingual Internet Names Consortium, http://www.minc.org/ has been an early advocate for the importance of expansion of DNS names to accommodate non-ASCII characters. Some of their specific proposals, while helping people to understand the problems better, were not compatible with the
design of the DNS.

[NAPTR] Mealling, M. and R. Daniel, «The Naming Authority Pointer (NAPTR) DNS Resource Record», RFC 2915, September 2000.
Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS», RFC 3401, October 2002.
Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm», RFC 3402, October 2002.
Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database», RFC 3403, October 2002.

[REGISTRAR] In an early stage of the process that created the Internet Corporation for Assigned Names and Numbers (ICANN), a «Green Paper» was released by the US Government. That paper introduced new terminology and some concepts not needed by traditional DNS operations. The term «registry» was applied to the actual operator and database holder of a domain (typically at the top level, since the Green Paper was little concerned with anything else), while organizations that marketed names and made them available to «registrants» were known as «registrars».
In the classic DNS model, the function of «zone administrator» encompassed both registry and registrar roles, although that model did not anticipate a commercial market in names.

[RFC625] Kudlick, M. and E. Feinler, «On-line hostnames service», RFC 625, March 1974.

[RFC734] Crispin, M., «SUPDUP Protocol», RFC 734, October 1977.

[RFC811] Harrenstien, K., White, V. and E. Feinler, «Hostnames Server», RFC 811, March 1982.

[RFC819] Su, Z. and J. Postel, «Domain naming convention for Internet user applications», RFC 819, August 1982.

[RFC830] Su, Z., «Distributed system for Internet name service», RFC 830, October 1982.

[RFC882] Mockapetris, P., «Domain names: Concepts and facilities», RFC 882, November 1983.

[RFC883] Mockapetris, P., «Domain names: Implementation specification», RFC 883, November 1983.

[RFC952] Harrenstien, K, Stahl, M. and E. Feinler, «DoD Internet host table specification», RFC 952, October 1985.

[RFC953] Harrenstien, K., Stahl, M. and E. Feinler, «HOSTNAME SERVER», RFC 953, October 1985.

[RFC1034] Mockapetris, P., «Domain names, Concepts and facilities», STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

[RFC1591] Postel, J., «Domain Name System Structure and Delegation», RFC 1591, March 1994.

[RFC2181] Elz, R. and R. Bush, «Clarifications to the DNS Specification», RFC 2181, July 1997.

[RFC2295] Holtman, K. and A. Mutz, «Transparent Content Negotiation in HTTP», RFC 2295, March 1998

[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, «Uniform Resource Identifiers (URI): Generic Syntax», RFC 2396, August 1998.

[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, «Service Location Protocol, Version 2», RFC 2608, June 1999.

[RFC2671] Vixie, P., «Extension Mechanisms for DNS (EDNS0)», RFC 2671, August 1999.

[RFC2825] IAB, Daigle, L., Ed., «A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols», RFC 2825, May 2000.

[RFC2826] IAB, «IAB Technical Comment on the Unique DNS Root», RFC 2826, May 2000.

[RFC2972] Popp, N., Mealling, M., Masinter, L. and K. Sollins, «Context and Goals for Common Name Resolution», RFC 2972, October 2000.

[RFC3305] Mealling, M. and R. Denenberg, Eds., «Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations», RFC 3305, August 2002.

[RFC3439] Bush, R. and D. Meyer, «Some Internet Architectural Guidelines and Philosophy», RFC 3439, December 2002.

[Seng] Seng, J., et al., Eds., «Internationalized Domain Names: Registration and Administration Guideline for Chinese, Japanese, and Korean», Work in Progress.

[STRINGPREP] Hoffman, P. and M. Blanchet, «Preparation of Internationalized Strings (stringprep)», RFC 3454, December 2002.
The particular profile used for placing internationalized strings in the DNS is called «nameprep», described in Hoffman, P. and M. Blanchet, «Nameprep: A Stringprep Profile for Internationalized Domain Names», Work in Progress.

[TELNET] Postel, J. and J. Reynolds, «Telnet Protocol Specification», STD 8, RFC 854, May 1983. Postel, J. and J. Reynolds, «Telnet Option Specifications», STD 8, RFC 855, May 1983.

[UNICODE] The Unicode Consortium, The Unicode Standard, Version 3.0, Addison-Wesley: Reading, MA, 2000. Update to version 3.1, 2001. Update to version 3.2, 2002.

[UTR15] Davis, M. and M. Duerst, «Unicode Standard Annex #15: Unicode Normalization Forms», Unicode Consortium, March 2002. An integral part of The Unicode Standard,
Version 3.1.1. Available at (http://www.unicode.org/reports/tr15/tr15-21.html).

[WHOIS] Harrenstien, K, Stahl, M. and E. Feinler, «NICNAME/WHOIS», RFC 954, October 1985.

[WHOIS-UPDATE] Gargano, J. and K. Weiss, «Whois and Network Information Lookup Service, Whois++», RFC 1834, August 1995.
Weider, C., Fullton, J. and S. Spero, «Architecture of the Whois++ Index Service», RFC 1913, February 1996.

Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. Zeilstra, «Referral Whois (RWhois) Protocol V1.5», RFC 2167, June 1997;

Daigle, L. and P. Faltstrom, «The application/whoispp-query Content-Type», RFC 2957, October 2000.

Daigle, L. and P. Falstrom, «The application/whoisppresponse Content-type», RFC 2958, October 2000.

[X29] International Telecommuncations Union, «Recommendation X.29: Procedures for the exchange of control information and user data between a Packet Assembly/Disassembly (PAD) facility and a packet mode DTE or another PAD», December 1997.

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

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

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

John C. Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
EMail: klensin+srch@jck.com

Список рассылки был инициирован для обсуждения тем, обсуждаемых в этом документе, и тесно связанных вопросов, по адресу ietf-irnss@lists.elistx.com. Смотрите http://lists.elistx.com/archives/ для подписки и архивной информации.

Copyright (C) Интернет-общество (2003). Все права защищены.

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

Ограниченные разрешения, предоставленные выше, являются бессрочными и не будут отменены Обществом Интернета или его правопреемниками или правопреемниками.

Этот документ и информация, содержащаяся в настоящем документе, предоставляются на условиях «КАК ЕСТЬ», и ИНТЕРНЕТ-ОБЩЕСТВО И ИНТЕРНЕТ-ИНЖЕНЕРНАЯ ЗАДАЧА ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, НО ОГРАНИЧИВАЕТСЯ НИКАКИХ ГАРАНТИЙ, ЧТО ИСПОЛЬЗОВАНИЕ ИНФОРМАЦИИ ЗДЕСЬ НЕ БУДЕТ НАРУШИТЬ ЛЮБЫЕ ПРАВА ИЛИ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОГО ОБЕСПЕЧЕНИЯ ИЛИ ПРИГОДНОСТИ ДЛЯ ОСОБЫХ ЦЕЛЕЙ.

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

Финансирование функции RFC Editor в настоящее время обеспечивается Обществом Интернета.

Поделись записью