Internet-Draft | Постановка проблемы: DNS-разрешение псевдонимов имен

draft-ietf-dnsext-aliasing-requirements-00

Аннотация

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

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

Оглавление

1. Введение
1.1. Что делает этот документ?
1.2. Что этот документ не делает?
1.3. Терминология
2. Постановка проблемы
2.1. Регистрация вариантов доменного имени
2.2. Одинаковое разрешение DNS для связанных DNS-имен
2.3. Варианты символа
2.3.1. Пример: упрощенный и традиционный китайский
2.3.2. Пример: греческий
2.3.3. Пример: арабский
2.4. Использование вариантов
3. Эксплуатационные соображения
3.1. Серверы обеспечения зоны и авторизации
3.1.1. Предоставление псевдонимов в реестре
3.1.2. Воздействие специальных механизмов
3.2. Рекурсивные резольверы
3.3. Приложения
4. Предлагаемые требования
5. Возможные решения
5.1. Сопоставление или перенаправление доменных имен
5.1.1. Картографирование себя
5.1.2. Картирование его потомков
5.1.3. Картографирование себя и его потомков
5.2. Зона Clone
6. Соображения IANA
7. Вопросы безопасности
8. Благодарности
9. История изменений
9.1. draft-yao-dnsext-identical-resolution: версия 00
9.2. draft-yao-dnsext-identical-resolution: версия 01
10. Ссылки
10.1. Нормативные ссылки
10.2. Информационные ссылки
Адреса авторов

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

Этот Интернет-черновик представлен в полном соответствии с положениями BCP 78 и BCP 79.

Интернет-черновики являются рабочими документами Инженерной рабочей группы по Интернету (IETF). Обратите внимание, что другие группы могут также распространять рабочие документы как Интернет-проекты. Список текущих интернет-черновиков находится по адресу http://datatracker.ietf.org/drafts/current/.

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

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

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

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

Этот документ может содержать материалы из Документов IETF или Вкладов IETF, опубликованных или обнародованных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из этих материалов, возможно, не предоставили Трасту IETF право разрешать модификации таких материалов. вне процесса стандартизации IETF.

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

1. Введение

Поскольку Интернет и DNS эволюционировали за пределы своих первоначальных сфер использования, появился ряд потребностей и ожиданий относительно того, как ведут себя метки DNS, что в значительной степени основывается на общих человеческих предположениях о том, как работают «имена» или «слова». Одним из аспектов этого является понятие или ожидание того, что несколько наборов имен могут быть похожи на человека-пользователя и, как ожидается, будут вести себя «одинаково» или как «псевдонимы» друг друга в нескольких сервисах и взаимодействиях. DNS был спроектирован с неявным ожиданием того, что имена будут основаны на символах ASCII, и свойство «сходства» или «одинаковости», по-видимому, не очень часто встречается в именах, которые люди первоначально хотели использовать в DNS; таким образом, требования идентичного разрешения «псевдонимных» или «связанных» имен не фигурируют в качестве атрибута, который необходимо учитывать при создании или поиске имен DNS. Однако со стандартизацией протоколов интернационализированных доменных имен (ref: IDNA и IDNAbis) в зонах DNS появляется все больше и больше интернационализированных меток доменных имен [RFC3490]. В некоторых случаях эти метки [RFC3743] сопровождаются ожиданием того, что они «эквивалентны» или должны вести себя «одинаково», часто потому, что эти метки получены из имен или строк, которые пользователи считают «одинаковыми» в некоторых языках. Соответственно, интернет-пользователи надеются, что такие метки будут вести себя в контексте DNS, поскольку они ожидают, что соответствующие человеческие конструкции будут вести себя независимо от конкретной службы (smtp, http и т. д.).

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

Существует некоторая существующая технология, определенная в DNS для поведения, которое можно описать как одно имя, которое ведет себя «так же, как другое». Для одного узла в дереве DNS CNAME может использоваться для сопоставления одного имени как «псевдонима» с другим, «каноническим» именем. Если необходимо сопоставить поддерево DNS — зоны или домена и его поддоменов — с другим доменом, DNAME был определен, чтобы разрешить такое поведение. Тем не менее, в настоящее время не определено, как сделать то и другое, поскольку CNAME должна быть единственной записью на своем узле в дереве. Поведение, объединяющее характеристики CNAME и DNAME, в настоящее время не определено в DNS.

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

1.1. Что делает этот документ?

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

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

