RFC 8244 | Постановка проблемы доменных имен специального назначения

Аннотация

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

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

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

 

Оглавление

1. Введение
2. Терминология
3. Проблемы, связанные с доменными именами специального назначения
4. Существующая практика в отношении доменных имен специального назначения
4.1. Основные документы доменного имени специального назначения
4.1.1. Технический комментарий IAB об уникальном корне DNS
4.1.2. Специальные доменные имена
4.1.3. Меморандум о взаимопонимании в отношении технической работы IANA
4.1.4. Заявление о взаимодействии по техническому использованию доменных имен
4.1.5. Заявление IAB о регистрации имен специального использования в домене ARPA
4.2. Вторичные документы, относящиеся к вопросу о доменном имени специального назначения
4.2.1. Многоадресный DNS
4.2.2. Доменное имя верхнего уровня специального назначения .onion
4.2.3. Локально обслуживаемые DNS-зоны
4.2.4. Столкновение имен в DNS
4.2.5. Рекомендации SSAC по стабильности пространства имен доменов
4.2.6. Обнаружение префикса IPv6, используемого для синтеза адресов IPv6
4.2.7. Дополнительные зарезервированные домены верхнего уровня
5. История
6. Вопросы безопасности
7. Соображения IANA
8. Информационные ссылки
Авторы
Адреса авторов

 

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

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

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественную рецензию и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Не все документы, утвержденные IESG, являются кандидатами на любой уровень Интернет-стандарта; см. раздел 2 RFC 7841.

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

 

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

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

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

 

1. Введение

Одним из ключевых сервисов, необходимых для использования Интернета, является разрешение имен. Разрешение имен — это процесс преобразования символического имени в некоторый объект или набор объектов, к которым относится имя, чаще всего один или несколько IP-адресов. Эти имена часто называют «доменными именами». При чтении этого документа следует позаботиться о том, чтобы термин «доменное имя» не подразумевал использование системы доменных имен [RFC1034] для разрешения этих имен. Отличную презентацию на эту тему можно найти в доменных именах [DOMAIN-NAMES].

«Доменные имена специального назначения» [RFC6761] создали реестр IANA «Доменные имена специального назначения» [SDO-IANA-SUDR], определили политики для добавления в реестр и внесли некоторые предложения о том, как эти политики могут быть реализованы. После публикации RFC 6761 IETF было предложено указать несколько новых доменных имен специального назначения в этом реестре. В процессе оценки этих доменных имен специального назначения IETF столкнулся с несколькими различными видами проблем. По этой причине IETF решила исследовать проблему и решить, можно ли и каким образом улучшить процесс, определенный в RFC 6761, или его следует считать устаревшим. Устав рабочей группы IETF DNSOP был расширен, чтобы включить проведение обзора процесса добавления имен в реестр, который определен в RFC 6761. Этот документ является продуктом этого обзора.

Исходя из текущей практики ICANN и IETF, включая RFC 6761, в корне пространства имен доменов есть несколько разных типов имен:

o Имена, зарезервированные IETF для технических целей

o имена, назначенные ICANN общедоступному корню DNS; некоторые имена, зарезервированные IETF для технических целей, могут появляться в глобальном корне DNS по причинам, связанным с работой DNS

o Зарезервированные имена ICANN; имена, которые не могут быть использованы в качестве TLD (см. «Зарезервированные имена» и «Обработка названий стран или территорий» (разделы 2.2.1.2.1 и 2.2.1.4.1, соответственно) [SDO-ICANN-DAG]).

o Имена, используемые другими организациями без соблюдения установленных процессов

o Имена, которые не используются и доступны для присвоения одной из предыдущих категорий

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

 

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

Этот документ использует терминологию из RFC 7719 [RFC7719]. Другие термины, используемые в этом документе, определены здесь:

• Доменное имя. В этом документе используется термин «доменное имя», как это определено в разделе 2 RFC 7719 [RFC7719].
• Пространство доменных имен: набор всех возможных доменных имен.
• Доменное имя специального использования: доменное имя, указанное в реестре «доменных имен специального назначения» [SDO-IANA-SUDR].

Для краткости в этом документе используются некоторые сокращения, которые здесь расширены:

IANA: Управление по присвоению номеров в Интернете
ICANN: Интернет-корпорация по присвоению имен и номеров
TLD: домен верхнего уровня, как определено в разделе 2 RFC 7719 [RFC7719]
gTLD: общий домен верхнего уровня (см. раздел 2 RFC 2352 [RFC2352])

 

3. Проблемы, связанные с доменными именами специального назначения

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

Доменные имена специального назначения существуют для решения различных проблем. Этот документ преследует две цели: перечислить все проблемы, которые были определены, для которых доменные имена специального назначения являются решением, и перечислить все проблемы, которые возникли в процессе попытки использования RFC 6761 по назначению. Поскольку некоторые из этих проблем могут быть отнесены к обеим категориям, в этом документе не делается попыток классифицировать проблемы.

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

