RFC 6761 | Специальные доменные имена

Аннотация

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

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

 

Оглавление

1. Введение
2. Терминология
3. Применимость
4. Процедура
5. Вопросы резервирования доменных имен
6. Первоначальный реестр
6.1. Вопросы резервирования доменных имен для частных адресов
6.2. Соображения о резервировании доменного имени для «test.»
6.3. Соображения о резервировании доменного имени для «localhost.»
6.4. Соображения о резервировании доменного имени для «invalid.»
6.5. Вопросы резервирования доменных имен для примеров доменов
7. Вопросы безопасности
8. Соображения IANA
9. Ссылки
9.1. Нормативные ссылки
9.2. Информационные ссылки
Адреса авторов

 

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

Это документ по отслеживанию стандартов Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественную рецензию и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 5741.
Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc6761.

 

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

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

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

 

1. Введение

Некоторые отдельные IP-адреса и диапазоны IP-адресов специально обрабатываются сетевыми реализациями и, следовательно, не подходят для использования в качестве одноадресных адресов. Например, адреса IPv4 с 224.0.0.0 по 239.255.255.255 являются многоадресными адресами [RFC5735], причем 224.0.0.1 является многоадресным адресом «все хосты» [RFC1112] [RFC5771]. Другой пример — 127.0.0.1, адрес локального хоста IPv4 [RFC5735].

По аналогии со специальными адресами IPv4 [RFC5735], система доменных имен (DNS) [RFC1034] [RFC1035] имеет свою собственную концепцию зарезервированных имен, таких как «example.com.», «Example.net.» И « example.org. «, или любое имя, попадающее под псевдодомен верхнего уровня» invalid «. [RFC2606]. Однако «Зарезервированные DNS-имена верхнего уровня» [RFC2606] не указывают, должны ли реализации обрабатывать такие имена по-разному, и если да, то каким образом.

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

 

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

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].

 

3. Применимость

Когда была создана многоадресная IP-рассылка [RFC1112], необходимо было обновить реализацию, чтобы понять, что означает многоадресный IP-адрес и что с ним делать. Добавление многоадресной IP-рассылки к сетевому стеку повлекло за собой нечто большее, чем просто добавление правильных записей таблицы маршрутизации для этих адресов. Более того, поддержка многоадресной IP-передачи влечет за собой некоторый уровень общности, который одинаков для всех совместимых хостов, независимо от того, к каким сетям эти хосты могут быть подключены. Хотя можно построить частную изолированную сеть, используя любые допустимые одноадресные IP-адреса и топологию маршрутизации, которую вы выбираете (независимо от того, используются ли эти одноадресные IP-адреса другими хостами в общедоступном Интернете), многоадресный IPv4-адрес 224.0.0.1 всегда групповой адрес «все хосты», и это не локальное решение.

Точно так же, если у доменного имени есть специальные свойства, которые влияют на то, как аппаратные и программные реализации обрабатывают имя, которые применяются повсеместно, независимо от того, к какой сети может быть подключена реализация, тогда это доменное имя может быть кандидатом на то, чтобы IETF объявила его быть доменным именем специального назначения и указать, какие реализации специального режима должны давать этому имени. С другой стороны, если объявление данного имени специальным не приведет к изменению каких-либо реализаций, то это говорит о том, что имя не может быть особенным каким-либо существенным образом, и может оказаться более целесообразным использовать существующие механизмы DNS [ RFC1034] для предоставления желаемого делегирования, данных или отсутствия данных для рассматриваемого имени. Если желаемое поведение может быть достигнуто с помощью существующих процессов регистрации доменных имен, этот процесс следует использовать. Резервирование доменного имени специального назначения не является механизмом обхода обычных процессов регистрации доменного имени.