Для любых возможных изменений протокола DNS предлагается список общих требований.

Мы также проверяем существующие конструкции (CNAME, DNAME) и предлагаемые новые («BNAME», «клоны зоны») на соответствие предлагаемым требованиям.

1.2. Что этот документ не делает?

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

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

1.3. Терминология

Все основные термины, используемые в данной спецификации, определены в документах [RFC1034], [RFC1035], [RFC2672] и [RFC3490].

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

2. Постановка проблемы

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

Один вопрос состоит в том, что именно следует определять как «то же самое»? Являются ли конечные результаты идентичными, и если да, то с какой точки зрения: у рекурсивного резольвера? Приложение? Человеческий потребитель контента? Достаточно ли того, что поиск в части FQDN адреса электронной почты приводит к тем же записям A или AAAA, или необходимо поддерживать некоторое промежуточное сопоставление между записями MX в цепочке разрешений? Как насчет части FQDN URL-адреса, переданного приложению, или в процессах разрешения, которые включают в себя несколько поисков записей, которые могут включать FQDN? Должны ли быть общие правила, определенные для обработки полных доменных имен в RDATA настоящего и будущего типов RR?

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

Кроме того, древовидная структура DNS требует, чтобы мы рассмотрели поведение «идентичных» имен в нескольких зонах в иерархии. Должны ли отображения поддерживаться в именах больше, чем уровень или два, глубоко? Если да, то с какими характеристиками и какими характеристиками требуется масштабируемость?

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

2.1. Регистрация вариантов доменного имени

Введение IDN предоставило принудительную функцию для определения того, как «варианты» могут вести себя как DNS-имена. Общепризнанно, что признание и тщательное управление случаями, когда несколько имен связаны друг с другом как «варианты» в ожидании или предпочтении пользователей, имеют важное значение; без такого управления сгруппированными доменными именами риски безопасности могут быть увеличены, а качество взаимодействия с пользователем может быть поставлено под угрозу. [RFC3743], разработанный JET (Joint Engineering Team), дает одно из возможных решений о том, как управлять регистрацией доменного имени, предназначенного для применения к сценарию и использования, распространенного среди пользователей из Китая, Японии и Кореи.

[RFC3743] предложил алгоритм, который будет распределять группу имен, состоящую из имени домена и его вариантов, одному и тому же владельцу домена. Это означает, что владелец домена получит контроль над доменным именем и его вариантами. [RFC4290] предлагает использовать практику [RFC3743] при регистрации интернационализированных доменных имен. Но [RFC3743] и [RFC4290] не определяют, как именно эти пачки имен должны обрабатываться реестром или DNS, чтобы получить желаемое «идентичное» поведение. [RFC4690] сказал, что «вариантная» модель, представленная в [RFC3743] и [RFC4290], может использоваться реестром для предотвращения наиболее негативных последствий возможной путаницы, обеспечивая либо то, что оба имени зарегистрированы для одной и той же стороны в данной домен или что один из них полностью запрещен. Принципы, описанные в [RFC3743], [RFC4290] и [RFC4690], были приняты многими реестрами. Но технические детали того, как гарантировать, что набор доменных имен «идентичен» в DNS, остаются неуказанными.

2.2. Одинаковое разрешение DNS для связанных DNS-имен

В некоторой степени желаемое поведение может быть описано: «идентичное разрешение DNS» означает, что процесс разрешения двух доменных имен будет заканчиваться одинаковым результатом, в большинстве случаев одним и тем же IP-адресом. В истории разработки протокола DNS было предпринято две попытки указать такое поведение «идентичного разрешения»: CNAME [RFC1034], который сопоставляет или перенаправляет себя, и DNAME [RFC2672], который сопоставляет или перенаправляет его потомков. Однако в случае групп или групп имен некоторые операторы утверждают, что им необходимо идентичное разрешение DNS для доменных имен всех уровней, включая само доменное имя и его потомков. Как упоминалось выше, в реестрах предусмотрены специальные механизмы обеспечения и управления базами данных для управления именами вариантов с некоторой помощью существующих механизмов протокола DNS для сопоставления меток или полных доменных имен друг другу. Однако некоторые считают, что существующие механизмы имеют неудовлетворительные ограничения; они ищут большего руководства по использованию существующих механизмов и, возможно, добавлению новых в протокол DNS.

2.3. Варианты символа

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

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

2.3.1. Пример: упрощенный и традиционный китайский