Список проблем не представлен в порядке важности; номера назначаются так, чтобы на каждую проблему можно было легко ссылаться по номеру, а не указывать приоритет. Список проблем выглядит следующим образом:

1. Хотя IETF и ICANN имеют отношения связи, посредством которых можно обсуждать распределения специального назначения, формального процесса для координации этих распределений не существует (см. Раздел 4.1.3). Отсутствие координации усложняет управление корнем пространства имен доменов и может привести к конфликтам при назначении имен [SDO-ICANN-SAC090].
2. Нет четкого определения того, что может представлять собой «техническое использование» [RFC2860], а что нет; в IETF также нет единого мнения о том, что означает этот термин.
3. Не все разработчики протоколов в Интернете согласны с тем, что полномочия по всему пространству доменных имен должны принадлежать исключительно IETF и ICANN.
4. Хотя IETF и ICANN номинально имеют полномочия над этим пространством имен, ни одна организация не может навязать эти полномочия любой третьей стороне, которая хочет просто начать использовать подмножество пространства имен. Такие стороны могут заметить, что IETF никогда не устанавливал контроль или полномочия в отношении того, какие протоколы «разрешены» в Интернете, и что принцип «неразрешенных инноваций» предполагает, что у людей должен быть способ включить новые виды использования доменных имен в новые протоколы и приложения.
5. На самом деле организации иногда используют подмножества пространства имен доменов, не следуя установленным процессам. Причины, по которым третья сторона может сделать это, включают:
   1. Недостаток знаний о том, что существует процесс присвоения таких имен.
   2. Предполагаемое использование охватывается процессом gTLD [SDO-ICANN-DAG], но процесс gTLD не продолжается.
   3. Использование по назначению подпадает под действие процесса gTLD, но третье лицо не хочет вносить плату.
   4. Использование по назначению подпадает под действие какого-либо процесса IETF, но третья сторона не хочет следовать этому процессу.
   5. Использование по назначению обеспечивается процессом ICANN или IETF, но третья сторона ожидает, что результатом будет отказ или бездействие.
   6. Недостаток знаний о том, что имя, предназначенное для использования только локально, тем не менее может утечь.
   7. Недостаток знаний о том, что имя, используемое локально с неформальным распределением, впоследствии может быть присвоено официально, что создает операционные проблемы
6. Существует потребность в более чем одном протоколе разрешения имен для доменных имен. Доменные имена не содержат метаданных, чтобы указать, какой протокол использовать для их разрешения. API разрешения доменных имен не предоставляют способ указать, какой протокол использовать.
7. Когда доменное имя специального назначения добавляется в реестр «доменных имен специального назначения», не все программное обеспечение, которое обрабатывает такие имена, поймет специальное использование этого имени. Во многих случаях программное обеспечение для разрешения имен будет использовать Систему доменных имен для разрешения имен, которые, как известно, не имеют специального назначения. Следовательно, любое такое использование приведет к тому, что запросы на доменные имена специального назначения будут отправлены на официальные серверы системы доменных имен. Эти запросы могут представлять собой операционную проблему для операторов авторитетных серверов имен корневой зоны. Эти запросы могут также непреднамеренно раскрыть личную информацию через содержимое запроса, что является соображением конфиденциальности.
8. Некоторые разработчики протоколов предположили, что им не удалось получить имя, назначенное через IETF, с использованием процесса, определенного в RFC 6761. Это происходит потому, что, когда IETF попытался следовать процессу, определенному в RFC 6761, он был медленным и неопределенный. Например, процесс назначения первого нового имени («.local») с использованием процесса, определенного в RFC 6761, занимал более десяти лет от начала до конца: дольше в десять раз, чем любая другая часть процесса разработки протокола ( во многом потому, что эти десять лет включали в себя время для разработки процесса, а также его использования). Другие способы использования этого процесса проходили более плавно, но существует достаточно обоснованное мнение о том, что использование этого процесса может быть медленным и трудным с неопределенным результатом.
9. В IETF существует сильное сопротивление присвоению доменных имен системам разрешения вне DNS по ряду причин:
   • Требуется механизм для определения того, какой набор процессов разрешения необходим для разрешения конкретного имени.
   • Утверждение полномочий: существует ощущение, что Пространство имен доменов «принадлежит» IETF или ICANN, поэтому, если заявлено имя, не следуя его процессам, лицо или организация, заявившие это имя, должны понести некоторые последствия, которые предположительно, будет сдерживать будущее обход официальных процессов.
   • Несколько протоколов разрешения имен плохие, в том смысле, что один протокол менее сложен в реализации и развертывании.
   • Семантика протоколов альтернативного разрешения может отличаться от протокола DNS; DNS имеет концепцию типов RR, тогда как другие протоколы могут не поддерживать типы RR или могут поддерживать какой-то совершенно иной механизм структурирования данных.
   • Если есть процесс IETF, посредством которого TLD может быть назначен с нулевой стоимостью, отличной от времени, этот процесс будет использоваться в качестве альтернативы более дорогостоящему процессу регистрации имени через ICANN.
   • Имя может быть назначено для конкретной цели, когда более общее использование имени будет более полезным.
   • Если IETF присваивает имя, которое, по мнению некоторых третьих сторон или сторон, принадлежит им, IETF может оказаться втянутым в дорогостоящий спор с этими сторонами.