В качестве примера, предположим, что должен был быть документ IETF, указывающий, что конкретное имя (или набор имен) гарантированно приведет к результату NXDOMAIN («Ошибка имени» [RFC1035]). Такой документ входит в обязанности IETF. IETF отвечает за правила протокола. IETF определяет набор символов имени, пределы длины, синтаксис, тот факт, что в DNS «A» эквивалентен «a» и т. Д. [RFC1034] [RFC1035]. Части пространства имен, созданные в соответствии с этими правилами, передаются в ICANN для управления, но из-за установленных правил протокола DNS ICANN не может выделять «COM» и «com» ​​двум различным серверам имен. IETF несет ответственность за указание того, как работает протокол DNS, а ICANN отвечает за распределение имен, которые стали возможны благодаря этому протоколу DNS. Теперь предположим, что разработчик использовал это специальное «гарантированное несуществующее» имя, «зная», что оно гарантированно вернет NXDOMAIN, и предположим также, что DNS-сервер пользователя не может вернуть NXDOMAIN для этого имени. Программное обеспечение разработчика тогда терпит неудачу. На кого жалуются пользователь и / или разработчик? ICANN? IETF? Оператор DNS-сервера? Если разработчик не может зависеть от специального «гарантированного несуществующего» имени, которое всегда возвращает NXDOMAIN, то специальное имя бесполезно, поскольку на него нельзя полагаться в том, что он должен делать. Чтобы это специальное «гарантированное несуществующее» имя имело какое-либо использование, оно должно быть определено так, чтобы оно возвращало NXDOMAIN, BY PROTOCOL для всех установок, а не только для размещения ICANN в общедоступном Интернете. ICANN не обладает юрисдикцией в отношении того, как пользователи выбирают для настройки своих собственных частных DNS-серверов в своих частных сетях, но разработчикам нужна спецификация протокола, в которой говорится, что возврат положительных ответов для специального «гарантированного несуществующего» имени является нарушением протокола во всех * сетях * , а не только публичный интернет. Следовательно, действие по определению такого специального имени создает правило протокола более высокого уровня над управлением ICANN по распределению имен в общедоступном Интернете.

 

4. Процедура

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

Спецификация ДОЛЖНА указывать, как реализации определяют, что для любого заданного имени требуется специальная обработка. Обычно это делается путем о том, что любое полное доменное имя заканчивается в определенный суффикс (например, падение в пределах заданного родительского pseudodomain) получит специальное поведение. По сути, это выделяет поддерево пространства имен DNS, в котором применяются измененные правила обработки имен, аналогично тому, как многоадресные IP-адреса [RFC1112] или локальные IP-ссылки [RFC3927] [RFC4862] выделяют фрагменты IP-адреса. пространство, в котором применяются соответствующие измененные правила обработки адресов.

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

 

5. Вопросы резервирования доменных имен

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

1. Пользователи:
Ожидается ли, что пользователи распознают эти имена как особые и используют их по-другому? В каком смысле?

2. Прикладное программное обеспечение:
Ожидается, что авторы прикладного программного обеспечения заставят свое программное обеспечение распознавать эти имена как особые и относиться к ним по-разному? В каком смысле? (Например, если пользователь вводит такое имя, должно ли прикладное программное обеспечение отклонять его с сообщением об ошибке?)

3. API разрешения имен и библиотеки:
Ожидается, что авторы API и библиотек разрешения имен заставят свое программное обеспечение распознавать эти имена как особые и по-разному к ним относятся? Если так, то как?

4. Кеширование DNS-серверов:
Ожидается ли от разработчиков кэширующих серверов доменных имен, чтобы их реализации распознавали эти имена как специальные и относились к ним по-разному? Если так, то как?

5. Официальные DNS-серверы:
Ожидается ли от разработчиков авторитетных серверов доменных имен, чтобы их реализации распознавали эти имена как специальные и относились к ним по-разному? Если так, то как?

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

7. DNS-реестры / регистраторы:
Как DNS-реестры / регистраторы должны обрабатывать запросы на регистрацию этого зарезервированного доменного имени? Должны ли такие запросы быть отклонены? Должны ли такие запросы быть разрешены, но только специально назначенному объекту? (Например, имя «www.example.org» зарезервировано для примеров документации и недоступно для регистрации; однако, имя фактически зарегистрировано; на этом имени даже есть веб-сайт, в котором циркулярно говорится, что имя зарезервировано для использования в документации и не может быть зарегистрировано!)

 

6. Первоначальный реестр

Первоначальный реестр IANA «Особые доменные имена» должен содержать записи для доменов с обратным отображением частного адреса [RFC1918] и для существующих зарезервированных DNS-имен верхнего уровня [RFC2606].

 

6.1. Вопросы резервирования доменных имен для частных адресов

Перечисленные ниже домены обратного сопоставления с частным адресом [RFC1918] и любые имена, попадающие в эти домены, являются доменными именами специального назначения:

10.in-addr.arpa.
16.172.in-addr.arpa.
17.172.in-addr.arpa.
18.172.in-addr.arpa.
19.172.in-addr.arpa.
20.172.in-addr.arpa.
21.172.in-addr.arpa.
22.172.in-addr.arpa.
23.172.in-addr.arpa.
24.172.in-addr.arpa.
25.172.in-addr.arpa.
26.172.in-addr.arpa.
27.172.in-addr.arpa.
28.172.in-addr.arpa.
29.172.in-addr.arpa.
30.172.in-addr.arpa.
31.172.in-addr.arpa.
168.192.in-addr.arpa.