Например, IDN TLD «Китай» (U + 4E2D U + 56FD) и его вариант (U + 4E2D U + 570B) находятся сегодня в корне. Первый (U + 4E2D U + 56FD) может считаться «исходным» TLD IDN, а второй (U + 4E2D U + 570B) может рассматриваться как «вариант» TLD IDN. В идеале должна быть возможность трактовать исходный IDN TLD и его вариант IDN TLD как «идентичные» для целей разрешения DNS, аналогично случаю, который большинство пользователей DNS считают само собой разумеющимся, в котором заглавная буква «A» вариант строчной буквы «а». Например, строка «.COM» может рассматриваться как вариант «.com», а соответствующие метки DNS считаются идентичными. Однако по историческим причинам, которые уже обсуждались, а также по техническим причинам, связанным с основами протокола IDNAbis (см. Обоснование IDNAbis), отсутствует обобщение сопоставления «случай», доступного для ситуаций, в которых оно может быть полезно для ИДИ. Кроме того, это опасно, потому что правила DNS относительно «нечувствительности к регистру» и «сохранения регистра» не являются интуитивно непротиворечивыми; например, сворачивание дела сделано для сравнения, но не для сжатия.

На момент написания этой статьи четыре корневых домена IDN со сценарием Han находятся в корне, включая две пары, включающие традиционное китайское имя и его упрощенный аналог. Эти операторы в идеальном мире смогут поделиться некоторым опытом эксплуатации политики реестра, касающейся управления несколькими деревьями DNS как «одинаковыми».

2.3.2. Пример: греческий

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

Например, доменные имена «xn--0xadhj4a.gr» и «xn--0xaafjl.gr» кажутся носителю / читателю греческого языка «одним и тем же словом», в некотором смысле очень похожим на нечувствительность к регистру что местные пользователи латинского алфавита считают само собой разумеющимся в DNS.

2.3.3. Пример: арабский