10. Если бы не было процесса назначения имен для технического использования через IETF, существует проблема, что протоколы, требующие таких имен, не смогут их получить.
11. В некоторых случаях, когда IETF делала назначения в процессе, определенном в RFC 6761, технические ошибки были сделаны из-за неправильного понимания фактического процесса, указанного в RFC 6761 (например, обработка списка предлагаемых соображений для присвоения имени как набор требований, которые должны быть выполнены). В других случаях IETF фактически присваивает доменные имена специального назначения, не выполняя процедуру, описанную в RFC 6761 (см. [RFC7050] и [RFC7788]).
12. Существует несколько доменных имен верхнего уровня, которые используются без надлежащей правовой процедуры для различных целей. Статус этих имен необходимо уточнить и записать, чтобы избежать будущих споров об их использовании [SDO-ICANN-COLL].
13. В принципе, процесс, определенный в RFC 6761, может использоваться для документирования существования доменных имен, которые небезопасно присваивать, и предоставления информации о том, как эти имена используются на практике. Однако попытки использовать RFC 6761 для выполнения этой документации не увенчались успехом (например, см. «Дополнительные зарезервированные домены верхнего уровня» [RESERVED-TLDS] и раздел 4.2.7 этого документа). Одним из побочных эффектов отсутствия документации является то, что любое влияние на корневые серверы имен или соображения конфиденциальности было упущено.
14. Доменное имя можно идентифицировать как DNS-имя, поместив его в зону (ы) DNS, или как специальное доменное имя, добавив его в реестр IANA. Некоторые имена в обоих местах; например, некоторые локально обслуживаемые имена зон находятся в зонах DNS и задокументированы в реестре «доменных имен специального назначения». В настоящее время единственным способом, которым доменное имя может быть добавлено в реестр «доменного имени специального назначения», является то, что IETF берет на себя ответственность за имя и назначает его для «технического использования». Существуют и другие потенциальные возможности использования доменных имен, которые должны быть зарегистрированы в реестре, но за которые IETF не должна брать на себя ответственность.
15. В некоторых случаях IETF может столкнуться с необходимостью документировать, что имя используется, не утверждая, что использование имени является особым использованием IETF имени. В текущем реестре не существует механизма для пометки имен таким образом.
16. На любом из этапов рецензирования документа не существует формального процесса, в котором выполняется проверка, чтобы убедиться, что документ не непреднамеренно нарушает процесс IETF для добавления доменных имен специального назначения в реестр, как это имело место. например, в RFC 7788 [RFC7788].
17. Использование реестра противоречиво — некоторые RFC для доменных имен специального назначения специально добавляют записи реестра, некоторые нет; некоторые указывают, как и нужно ли делать делегирование имен специального назначения, а некоторые нет.
18. Не существует безопасного, не нарушающего процесс механизма для специального назначения доменных имен специального назначения.
19. Обычно предполагается, что протоколы, которым необходимо доменное имя специального назначения, нуждаются в мнемоническом, однокомпонентном, понятном для человека доменном имени специального использования для использования в пользовательских интерфейсах, таких как командные строки или поля ввода URL. Хотя в некоторых случаях это предположение верно, оно, вероятно, не во всех случаях, например, в приложениях, где доменное имя никогда не видимо пользователю.
20. В RFC 6761 термин «доменное имя» используется для описания объекта, для которого регистрируются специальные виды использования. Это создает большую путаницу, потому что некоторые читатели используют «доменное имя», чтобы подразумевать использование протокола DNS.
21. Использование DNSSEC с доменными именами специального назначения является открытой проблемой. Нет единого мнения или руководства о том, как использовать DNSSEC с различными классами доменных имен специального назначения. Соображения по использованию DNSSEC с доменными именами специального назначения включают в себя:
    • Какой класс специального доменного имени рассматривается: не DNS, локально обслуживаемая зона или другое?
    • Требует ли доменное имя специального использования делегирования в корневой зоне; если так, то эта делегация должна быть подписана или нет? Если нет делегирования, то это будет рассматриваться путем проверки распознавателей как безопасного отказа в существовании для этой зоны. Это не подходит для разрешения имени с использованием протокола DNS.
    • Потребуется процесс, с помощью которого IETF может инициировать делегирование в корневой зоне.
    • Каковы рекомендуемые методы использования DNS с определенным доменным именем специального назначения?

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

 