Эти домены и любые имена, попадающие в эти домены, являются особенными в следующих отношениях:

1. Пользователи могут использовать эти имена так же, как и любые другие имена с обратным отображением. Однако, поскольку нет централизованного органа, ответственного за использование частных адресов, пользователи ДОЛЖНЫ знать, что эти имена могут давать разные результаты в разных сетях.

2. Прикладному программному обеспечению НЕ СЛЕДУЕТ распознавать эти имена как специальные, и СЛЕДУЕТ использовать эти имена, как и другие имена с обратным отображением.

3. API и библиотеки разрешения имен НЕ ДОЛЖНЫ распознавать эти имена как специальные и НЕ ДОЛЖНЫ трактовать их по-разному. API разрешения имен ДОЛЖНЫ отправлять запросы на эти имена на свои настроенные DNS-серверы кэширования.

4. Кэширующим DNS-серверам СЛЕДУЕТ распознавать эти имена как специальные и НЕ ДОЛЖНЫ, по умолчанию, НЕ пытаться искать записи NS для них или иным образом запрашивать авторитетные DNS-серверы, пытаясь разрешить эти имена. Вместо этого кэширующие DNS-серверы ДОЛЖНЫ по умолчанию генерировать немедленные (положительные или отрицательные) ответы на все такие запросы. Это сделано для того, чтобы избежать ненужной нагрузки на корневые серверы имен и другие серверы имен. Кэширующим DNS-серверам СЛЕДУЕТ предлагать опцию конфигурации (по умолчанию отключена) для разрешения восходящего разрешения таких имен для использования в частных сетях, где известно, что имена обратного преобразования частных адресов обрабатываются авторитетным DNS-сервером в указанной частной сети.

5. Авторитетным DNS-серверам СЛЕДУЕТ распознавать эти имена как специальные, и СЛЕДУЕТ, по умолчанию, генерировать немедленные отрицательные ответы на все такие запросы, если только администратор явно не настроит положительные ответы для имен обратного сопоставления частных адресов.

6. Операторам DNS-серверов СЛЕДУЕТ, если они используют частные адреса, настроить свои доверенные DNS-серверы так, чтобы они действовали как доверенные для этих имен.

7. Реестры / регистраторы DNS НЕ ДОЛЖНЫ предоставлять запросы на регистрацию любого из этих имен обычным способом любому физическому или юридическому лицу. Эти имена зарезервированы для использования в частных сетях и выходят за пределы набора имен, доступных для распределения реестрами / регистраторами. Попытка выделить одно из этих имен, как если бы это было обычное доменное имя DNS, вероятно, не будет работать должным образом по причинам 4, 5 и 6 выше.

 

6.2. Соображения о резервировании доменного имени для «test.»

Домен «test.» И любые имена, попадающие в «.test.», Являются специальными в следующих отношениях:

1. Пользователи могут свободно использовать эти тестовые имена, как и любые другие доменные имена. Однако, поскольку нет центрального органа, ответственного за использование имен тестов, пользователи ДОЛЖНЫ знать, что эти имена могут давать разные результаты в разных сетях.

2. Прикладному программному обеспечению НЕ СЛЕДУЕТ распознавать тестовые имена как специальные, и СЛЕДУЕТ использовать тестовые имена, как и другие доменные имена.

3. API и библиотеки разрешения имен НЕ ДОЛЖНЫ распознавать имена тестов как специальные и НЕ ДОЛЖНЫ обрабатывать их по-разному. API разрешения имен ДОЛЖНЫ отправлять запросы на имена тестов на свои настроенные DNS-серверы кэширования.

4. Кэширование DNS-серверов ДОЛЖНО распознавать имена тестов как специальные, и НЕ ДОЛЖНО по умолчанию пытаться найти для них записи NS или иным образом запрашивать авторитетные DNS-серверы в попытке разрешить имена тестов. Вместо этого кэширующие DNS-серверы ДОЛЖНЫ по умолчанию генерировать немедленные отрицательные ответы на все такие запросы. Это сделано для того, чтобы избежать ненужной нагрузки на корневые серверы имен и другие серверы имен. Кеширующим DNS-серверам СЛЕДУЕТ предлагать опцию конфигурации (по умолчанию отключена), чтобы разрешить исходное разрешение имен тестов для использования в сетях, где известно, что имена тестов обрабатываются уполномоченным DNS-сервером в указанной частной сети.

