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. Полное заявление об авторских правах

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

Аннотация

В этом документе рассматриваются первоначальные функции и назначение системы доменных имен (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