4. Существующая практика в отношении доменных имен специального назначения

Существует три основных (см. Раздел 4.1) и множество дополнительных (раздел 4.2) документов, которые следует учитывать при рассмотрении процесса доменных имен специального назначения.

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

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

 

4.1. Основные документы доменного имени специального назначения

Первичные документы считаются первичными, потому что они напрямую касаются прошлых мыслей IETF по этой теме в целом, а также потому, что они описывают то, что IETF делает на практике.

 

4.1.1. Технический комментарий IAB об уникальном корне DNS

[RFC2826] не является документом консенсуса IETF, и, похоже, он был написан для решения проблемы, отличной от проблемы доменного имени специального назначения. Тем не менее, в нем напрямую говорится о нескольких ключевых вопросах, которые необходимо рассмотреть, и, как и в случае с IAB, он по праву считается значительным авторитетом, несмотря на то, что он не является документом консенсуса IETF.

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

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

o Частные сети могут работать с частными пространствами имен, имена которых имеют значение только локально (в частной сети), но они по-прежнему требуют, чтобы имена в общедоступном пространстве имен были глобально уникальными.

o Система доменных имен [RFC1035] — не единственный протокол, который может использоваться для разрешения доменных имен.

o Нельзя предполагать, что пользователи знают, как различать символические ссылки, имеющие локальное значение, и ссылки, имеющие глобальное значение. Поэтому пользователи могут делиться ссылками, которые включают доменные имена без глобального значения (например, URL-адрес «http: //mysite.example.corp», где «example.corp» — это домен, используемый в частном и неформальном порядке, как описано в [ СДО-ICANN, COLL]).

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

Эта же проблема может также возникнуть, когда один пользователь копирует имя из одного контекста, в котором оно имеет одно значение, в другой контекст, в котором оно имеет другое значение — например, копирование доменного имени «.onion» из Tor. Браузер [TOR], где он имеет значение, и вставка этого имени в SSH-клиент, который не поддерживает подключение по сети Tor.

Мы можем суммировать рекомендации в этом документе следующим образом:

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

o На момент написания этого документа IAB придерживался мнения, что для разрешения доменных имен вполне может использоваться более одного протокола разрешения имен.

 

4.1.2. Специальные доменные имена

Второй важный документ — «доменные имена специального назначения» [RFC6761]. RFC 6761 представляет текущий консенсус IETF по назначению и записи доменных имен специального назначения. У IETF возникли проблемы с процессом назначения, описанным в RFC 6761; эти проблемы мотивируют этот документ. Знакомство с RFC 6761 является обязательным условием для получения обоснованного мнения по теме доменных имен специального назначения.

RFC 6761 определяет два аспекта доменных имен специального назначения: назначение доменного имени для специального назначения и регистрация этого специального использования в реестре «доменных имен специального назначения». Процесс обозначения определяется в одном предложении (RFC 6761, раздел 4):

• Если определено, что для реализации некоторых желаемых новых функциональных возможностей требуется специальная обработка имени, тогда ДОЛЖНА быть опубликована спецификация IETF «Стандартные действия» или «Утверждение IESG» [RFC5226], описывающая новые функциональные возможности.

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

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

RFC 6761 обеспечивает процесс, посредством которого «Multicast DNS» [RFC6762] обозначил «.local» в качестве доменного имени специального назначения и включил его в реестр «доменных имен специального назначения». RFC 6761 также перечисляет набор имен, которые ранее использовались или были определены для специального использования до его публикации. Поскольку до публикации RFC 6761 не было реестра для этих имен, документы, определяющие эти имена, не могли добавить их в реестр.

В отношении RFC 6761 следует учитывать несколько важных моментов:

• Доменное имя специального использования может быть именем, которое должно быть разрешено с использованием протокола DNS без специальной обработки. Примером этого является «in-addr.arpa» (который является примером доменного имени специального назначения, которое не является TLD).
• Доменное имя специального использования может быть именем, которое разрешается с использованием протокола DNS и не требует специальной обработки в решателе заглушки, но требует специальной обработки в рекурсивном решателе. Примером этого может быть «10 .in-addr.arpa.».
• Доменное имя специального использования может быть именем, которое требует особой обработки в обработчике заглушки. Примером может служить специальное использование доменного имени верхнего уровня, такого как .local, которое действует как сигнал, указывающий на то, что локальный распознаватель заглушек должен использовать не-DNS-протокол для разрешения имен.
• Текущий консенсус IETF (с точки зрения процесса, не обязательно с точки зрения того, что будет консенсусом, если бы IETF попытался создать новый согласованный документ), состоит в том, что все эти цели для доменных имен специального назначения являются действительными.

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

RFC 6761 не ограничивает доменные имена специального использования TLD. Однако в настоящее время все доменные имена специального назначения, зарегистрированные в реестре «доменных имен специального назначения» [SDO-IANA-SUDR], предназначены для разрешения с использованием протокола DNS, являются TLD или являются обоими. То есть, в настоящее время не существует доменных имен специального назначения, которые требуют специальной обработки обработчиками-заглушками и которые не находятся на верхнем уровне иерархии имен.

Из этого следует обратить внимание на то, что в RFC 6762 уже существует требование о том, что когда решатель-заглушка встречает специальную метку «local» в качестве крайней правой метки доменного имени, он может использовать только протокол Multicast DNS (mDNS) для разрешить это доменное имя.

 

4.1.3. Меморандум о взаимопонимании в отношении технической работы IANA

Между IETF и ICANN существует Меморандум о взаимопонимании (МоВ) [RFC2860], в котором обсуждается, как имена и номера будут управляться через IANA. Этот документ важен для обсуждения доменных имен специального назначения, поскольку, хотя он делегирует полномочия по управлению пространством имен DNS в целом ICANN, он оставляет за IETF полномочия, которые затем формализуются в RFC 6761. В RFC 2860 конкретно говорится:

Обратите внимание, что (a) назначения доменных имен для технического использования (например, доменные имена для обратного поиска DNS), (b) назначения специализированных блоков адресов (таких как многоадресные или произвольные блоки) и (c) экспериментальные назначения не рассматриваются как вопросы политики, и должны оставаться в соответствии с положениями настоящего Раздела 4.

Приведенный выше текст является дополнением к следующему:

Два конкретных назначенных пространства представляют проблемы политики в дополнение к техническим соображениям, указанным IETF: назначение доменных имен и назначение блоков IP-адресов. Эти вопросы политики выходят за рамки настоящего Меморандума.

Назначение имен в корневой зоне DNS и управление пространством имен доменов по умолчанию является функцией, выполняемой ICANN. Однако MoU специально исключает доменные имена, назначенные для технического использования, и использует пример доменов, используемых для обратного поиска DNS. И in -addr.arpa, и ip6.arpa находятся в реестре доменных имен специального назначения.

Подразумеваемым в МоВ является тот факт, что IETF и ICANN сохраняют между собой единоличное право назначать любые имена из пространства имен доменов. И IETF, и ICANN имеют внутренние процессы для выполнения таких назначений.

Суть здесь не в том, чтобы сказать, каковы последствия этого заявления в МоВ, а в том, чтобы привлечь внимание читателя к существованию этого заявления.

 

4.1.4. Заявление о взаимодействии по техническому использованию доменных имен

Когда IETF получил запросы на обработку для добавления имен в реестр «доменных имен специального назначения», как описано в [RESERVED-TLDS] и [P2P-DOMAIN-NAMES], IETF провела проверку процесса, определенного в RFC 6761 для добавление имен в реестр (как объяснено ранее). IETF направила в ICANN заявление о взаимодействии [SDO-IAB-ICANN-LS], чтобы уведомить их о проверке, подтвердить, что обсуждение будет «открытым и прозрачным для участия заинтересованных сторон», и прямо пригласить членов сообщества ICANN участвовать.

 

4.1.5. Заявление IAB о регистрации имен специального использования в домене ARPA

В рамках процесса разрешения разногласий, упомянутых в разделе 4.2.7, IAB выпустил заявление, в котором частично говорится:

В настоящее время в ICANN не определен процесс для делегирования имен специального использования в корневой зоне; казалось, что для его создания потребуются значительные усилия. IAB отметил, что .arpa можно использовать «для технической инфраструктуры, созданной в соответствии со стандартами IETF» [SDO-IAB-SUDN-REG].

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

 

4.2. Вторичные документы, относящиеся к вопросу о доменном имени специального назначения

В дополнение к этим документам, есть несколько других, с которыми участники этой дискуссии должны быть знакомы.

4.2.1. Многоадресный DNS

Многоадресная DNS [RFC6762] определяет протокол многоадресной DNS, который использует специальное доменное имя верхнего уровня .local. Раздел 3 описывает семантику «многоадресных DNS-имен». Имеет большое историческое значение отметить, что версия документа -00, которая в итоге стала отдельным документом RFC 6762, была опубликована в июле 2001 года. Версия, опубликованная в то время, по существу, содержит тот же текст в разделе 3, что и RFC 6762. это было сделано после публикации и обсуждалось в рабочей группе DNSEXT на IETF 51 в августе 2001 года [IETF-PRO-51]. В июльском проекте 2001 года доменное имя специального назначения обозначено как «.local.arpa». Эта идея была категорически отвергнута участниками Рабочей группы DNSEXT, и в результате автор в итоге переключился на использование «.local».

История RFC 6762 подробно описана в Приложении H к RFC 6762; Некоторые заметные этапы включают первоначальное предложение о замене протокола связывания имен AppleTalk (NBP) в июле 1997 года, создание рабочей группы Zeroconf в сентябре 1999 года и назначение многоадресного адреса для обнаружения локальных имен в апреле 2000 года. Документ о сопутствующих требованиях, в конечном итоге опубликованный как [RFC6760], был впервые опубликован в сентябре 2001 года.

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

4.2.2. Доменное имя верхнего уровня специального назначения .onion

Доменное имя верхнего уровня специального назначения .onion [RFC7686] важно, потому что это последнее действие IETF по теме доменных имен специального назначения; хотя он не устанавливает новую политику, сам факт его публикации стоит задуматься.

Два важных момента, которые следует учитывать в отношении этого документа:

o IETF получил согласие опубликовать его.

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

Во-вторых, некоторое время форум CA / Browser [SDO-CABF] выдавал сертификаты на то, что они называли «внутренними именами». Внутренние имена — это имена, выделенные в одностороннем порядке для использования в специфических для сайта контекстах. Выдача сертификатов для таких имен считалась проблематичной, поскольку формального процесса проверки действительности таких имен не существовало. Следовательно, CA / Browser Forum решил прекратить использование таких имен в сертификатах [SDO-CABF-INT] и установить крайний срок, после которого новые сертификаты для таких имен не будут выдаваться [SDO-CABF-DEADLINE]. Поскольку домен «.onion» был распределен в одностороннем порядке, это будет означать, что сертификаты для поддоменов «.onion» больше не могут быть выданы.

Определение IETF «.onion» в качестве специального доменного имени верхнего уровня было необходимо для содействия развитию процесса выдачи сертификата, специфичного для «.onion» доменных имен [SDO-CABF-BALLOT144].

4.2.3. Локально обслуживаемые DNS-зоны

«Локально обслуживаемые DNS-зоны» [RFC6303] описывает конкретный вариант использования для зон, которые существуют по определению и которые разрешаются с использованием протокола DNS, но не могут иметь глобального значения, поскольку IP-адреса хоста, на которые они ссылаются, не являются уникальными. Это относится к различным адресам, включая частные IPv4-адреса [RFC1918], «Уникальные локальные IPv6-адреса одноадресной рассылки» [RFC4193] (в которых эта практика была впервые описана) и «Зарезервированный IANA префикс IPv4 для общего адресного пространства» [RFC6598 ].

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

4.2.4. Столкновение имен в DNS

«Столкновение имен в DNS» [SDO-ICANN-COLL] — это исследование, которое было заказано ICANN в попытке охарактеризовать потенциальный риск для Интернета добавления глобальных делегаций DNS для имен, которые ранее не делегировались в DNS и были не зарезервированы ни по какому RFC, но также известно, что они (в случае «.home») или предположительно (в случае «.corp») широко используются по причинам типа специального использования (локальная область DNS или другие протоколы разрешения в целом).

4.2.5. Рекомендации SSAC по стабильности пространства имен доменов

Спецификация Консультативного комитета ICANN по безопасности и стабильности (SSAC) [SDO-ICANN-SSAC] «Рекомендации SSAC по стабильности пространства имен домена» [SDO-ICANN-SAC090] сообщает о некоторых проблемах, связанных с конфликтующим использованием, заинтересованными сторонами и процессами. связанные с пространством доменных имен. Спецификация рекомендует разработку совместных процессов между различными заинтересованными сторонами для координации их действий, связанных с пространством доменных имен.

4.2.6. Обнаружение префикса IPv6, используемого для синтеза адресов IPv6

«Обнаружение префикса IPv6, используемого для синтеза адресов IPv6» [RFC7050] является примером документа, в котором успешно использовался процесс в RFC 6761 для обозначения файла .ipv4only.arpa в качестве доменного имени специального назначения; в этом случае процесс работал гладко и без противоречий.

К сожалению, хотя процесс IETF работал гладко, в том смысле, что было мало споров или задержек при утверждении нового использования, он работал неправильно: имя «ipv4only.arpa» никогда не добавлялось в «доменные имена специального назначения» реестр. Похоже, это произошло из-за того, что документ явно не запрашивал добавление записи для «ipv4only.arpa» в реестре «доменных имен специального назначения». Это иллюстрация одной из проблем, которые у нас возникают с процессом в RFC 6761: очевидно, довольно легко пропустить шаг добавления имени в реестр.

4.2.7. Дополнительные зарезервированные домены верхнего уровня

«Дополнительные зарезервированные домены верхнего уровня» [RESERVED-TLDS] является примером документа, в котором предпринята попытка зарезервировать несколько доменов верхнего уровня, определенных ICANN, как особо подверженных риску коллизии, в качестве доменных имен специального назначения без документированного использования. Эта попытка не удалась.

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

RFC 7788 [RFC7788] определяет доменное имя верхнего уровня «.home» для использования в качестве имени по умолчанию для разрешения имен относительно контекста домашней сети. Хотя, как определено в RFC 7788, «.home» является доменным именем специального назначения, RFC 7788 не следовал процессу, указанному в RFC 6761: он не просил добавить «.home» в «Домен специального назначения». Имена «Реестр. Это было признано ошибкой и привело к публикации отчета об ошибках [Err4677]. Кроме того, «.home» является примером попытки повторно использовать доменное имя, которое уже было использовано для других целей, без соблюдения установленных процессов [SDO-ICANN-COLL], что еще больше усложняет ситуацию. На момент написания RFC 8244 IETF разрабатывал решение этой проблемы.

5. История

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

На самом деле, в первые дни Интернета имена хостов разрешались с использованием текстового файла HOSTS.TXT, который поддерживался центральным органом, Сетевым информационным центром, и распространялся на все хосты в Интернете с использованием протокола передачи файлов ( FTP) [RFC959]. Неэффективность этого процесса указывается в качестве причины развития DNS [RFC882] [RFC883] в 1983 году.

Однако переход с HOSTS.TXT на DNS не был гладким. Например, Сетевая информационная система (NIS) Sun Microsystems [CORP-SUN-NIS], в то время известная как «Желтые страницы», была активным конкурентом DNS, хотя и не смогла обеспечить полного решения глобальной проблемы именования.

Другим примером была служба имен NetBIOS, также известная как WINS [RFC1002]. Этот протокол использовался в основном компьютерами Microsoft Windows, но также и операционными системами BSD и Linux с открытым исходным кодом для разрешения имен с использованием собственного протокола разрешения имен Microsoft.
Большинство современных операционных систем по-прежнему могут использовать файл / etc / hosts для разрешения имен. Многие по-прежнему имеют переключатель службы имен, который можно настроить на хосте для разрешения некоторых доменов с использованием NIS или WINS. Большинство из них способны разрешать имена с использованием mDNS, распознавая особое значение «.local» специального доменного имени верхнего уровня.

Модель Sun Microsystems, заключающаяся в том, что частные домены внутри корпоративного сайта поддерживают глобальную систему доменных имен для удаленного сайта, сохранилась даже после того, как протокол NIS вышел из употребления. Microsoft обычно рекомендовала администраторам сайтов использовать «частный» TLD для внутреннего использования, и в то время эта практика во многом была частью духа времени (см. Раздел 5.1 [SDO-ICANN-COLL] и приложение G к [RFC6762]). ). Такое отношение лежит в основе широко распространенной практики простого выбора явно неиспользованного TLD и использования его в экспериментальных целях, которая сохраняется даже во время написания этой заметки.

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

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

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