5. Авторитетным DNS-серверам СЛЕДУЕТ распознавать имена тестов как специальные и СЛЕДУЕТ, по умолчанию, генерировать немедленные отрицательные ответы на все такие запросы, если только администратор явно не настроит давать положительные ответы для имен тестов.

6. Операторам DNS-серверов СЛЕДУЕТ, если они используют имена тестов, настроить свои доверенные DNS-серверы так, чтобы они действовали как авторитетные для тестовых имен.

7. DNS-реестры / регистраторы НЕ ДОЛЖНЫ предоставлять запросы на регистрацию тестовых имен обычным способом любому физическому или юридическому лицу. Имена тестов зарезервированы для использования в частных сетях и выходят за пределы набора имен, доступных для распределения реестрами / регистраторами. Попытка присвоить тестовое имя, как если бы оно было обычным DNS-именем домена, вероятно, не будет работать должным образом по причинам 4, 5 и 6 выше.

 

6.3. Соображения о резервировании доменного имени для «localhost.»

Домен «localhost.» и любые имена, попадающие в «.localhost.» являются особенными в следующих отношениях:

1. Пользователи могут свободно использовать имена локальных хостов, как и любые другие доменные имена. Пользователи могут предполагать, что запросы адресов IPv4 и IPv6 для имен локальных хостов всегда будут разрешаться для соответствующего IP-адреса обратной связи.

2. Прикладное программное обеспечение МОЖЕТ распознавать имена локальных хостов как специальные или МОЖЕТ передавать их в API разрешения имен, как и для других доменных имен.

3. API и библиотеки разрешения имен ДОЛЖНЫ распознавать имена локальных хостов как особые и ДОЛЖНЫ всегда возвращать IP-адрес обратной связи для адресных запросов и отрицательные ответы для всех других типов запросов. API разрешения имен НЕ ДОЛЖНЫ отправлять запросы на имена локальных хостов на свои настроенные кэширующие DNS-серверы.

4. Кэширующие DNS-серверы ДОЛЖНЫ распознавать имена локальных хостов как специальные и НЕ ДОЛЖНЫ пытаться найти записи NS для них или иным образом запрашивать авторитетные DNS-серверы в попытке разрешить имена локальных хостов. Вместо этого кэширующие DNS-серверы ДОЛЖНЫ для всех таких адресных запросов генерировать немедленный положительный ответ, дающий IP-адрес обратной связи, а для всех других типов запросов генерировать немедленный отрицательный ответ. Это сделано для того, чтобы избежать ненужной нагрузки на корневые серверы имен и другие серверы имен.

5. Официальным DNS-серверам СЛЕДУЕТ распознавать имена локальных хостов как специальные и обрабатывать их, как описано выше для кэширования DNS-серверов.

6. Операторам DNS-сервера СЛЕДУЕТ помнить, что эффективные RDATA для имен локальных хостов определяются спецификацией протокола и не могут быть изменены локальной конфигурацией.

7. DNS-реестры / регистраторы НЕ ДОЛЖНЫ предоставлять запросы на регистрацию имен локальных хостов обычным способом любому физическому или юридическому лицу. Имена локальных хостов определяются спецификацией протокола и выходят за пределы набора имен, доступных для распределения реестрами / регистраторами. Попытка присвоить имя локального хоста, как если бы это было обычное имя домена DNS, вероятно, не будет работать должным образом по причинам 2, 3, 4 и 5 выше.

 

6.4. Соображения о резервировании доменного имени для «invalid.»

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

1. Пользователи могут свободно использовать «недействительные» имена, как и любые другие доменные имена. Пользователи МОГУТ предположить, что запросы на «недопустимые» имена всегда будут возвращать ответы NXDOMAIN.

2. Прикладное программное обеспечение МОЖЕТ распознавать «недействительные» имена как специальные или МОЖЕТ передавать их в API разрешения имен, как и для других доменных имен.

3. API и библиотеки разрешения имен ДОЛЖНЫ распознавать «недопустимые» имена как специальные и ДОЛЖНЫ всегда возвращать немедленные отрицательные ответы. API разрешения имен НЕ СЛЕДУЕТ отправлять запросы на «недопустимые» имена своим настроенным DNS-серверам кэширования.

4. Кэширующим DNS-серверам СЛЕДУЕТ распознавать «недопустимые» имена как особые и НЕ СЛЕДУЕТ пытаться искать записи NS для них или иным образом запрашивать уполномоченные DNS-серверы в попытке разрешить «недопустимые» имена. Вместо этого кэширующие DNS-серверы ДОЛЖНЫ генерировать немедленные ответы NXDOMAIN на все такие запросы. Это сделано для того, чтобы избежать ненужной нагрузки на корневые серверы имен и другие серверы имен.

