Skip to main content
Resources

Консультативный документ: пояснения к требованиям о поддержке регистратурами и регистраторами WHOIS (порт 43) и веб-служб каталогов

Страница также доступна на следующих языках:

Дата опубликования: 12 сентября 2014 года; обновлено 27 апреля 2015 года; дополнительно обновлено 25 мая 2018 года

С указанием внесенных изменений

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

Этот консультативный документ содержит пояснения для регистратур и регистраторов касательно спецификаций WHOIS (порт 43) и веб-службы каталогов (в совокупности называемых в этом документе Whois), требования которых необходимо соблюдать в рамках соглашения об администрировании домена верхнего уровня и соглашения об аккредитации регистраторов, соответственно.

Пояснения в разделе I адресованы и регистратурам и регистраторам, в то время как раздел II предназначен только для регистратур; а раздел III — только для регистраторов.

Одна из целей этих пояснений — сохранить возможность легкого анализа выходных данных. Заинтересованным пользователям рекомендуется учитывать изложенные ниже пояснения при разработке анализаторов выходных данных WHOIS.

Понятия «МОЖЕТ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «НЕ СЛЕДУЕТ» и «СЛЕДУЕТ» используются для указания строгости требования в соответствии со стандартом RFC 2119, который представлен по адресу http://www.ietf.org/rfc/rfc2119.txt.http://www.ietf.org/rfc/rfc2119.txt [TXT, 5 KB].

  1. Следующие пояснения распространяются на спецификации служб каталогов регистрационных данных как регистратур, так и регистраторов:

    1. Для каждого вида объектов запроса (доменное имя, регистратор, DNS-сервер) в настоящем консультативном документе некоторые поля указаны как необязательные. Если в общей системе регистрации (SRS) стороны, связанной договорными обязательствами, в необязательном поле нет данных, то эта сторона ДОЛЖНА реализовать любой из двух вариантов: 1) ДОЛЖЕН отображаться ключ поля (то есть строка слева от двоеточия), не имеющий данных в разделе значения (то есть справа от двоеточия); 2) поле НЕ ДОЛЖНО отображаться. Если в конкретном необязательном поле есть данные, ключ и значение данных ДОЛЖНЫ отображаться.

    2. В ответах на запросы информации об объектах, являющихся доменными именами, перечисленные ниже поля данных считаются необязательными и должны обрабатываться так, как описано в пояснении 1:

      • Updated Date (Дата обновления) (если доменное имя не обновлялось с момента его создания)
      • Registrant/Admin/Tech Organization (Организация владельца домена/контактного лица по административным вопросам/контактного лица по техническим вопросам)
      • Registrant/Admin/Tech State/Province (Штат/провинция владельца домена/контактного лица по административным вопросам/контактного лица по техническим вопросам)
      • Registrant/Admin/Tech Postal Code (Почтовый индекс владельца домена/контактного лица по административным вопросам/контактного лица по техническим вопросам)
      • Registrant/Admin/Tech Phone Ext (Добавочный номер телефона владельца домена/контактного лица по административным вопросам/контактного лица по техническим вопросам)
      • Registrant/Admin/Tech Fax (Номер факса владельца домена/контактного лица по административным вопросам/контактного лица по техническим вопросам)
      • Registrant/Admin/Tech Fax Ext (Добавочный номер факса владельца домена/контактного лица по административным вопросам/контактного лица по техническим вопросам)
      • DNS-сервер

      Например, запрос информации по доменному имени без DNS-сервера (и без записей DS или DNSKEY) может привести к любому из двух результатов:


      Tech Email: EMAIL@EXAMPLE.TLD
      Name Server:
      DNSSEC: unsigned

      или


      Tech Email: EMAIL@EXAMPLE.TLD
      DNSSEC: unsigned

    3. Как указано в RFC 3912, протокол WHOIS (порт 43) еще не интернационализирован. Регистратурам и регистраторам рекомендуется использовать для выходных данных службы WHOIS (порт 43) только кодировку и набор символов US-ASCII. Если оператор регистратуры/регистратор использует символы не из набора US-ASCII, выходные данные СЛЕДУЕТ кодировать в формате UTF-8 чтобы обеспечить максимальную функциональную совместимость.

    4. В выходных данных WHOIS МОЖНО отображать перевод названия ключа на другие языки, но при этом первая запись ключа ДОЛЖНА иметь вид, указанный в соглашении, а переводы ДОЛЖНЫ находиться в круглых скобках (U+0028 и U+0029) с пробелом (U+0020) между ключом поля (согласно требованиям RAA 2013 или соглашения об администрировании домена верхнего уровня, соответственно) и открывающей скобкой (U+0028). Разные переводы ДОЛЖНЫ быть разделены косой чертой (U+002F). Закрывающая скобка (U+0029) ДОЛЖНА находиться непосредственно перед двоеточием. Между переводом названия ключа и скобками (U+0028 и U+0029) НЕ ДОЛЖНО быть пробелов. Справа и слева от косой черты (U+002F) НЕ ДОЛЖНО быть пробелов.

      Например, поле «Domain Name:» может отображаться на испанском и португальском языках следующим образом:

      Domain Name (Nombre de Dominio/Nome de Domínio): foo.example

    5. Все элементы доменного имени в значениях любого из полей (например, в поле Domain Name (Доменное имя), Name Server (DNS-сервер), в адресах электронной почты) ДОЛЖНЫ отображаться в ASCII-совместимой форме (A-Label).

      Например, данные о DNS-сервере с меткой IDN-домена следует отображать так:

      Name Server: ns1.xn--caf-dma.example

    6. Если в поле Domain Name (Доменное имя) находится интернационализированное доменное имя, оператор регистратуры/регистратор МОЖЕТ отображать IDN-домен в формате U-Label, используя ключ интернацио-нализированного доменного имени «Internationalized Domain Name:». Если это поле имеется в составе выходных данных, оно ДОЛЖНО отображаться либо как дополнительное поле, согласно определению в пояснении ‎11, либо сразу за полем Domain Name (Доменное имя). Например:

      Domain Name: xn--caf-dma.example
      Internationalized Domain Name: café.example

      или


      DNSSEC: signedDelegation
      Internationalized Domain Name: café.example

    7. Коды состояния доменов ДОЛЖНЫ соответствовать указанным в документах RFC по EPP: 5730-5734 и 3915. Согласно дополнению AWIP (https://www.icann.org/resources/pages/policy-awip-2014-07-02-en), за кодом состояния EPP ДОЛЖЕН следовать по крайней мере один, но не более девяти пробелов (U+0020) и затем URL-адрес страницы с описанием этого кода состояния на веб-сайте ICANN. Пример см. в пояснении ‎11.

    8. Дата и время в нижнем колонтитуле «>>> Last update of Whois database (Последнее обновление базы данных WHOIS): <Дата и время> <<<» — это дата и время (в формате RFC 3339) последнего обновления базы данных службы каталогов регистрационных данных (RDDS) на основе базы данных SRS. Согласно требованию об уровне обслуживания, сформулированному в разделе 1.4.2 RAA 2013 и в спецификации 10 базового соглашения об администрировании домена верхнего уровня, данные в службах RDDS должны обновляться в течение 60 минут после любого изменения. В том случае, когда сторона, связанная договорными обязательствами, направляет запрос непосредственно в свою базу данных SRS и, следовательно, использует данные в режиме реального времени, эти дата и время будут соответствовать метке времени ответа на запрос.

    9. IP-адреса DNS-серверов НЕ СЛЕДУЕТ отображать в составе выходных данных WHOIS при ответе на запросы информации по доменным именам. Если IP-адреса отображаются, они ДОЛЖНЫ быть указаны сразу после соответствующего DNS-серверa, как и при ответе на запросы информации об объектах, являющихся DNS-серверами.

    10. Поле «DNSSEC: signedDelegation» ДОЛЖНО отображаться, когда у доменного имени, являющегося объектом запроса, в базе данных SRS есть одна или несколько записей DS или DNSKEY. В всех остальных случаях ДОЛЖНО отображаться поле «DNSSEC: unsigned».

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

    12. Код сценариев JavaScript или других клиентских сценариев НЕ ДОЛЖЕН добавляться в состав выходных данных WHOIS (порт 43), а поступающие от объектов данные, которые можно неверно истолковать как язык разметки, ДОЛЖНЫ быть должным образом исключены в веб-службе WHOIS.

    13. Для выходных данных веб-службы Whois ДОЛЖНЫ соблюдаться те же соглашения, что и для WHOIS (порт 43).

    14. В конце каждого поля (пара ключ/значение) ДОЛЖЕН находиться символ ASCII CR, а затем ASCII LF <U+000D, U+000A>. (См. раздел 2 RFC 3912, Спецификация протокола WHOIS). Это относится и к параграфам отказа от юридической ответственности или к любым другим строкам, отображаемым в составе выходных данных WHOIS.

    15. Ключ ДОЛЖЕН быть отделен от значения двоеточием и одним пробелом, «:» <U+003A,U+0020>.

      Например, доменное имя следует отображать так:

      Name Server: ns1.xn--caf-dma.example

    16. В состав выходных данных WHOIS НЕ СЛЕДУЕТ включать начальные пробелы. Если начальные пробелы включены, их НЕ ДОЛЖНО быть больше 9. Конечные пробелы НЕ ДОЛЖНЫ включаться.

    17. НЕ СЛЕДУЕТ добавлять пустые строки между последним полем данных в ответе и нижним колонтитулом «>>> Last update of Whois database (Последнее обновление базы данных WHOIS): <дата/время> <<<». Между последним полем данных в ответе и нижним колонтитулом «Last update» (Последнее обновление) ДОЛЖНО быть не больше трех пустых строк.

    18. В ответ на запросы информации об объектах, являющихся доменным именами, к WHOIS (порт 43) СЛЕДУЕТ включать единственную регистрационную запись на запрос (то есть не следует предлагать функцию поиска частичного совпадения или другие возможности поиска, выполняется только поиск точного совпадения).

    19. Во всех полях учитывается регистр. Ключ (то есть строка слева от двоеточия) чувствителен к регистру и ДОЛЖЕН отображаться так, как определено в договоре или политике.

    20. Символы ASCII CR и/или ASCII LF <U+000D, U+000A> ДОЛЖНЫ находиться только в конце поля.

    21. Операторы регистратур и регистраторы ДОЛЖНЫ использовать полностью определенные имена доменов. Оператору регистратуры НЕ СЛЕДУЕТ при отображении доменных имен использовать точку в конце строки.

    22. Операторы регистратур и регистраторы МОГУТ отображать для доменного имени данные контактного лица по вопросам выставления счетов при условии соблюдения других требований договоров и политики. При отображении эти поля контактных данных ДОЛЖНЫ находиться либо в составе дополнительных полей, согласно определению в пояснении ‎11 настоящего документа, либо сразу за полями данных контактного лица по техническим вопросам.

    23. Согласно Дополнению к политике относительно данных WHOIS (AWIP) (https://www.icann.org/resources/pages/policy-awip-2014-07-02-en), выходные данные Whois ДОЛЖНЫ содержать следующий нижний колонтитул: «For more information on Whois status codes, please visit https://icann.org/epp» (Для получения дополнительной информации о кодах состояния, используемых в WHOIS, посетите веб-страницу https://icann.org/epp). Нижний колонтитул дополнения AWIP ДОЛЖЕН отображаться за последним нижним колонтитулом обновления, описанным в пояснении ‎17. Перед нижним колонтитулом дополнения AWIP ДОЛЖНА быть по крайней мере одна пустая строка, но не более трех. За нижним колонтитулом дополнения AWIP ДОЛЖЕН находиться отказ от юридической ответственности, отделенный не менее чем одной пустой строкой и не более чем тремя. Например:

      Domain Name: foobar.example
      Registry Domain ID: D1234567-example

      DNSSEC: signedDelegation
      URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
      >>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

      For more information on Whois status codes, please visit https://icann.org/epp

      Terms of Use: Users of this Whois service …

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

    25. В ответах на запросы информации об объектах, являющихся доменными именами, перечисленные ниже поля могут иметь несколько значений и, следовательно, МОГУТ повторяться:

      • Domain Status (Состояние домена)

      • DNS-сервер

      • Registrant/Admin/Tech/Billing Street (Почтовый адрес владельца домена/контактного лица по административным вопросам/контактного лица по техническим вопросам/контактного лица по вопросам выставления счетов) (то есть в соответствии с порядком использования EPP, который определен в RFC 5733)

    26. При получении запроса информации об объекте, которого нет в базе данных SRS, стороне, связанной договорными обязательствами, СЛЕДУЕТ вернуть ключ «The queried object does not exist:» (Указанный в запросе объект не существует). За этим ключом может следовать текстовое сообщение регистратуры (значение), содержащее дополнительную информацию об отсутствии объекта. Никакие другие поля НЕ ДОЛЖНЫ отображаться. Затем ДОЛЖЕН следовать нижний колонтитул «Last update» (Последнее обновление), пустая строка и отказ от юридической ответственности, как и для других запросов WHOIS.

  2. Следующие пояснения предназначены только для регистратур.

    1. В ответах на запросы информации по DNS-серверам перечисленные ниже поля данных считаются необязательными и должны обрабатываться в порядке, описанном в пояснении 1:

      • Регистратор

      • Сервер WHOIS регистратора

      • URL-адрес регистратора

    2. В ответ на запросы информации об объектах, являющихся DNS-серверами, к WHOIS (порт 43) НЕ СЛЕДУЕТ предлагать функцию поиска частичного совпадения или другие возможности поиска.

    3. Указанные в строке запроса информации об объекте, являющемся DNS-сервером, имя или IP-адрес DNS-сервера могут соответствовать нескольким объектам. В таком случае регистратуре СЛЕДУЕТ вернуть в ответ на запрос сообщение «Query matched more than one name server» (Указанным в запросе данным соответствует несколько DNS-серверов):, а затем перечислить соответствующие идентификаторы объектов репозитория (ROID) с указанием имен DNS-серверов в круглых скобках, по одному в каждой строке. Например, ответ на запрос информации по DNS-серверам с IP-адресом «203.0.113.7», которому в базе данных соответствует три объекта, будет иметь следующий вид:

      Query matched more than one name server:
      roid1abc-examplerep (ns1.foo.example)
      roid5jkl-examplerep (ns2.example.com)
      roid9mno-examplerep (ns1.example.net)
      >>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

    4. Регистратура, которая реализовала пояснение ‎29, ДОЛЖНА поддерживать запросы информации об объектах, являющихся DNS-серверами, с использованием ROID DNS-сервера, например, запросы следующего вида: whois roid <идентификатор объекта репозитория>, где <идентификатор объекта репозитория> — это ROID DNS-сервера.

    5. Регистратура МОЖЕТ предлагать функцию поиска частичного совпадения или другие возможности поиска для запросов информации об объектах, являющихся регистраторами. Если запросу информации об объекте, являющемся регистратором, соответствует несколько объектов, регистратура ДОЛЖНА вернуть несколько регистрационных записей. Каждый объект-регистратор ДОЛЖЕН быть отделен пустой строкой, за которой следует ключ «Registrar Name:» (Наименование регистратора), отмечающий начало новой записи. Например, ответ на запрос информации по регистратору «Example» (Пример), которому в базе данных соответствует два объекта, будет иметь следующий вид (если предоставлены возможности поиска):

      Registrar: Example Registrar, Inc.

      Registrar URL: http://www.example-registrar.example
      Admin Contact: Joe Registrar
      Phone Number: +1. 5553101213
      Fax Number: +1. 5553101213
      Email: joeregistrar@example-registrar.example
      Admin Contact: Jane Registrar
      Phone Number: +1. 5553101214
      Fax Number: +1. 5553101213
      Email: janeregistrar@example-registrar.example
      Technical Contact: John Geek

      Registrar: Example Registrar Two, Inc.

      Registrar URL: http://www.example-registrar-two.example
      Admin Contact: Joe Registrar Two
      Phone Number: +1. 5553101213
      Fax Number: +1. 5553101213
      Email: joeregistrar@example-registrar-two.example
      Admin Contact: Jane Registrar
      Phone Number: +1. 5553101214
      Fax Number: +1. 5553101213
      Email: janeregistrar@example-registrar-two.example
      Technical Contact: John Geek

      >>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

    6. При получении запроса информации об объекте, являющемся DNS-сервером, которому соответствует несколько объектов, регистратура ДОЛЖНА вернуть несколько регистрационных записей, если пояснение ‎29 из настоящего документа не было реализовано. Каждый объект, являющийся DNS-сервером, ДОЛЖЕН быть отделен пустой строкой, за которой следует ключ «Server Name:” (Наименование регистратора), отмечающий начало новой записи. Например, ответ на запрос информации по DNS-серверу с IP-адресом «203.0.113.7», которому в базе данных соответствует два объекта, будет иметь следующий вид:

      Server Name: ns1.foo.example
      IP Address: 203.0.113.7
      Registrar: Example Registrar, Inc.
      Registrar WHOIS Server: whois.example-registrar.example
      Registrar URL: http://www.example-registrar.example

      Server Name: ns3.bar.example
      IP Address: 203.0.113.7
      Registrar: Example Registrar 2, Inc.
      Registrar WHOIS Server: whois.example-registrar2.example
      Registrar URL: http://www.example-registrar2.example
      >>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

    7. Оператор регистратуры МОЖЕТ отображать элементы данных Phone Ext (Добавочный номер телефона) и/или Fax Ext (Добавочный номер факса) в контактных данных регистратора. При отображении каждое поле ДОЛЖНО находиться либо в составе дополнительных полей, согласно определению в пояснении ‎11 настоящего документа, либо сразу за соответствующим полем контактного телефона или факса.

    8. Регистратурам СЛЕДУЕТ поддерживать запросы на получение информации по регистраторам с использованием идентификатора регистратора в IANA, например, запросы следующего вида: whois registrar-id <IANA ID>.

    9. В ответах на запросы информации об объекте, являющемся DNS-сервером, поле «IP Address» (IP-адрес) может иметь несколько значений и, следовательно, МОЖЕТ повторяться несколько раз.

    10. В случае запросов информации по DNS-серверам, для которых есть хотя бы одно активное доменное имя, которое требует связующих данных в DNS (см. RFC 1034), если у регистратуры есть такие данные, она ДОЛЖНА включить в ответ данные из своей SRS (например, имя сервера, IP-адреса) — по крайней мере, соответствующие IP-адреса доменного имени, которое требует связующих данных в DNS. В остальных случаях регистратура МОЖЕТ включить в ответ данные из SRS.

      Например, если доменное имя «foo.example» активно в DNS и имеет DNS-сервер «ns.foo.example», то IP-адреса и соответствующие данные из SRS для этого DNS-сервера будут отображаться в составе выходных данных WHOIS при ответе на запрос информации по DNS-серверу «ns.foo.example».

    11. В ответах на запросы информации об объекте, являющемся регистратором, перечисленные ниже поля могут иметь несколько значений и, следовательно, МОГУТ повторяться:

      • Admin Contact (Контактное лицо по административным вопросам)

      • Technical Contact (Контактное лицо по техническим вопросам)

      • Email (Адрес электронной почты)

      • Fax Number (Номер факса)

      • Phone Number (Номер телефона)

      • Phone Ext (Добавочный номер телефона)

      • Fax Ext (Добавочный номер факса)

      • Street (Почтовый адрес)

      Если в ответе на запрос информации по регистратору есть несколько контактных лиц по административным или техническим вопросам, соответствующие поля (адрес электронной почты, номер факса и номер телефона) ДОЛЖНЫ следовать за полем имени контактного лица (то есть за полем Admin Contact или Technical Contact). Например, ответ на запрос информации по регистратору, у которого двое контактных лиц по административным вопросам, будет иметь следующий вид:

      Registrar: Example Registrar, Inc.

      Registrar URL: http://www.example-registrar.example
      Admin Contact: Joe Registrar
      Phone Number: +1. 5553101213
      Fax Number: +1. 5553101213
      Email: joeregistrar@example-registrar.example
      Admin Contact: Jane Registrar
      Phone Number: +1. 5553101214
      Fax Number: +1. 5553101213
      Email: janeregistrar@example-registrar.example
      Technical Contact: John Geek

      >>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

    12. При получении «неполного запроса» (то есть строки запроса, не содержащей параметров «nameserver» или «registrar»), которому соответствует объект — доменное имя и DNS-сервер, регистратуре СЛЕДУЕТ возвратить информацию об этом объекте — доменном имени.

    13. В ответах на запросы информации по регистраторам перечисленные ниже поля данных считаются необязательными и должны обрабатываться в порядке, описанном в пояснении 1:

      • State/Province (Штат/провинция)

      • Postal Code (Почтовый индекс)

      • Fax Number (Номер факса)

    14. В ответах на запросы информации по регистраторам СЛЕДУЕТ указывать по крайней мере одно контактное лицо по административным вопросам и одно контактное лицо по техническим вопросам.

    15. Если иное не предусмотрено политикой или договором, формат той части поля, которая отведена под значение (то есть справа от двоеточия), ДОЛЖЕН соответствовать указанному в документах RFC по EPP: 5730-5734 и 3915. Перечисленные ниже поля не определены в документах RFC по EPP: 5730-5734 или 3915. Для них ДОЛЖНЫ использоваться следующие спецификации формата:

      1. Значение «Registrar WHOIS Server» (Сервер WHOIS регистратора) определяется как имя хоста (см. RFC 952 и RFC 1123) и ДОЛЖНО отображать имя того сервера указанного регистратора-спонсора, где установлена служба WHOIS (порт-43), если упомянутый регистратор предлагает службу WHOIS (порт-43) для указанного в запросе объекта. В ином случае, это значение считалось бы необязательным, согласно пояснению 1;

      2. Значение «Registrar URL» (URL регистратора) определяется как URL-адрес (см. RFC 3986). Отображаемое значение ДОЛЖНО соответствовать адресу веб-сайта регистратора-спонсора. Этот URL-адрес ДОЛЖЕН быть URL-адресом либо веб-службы WHOIS указанного в запросе объекта, либо веб-службы WHOIS регистратора, либо главной страницы сайта регистратора-спонсора;

      3. Значение «Registrar IANA ID» (Идентификатор регистратора в IANA) определяется как положительное десятичное целое число;

      4. Значение «Registrar» (Регистратор) определяется как токен (см. расширяемый язык разметки 1.1);

      5. Элементы данных объектов, являющихся контактными лицами объекта-регистратора, определяются как элементы объектов контактных данных EPP.

    16. В ответах на запросы информации об объектах, являющихся доменными именами, регистраторами или DNS-серверами, перечисленные ниже поля данных считаются необязательными и должны обрабатываться так, как описано в пояснении 1:

      • «Registrar WHOIS Server» (Сервер WHOIS регистратора) (если указанный регистратор-спонсор не предлагает службу WHOIS (порт 43) для указанного в запросе объекта)

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

    1. ТРЕБОВАНИЕ о предоставлении регистратором данных WHOIS распространяется только на доменные имена, для которых он является регистратором-спонсором.

    2. Поле «Registry Domain ID:» (Идентификатор домена в регистратуре) в соответствии с RFC 5730 используется для отображения идентификатора объекта репозитория (ROID) для объекта-доменного имени (в спецификации 4 соглашения об администрировании домена верхнего уровня он называется идентификатором домена). Например, регистратор может получить ROID у регистратуры по протоколу EPP и хранить эту информацию в локальном кэше после создания доменного имени или получения в результате переноса.

    3. Поля «Registry Admin/Tech/Billing/Registrant ID» (Идентификатор владельца домена/контактного лица по административным вопросам/контактного лица по техническим вопросам/контактного лица по вопросам оплаты регистратуры) содержат идентификатор объекта репозитория (ROID) контактного лица в соответствии с определением RFC 5733. Например, регистратор может получить ROID у регистратуры по протоколу EPP и хранить эту информацию в локальном кэше. В соглашении RAA 2013 указано, что эта информация ДОЛЖНА отображаться, если она получена от регистратуры. Если регистратура не предоставила такую информацию (например, в случае сокращенного варианта записи данных регистратуры), вместо этого СЛЕДУЕТ отображать строку «Not Available From Registry» (Информация из регистратуры не поступила).

    4. Поле «Updated Date:» (Дата обновления) ДОЛЖНО отражать дату и время последнего успешного обновления, о котором известно регистратору. Регистраторы не обязаны постоянно обновлять поле «Updated Date:» по данным регистратуры.

    5. Требование об уровне обслуживания «RDDS update time» (Время обновления RDDS), сформулированное в разделе 2.2 спецификации службы каталогов регистрационных данных (WHOIS), относится только к изменениям по инициативе регистратора.

    6. Коды состояния EPP в выходных данных WHOIS ДОЛЖНЫ соответствовать последнему известному набору кодов состояния EPP по данным регистратуры. Регистраторы не обязаны постоянно обновлять информацию о кодах состояния EPP по данным регистратуры.

    7. Если иное не предусмотрено политикой или договором, формат той части поля, которая отведена под значение (то есть справа от двоеточия), ДОЛЖЕН соответствовать указанному в документах RFC по EPP: 5730-5734 и 3915. Перечисленные ниже поля не определены в документах RFC по EPP: 5730-5734 или 3915. Для них ДОЛЖНЫ использоваться следующие спецификации формата:

      1. «Registrar Abuse Contact Email» (Адрес электронной почты контактного лица регистратора по уведомлениям о неправильном использовании доменного имени) (как определено в RFC по EPP для полей адресов электронной почты)

      2. «Registrar Abuse Contact Phone» (Номер телефона контактного лица регистратора по уведомлениям о неправильном использовании доменного имени) (как определено в RFC по EPP для полей телефонных номеров)

      3. «Reseller» (Реселлер) определяется как токен (см. расширяемый язык разметки 1.1)

      4. Значение «Registrar WHOIS Server» (Сервер WHOIS регистратора) определяется как имя хоста (см. RFC 952 и RFC 1123) и является именем сервера службы WHOIS (порт 43) регистратора-спонсора

      5. Значение «Registrar URL» (URL регистратора) определяется как URL-адрес (см. RFC 3986) и это поле ДОЛЖНО указывать на веб-сайт регистратора-спонсора, а конкретнее — это URL-адрес веб-службы WHOIS указанного в запросе объекта или, как минимум, URL-адрес веб-службы WHOIS регистратора

      6. Значение «Registrar IANA ID» (Идентификатор регистратора в IANA) определяется как положительное десятичное целое число.

      7. Значение «Registrar» (Регистратор) определяется как токен (см. расширяемый язык разметки 1.1).

    8. Ту часть поля «Reseller» (Реселлер), которая отведена под значение, СЛЕДУЕТ отображать, но МОЖНО оставить пустой; также это поле МОЖНО не отображать вообще. Если поле отображается, его значение ДОЛЖНО быть наименованием организации, если реселлер доменного имени — юридическое лицо; в противном случае указывается имя физического лица.

    9. Поля, перечисленные ниже, МОЖНО отображать непосредственно перед последним полем («URL of the ICANN Whois Inaccuracy Complaint Form» (URL-адрес формы жалобы в ICANN на неточность информации в WHOIS) вместо того, чтобы его указывать после поля «Registrar IANA ID» (Идентификатор регистратора в IANA:

      • Registrar Abuse Contact Email (Адрес электронной почты контактного лица регистратора по уведомлениям о неправильном использовании доменного имени)

      • Registrar Abuse Contact Phone (Номер телефона контактного лица регистратора по уведомлениям о неправильном использовании доменного имени)

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."