Этот документ упоминает различные соображения безопасности и конфиденциальности в тексте. Однако этот документ не создает никаких новых проблем безопасности или конфиденциальности.

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

Этот документ не требует никаких действий IANA.

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

[CORP-SUN-NIS] Wikipedia, «Network Information Service», August 2017, <https://en.wikipedia.org/wiki/Network_Information_Service>.

[DOMAIN-NAMES] Lewis, E., «Domain Names, A Case for Clarifying», Work in Progress, draft-lewis-domain-names-09, August 2017.

[Err4677] RFC Errata, «Erratum ID 4677», RFC 7788, <https://www.rfc-editor.org/errata/eid4677>.

[IETF-PRO-51] IETF, «Proceedings of the 51st IETF Meeting», August 2001, <http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>.

[P2P-DOMAIN-NAMES] Grothoff, C., Wachs, M., Wolf, H., Ed., Appelbaum, J., and L. Ryge, «Special-Use Domain Names of Peer-to-Peer Systems», Work in Progress, draft-grothoff-iesg-specialuse-p2p-names-04, January 2015.

[PROBLEM-SPECIAL-NAMES] Huston, G., Koch, P., Durand, A., and W. Kumari, «Problem Statement for the Reservation of Special-Use Domain Names using RFC6761», Work in Progress, draft-adpkja-dnsopspecial-names-problem-06, September 2016.

