Доменное имя и интеллектуальная собственность
Очевидно, доменное имя, ранее служившее, в первую очередь, для идентификации адреса сайта, стало важным средством формирования имиджа компании, аналогично таким репутационным средствам индивидуализации как товарный знак, наименование места происхождения и другие.
В отношении доменного имени также действует правило, согласно которому каждое его использование третьим лицом уменьшает способность привлекать внимание потребителей, снижает его эксклюзивность и уменьшает ассоциативность, связь с товарным знаком. Создает, что называется, Brand Erosion – размывание бренда.
Так, к примеру, в судебном разбирательстве Intermatic Inc. против Toeppen окружной суд штата Иллинойс, США[1] установил, что использование известного товарного знака другим лицом в доменном имени уменьшает его потребительскую привлекательность, поскольку данный товарный знак появляется в качестве имени домена при каждой распечатке материалов с данного сайта.
Ответчик заявлял, что доменное имя при распечатке отображается браузером и вызывает лишь краткосрочную ассоциацию с товарным знаком, что является недостаточным для оказания негативного влияния на его рекламу.
По большому счету, доменное имя уже собрало в себе все главные характеристики полноценного объекта гражданского оборота, как минимум: оно выступает в качестве нематериального актива компаний, объекта купли-продажи, а также предмета многомиллионных судебных исков (к примеру, домен business.com в сделке R.H. Donnelley Corp. был продан за сумму не менее 340 миллионов долларов США, по сообщению The Wall Street Journal Online).
Несмотря на очевидную необходимость установления четких правовых основ регулирования доменных имен, однозначного подхода на международном уровне до сих пор не существует.
Применяемые в различных государствах при выработке юридических критериев понятия доменного имени, правового регулирования верхнего уровня и национального доменного имени верхнего уровня различаются.
В Российской Федерации в настоящее время доменные имена не являются объектом интеллектуальной собственности. При этом, по данным на 6 августа 2018 года, в доменной зоне. РФ насчитывается 5 084 280 активных домена[2].
Отсутствуют и специальные правовые акты, регулирующие систему регистрации доменных имен. На сегодняшний день регулятором регистрационных процедур выступает АНО «Координационный центр национального домена сети «Интернет», администратор национального домена сети.
Регистрация доменного имени осуществляется после заключения договора c компанией, являющейся официальным аккредитованным регистратором[3] в электронном виде чаще всего. В договоре обязательно указываются сервер, где будет располагаться домен, программное обеспечение. Урегулирование спорных вопросов владельцами доменных имен, предоставленными национальными регистраторами, как правило, происходит в рамках судебных разбирательств. Однако в некоторых случаях помимо судебных процедур доменные споры разрешаются в рамках процедуры UDRP, схожий в некоторой степени с третейским судом.
Определение понятия «доменное имя» содержится в Федеральном законе от 27.07.2006 N 149-ФЗ (ред. от 06.07.2016) «Об информации, информационных технологиях и о защите информации», согласно которому под доменным именем понимается обозначение символами, предназначенное для адресации сайтов в сети «Интернет» в целях обеспечения доступа к информации, размещенной в сети «Интернет».
При подготовке IV части Гражданского кодекса многие специалисты склонялись к необходимости рассмотрения доменного имени в качестве средства индивидуализации, в проекте Федерального закона N 47538-6 «О внесении изменений в части первую, вторую, третью и четвертую Гражданского кодекса Российской Федерации, а также в отдельные законодательные акты Российской Федерации» давалось определение доменного имени и фиксировалось, что исключительное право на него возникает с момента регистрации. Но в процессе рассмотрения законопроекта указанные положения были исключены, в настоящее время Гражданский кодекс Российской Федерации устанавливает, что доменное имя является лишь одним из способов использования товарного знака и наименования места происхождения товара в сети «Интернет».
Отражено это в двух статьях:
1484 об исключительном праве на товарный знак, в которой указано, что исключительное право на товарный знак может быть осуществлено для индивидуализации товаров, работ или услуг, в отношении которых товарный знак зарегистрирован, в частности, путем размещения товарного знака в сети «Интернет», в том числе в доменном имени и при других способах адресации; и
1519 при аналогичном вопросе – использовании исключительного права на наименование места происхождения товара — использование наименования места происхождения товара считается, в частности, размещение этого наименования, в частности, в сети «Интернет», в том числе в доменном имени и при других способах адресации.
Одним из доводов, аргументирующих невозможность отнесения доменных имен в перечень средств индивидуализации, является отсутствие их различительной способности.
Несмотря на отсутствие признания доменного имени в качестве объекта интеллектуальной собственности на законодательном уровне при вынесении судебных решений суды могут руководствоваться постановлениями высших органов судов.
Так в Постановлении Президиума Высшего Арбитражного Суда Российской Федерации при рассмотрении дела по иску Корпорации «Истман Кодак Компани» о запрещении использования товарного знака «Kodak», зарегистрированного на имя истца, в доменном имени страницы ответчика в «Интернете» (Постановление Президиума ВАС РФ от 16.01.2001 N 1192/00 по делу N А40-25314/99-15-271) было отмечено, что доменные имена фактически трансформировались в средство, выполняющее функцию товарного знака, который дает возможность отличать соответственно товары и услуги одних юридических или физических лиц от однородных товаров и услуг других юридических или физических лиц, поскольку современная коммерческая практика показала, что при выборе доменных имен для «Интернета» владельцы информационных ресурсов останавливаются на максимально простых и логичных именах (слово, группа букв и т.п.), которые обычно ассоциируются у потребителей непосредственно с конкретным участником хозяйственного оборота или его деятельностью.
Кроме того, как отмечается в указанном Постановлении, доменные имена, содержащие товарные знаки или торговые наименования, имеют коммерческую стоимость.
Позиция Высшего Арбитражного Суда Российской Федерации, фактически приравнявшая доменные имена к товарным знакам, была позже учтена в решениях нижестоящих судов.
Позднее Суд по интеллектуальным правам в специальном документе «Об утверждении справки по вопросам, возникающим при рассмотрении доменных споров», утвержденным Постановлением Президиума Суда по интеллектуальным правам от 28.03.2014 N СП-21/4, обратил особое внимание на положения, сформулированные в Единообразной политике по разрешению споров в связи с доменными именами, одобренной интернет-корпорацией по присвоению названий и номеров, в том числе в ее параграфах 4(a), 4(b) и 4(c).
Доменные споры определяются указанным Постановлением как споры по использованию доменных имен, тождественных или сходных до степени смешения с товарными знаками или иными средствами индивидуализации юридических лиц, товаров, работ, услуг и предприятий.
Исключительное право на товарный знак может быть осуществлено для индивидуализации товаров, работ или услуг, в отношении которых товарный знак зарегистрирован, в частности, путем размещения товарного знака в сети «Интернет», в том числе в доменном имени. Аналогичный поход применяется в отношении наименований мест происхождения товаров.
Исключительному праву на использование товарного знака корреспондирует обязанность неопределенного круга третьих лиц по недопущению использования обозначений, тождественных или сходных до степени смешения с товарным знаком правообладателя в отношении однородных товаров.
При рассмотрении ситуаций использования товарных знаков в доменном имени без согласия правообладателя выделяются следующую виды нарушений:
1) нарушение используется для создания препятствия правообладателю, для размещения информации о нем и его товарах (услугах) в указанном домене;
2) у владельца доменного имени нет каких-либо законных прав и законных интересов в отношении доменного имени;
3) доменное имя зарегистрировано и используется недобросовестно.
Защита исключительного права на товарный знак реализуется, в том числе путем предъявления в суд искового требования о пресечении действий, нарушающих право владельца товарного знака. При этом при рассмотрении доменных споров такое требование может быть заявлено в виде требования о запрете использования доменного имени, в том числе определенным образом (например, удалить и более не размещать информацию о конкретных видах товаров на соответствующем сайте).
Кроме того, действия по регистрации доменного имени (в том числе с учетом обстоятельств последующего его использования) могут быть признаны актом недобросовестной конкуренции. В этом случае также нарушением исключительного права на товарный знак может быть признана сама по себе регистрация доменного имени исходя из целей такой регистрации.
Постановлением также установлено, что при рассмотрении доменных споров судами могут применяться положения статьи 10 Гражданского кодекса Российской Федерации и статьи 10.bis Парижской конвенции, в параграфе 2 которой отмечено, что актом недобросовестной конкуренции считается всякий акт конкуренции, противоречащий честным обычаям в промышленных и торговых делах.
Таким образом, вопрос недобросовестной конкуренции при доменных спорах является одним из возможных его аспектов, в то время как основной акцент при обеспечении прав владельца доменного имени связан с защитой исключительных прав на товарный знак и наименование места происхождения товара.
Также согласно Постановлению Президиума ВАС Российской Федерации № 1192/00 от 16 января 2001 г. в рамках разрешения спора об использовании товарного знака в доменном имени «доменные имена фактически трансформировались в средство, выполняющее функцию товарного знака, который дает возможность отличать соответственно товары и услуги одних юридических или физических лиц от однородных товаров и услуг других юридических или физических лиц. Кроме того, доменные имена, содержащие товарные знаки или торговые наименования, имеют коммерческую стоимость».
Обращаясь к зарубежной практике касательно вопросов, связанных с правовым регулированием доменных имен, пожалуй, стоить отметить следующее.
Соглашение по торговым аспектам прав интеллектуальной собственности не признает доменные имена в качестве объекта интеллектуальной собственности.
Тем не менее, в контексте Всемирной торговой организации фактом возрастающего значения доменных имен в международной торговле, а именно в электронной коммерции, нельзя пренебречь. Так, более семнадцати соглашений о свободной торговле содержит то или иное упоминание о механизме разрешения доменных споров, включая торговые соглашения США, Китая и Никарагуа. Главенствующей причиной необходимости фиксации в международных договорах порядка регулирования разрешения доменных споров, является возрастающее количество случаев кибер-пиратства, с которыми сталкиваются владельцы товарных знаков. Как правило, соглашения устанавливают обязательство по установлению процедур по разрешению споров, основанных на правилах Единой политики разрешения споров в доменных именах ICANN. Между тем, подходы, сами правила осуществления разрешительных процедур продолжают сохранять существенные различия.
Очевидно, что характеристики доменных имен не позволяют отнести их к средствам индивидуализации. Так, к примеру, доменное имя индивидуализирует не товар или услугу, а информационный ресурс.
Доменное имя в целом не может быть относительно новым, а исключительно новым. Охрана товарного знака ставится в зависимость от использования, в то время как досрочное прекращение прав на доменное имя не используется. Также отличной чертой является то, что доменное имя является абсолютно уникальным не только для государства, где была осуществлена регистрация, но и для всех остальных государств.
Учитывая принципиально разный подход к правовому регулированию доменного имени на международном уровне, весьма стремительно меняющиеся правила, а, самое важное – увеличение количества споров с их участием, видится, что наиболее оптимальным решением проблемных вопросов с доменными именами, возможно, стало бы создание отдельного органа, специализирующегося именно на данном вопросе, к примеру, судебной палаты по доменным спорам. Главным аргументом в данном видении решения проблемы выступает требование по наличию высококвалифицированных специалистов – способных выявлять особенности каждого конкретного случая, относить по наличествующим признакам спор в область института конкурентного права или делая акцент на связи доменного имени с объектами интеллектуальной собственности — в противовес радикальным призывам к кардинальным изменениям, таким как, признания доменного имени в качестве объекта интеллектуальной собственности, к примеру.
[1] INTERMATIC INCORPORATED, Plaintiff, v. Dennis TOEPPEN, Defendant. No. 96 C 1982. United States District Court, N.D. Illinois, Eastern Division. Nov. 26, 1996. https://cyber.harvard.edu//property00/domain/Intermatic.html
[2] https://statonline.ru/?tld=ru
[3] К примеру, RU-CENTER (АО «Региональный Сетевой Информационный Центр») — первый в России и крупнейший профессиональный регистратор доменов, один из ведущих хостинг-провайдеров.
Что такое DNS-записи домена? Типы ресурсных записей 🌐
Содержание
- Составные части DNS-записи
- Популярные типы записей
- Как добавить запись
Система доменных имен (Domain Name System) или просто DNS — важнейшая часть механизма Всемирной сети. Именно она позволяет сопоставить доменные имена веб-ресурсов с IP-адресами физических устройств, на которых они расположены.
Эту распределенную базу данных можно назвать аналогом «телефонного справочника» всего Интернета.
«Телефонные номера» в ней — это IP-адреса, а «ФИО абонентов» — соответствующие им доменные имена.
Информацию о доменах для подобной «телефонной книги» хранят специальные DNS-серверы в виде ресурсных записей (DNS-записей ресурса). Чтобы новый сайт получил официальную «прописку» в Сети, нужно сначала прикрепить (делегировать) его домен на DNS-серверы, а затем прописать на этих серверах ресурсные записи.
Об основных типах DNS-записей и их назначении расскажем в данной статье.
Из чего состоит DNS-запись
В состав DNS-записи входят следующие поля:
- Name / Hostname (Имя, хост, домен — имеет несколько названий). Определяет домен, к которому относится (привязана) данная ресурсная запись.
- Type (Тип). Указывает на тип (назначение) данной ресурсной записи. Наиболее распространенные типы DNS-записей — A, AAAA, MX, CNAME и TXT.
- Class (Класс). Здесь указывается тип рабочей сети. Теоретически, система может работать во всех ее типах.
Но, TCP/IP сети — самые распространенные. Поэтому, поле редко используется. - TTL (Time To Live) — время жизни (хранения) DNS-записи.
- RDATA (Resource Data) — значение данного поля ресурсной записи зависит от ее конкретного типа.
- Priority (Приоритет) — задает приоритет (очередность) обработки конкретной DNS-записи.
- Protocol (Протокол)— указывает на протокол, используемый TCP, UDP, TLS.
- Service Name (Имя сервиса) — его можно посмотреть в файле /etc/services. Например: pop3, telnet.
- Weight (Вес) — задает вес хоста. Обработка запросов распределяется по весу хоста.
- Address
Но, TCP/IP сети — самые распространенные. Поэтому, поле редко используется.Некоторые виды DNS-записей могут иметь дополнительные поля, отличные от указанных.
Распространенные типы записей
Типы DNS-записей зависят от их функционального назначения.
A-запись (Address record)
Address record указывает на конкретный IP-адрес домена. Без нее сайт работать не будет. По этой записи система определяет к какому серверу обращаться за получением информации, когда пользователь вводит название сайта в адресную строку веб-браузера.
Пример| Hostname | Тип записи | Значение записи |
| eternalhost.net. | A | 194.61.0.6 |
AAAA-запись (Address record to IPv6)
AAAA запись DNS — аналог предыдущей А-записи. В значении указывается внешний IP-адрес в формате IPv6.
Пример| Hostname | Тип записи | Значение записи |
| eternalhost.net. | AAAA | 212:14:2127:1:211:4eef:fe10:b17 |
CNAME-запись (Canonical name)
CNAME («каноническое имя») указывает на расположение хостов на одном сервере.
С ее помощью, можно прописать несколько доменов и поддоменов в рамках одного сервера.
Каноническое имя позволяет создать наследование, при котором поддомен получает свойства всех ресурсных записей одного домена (кроме NS), через псевдоним (алиас).
Перед ее заполнением, надо прописать A-запись. После, можно создавать псевдонимы (их количество не ограничено).
Пример| Hostname | Тип записи | Значение записи |
| www.eternalhost.net | CNAME | eternalhost.net. |
Каждое значение обязательно должно заканчиваться точкой. Таким образом, можно привязывать разные хосты к одному серверу или выполнять редирект.
MX-запись (Mail exchanger)
MX-запись задает почтовый сервер, который будет принимать и отправлять почту для данного домена. Запись может указывать на внутренний или внешний почтовый сервер.
Пример| Hostname | Тип записи | Значение записи |
eternalhost. net. | MX | mx1.eternalhost.net. |
При обработке электронной почты на внутреннем сервере, должна присутствовать A-запись.
Пример| Host name | Тип записи | Значение записи |
| eternalhost.net. | A | 194.61.0.6 |
Например, для привязки почты для домена на серверы Яндекс почты, надо указать следующие записи:
| Hostname | Тип записи | Значение | Приоритет | TTL |
| eternalhost.net. | MX | mx.yandex.net. | 10 |
Привязка почты для домена к Google, Mail.ru и другим почтовым сервисам осуществляется по такому же принципу.
NS-запись (Name Server)
Этой записью определяется доменный адрес DNS-сервера, обслуживающий конкретный домен.
Интернет-соединение с доменом не функционирует, если не указана NS-запись.
| Hostname | Тип записи | Значение записи |
| eternalhost.net. | NS | ns1.eternalhost.net. |
TXT-запись (Text String)
TXT-запись используется для хранения текстовых данных о домене. Их число может быть любым, если содержание одной записи не противоречит другим. TXT-запись ограничена размером до 255 байт.
Часто применяется для подтверждения прав на владение доменом. Например, когда осуществляется привязка к стороннему почтовому серверу, а также при подключении метрик и в других ситуациях.
Пример| Hostname | Тип записи | Значение записи |
| eternalhost.net. | TXT | Любая текстовая запись без кавычек. |
SOA-запись (Start of Authority)
Указывает местоположение сервера с эталонной информацией о домене. Запись создается автоматически в самом начале и не может быть отредактирована или удалена.
Пример| Hostname | Тип записи | Serial number | TTL | Refresh | Retry | Expire | Minimum TTL |
| Контактный адрес администратора файловой зоны | SOA | 1812191123 | 3600 | 7200 | 540 | 604800 | 86400 |
SRV-запись (Service record)
Указывает расположение серверов (имя хоста, № порта) для определенных сервисов. Выполняет ассоциативную роль. Например, через него можно задать:
IMAP-сервер для eternalhost.net находится по адресу mail.
eternalhost.net. При этом, eternalhost.net — веб-сервер.
| Host name | Service Name | Protocol | Priority | Weight |
| eternalhost.net. | _xmpp-server | _tcp | 100 | 0 |
PTR-запись (Reverse DNS)
Обратная запись DNS служит для связывания отдельного IP-адреса с доменным именем. В основном, запись используется для отправки почты с домена. Если PTR-запись совпадет с именем почтового сервера из параметра HELO (EHLO), повысится шанс миновать спам-фильтры почтовых серверов на стороне получателя письма.
Пример| Host name | Тип записи | Address |
| mail.eternalhost.net. | PTR | 194.61.06.in-addr.arpa |
DNAME-запись (Domain Name)
Запись используется для создания алиасов (псевдонимов) для всего дерева поддоменов, не затрагивая основной домен.
В этом заключается отличие DNAME от CNAME-записи, которая создает псевдонимы только для одного домена, без его поддоменов.
CAA-запись (Certification Authority Authorization)
Запись определяет, SSL/TLS-сертификаты каких центров сертификации могут применяться для указанного домена или поддомена. Обычно она генерируется на хостинге автоматически. Если CAA-запись не указана, это будет интерпретировано центром, как разрешение на выпуск сертификата.
HINFO-запись (Host Information)
В ней указывается архитектура и операционная система заданного хоста. Запись надо применять с крайней осторожностью, а лучше совсем не пользоваться самостоятельно (обычно ее заполняет хостинг-провайдер). Злоумышленники часто используют HINFO-запись для подготовки хакерских атак.
WKS-запись (Well Known Service)
Ассоциация hostname с конкретным портом и протоколом. Может задавать хост для обработки почты клиентов. На практике, почтовые сервисы почти никогда не запрашивают этих данных.
RP-запись (Responsible person)
Здесь прописаны реквизиты ответственных за домен. Указать можно как одного человека, так группу людей. Поле «Text Record Name» хранит Ф.И.О. ответственного работника, а поле «E-mail Address» — его электронную почту.
LOC-запись (Location information)
В соответствующие поля этой записи указываются широта и долгота физического местонахождения DNS-сервера, к которому привязан домен. Используется редко. Может быть полезна только для крупных компаний.
Где редактируются DNS-записи
Правильное заполненный список DNS-записей необходим для корректной работы сайта. Записи можно легко отредактировать в панели управления DNS-записями.
На Eternalhost для управления DNS-записями на виртуальном хостинге используется панель ISPmanager, а для доменов размещенных на VDS – DNS-хостинг.
DNS-хостинг
Услуга DNS-хостинг является бесплатной и заказывается отдельно. В этом случае управление DNS-записями будет выполняться в отдельной панели.
Для редактирования или создания DNS-записей нужно перейти в разделе «Главное» в «Доменные имена», выбрать нужное доменное имя и нажать «Записи» в верхнем меню.
В открывшемся списке можно добавить или отредактировать DNS-запись при помощи функциональных кнопок «Создать» и «Изменить».
При добавлении новой записи, прежде всего нужно выбрать тип записи, а уже потом заполнять необходимы поля для DNS-записи выбранного типа.
ISPmanager
В ISPmanager это делается в разделе «Доменные имена». Для редактирования нужно войти в панель управления, перейти в «Основное» → «Доменные имена», выделить курсором нужный домен и нажать кнопку «Управлять DNS записями» в верхнем меню.
Далее управление DNS-записями выполняется по аналогии с DNS-хостингом.
Что такое доменное имя? (+Как его получить!)
Сколько веб-сайтов вы посещаете в день?
Я не говорю о версиях веб-сайта для мобильных приложений, я говорю об использовании реального веб-браузера.
Но прежде чем мой любимый веб-сайт мог стать моим любимым, его нужно было создать, и первым шагом в процессе создания часто является выбор правильного доменного имени. Хотя есть много шагов, чтобы научиться создавать веб-сайт, одним из первых элементов, необходимых для этого, является определение доменного имени.
Заинтересованы в чем-то конкретном, касающемся доменных имен? В этой статье мы расскажем.
- Типы доменов верхнего уровня
- Выбор доменного имени
- Регистрация доменного имени
- Стоимость доменного имени
Доменное имя используется в URL-адресе (унифицированный указатель ресурсов) для идентификации конкретных веб-страниц. Например, в URL-адресе https://www.g2.com/categories/crm доменное имя g2.com .
По сути, ваше доменное имя — это то, как ваш веб-сайт будет известен в Интернете, независимо от того, какой у вас веб-сайт.
Пользователи, которые уже знают ваш домен, могут просто ввести его в свой браузер и перейти на ваш сайт.
Доменное имя состоит из двух частей, одна из которых является именем (g2crowd), а другая — расширением (.com).
Типы доменов верхнего уровня
У каждого доменного имени есть суффикс, указывающий, к какому домену верхнего уровня (TLD) оно принадлежит. TLD часто является индикатором для посетителя веб-сайта того, к чему на самом деле относится веб-сайт.
Существует много типов TLD, которые представляют собой часть расширения URL-адреса, расположенную справа от точки, и вы можете выбрать тот, который лучше всего подходит для вашего веб-сайта, в процессе регистрации.
.com
Самым популярным и распространенным TLD является .com, так как 75 процентов всех веб-сайтов имеют .com в качестве своего TLD. Он означает «коммерческий» и используется большинством коммерческих веб-сайтов. Пример: www.youtube.com
.ио
URL-адрес веб-сайта с расширением .
io обычно означает, что веб-сайт связан с технологической отраслью, поскольку означает ввод/вывод. Это популярный выбор домена в технических сообществах и сообществах стартапов. Пример: www.hunter.io
.org
URL-адреса веб-сайтов с доменом, оканчивающимся на .org, являются некоммерческими организациями. Пример: www.change.org
.gov
Когда URL-адрес веб-сайта заканчивается на домене верхнего уровня .gov, это государственное учреждение. Пример: www.usa.gov
.edu
URL-адреса веб-сайтов с доменом, оканчивающимся на .edu, являются веб-сайтами образовательных учреждений. Пример: www.depaul.edu
.нет
URL-адрес, оканчивающийся на .net, принадлежит сетевой организации. Пример: www.slideshare.net
| Связанный: Узнайте больше о разнице .com и .net, чтобы сделать правильный выбор для своего веб-сайта. |
Выберите доменное имя
Когда вы выбираете доменное имя для своего веб-сайта, думайте о нем как о своем домашнем адресе.
Поскольку домен веб-сайта должен быть зарегистрирован, нет двух одинаковых доменных имен веб-сайта. Помните, что ваш домен — это то, что клиенты и зрители вашего веб-сайта будут ассоциировать с вашим брендом, поэтому не стоит торопиться и относиться к нему легкомысленно.
5 советов по выбору доменного имени:
- Упростите ввод
- Говорите кратко и просто
- Избегайте цифр, дефисов и знаков подчеркивания
- Используйте ключевые слова, относящиеся к вашему бренду
- Используйте правильный TLD
Регистрация доменного имени
После того, как вы определились с доменным именем, пришло время перейти к этапу регистрации. Некоторые популярные провайдеры регистрации доменов включают:
- Годэдди
- Google Домены
- Сетевые решения
- Регистрация.com
- Блюхост
Некоторые платформы для создания веб-сайтов предлагают пакет, включающий регистрацию домена, если вы не хотите регистрировать свое имя отдельно при создании веб-сайта.
Важно помнить, что веб-хостинг отличается от регистрации вашего доменного имени.
Если вы даже думаете о том, чтобы получить доменное имя, лучше действовать быстро. Каждый день регистрируются тысячи новых доменов, поэтому броское и кликбейтное доменное имя, о котором вы думали вчера, может исчезнуть сегодня, если вы будете ждать слишком долго. Согласно исследованию, проведенному Verisign, в 2018 году во всех TLD было зарегистрировано около 342,4 миллиона доменных имен9.0003
Стоимость доменного имени
На создание веб-сайта может уйти много денег, включая стоимость доменного имени. Цена, которую вы заплатите за свой домен, будет зависеть от того, какой веб-хостинг или регистрируемый веб-сайт вы выберете. Диапазон может варьироваться от 10 долларов в год до тысяч долларов в год. Однако средний новый домен стоит от 10 до 15 долларов в год.
Что в имени
Как видите, от выбора доменного имени зависит многое. Есть много факторов, которые следует учитывать, так как они будут представлять бренд вашего веб-сайта (надеюсь) в ближайшие годы.
Принятие решения и регистрация вашего доменного имени являются обязательными шагами, когда дело доходит до создания веб-сайта, поэтому обязательно уделите некоторое время мозговому штурму потенциальных идей и будьте готовы полностью посвятить себя тому доменному имени, которое вы выберете.
Хотите узнать больше об основах создания веб-сайтов? Ознакомьтесь с этими обязательными функциями веб-сайта!
Мара Кальвелло
Мара Кальвелло (Mara Calvello) — менеджер по контент-маркетингу в G2, специализирующийся на дизайне, управлении персоналом и SaaS-менеджменте. Она получила степень бакалавра искусств в Колледже Элмхерст (ныне Университет Элмхерст). Помимо работы в G2, Мара является писателем-фрилансером в нескольких малых и средних технологических компаниях. В свободное время Мара либо занимается в тренажерном зале, исследуя природу со своим псом-спасателем Зиком, наслаждаясь итальянской едой, либо прямо посреди запоя Гарри Поттера.
RFC 6761: доменные имена специального назначения
RFC 6761: доменные имена специального назначения [RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Информационная страница] PROPOSED STANDARD
Errata Exist
Internet Engineering Task Force (IETF) S. Cheshire
Запрос комментариев: 6761 М. Крохмаль
Обновления: 1918, 2606 Apple Inc.
Категория: Трек стандартов, февраль 2013 г.
ISSN: 2070-1721
Доменные имена специального назначения
Абстрактный
В этом документе описывается, что значит сказать, что доменное имя (DNS
имя) зарезервировано для специального использования, при этом резервирование такого имени
уместно и как это сделать. Он учреждает IANA
реестр для таких доменных имен и заполняет его записями для некоторых из
уже установленные специальные доменные имена.
Статус этого меморандума
Это документ для отслеживания стандартов Интернета.
Этот документ является продуктом Инженерной группы Интернета.
(IETF). Он представляет собой консенсус сообщества IETF. В нем есть
получил общественное мнение и был одобрен для публикации
Руководящая группа по разработке Интернет-технологий (IESG). Дополнительная информация о
Интернет-стандарты доступны в разделе 2 RFC 5741.
Информация о текущем статусе этого документа, любых опечатках,
и как предоставить отзыв о нем можно получить на
http://www.rfc-editor.org/info/rfc6761.
Уведомление об авторских правах
Copyright (c) 2013 IETF Trust и лица, указанные в качестве
авторы документа. Все права защищены.
Этот документ регулируется BCP 78 и юридическими документами IETF Trust.
Положения, касающиеся документов IETF
(http://trustee.ietf.org/license-info) действует на дату
публикации этого документа. Пожалуйста, ознакомьтесь с этими документами
внимательно, так как они описывают ваши права и ограничения в отношении
к этому документу. Компоненты кода, извлеченные из этого документа, должны
включить текст упрощенной лицензии BSD, как описано в Разделе 4. e
Доверительные юридические положения и предоставляются без гарантии, поскольку
описан в Упрощенной лицензии BSD.
Трек стандартов Чешира и Крохмаля [Страница 1] 
Он представляет собой консенсус сообщества IETF. В нем есть
получил общественное мнение и был одобрен для публикации
Руководящая группа по разработке Интернет-технологий (IESG). Дополнительная информация о
Интернет-стандарты доступны в разделе 2 RFC 5741.
Информация о текущем статусе этого документа, любых опечатках,
и как предоставить отзыв о нем можно получить на
http://www.rfc-editor.org/info/rfc6761.
Уведомление об авторских правах
Copyright (c) 2013 IETF Trust и лица, указанные в качестве
авторы документа. Все права защищены.
Этот документ регулируется BCP 78 и юридическими документами IETF Trust.
Положения, касающиеся документов IETF
(http://trustee.ietf.org/license-info) действует на дату
публикации этого документа. Пожалуйста, ознакомьтесь с этими документами
внимательно, так как они описывают ваши права и ограничения в отношении
к этому документу. Компоненты кода, извлеченные из этого документа, должны
включить текст упрощенной лицензии BSD, как описано в Разделе 4.
e
Доверительные юридические положения и предоставляются без гарантии, поскольку
описан в Упрощенной лицензии BSD.
Трек стандартов Чешира и Крохмаля [Страница 1] RFC 6761 Доменные имена специального назначения, февраль 2013 г. 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.», или любое имя, подпадающее под псевдодомен верхнего уровня, считается недействительным. [RFC2606].
Однако «Зарезервированные DNS-имена верхнего уровня» [RFC2606]
не указывать, должны ли реализации обрабатывать такие имена
по-разному, и если да, то каким образом.
В этом документе указывается, при каких обстоятельствах применяется особый режим.
уместно и какими способами.
2. Терминология
Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН»,
"СЛЕДУЕТ", "НЕ СЛЕДУЕТ", "РЕКОМЕНДУЕТСЯ", "МОЖЕТ" и "ДОПОЛНИТЕЛЬНО" в этом
документ следует интерпретировать, как описано в «Ключевых словах для использования в
RFC для указания уровней требований» [RFC2119].
3. Применимость
Когда была создана многоадресная IP-рассылка [RFC1112], реализации должны были быть
обновлен, чтобы понять, что означает многоадресный IP-адрес и что
делать с этим. Добавление многоадресной IP-адресации в сетевой стек повлекло за собой дополнительные
чем просто добавление правильных записей в таблицу маршрутизации для тех
адреса. Более того, поддержка многоадресной рассылки по IP влечет за собой определенный уровень
общность, согласованная на всех совместимых хостах,
независимо от того, к каким сетям могут быть подключены эти хосты.
Пока
можно построить частную изолированную сеть, используя что угодно
действительные одноадресные IP-адреса и топология маршрутизации по выбору
(независимо от того, используются ли уже эти одноадресные IP-адреса
другими хостами в общедоступном Интернете), многоадресный адрес IPv4
224.0.0.1 всегда является многоадресным адресом «всех хостов», и это не
локальное решение.
Точно так же, если доменное имя имеет специальные свойства, влияющие на
способ, которым аппаратные и программные реализации обрабатывают имя, которое применяется
универсально, независимо от того, в какой сети может быть реализация
подключено, то это доменное имя может быть кандидатом на получение
Трек стандартов Чешира и Крохмаля [Страница 2] RFC 6761 Доменные имена специального назначения, февраль 2013 г. IETF объявляет его доменным именем специального назначения и указывает, что специальные реализации обработки должны дать этому имени. На с другой стороны, если объявление данного имени особым приведет к никаких изменений в каких-либо реализациях, то это говорит о том, что имя не может быть особенным в каком-либо материальном отношении, и это может быть более целесообразно использовать существующие механизмы DNS [RFC1034] для предоставления желаемое делегирование, данные или отсутствие данных для имени в вопрос.
Где желаемое поведение может быть достигнуто с помощью
существующие процессы регистрации доменных имен, этот процесс должен быть
использовал. Резервирование доменного имени специального назначения не является механизмом
для обхода обычных процессов регистрации доменных имен.
В качестве примера предположим, что должен быть документ IETF, определяющий
что конкретное имя (или набор имен) гарантированно создаст
Результат NXDOMAIN ("Ошибка имени" [RFC1035]). Такой документ попадает
входит в обязанности IETF. IETF отвечает за
правила протокола. IETF определяет набор символов имени, ограничения длины,
синтаксис, тот факт, что в DNS «А» эквивалентен «а» и т.д.
[RFC1034] [RFC1035]. Части пространства имен, созданные этими
правила переданы ICANN для управления, но из-за установленной DNS
правила протокола, ICANN не вправе распределять «COM» и «com» по двум
разные серверы имен. IETF несет ответственность за определение
как работает протокол DNS, и ICANN отвечает за выделение
имена, которые стали возможными благодаря этому протоколу DNS.
Теперь предположим,
разработчик должен был использовать это специальное «гарантированное несуществующее» имя,
«зная», что он гарантированно вернет NXDOMAIN, и предположим также
что DNS-сервер пользователя не может вернуть NXDOMAIN для этого имени.
Затем программное обеспечение разработчика дает сбой. Кто делает пользователя и/или
разработчику пожаловаться? ИКАНН? IETF? Оператор DNS-сервера?
Если разработчик не может полагаться на специальные «гарантированные несуществующие»
имя всегда возвращает NXDOMAIN, тогда специальное имя бесполезно,
потому что нельзя полагаться на то, что он делает то, что должен. Для этого
специальное «гарантированное несуществующее» имя, чтобы его можно было использовать, оно должно быть
определено для возврата NXDOMAIN, ПО ПРОТОКОЛУ, для всех установок, а не
просто размещением ICANN в общедоступном Интернете. ICANN не имеет
юрисдикция в отношении того, как пользователи решают настроить свой собственный частный DNS
серверы в своих частных сетях, но разработчикам нужен протокол
спецификация, в которой говорится, что возврат положительных ответов на
специальное "гарантированное несуществующее" имя является нарушением протокола на
*все* сети, а не только общедоступный Интернет.
Следовательно, акт о
определение такого специального имени создает правило протокола более высокого уровня,
выше Управление ICANN присваиваемыми именами в общедоступном Интернете.
Трек стандартов Чешира и Крохмаля [Страница 3] RFC 6761 Доменные имена специального назначения, февраль 2013 г. 4. Процедура Если определено, что требуется особая обработка имени в чтобы реализовать некоторые желаемые новые функции, то IETF Спецификация «Действие по стандартам» или «Утверждение IESG» [RFC5226] ДОЛЖНА быть опубликовано описание новой функциональности. Спецификация ДОЛЖНА указывать, как реализации определяют, что для любого заданного имени требуется особая обработка. Обычно это сделать, заявив, что любое полное доменное имя, оканчивающееся на определенный суффикс (т. е. попадающий в указанный родительский псевдо- домен) получит особое поведение. По сути, это вырезает вне поддерева пространства имен DNS, в котором измененное имя применяются правила обработки, аналогичные многоадресной рассылке IP [RFC1112] или локальные адреса ссылок [RFC3927] [RFC4862] отсекает куски IP адресное пространство, в котором их соответствующая модифицированная адресная обработка применяются правила.
Спецификация также ДОЛЖНА указывать в каждом из семи «Доменных имен».
"Соображения о бронировании" ниже, какое особое отношение,
если таковые имеются, следует применить. Если во всех семи категориях ответ
"нет", то, возможно, не требуется специального лечения и запроса
резервирование доменного имени специального назначения может оказаться нецелесообразным.
5. Вопросы резервирования доменных имен
Документ IETF «Действие по стандартам» или «Одобрение IESG», определяющий
некоторое новое поведение именования, для которого требуется специальное доменное имя
быть зарезервировано для реализации этого желаемого нового поведения, должно содержать
подраздел раздела «Вопросы IANA», озаглавленный «Доменное имя
Соображения о резервировании», дающие ответы в семи категориях.
перечислено ниже. В случае алгоритмически сгенерированных DNS-имен
специфицирующий документ должен четко идентифицировать набор имен
сгенерированный алгоритмом, который потребовал бы предлагаемого специального
уход.
1. Пользователи:
Ожидается ли, что пользователи-люди распознают эти имена как специальные и
использовать их по-разному? В каком смысле?
2. Прикладное программное обеспечение:
Ожидается ли, что разработчики прикладного программного обеспечения
программное обеспечение распознает эти имена как специальные и обрабатывает их
иначе? В каком смысле? (Например, если пользователь-человек вводит
такое имя, если прикладное программное обеспечение отклонит его с
сообщение об ошибке?)
Трек стандартов Чешира и Крохмаля [Страница 4]
RFC 6761 Доменные имена специального назначения, февраль 2013 г.
3. API и библиотеки разрешения имен:
Ожидается ли, что авторы API разрешения имен и библиотек будут
заставить их программное обеспечение распознавать эти имена как специальные и обрабатывать
их по-разному? Если да, то как?
4. Кэширующие DNS-серверы:
Ожидается ли, что разработчики кэширующих серверов доменных имен сделают
их реализации распознают эти имена как специальные и обрабатывают
их по-разному? Если да, то как?
5. Авторитетные DNS-серверы:
Ожидается ли, что разработчики авторитетных серверов доменных имен
заставить свои реализации распознавать эти имена как специальные и
относиться к ним иначе? Если да, то как?
6. Операторы DNS-серверов:
Есть ли у этого зарезервированного доменного имени специального назначения какой-либо потенциал?
влияние на операторов DNS-серверов? Если они попытаются настроить
полномочный DNS-сервер как полномочный для этого зарезервированного имени,
будет ли совместимое программное обеспечение сервера имен отвергать его как недействительное? Сделать DNS
операторы серверов должны знать об этом и понимать, почему?
Даже если программное обеспечение DNS-сервера не запрещает им использовать
это зарезервированное имя, есть ли другие способы, которыми оно может не работать
ожидается, о чем должен знать оператор DNS-сервера?
7. Реестры/регистраторы DNS:
Как реестры/регистраторы DNS должны обрабатывать запросы на регистрацию
это зарезервированное доменное имя? Следует ли отклонять такие запросы?
Должны ли такие просьбы быть разрешены, но только специально-
назначенное лицо? (Например, имя «www. example.org»
зарезервирован для примеров документации и недоступен для
Регистрация; однако на самом деле это имя зарегистрировано; и там
есть даже веб-сайт с таким названием, на котором циркулярно говорится, что
имя зарезервировано для использования в документации и не может быть
зарегистрирован!)
Трек стандартов Чешира и Крохмаля [Страница 5] 
Авторитетные DNS-серверы:
Ожидается ли, что разработчики авторитетных серверов доменных имен
заставить свои реализации распознавать эти имена как специальные и
относиться к ним иначе? Если да, то как?
6. Операторы DNS-серверов:
Есть ли у этого зарезервированного доменного имени специального назначения какой-либо потенциал?
влияние на операторов DNS-серверов? Если они попытаются настроить
полномочный DNS-сервер как полномочный для этого зарезервированного имени,
будет ли совместимое программное обеспечение сервера имен отвергать его как недействительное? Сделать DNS
операторы серверов должны знать об этом и понимать, почему?
Даже если программное обеспечение DNS-сервера не запрещает им использовать
это зарезервированное имя, есть ли другие способы, которыми оно может не работать
ожидается, о чем должен знать оператор DNS-сервера?
7. Реестры/регистраторы DNS:
Как реестры/регистраторы DNS должны обрабатывать запросы на регистрацию
это зарезервированное доменное имя? Следует ли отклонять такие запросы?
Должны ли такие просьбы быть разрешены, но только специально-
назначенное лицо? (Например, имя «www.
example.org»
зарезервирован для примеров документации и недоступен для
Регистрация; однако на самом деле это имя зарегистрировано; и там
есть даже веб-сайт с таким названием, на котором циркулярно говорится, что
имя зарезервировано для использования в документации и не может быть
зарегистрирован!)
Трек стандартов Чешира и Крохмаля [Страница 5]
RFC 6761 Доменные имена специального назначения, февраль 2013 г.
6. Первоначальный реестр
Первоначальный реестр IANA «Доменные имена специального назначения» должен содержать
записи для доменов с обратным отображением частных адресов [RFC1918] и
для существующих зарезервированных DNS-имен верхнего уровня [RFC2606].
6.1. Рекомендации по резервированию доменных имен для частных адресов
Домены с обратным отображением частных адресов [RFC1918], перечисленные ниже,
и любые имена, попадающие в эти домены, являются доменами специального назначения.
Имена:
10.в-аддр.арпа. 21.172. in-addr.arpa. 26.172.in-addr.arpa.
16.172.in-addr.arpa. 22.172.in-addr.arpa. 27.172.in-addr.arpa.
17.172.in-addr.arpa. 30.172.in-addr.arpa. 28.172.in-addr.arpa.
18.172.in-addr.arpa. 23.172.in-addr.arpa. 29.172.in-addr.arpa.
19.172.in-addr.arpa. 24.172.in-addr.arpa. 31.172.in-addr.arpa.
20.172.in-addr.arpa. 25.172.in-addr.arpa. 168.192.in-addr.arpa.
Эти домены и любые имена, относящиеся к этим доменам,
особым образом:
1. Пользователи могут свободно использовать эти имена, как и любые другие.
имена с обратным отображением. Однако, поскольку нет центрального
органа, ответственного за использование частных адресов, пользователи ДОЛЖНЫ
имейте в виду, что эти имена, вероятно, дадут разные результаты
в разных сетях.
2. Прикладное ПО НЕ ДОЛЖНО распознавать эти имена как специальные,
и СЛЕДУЕТ использовать эти имена так же, как и другие
имена.
3. API и библиотеки разрешения имен НЕ ДОЛЖНЫ распознавать эти
имена как специальные и НЕ ДОЛЖНЫ относиться к ним по-разному. Имя
API разрешения СЛЕДУЕТ отправлять запросы на эти имена своим
настроенный кеширующий DNS-сервер(ы).
4. Кэширующие DNS-серверы ДОЛЖНЫ распознавать эти имена как специальные и
НЕ СЛЕДУЕТ по умолчанию пытаться найти для них записи NS,
или иным образом запрашивать авторитетные DNS-серверы в попытке
разрешить эти имена. Вместо этого кэширующие DNS-серверы ДОЛЖНЫ,
по умолчанию, генерировать немедленные (положительные или отрицательные) ответы для
все такие запросы. Это сделано для того, чтобы избежать лишней нагрузки на корень
серверы имен и другие серверы имен. Кэширующие DNS-серверы ДОЛЖНЫ
предложить параметр конфигурации (отключен по умолчанию), чтобы включить
восходящее разрешение таких имен для использования в частных сетях
где известно, что имена обратного отображения частных адресов
обрабатывается авторитетным DNS-сервером в указанной частной сети.
Трек стандартов Чешира и Крохмаля [Страница 6] 
in-addr.arpa. 26.172.in-addr.arpa.
16.172.in-addr.arpa. 22.172.in-addr.arpa. 27.172.in-addr.arpa.
17.172.in-addr.arpa. 30.172.in-addr.arpa. 28.172.in-addr.arpa.
18.172.in-addr.arpa. 23.172.in-addr.arpa. 29.172.in-addr.arpa.
19.172.in-addr.arpa. 24.172.in-addr.arpa. 31.172.in-addr.arpa.
20.172.in-addr.arpa. 25.172.in-addr.arpa. 168.192.in-addr.arpa.
Эти домены и любые имена, относящиеся к этим доменам,
особым образом:
1. Пользователи могут свободно использовать эти имена, как и любые другие.
имена с обратным отображением. Однако, поскольку нет центрального
органа, ответственного за использование частных адресов, пользователи ДОЛЖНЫ
имейте в виду, что эти имена, вероятно, дадут разные результаты
в разных сетях.
2. Прикладное ПО НЕ ДОЛЖНО распознавать эти имена как специальные,
и СЛЕДУЕТ использовать эти имена так же, как и другие
имена.
3. API и библиотеки разрешения имен НЕ ДОЛЖНЫ распознавать эти
имена как специальные и НЕ ДОЛЖНЫ относиться к ним по-разному.
Имя
API разрешения СЛЕДУЕТ отправлять запросы на эти имена своим
настроенный кеширующий DNS-сервер(ы).
4. Кэширующие DNS-серверы ДОЛЖНЫ распознавать эти имена как специальные и
НЕ СЛЕДУЕТ по умолчанию пытаться найти для них записи NS,
или иным образом запрашивать авторитетные DNS-серверы в попытке
разрешить эти имена. Вместо этого кэширующие DNS-серверы ДОЛЖНЫ,
по умолчанию, генерировать немедленные (положительные или отрицательные) ответы для
все такие запросы. Это сделано для того, чтобы избежать лишней нагрузки на корень
серверы имен и другие серверы имен. Кэширующие DNS-серверы ДОЛЖНЫ
предложить параметр конфигурации (отключен по умолчанию), чтобы включить
восходящее разрешение таких имен для использования в частных сетях
где известно, что имена обратного отображения частных адресов
обрабатывается авторитетным DNS-сервером в указанной частной сети.
Трек стандартов Чешира и Крохмаля [Страница 6] RFC 6761 Доменные имена специального назначения, февраль 2013 г.
5. Полномочные DNS-серверы ДОЛЖНЫ распознавать эти имена как специальные.
и СЛЕДУЕТ по умолчанию генерировать немедленные отрицательные ответы на
все такие запросы, если они явно не настроены
администратор давать положительные ответы на приват-адрес
имена с обратным отображением.
6. Операторам DNS-серверов СЛЕДУЕТ, если они используют частные адреса,
настроить свои авторитетные DNS-серверы, чтобы они действовали как авторитетные
для этих имен.
7. Реестры/регистраторы DNS НЕ ДОЛЖНЫ удовлетворять запросы на регистрацию любых
этих имен обычным способом любому физическому или юридическому лицу. Эти
имена зарезервированы для использования в частных сетях и выходят за их пределы.
набор имен, доступных для распределения по реестрам/
регистраторы. Попытка выделить одно из этих имен так, как если бы оно
обычное доменное имя DNS, вероятно, не будет работать должным образом,
по причинам 4, 5 и 6 выше.
6.2.
Рекомендации по резервированию доменных имен для «теста».
Домен «test.» и любые имена, попадающие в «.test.»,
особым образом:
1. Пользователи могут свободно использовать эти имена тестов, как и любые другие.
доменные имена. Однако в связи с отсутствием центральной власти
ответственность за использование названий тестов, пользователи ДОЛЖНЫ знать, что
эти имена, вероятно, дадут разные результаты на разных
сети.
2. Прикладное ПО НЕ ДОЛЖНО распознавать имена тестов как специальные,
и СЛЕДУЕТ использовать тестовые имена так же, как и другие доменные имена.
3. API и библиотеки разрешения имен НЕ ДОЛЖНЫ распознавать test
имена как специальные и НЕ ДОЛЖНЫ относиться к ним по-разному. Имя
API-интерфейсы разрешения СЛЕДУЕТ отправлять запросы на имена тестов своим
настроенный кеширующий DNS-сервер(ы).
4. Кэширующие DNS-серверы ДОЛЖНЫ распознавать тестовые имена как специальные и
НЕ СЛЕДУЕТ по умолчанию пытаться найти для них записи NS,
или иным образом запрашивать авторитетные DNS-серверы в попытке
разрешить имена тестов.
Вместо этого кэширующие DNS-серверы ДОЛЖНЫ,
по умолчанию, генерировать немедленные отрицательные ответы для всех таких
запросы. Это сделано для того, чтобы избежать ненужной нагрузки на корневое имя.
серверы и другие серверы имен. Кэширующие DNS-серверы ДОЛЖНЫ предлагать
параметр конфигурации (отключен по умолчанию), чтобы включить восходящий поток
разрешение имен тестов для использования в сетях, где имена тестов
известно, что он обрабатывается авторитетным DNS-сервером в указанном
частная сеть.
Трек стандартов Чешира и Крохмаля [Страница 7]
RFC 6761 Доменные имена специального назначения, февраль 2013 г.
5. Полномочные DNS-серверы ДОЛЖНЫ распознавать тестовые имена как специальные.
и СЛЕДУЕТ по умолчанию генерировать немедленные отрицательные ответы на
все такие запросы, если они явно не настроены
администратору давать положительные ответы на названия тестов.
6. Операторам DNS-серверов СЛЕДУЕТ, если они используют тестовые имена,
настроить свои авторитетные DNS-серверы, чтобы они действовали как авторитетные
для названий тестов.
7. Реестры/регистраторы DNS НЕ ДОЛЖНЫ удовлетворять запросы на регистрацию
проверяйте имена обычным способом для любого человека или организации. Названия тестов
зарезервированы для использования в частных сетях и не входят в набор
имен, доступных для выделения реестрами/регистраторами.
Попытка выделить тестовое имя, как если бы это был обычный DNS
доменное имя, вероятно, не будет работать так, как хотелось бы, по причинам 4, 5,
и 6 выше.
6.3. Рекомендации по резервированию доменных имен для «localhost».
Домен "localhost". и любые имена, попадающие в «.localhost».
являются особенными в следующих отношениях:
1. Пользователи могут свободно использовать имена локальных хостов, как и любые другие.
доменные имена. Пользователи могут предположить, что адреса IPv4 и IPv6
запросы для имен локальных хостов всегда будут разрешаться в соответствующие
петлевой IP-адрес.
2. Прикладное программное обеспечение МОЖЕТ распознавать имена локальных хостов как специальные или
МОЖЕТ передавать их в API разрешения имен, как и для других
доменные имена.
3. API и библиотеки разрешения имен ДОЛЖНЫ распознавать localhost
имена как специальные и ДОЛЖНЫ всегда возвращать петлевой IP-адрес
для адресных запросов и отрицательных ответов на все остальные запросы
типы. API разрешения имен НЕ ДОЛЖНЫ отправлять запросы на
имена localhost на свои настроенные кэширующие DNS-серверы.
4. Кэширующие DNS-серверы ДОЛЖНЫ распознавать имена локальных хостов как специальные.
и НЕ ДОЛЖНЫ пытаться найти для них записи NS, или
в противном случае запрашивайте авторитетные DNS-серверы в попытке
разрешить имена локальных хостов. Вместо этого кэширующие DNS-серверы ДОЛЖНЫ,
для всех таких адресных запросов генерировать немедленный положительный
ответ, дающий петлевой IP-адрес, и для всех других запросов
типы, вызывают немедленный отрицательный ответ. Это чтобы избежать
ненужная нагрузка на корневые серверы имен и другие серверы имен.
Трек стандартов Чешира и Крохмаля [Страница 8] 
7. Реестры/регистраторы DNS НЕ ДОЛЖНЫ удовлетворять запросы на регистрацию
проверяйте имена обычным способом для любого человека или организации. Названия тестов
зарезервированы для использования в частных сетях и не входят в набор
имен, доступных для выделения реестрами/регистраторами.
Попытка выделить тестовое имя, как если бы это был обычный DNS
доменное имя, вероятно, не будет работать так, как хотелось бы, по причинам 4, 5,
и 6 выше.
6.3. Рекомендации по резервированию доменных имен для «localhost».
Домен "localhost". и любые имена, попадающие в «.localhost».
являются особенными в следующих отношениях:
1. Пользователи могут свободно использовать имена локальных хостов, как и любые другие.
доменные имена. Пользователи могут предположить, что адреса IPv4 и IPv6
запросы для имен локальных хостов всегда будут разрешаться в соответствующие
петлевой IP-адрес.
2. Прикладное программное обеспечение МОЖЕТ распознавать имена локальных хостов как специальные или
МОЖЕТ передавать их в API разрешения имен, как и для других
доменные имена.
3. API и библиотеки разрешения имен ДОЛЖНЫ распознавать localhost
имена как специальные и ДОЛЖНЫ всегда возвращать петлевой IP-адрес
для адресных запросов и отрицательных ответов на все остальные запросы
типы. API разрешения имен НЕ ДОЛЖНЫ отправлять запросы на
имена localhost на свои настроенные кэширующие DNS-серверы.
4. Кэширующие DNS-серверы ДОЛЖНЫ распознавать имена локальных хостов как специальные.
и НЕ ДОЛЖНЫ пытаться найти для них записи NS, или
в противном случае запрашивайте авторитетные DNS-серверы в попытке
разрешить имена локальных хостов. Вместо этого кэширующие DNS-серверы ДОЛЖНЫ,
для всех таких адресных запросов генерировать немедленный положительный
ответ, дающий петлевой IP-адрес, и для всех других запросов
типы, вызывают немедленный отрицательный ответ. Это чтобы избежать
ненужная нагрузка на корневые серверы имен и другие серверы имен.
Трек стандартов Чешира и Крохмаля [Страница 8] RFC 6761 Доменные имена специального назначения, февраль 2013 г.
5. Полномочные DNS-серверы ДОЛЖНЫ распознавать имена локальных хостов как
специальные и обрабатывать их, как описано выше для кэширования DNS
серверы.
6. Операторы DNS-серверов ДОЛЖНЫ знать, что действующие RDATA для
Имена локальных хостов определяются спецификацией протокола и не могут
быть изменены локальной конфигурацией.
7. Реестры/регистраторы DNS НЕ ДОЛЖНЫ удовлетворять запросы на регистрацию
имена localhost обычным способом для любого человека или организации.
Имена локальных хостов определяются спецификацией протокола и
вне набора имен, доступных для распределения реестрами/
регистраторы. Попытка выделить имя локального хоста, как если бы оно
обычное доменное имя DNS, вероятно, не будет работать должным образом,
по причинам 2, 3, 4 и 5 выше.
6.4. Соображения по резервированию доменного имени для «недействительного».
Домен "недействителен". и любые имена, подпадающие под «.invalid». являются
специальными способами, перечисленными ниже.
В приведенном ниже тексте термин
«недействительный» используется в кавычках для обозначения таких имен, в отличие от
имена, которые могут быть недействительными по другим причинам (например, слишком длинные).
1. Пользователи могут свободно использовать «недопустимые» имена, как и любые другие
доменные имена. Пользователи МОГУТ предполагать, что запросы на «недопустимые» имена
всегда будет возвращать ответы NXDOMAIN.
2. Прикладное программное обеспечение МОЖЕТ распознавать «недопустимые» имена как специальные или
МОЖЕТ передавать их в API разрешения имен, как и для других
доменные имена.
3. API и библиотеки разрешения имен ДОЛЖНЫ распознавать «недействительные»
имена как специальные и ДОЛЖНЫ всегда возвращать немедленное отрицательное значение
ответы. API разрешения имен НЕ ДОЛЖНЫ отправлять запросы на
«недопустимые» имена для своих настроенных кэширующих DNS-серверов.
4. Кэширующие DNS-серверы ДОЛЖНЫ распознавать «недопустимые» имена как специальные.
и НЕ ДОЛЖНЫ пытаться найти для них записи NS, или
в противном случае запрашивайте авторитетные DNS-серверы в попытке
разрешить «недопустимые» имена. Вместо этого кэширующие DNS-серверы ДОЛЖНЫ
генерировать немедленные ответы NXDOMAIN для всех таких запросов. Этот
заключается в том, чтобы избежать ненужной нагрузки на корневые серверы имен и другие
серверы имен.
5. Полномочные DNS-серверы ДОЛЖНЫ распознавать «недопустимые» имена как
специальные и обрабатывать их, как описано выше для кэширования DNS
серверы.
Трек стандартов Чешира и Крохмаля [Страница 9]
RFC 6761 Доменные имена специального назначения, февраль 2013 г.
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 навечно:
Трек стандартов Чешира и Крохмаля [Страница 10] 
Эти
«недопустимые» имена определяются спецификацией протокола как
не существует, и они не входят в набор имен, доступных для
распределение по реестрам/регистраторам. Попытка выделить
"недопустимое" имя, как если бы это было обычное доменное имя 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 навечно:
Трек стандартов Чешира и Крохмаля [Страница 10]
RFC 6761 Доменные имена специального назначения, февраль 2013 г.
Доменное имя: EXAMPLE.COM
Регистратор: RESERVED-INTERNET ASSIGNED NUMBERS AUTHORITY
Whois-сервер: whois.iana.org
Реферальный URL: http://res-dom.iana.org
Сервер имен: A.IANA-SERVERS.NET
Сервер имен: B.IANA-SERVERS.NET
Статус: clientDeleteProhibited
Статус: clientTransferProhibited
Статус: clientUpdateProhibited
Дата обновления: 26 марта 2004 г.
Дата создания: 14 августа 19 г.95
Срок годности: 13 августа 2011 г.
В настоящее время IANA поддерживает веб-сервер, предоставляющий веб-страницу, объясняющую
назначение примерных доменов.
7. Вопросы безопасности
В этом документе описываются обстоятельства, при которых резервирование домена
имя для специального использования является подходящим, а процедура получения
это доменное имя специального назначения, зарегистрированное IANA. Любой документ
запрос такого доменного имени специального назначения должен содержать
соответствующий раздел «Вопросы безопасности», в котором описываются любые
вопросы безопасности, относящиеся к этому специальному использованию.
8. Соображения IANA
IANA создала новый реестр доменных имен специального назначения,
изначально заполняется доменами обратного сопоставления частных адресов
и зарезервированные DNS-имена верхнего уровня, описанные выше в Разделе 6.
Когда IANA получает запрос на запись нового домена специального назначения
Name", он должен проверить, проконсультировавшись с IESG, что IETF
Документ «Действие по стандартам» или «Утверждение IESG» [RFC5226] включает
обязательный раздел "Вопросы резервирования доменных имен" с указанием того, как
особое значение этого имени влияет на поведение оборудования,
программное обеспечение и люди в семи категориях. Если IANA и IESG
определить, что особое обращение с этим «доменным именем специального назначения»
целесообразно, IANA должна записать доменное имя специального назначения, а
ссылка на спецификацию, которая его документирует, в реестре.
Трек стандартов Чешира и Крохмаля [Страница 11] 
Дата создания: 14 августа 19 г.95
Срок годности: 13 августа 2011 г.
В настоящее время IANA поддерживает веб-сервер, предоставляющий веб-страницу, объясняющую
назначение примерных доменов.
7. Вопросы безопасности
В этом документе описываются обстоятельства, при которых резервирование домена
имя для специального использования является подходящим, а процедура получения
это доменное имя специального назначения, зарегистрированное IANA. Любой документ
запрос такого доменного имени специального назначения должен содержать
соответствующий раздел «Вопросы безопасности», в котором описываются любые
вопросы безопасности, относящиеся к этому специальному использованию.
8. Соображения IANA
IANA создала новый реестр доменных имен специального назначения,
изначально заполняется доменами обратного сопоставления частных адресов
и зарезервированные DNS-имена верхнего уровня, описанные выше в Разделе 6.
Когда IANA получает запрос на запись нового домена специального назначения
Name", он должен проверить, проконсультировавшись с IESG, что IETF
Документ «Действие по стандартам» или «Утверждение IESG» [RFC5226] включает
обязательный раздел "Вопросы резервирования доменных имен" с указанием того, как
особое значение этого имени влияет на поведение оборудования,
программное обеспечение и люди в семи категориях.
Если IANA и IESG
определить, что особое обращение с этим «доменным именем специального назначения»
целесообразно, IANA должна записать доменное имя специального назначения, а
ссылка на спецификацию, которая его документирует, в реестре.
Трек стандартов Чешира и Крохмаля [Страница 11] RFC 6761 Доменные имена специального назначения, февраль 2013 г. 9. Ссылки 9.1. Нормативные ссылки [RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для указания Уровни требований», BCP 14, RFC 2119, март 1997 г. [RFC1034] Мокапетрис, П., «Доменные имена — концепции и возможности», STD 13, RFC 1034, ноябрь 1987 г. [RFC1035] Мокапетрис, П., «Доменные имена — реализация и спецификация», STD 13, RFC 1035, 19 ноября87. [RFC5226] Нартен, Т. и Х. Альвестранд, «Рекомендации по написанию Раздел рекомендаций IANA в RFC", BCP 26, RFC 5226, май 2008 г. 9.2. Информативные ссылки [RFC1112] Диринг, С.