[STW: [будет добавлено]

2.4. Использование вариантов

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

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

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

  1. Ожидание, что два или более имени будут «одинаковыми», часто выражается в виде желания зарегистрировать связанные имена в качестве «связки» или иным образом связать их как доменные имена. Это связано с тем, что доменное имя в URL-адресе или адресе электронной почты часто представляется пользователю как семантически значимое, основанное на строках, используемых для получения меток DNS — собственных имен, «слов» и т. Д. Это ставит такие проблемы перед вниманием поставщиков доменных имен, и предлагает, по крайней мере, изучить, как ответить на вопрос рядом с тем, где он задается — то есть в реестре.
  2. Желание, чтобы имена в Интернете действовали как слова, часто не зависит от услуг; пользователи хотят иметь возможность использовать идентичные строки в процессе вызова нескольких служб, которые, по-видимому, связаны между собой, таких как переход на веб-страницу, а затем отправка электронной почты на адрес в «одном и том же» домене (возможно, полное доменное имя). Было отмечено, что людям очень комфортно с определенной долей неясности в отношении «альтернативных вариантов написания» и разных вариаций в рамках понятия «одинаковость», но тем не менее они часто хотят, чтобы такая ассоциация существовала. В случаях, когда набор вариантных строк анализируется в приложении, имеет соответствующие A-метки, которые можно искать в DNS и т. Д., Но только подмножество может быть набрано на устройстве ввода пользователя или отображено на экране пользователя, ассоциация может быть необходима для успешного завершения действия, которое пытается выполнить пользователь. Это, в свою очередь, приводит аргументы в пользу некоторого механизма, который не зависит от конкретной службы, протокола или приложения, поскольку он оставляет его на усмотрение механизмов, специфичных для службы, или соглашений об использовании записей DNS или других механизмов, не предназначенных для этой цели, приводит к путанице и непоследовательности.

3. Эксплуатационные соображения

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

3.1. Серверы обеспечения зоны и авторизации

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

3.1.1. Предоставление псевдонимов в реестре

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

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

Отдельная инициализация также налагает ограничение для некоторых операторов реестра в том, что нет способа проверить, что деревья поддерживаются параллельно без исчерпывающего обхода зон, которые могут быть большими или вложенными в несколько уровней. В случае, например, зоны ABCexample.com, в которой каждый из A, B, C получен из строк с одним символьным вариантом каждая, восемь зон должны поддерживаться параллельно и, возможно, доступны для аудита органом over example.com, в зависимости от политики делегирования.

3.1.2. Воздействие специальных механизмов

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

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

3.2. Рекурсивные резольверы

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

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

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

3.3. Приложения

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

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

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

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

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

4. Предлагаемые требования

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

1. Любой механизм, предложенный в DNS для поддержки «псевдонимов» или нескольких имен как «одинаковых», ДОЛЖЕН работать для зон, подписанных DNSSEC.

2. Любой механизм, предложенный в DNS для поддержки «псевдонимов» или нескольких имен как «одинаковых», ДОЛЖЕН быть «обратно совместимым», поскольку он НЕ ДОЛЖЕН изменять установленное поведение существующих типов RR и обработки запросов.

3. Любому предлагаемому механизму НЕ СЛЕДУЕТ требовать больше накладных расходов для реестров, авторитетных серверов или клиентов, чем для существующих механизмов аппроксимации желаемого поведения, таких как предоставление нескольких параллельных деревьев или обработка CNAME. Если новое решение — это больше работы, чем существующие механизмы, какими бы несовершенными они ни были, неясно, где будут мотивы для его развертывания. Это особенно важно для разработчиков и разработчиков приложений.

4. Любой предложенный механизм МОЖЕТ требовать новых типов RR и специальной обработки для них.

5. Любой предложенный механизм НЕ ДОЛЖЕН только снижать затраты на создание и предоставление авторитетного обслуживания для зон DNS. Было бы слишком легко сократить расходы на поставщика авторитетных серверов, добавив при этом затраты в других местах, особенно с точки зрения сложности. Учитывая центральное значение службы DNS для работы в Интернете, любые изменения, предпринимаемые для снижения затрат для поставщиков, могут быть полезны, но не должны просто переносить расходы на пользователей DNS, будь то приложения или конечные пользователи.

5. Возможные решения

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

Кроме того, появились новые предложения по протоколу DNS для поддержки «псевдонимов» в DNS как части желаемого поведения «вариантов» имен: Направление имен [BNAME] и «Зона клонирования».

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

5.1. Сопоставление или перенаправление доменных имен

5.1.1. Картографирование себя

В первоначальной спецификации DNS было признано, что хост может иметь много имен; на самом деле это ожидание предшествует DNS, ссылаясь на более раннюю спецификацию имен хостов. В простейшем случае для «псевдонимов» пользователям Интернета необходимо, чтобы эти множественные имена были разрешены DNS-сервером на один и тот же IP-адрес. Запись CNAME [RFC1034], где «CNAME» — это аббревиатура «Каноническое имя», — это способ обозначить псевдонимы «реального» или канонического имени хоста. В некоторых случаях CNAME может использоваться для создания необходимой ассоциации набора вариантов доменных имен. Но CNAME отображает только себя, а не своих потомков; фактически он определен как не имеющий потомков, так как это единственное имя в узле дерева DNS и не может существовать с тем же именем, что и делегирование. Однако в случае вариантов ИДИ часто желательно, чтобы имя отображало как себя, так и его потомков.

5.1.2. Картирование его потомков

Чтобы поддерживать сопоставления адреса с именем в контексте перенумерации сети, была изобретена запись DNAME или запись имени делегации, определенная в [RFC2672], чтобы создать псевдоним для всех его поддоменов. В отличие от этого, запись CNAME создает псевдоним только одного имени (но не его поддоменов). Как и в случае с записью CNAME, поиск DNS будет продолжен путем повторной попытки поиска с новым именем. Если преобразователь DNS отправляет запрос без EDNS [EDNS0] или с EDNS версии 0, тогда сервер имен синтезирует запись CNAME для имитации семантики записи DNAME. Запись DNAME очень похожа на запись CNAME, но в то время как запись CNAME применяется только для одного имени, с помощью записи DNAME можно создавать псевдонимы для всех записей своего субдомена.

5.1.3. Картографирование себя и его потомков

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

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

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

5.2. Зона Clone

Предложение «клонирование зоны» или «тень dns» является альтернативным решением для более высокого уровня поддержки, чем DNS в настоящее время обеспечивает поведение «псевдонима» в зонах. В этой схеме указывается новый тип RR, SHADOW; он может существовать на вершине зоны и может использоваться для определения «клонов» или «теней» содержимого зоны, так что записи в зоне достижимы посредством поиска из нескольких делегаций. Этот механизм принципиально отличается от CNAME / DNAME / BNAME тем, что он создает локальную копию на каждом взаимодействующем полномочном сервере, имеющем исходную зону, доступную по именам, указанным в RAD SHADOW. Следовательно, его область действия — это зона, поддерживаемая авторитетным сервером, а не одним RRset (даже тем, который соответствует делегированию).

Эта схема имеет преимущество в том, что она позволяет использовать зону SHADOW во всех тех же контекстах, что и каноническая или базовая зона, включая контексты, в которых CNAME или DNAME (или, по-видимому, BNAME) не могут появляться, например в RDATA определенные типы RR. Из предложенных механизмов протокола DNS он, вероятно, наиболее близок к поведению, которое некоторые запрашивают как «эквивалентность», когда ни одно из связанных имен или имен SHADOW не является каноническим или предпочтительным по сравнению с другими. Это подразумевает неизвестный уровень усилий для реализации и поддержки.

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

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

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

[STW: ищу примеры для этого раздела.]

Неразрешенные проблемы, которые необходимо учитывать при определении того, что «то же самое» означает для DNS, включают в себя последствия для DNSSEC и то, включает ли «идентичное» разрешение проверку DNSSEC в ожидаемом «идентичном» поведении.

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

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

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

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

Большинство идей здесь и большая часть текста взяты из обсуждений в списках рассылки DNSEXT и DNSOP WG. Особая помощь выражается авторами проектов предлагаемых решений и многими авторами работы IDNAbis и ее основ. Особая благодарность на пересечении DNS и IDNAbis выражается в благодарность Патрику Фальтстрому, Кэри Карпу, Джону Кленсину, Ваггелису Сегредакису и Эндрю Салливану за их терпеливые объяснения.

9. История изменений

[[anchor28: Редактор RFC: Пожалуйста, удалите этот раздел.]]

9.1. draft-yao-dnsext-identical-resolution: версия 00

o Постановка проблемы идентичного разрешения доменного имени (первоначальная попытка)

9.2. draft-yao-dnsext-identical-resolution: версия 01

o Расширенное введение
o Добавлен греческий пример
o Добавлены некоторые детали в описания предлагаемых решений.

10. Ссылки

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

[ASCII] American National Standards Institute (formerly United States of America Standards Institute), «USA Code for Information Interchange», ANSI X3.4-1968, 1968.

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

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

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, «Dynamic Updates in the Domain Name System (DNS UPDATE)», RFC 2136, April 1997.

[RFC2672] Crawford, M., «Non-Terminal DNS Name Redirection», RFC 2672, August 1999.

[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, «Internationalizing Domain Names in Applications (IDNA)», RFC 3490, March 2003.

[RFC3597] Gustafsson, A., «Handling of Unknown DNS Resource Record (RR) Types», RFC 3597, September 2003.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», RFC 3629, November 2003.

[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, «Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for
Chinese, Japanese, and Korean», RFC 3743, April 2004.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, March 2005.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for the DNS Security Extensions», RFC 4034, March 2005.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, March 2005.

[RFC4290] Klensin, J., «Suggested Practices for Registration of Internationalized Domain Names (IDN)», RFC 4290, December 2005.

[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, «Review and Recommendations for Internationalized Domain Names (IDNs)», RFC 4690, September 2006.

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

[BNAME] Yao, J., Lee, X., and P. Vixie, «Bundle DNS Name Redirection», draft-yao-dnsext-bname-01.txt (work in progress), 12 2009.

[CNAME-DNAME] Sury, O., «CNAME+DNAME Name Redirection», draft-sury-dnsext-cname-dname-00.txt (work in progress), 4 2010.

[IDN-TLD-Variants] Yao, J. and X. Lee, «IDN TLD Variants Implementation Guideline», draft-yao-dnsop-idntld-implementation-01.txt (work in progress), 11 2009.

[RFC2672bis] Rose, S. and W. Wijngaards, «Update to DNAME Redirection in the DNS», Internet-Draft ietf-dnsext-rfc2672bis-dname-17.txt, 6 2009.

[SHADOW] Vixie, P., «Use of DNS to Carry Configuration Metadata Concerning Automatic Replication of Zones», draft-vixie-dnsext-dnsshadow-00.txt (work in progress),
2 2010.

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

Suzanne Woolf
Internet Systems Consortium, Inc.
950 Charter St.
Redwood City, CA 94063
Phone: +1 650 423 1333
Email: woolf@isc.org

Xiaodong LEE
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58813020
Email: lee@cnnic.cn

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