[RESERVED-TLDS] Chapin, L. and M. McFadden, «Additional Reserved Top Level Domains», Work in Progress, draft-chapin-additionalreserved-tlds-02, March 2015.

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

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

[RFC959] Postel, J. and J. Reynolds, «File Transfer Protocol», STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, <https://www.rfc-editor.org/info/rfc959>.

[RFC1002] NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, and End-to-End Services Task Force, «Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications», STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, <https://www.rfc-editor.org/info/rfc1002>.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.

[RFC2352] Vaughan, O., «A Convention For Using Legal Names as Domain Names», RFC 2352, DOI 10.17487/RFC2352, May 1998, <https://www.rfc-editor.org/info/rfc2352>.

[RFC2826] Internet Architecture Board, «IAB Technical Comment on the Unique DNS Root», RFC 2826, DOI 10.17487/RFC2826, May 2000, <https://www.rfc-editor.org/info/rfc2826>.

[RFC2860] Carpenter, B., Baker, F., and M. Roberts, «Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority», RFC 2860, DOI 10.17487/RFC2860, June 2000, <https://www.rfc-editor.org/info/rfc2860>.

[RFC4193] Hinden, R. and B. Haberman, «Unique Local IPv6 Unicast Addresses», RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.

[RFC6303] Andrews, M., «Locally Served DNS Zones», BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011, <https://www.rfc-editor.org/info/rfc6303>.