5. Авторитетным DNS-серверам СЛЕДУЕТ распознавать «недействительные» имена как специальные и обрабатывать их, как описано выше для кэширования DNS-серверов.

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

7. DNS-реестры / регистраторы НЕ ДОЛЖНЫ предоставлять запросы на регистрацию «недействительных» имен обычным способом любому физическому или юридическому лицу. Эти «недопустимые» имена определены в спецификации протокола как несуществующие, и они выходят за пределы набора имен, доступных для распределения реестрами / регистраторами. Попытка присвоить «недопустимое» имя, как если бы оно было нормальным доменным именем DNS, вероятно, не будет работать должным образом по причинам 2, 3, 4 и 5 выше.

 

6.5. Вопросы резервирования доменных имен для примеров доменов

Домены «example.», «example.com.», «example.net.», «example.org.» и любые имена, попадающие в эти домены, являются специальными в следующих отношениях:

1. Пользователи ДОЛЖНЫ понимать, что примеры имен зарезервированы для использования в документации.

2. Прикладному программному обеспечению НЕ СЛЕДУЕТ распознавать имена примеров как специальные и СЛЕДУЕТ использовать имена примеров, как и другие доменные имена.

3. API и библиотеки разрешения имен НЕ СЛЕДУЕТ распознавать имена примеров как особые и НЕ СЛЕДУЕТ относиться к ним по-разному. API-интерфейсы разрешения имен ДОЛЖНЫ отправлять запросы примеров имен на свои настроенные кэширующие DNS-серверы.

4. Кеширующие DNS-серверы НЕ ДОЛЖНЫ распознавать имена примеров как особые и ДОЛЖНЫ разрешать их как обычно.

5. Авторитетным DNS-серверам НЕ СЛЕДУЕТ распознавать имена примеров как специальные.

6. Операторы DNS-сервера ДОЛЖНЫ знать, что примеры имен зарезервированы для использования в документации.

7. DNS-реестры / регистраторы НЕ ДОЛЖНЫ предоставлять запросы на регистрацию имен примеров обычным способом любому физическому или юридическому лицу. Все примеры имен зарегистрированы на неограниченный срок в IANA:

Domain Name: EXAMPLE.COM
Registrar: RESERVED-INTERNET ASSIGNED NUMBERS AUTHORITY
Whois Server: whois.iana.org
Referral URL: http://res-dom.iana.org
Name Server: A.IANA-SERVERS.NET
Name Server: B.IANA-SERVERS.NET
Status: clientDeleteProhibited
Status: clientTransferProhibited
Status: clientUpdateProhibited
Updated Date: 26-mar-2004
Creation Date: 14-aug-1995
Expiration Date: 13-aug-2011

В настоящее время IANA поддерживает веб-сервер, предоставляющий веб-страницу, объясняющую назначение примеров доменов.

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

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

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

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

Когда IANA получает запрос на запись нового «доменного имени специального назначения», он должен после консультации с IESG проверить, что документ IETF «Стандартные действия» или «Утверждение IESG» [RFC5226] включает в себя обязательное «Резервирование доменного имени». Раздел «Соображения», в котором говорится о том, как особое значение этого имени влияет на поведение оборудования, программного обеспечения и людей в семи категориях. Если IANA и IESG определят, что специальная обработка этого «доменного имени специального назначения» является подходящей, IANA должна записать доменное имя специального использования и ссылку на спецификацию, которая его документирует, в реестре.

9. Ссылки

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

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

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

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

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

[RFC1112] Deering, S., «Host extensions for IP multicasting», STD 5, RFC 1112, August 1989.

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, February 1996.

[RFC2606] Eastlake, D. and A. Panitz, «Reserved Top Level DNS Names», BCP 32, RFC 2606, June 1999.

[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, «Dynamic Configuration of IPv4 Link-Local Addresses», RFC 3927, May 2005.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, «IPv6 Stateless Address Autoconfiguration», RFC 4862, September 2007.

[RFC5735] Cotton, M. and L. Vegoda, «Special Use IPv4 Addresses», BCP 153, RFC 5735, January 2010.

[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, «IANA Guidelines for IPv4 Multicast Address Assignments», BCP 51, RFC 5771, March 2010.

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

Stuart Cheshire
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
Phone: +1 408 974 3207
EMail: cheshire@apple.com

Marc Krochmal
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
Phone: +1 408 974 4368
EMail: marc@apple.com
Cheshire