[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, «IANA-Reserved IPv4 Prefix for Shared Address Space», BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
2012, <https://www.rfc-editor.org/info/rfc6598>.

[RFC6760] Cheshire, S. and M. Krochmal, «Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)», RFC 6760, DOI 10.17487/RFC6760, February 2013,
<https://www.rfc-editor.org/info/rfc6760>.

[RFC6761] Cheshire, S. and M. Krochmal, «Special-Use Domain Names», RFC 6761, DOI 10.17487/RFC6761, February 2013, <https://www.rfc-editor.org/info/rfc6761>.

[RFC6762] Cheshire, S. and M. Krochmal, «Multicast DNS», RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.

[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, «Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis», RFC 7050, DOI 10.17487/RFC7050, November 2013, <https://www.rfc-editor.org/info/rfc7050>.

[RFC7686] Appelbaum, J. and A. Muffett, «The «.onion» Special-Use Domain Name», RFC 7686, DOI 10.17487/RFC7686, October 2015, <https://www.rfc-editor.org/info/rfc7686>.

[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, «DNS Terminology», RFC 7719, DOI 10.17487/RFC7719, December 2015, <https://www.rfc-editor.org/info/rfc7719>.

[RFC7788] Stenberg, M., Barth, S., and P. Pfister, «Home Networking Control Protocol», RFC 7788, DOI 10.17487/RFC7788, April 2016, <https://www.rfc-editor.org/info/rfc7788>.

[SDO-CABF] CA/Browser Forum, «CA/Browser Forum Home Page», <https://cabforum.org>.

[SDO-CABF-BALLOT144] CA/Browser Forum, «Ballot 144 — Validation Rules for .onion Names», February 2015, <https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names>.

[SDO-CABF-DEADLINE] CA/Browser Forum, «SSL Certificates for Internal Server Names», January 2013, <https://www.digicert.com/internal-names.htm>.

[SDO-CABF-INT] CA/Browser Forum, «Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses», June 2012, <https://cabforum.org/internal-names/>.

[SDO-IAB-ICANN-LS] IETF, «Liaison Statement from the IAB to the ICANN Board on Technical Use of Domain Names», September 2014, <https://datatracker.ietf.org/liaison/1351>.

[SDO-IAB-SUDN-REG] IAB, «Internet Architecture Board statement on the registration of special use names in the ARPA domain», March 2017,

<https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-onthe-registration-of-special-use-names-in-the-arpadomain/>.

[SDO-IANA-SUDR] IANA, «Special-Use Domain Names», <http://www.iana.org/assignments/special-use-domain-names>.

[SDO-ICANN-COLL] Interisle Consulting Group, LLC, «Name Collision in the DNS», Version 1.5, August 2013, <https://www.icann.org/en/system/files/files/name-collision-02aug13-en.pdf>.

[SDO-ICANN-DAG] ICANN, «gTLD Applicant Guidebook», Version 2012-06-04, June 2012, <https://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf>.

[SDO-ICANN-SAC090] ICANN Security and Stability Advisory Committee, «SSAC Advisory on the Stability of the Domain Namespace», ICANN SAC090, December 2016, <https://www.icann.org/en/system/files/files/sac-090-en.pdf>.

[SDO-ICANN-SSAC] ICANN, «Security and Stability Advisory Committee (SSAC)», December 2016, <https://www.icann.org/groups/ssac>.

[TOR] Tor, «Tor — Anonymity Online», <https://www.torproject.org>.

Авторы

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

Стефан Борцмейер, Джон Дикинсон, Боб Гарольд, Пол Хоффман, Расс Хоусли, Джоэл Джеггли, Эндрю МакКонахи, Джордж Майклсон, Петр Спейсек и другие предоставили значительный обзор и / или полезные комментарии.

Этот документ также во многом обязан прекрасной работе Эда Льюиса над тем, что такое «доменное имя» [DOMAIN-NAMES].

Мы также хотели бы поблагодарить авторов [PROBLEM-SPECIAL-NAMES], в том числе Алена Дюранда, Джеффа Хьюстона, Питера Коха и Джо Абли, за их усилия по постановке вопросов и привлечению рабочей группы, а также за их вклад в список вопросов из их документа [PROBLEM-SPECIAL-NAMES].

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

Ted Lemon
Nominum, Inc.
800 Bridge Parkway
Redwood City, CA 94065
United States of America
Phone: +1 650 381 6000
Email: ted.lemon@nominum.com

Ralph Droms
Email: rdroms.ietf@gmail.com

Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: warren@kumari.net