Skip to main content
Resources

Informe: Esclarecimentos do contrato de registro e do contrato de credenciamento de registradores (RAA) 2013 em relação às especificações aplicáveis do serviço de diretório de dados de registro (WHOIS)

Esta página também está disponível em:

Por favor, observe que a versão em inglês de todo o conteúdo e dos documentos traduzidos são versões oficiais e que as traduções em outras línguas são apenas para fins de informar.

Data de publicação: 27 de abril de 2015 – Observação: Este informe suplanta o informe publicado em 12 de setembro de 2014 em: https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014-09-12-en


O objetivo deste informe é fornecer esclarecimentos a registros e registradores em relação às especificações aplicáveis do serviço de diretório de dados de registro (WHOIS ou RDDS) necessárias para manter a conformidade com o Contrato de Registro e com o Contrato de Credenciamento de Registradores, respectivamente.

Os esclarecimentos da Seção I se aplicam tanto a registros quanto a registradores; a Seção II se aplica apenas a registros; e a Seção III se aplica apenas a registradores. A fim de permitir que os registros e registradores tenham tempo para implementar tais esclarecimentos em seus sistemas ativos, a fiscalização começará a partir de 31 de janeiro de 2016.

Um dos objetivos desses esclarecimentos é manter a capacidade de analisar facilmente os resultados. Recomendamos que os usuários interessados considerem os esclarecimentos abaixo ao desenvolver analisadores para resultados de RDDS.

Os termos "PODE", "DEVE", "NÃO DEVE", "OBRIGATÓRIO", "NÃO PODE" e "PRECISA" são usados para indicar o nível de necessidade de acordo com o RFC 2119, disponível em http://www.ietf.org/rfc/rfc2119.txt [TXT, 5 KB].

  1. Os seguintes esclarecimentos se aplicam a especificações para serviços de diretório de dados de registro para registros e registradores:

    1. Os seguintes esclarecimentos se aplicam a especificações para serviços de diretório de dados de registro para registros e registradores:

      Para cada tipo de consulta de objeto (nome de domínio, registrador ou servidor de nome), este informe identifica alguns campos como opcionais. Para os campos opcionais sem dados no sistema de registro (SRS) de uma parte contratada, tal parte contratada DEVE implementar uma destas opções: 1) a chave (isto é, a cadeia de caracteres à esquerda dos dois pontos) DEVE ser exibida sem informações na seção de valor (isto é, o que está à direita dos dois pontos) do campo; ou 2) nenhum campo DEVE ser exibido. Se houver dados para um determinado campo opcional, a chave e o valor com os dados DEVEM ser exibidos.

    2. Em respostas a consultas sobre objetos de nomes de domínio, os campos abaixo são considerados opcionais e devem ser tratados conforme o esclarecimento 1:

      • Data Atualizada (caso o nome de domínio não tenha sido atualizado desde que foi criado)

      • Empresa do Registrante/Administrador/Técnico

      • Estado/Província do Registrante/Administrador/Técnico

      • Código Postal do Registrante/Administrador/Técnico

      • Ramal do Registrante/Administrador/Técnico

      • Fax do Registrante/Administrador/Técnico

      • Ramal de Fax do Registrante/Administrador/Técnico

      • Servidor de Nome

      Por exemplo, uma consulta por um nome de domínio sem servidores de nome pode gerar um destes dois resultados:


      E-mail do Técnico: EMAIL@EXEMPLO.TLD
      Servidor de Nome:
      DNSSEC: não assinadas

      ou


      E-mail do Técnico: EMAIL@EXEMPLO.TLD
      DNSSEC: não assinadas

    3. Conforme o RFC 3912, o protocolo de WHOIS (porta 43) não foi internacionalizado. Enquanto o protocolo de substituição é desenvolvido na IETF, recomendamos que os registros e registradores usem apenas a codificação US-ASCII e seu repertório de caracteres para resultados de WHOIS (porta 43). Caso o operador de registro/registrador use caracteres fora do repertório US-ASCII, o resultado PRECISA ser codificado em UTF-8 para maximizar a possibilidade de interoperabilidade.

    4. O resultado de WHOIS PODE apresentar uma tradução do nome da chave em outros idiomas. No entanto, a primeira entrada da chave DEVE ser mostrada conforme aparece no contrato, e as traduções DEVEM ser mostradas entre parêntesis (U+0028 e U+0029) com um espaço (U+0020) entre a chave do campo (conforme especificado pelo RAA 2013 ou o Contrato de registro, dependendo do caso) e o parêntesis de abertura (U+0028). As traduções DEVEM ser separadas por uma barra inclinada (U+002F). O parêntesis final (U+0029) DEVE estar imediatamente antes dos dois pontos. NÃO DEVE haver espaços entre a tradução do nome da chave e os parêntesis (U+0028 e U+0029). NÃO DEVE haver espaços antes e depois das barras inclinadas (U+002F).

      Por exemplo, "Domain Name:" poderia aparecer em espanhol e português como:

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

    5. Todos os rótulos de nomes de domínio nos valores de qualquer campo descrito na seção 1.4.2 do RAA 2013 e nas seções 1.5, 1.6 e 1.7 da Especificação 4 do Contrato de registro (por exemplo, Nome de Domínio, Servidor de Nome, e-mail) DEVEM ser apresentados em formato compatível com ASCII (A-Label).

      Por exemplo, um servidor de nome com rótulo IDN deve ser exibido como:

      Servidor de Nome: ns1.xn--caf-dma.exemplo

    6. Se o Nome de Domínio for IDN, o operador de registro/registrador PODE apresentar o IDN em formato U-Label usando a chave "Nome de Domínio Internacionalizado:" Caso seja exibido, o campo DEVE aparecer como campo adicional, conforme definido no esclarecimento 11, ou imediatamente depois do campo "Nome de Domínio". Por exemplo:

      Nome de Domínio: xn--caf-dma.exemplo
      Nome de Domínio Internacionalizado: café.exemplo

      ou


      DNSSEC: signedDelegation
      Nome de Domínio Internacionalizado: café.exemplo

    7. Os status dos domínios DEVEM estar em conformidade com os mapeamentos especificados nos RFCs de EPP: 5730-5734 e 3915. De acordo com a AWIP (https://www.icann.org/resources/pages/policy-awip-2014-07-02-en), o status de EPP DEVE ser imediatamente seguido por no mínimo um e no máximo nove espaços (U+0020), e depois uma URL correspondente à descrição do status no site da ICANN. Se quiser um exemplo, consulte o esclarecimento 11.

    8. A data e a hora mostradas no rodapé ">>> Última atualização do banco de dados de WHOIS: <<

    9. Os endereços IP de servidores de nomes NÃO DEVEM ser exibidos no resultado de consultas de WHOIS por nomes de domínio. Caso sejam exibidos, os endereços IP DEVEM aparecer imediatamente depois do servidor de nome correspondente, assim como nas respostas para objetos de servidor de nome.

    10. "DNSSEC: signedDelegation" DEVE ser exibido se houver um ou mais registros DS ou DNSKEY no SRS para o nome de domínio consultado. "DNSSEC: não assinadas" DEVE ser exibido em todos os outros casos.

    11. Os campos de dados DEVEM ser exibidos no formato (incluindo a ordem das chaves, entre outros) especificado no RAA 2013 (para registradores) ou no Contrato de registro (para registros). Se houver campos de dados adicionais no resultado de WHOIS, eles DEVEM ser colocados no final do formato de texto definido no Contrato de registro ou RAA 2013, exceto caso seja descrito de outra forma neste Informe. Por exemplo, para respostas de objetos de nome de domínio: depois do campo DNSSEC para registros, depois do campo "URL do Sistema de Relatório de Problemas com Dados WHOIS da ICANN" para registradores. (Observação: Conforme especificado na seção 1.4 da Especificação 4 do Contrato de registro, o operador de registro DEVE pedir aprovação da ICANN antes de adicionar campos ao resultado de WHOIS, ou seja, fazer uma solicitação usando o processo de RSEP).

      Por exemplo, ao consultar por um nome de domínio:

      Nome de Domínio: xn--caf-dma.exemplo
      ID do Domínio: D1234567-TLD
      Servidor WHOIS: whois.nic.exemplo
      URL de Referência: http://www.nic.exemplo
      Data Atualizada: 2009-05-29T20:13:00Z
      Data de Criação: 2000-10-08T00:45:00Z
      Data de Vencimento do Registro: 2010-10-08T00:44:59Z
      Registrador Responsável: EXEMPLO DE REGISTRADOR LLC
      ID IANA DO Registrador Responsável: 5555555
      Status do Domínio: clientDeleteProhibited
      https://icann.org/epp#clientDeleteProhibited
      Status do Domínio: clientRenewProhibited
      https://icann.org/epp#clientRenewProhibited
      Status do Domínio: clientTransferProhibited
      https://icann.org/epp#clientTransferProhibited
      Status do Domínio: serverUpdateProhibited
      https://icann.org/epp#serverUpdateProhibited
      ID do Registrante: 5372808-ERL
      Nome do Registrante: EXEMPLO DE REGISTRANTE
      Empresa do Registrante: EXEMPLO DE EMPRESA
      Endereço do Registrante: RUA DO EXEMPLO 123
      Cidade do Registrante: QUALQUERCIDADE

      Servidor de Nome: NS01.EXEMPLODEREGISTRADOR.TLD
      Servidor de Nome: NS02.EXEMPLODEREGISTRADOR.TLD
      DNSSEC: signedDelegation
      Nome Canônico: café.exemplo

    12. JavaScript ou outros códigos de script no cliente NÃO DEVEM ser adicionados ao resultado (porta 43) de WHOIS, e os dados dos objetos que poderiam ser interpretados de forma equivocada como linguagem de marcação DEVEM estar entre caracteres de escape no WHOIS baseado na Web.

    13. O resultado do WHOIS baseado na Web DEVE seguir as mesmas convenções definidas na seção 1.4.2 da especificação de RDDS do RAA 2013, e as seções 1.5, 1.6 e 1.7 da Especificação 4 do Contrato de Registro.

    14. Cada campo (par chave/valor) DEVE terminar com um CR ASCII e depois LF ASCII . (Consulte a Seção 2 do RFC 3912, Especificação de protocolo de WHOIS). Isso se aplica aos parágrafos usados para avisos legais ou qualquer outra linha mostrada no resultado de WHOIS.

    15. A chave e os valores DEVEM ser separados por dois pontos, seguidos por um espaço, ": " .

      Por exemplo, um nome deve ser mostrado como:

      Servidor de Nome: ns1.xn--caf-dma.exemplo

    16. NÃO DEVE haver espaços à esquerda no resultado de WHOIS. Se houver, DEVEM ser no máximo 9 espaços à esquerda. NÃO DEVE haver espaços à direita.

    17. NÃO DEVE haver linhas vazias entre o último campo de dados da resposta e o rodapé ">>> Última atualização do banco de dados de WHOIS: <<

    18. As consultas de WHOIS (porta 43) por objetos de nome de domínio DEVEM retornar apenas um registro por consulta (isto é, sem correspondências parciais ou outros recursos de pesquisa, apenas buscas de correspondências exatas).

    19. Todos os campos (ou seja, linhas) descritos na seção 1.4.2 da especificação do RDDS do RAA 2013 (para registradores) e as seções 1.5, 1.6 e 1.7 da Especificação 4 do Contrato de Registro (para registros) diferenciam maiúsculas e minúsculas. A chave (isto é, a cadeia de caracteres à esquerda dos dois pontos) diferencia maiúsculas e minúsculas e DEVE ser exibida conforme a definição da seção 1.4.2 da especificação de RDDS do RAA 2013 (para registradores), e das seções 1.5, 1.6 e 1.7 da Especificação 4 do Contrato de registro (para registros).

    20. O CR ASCII e/ou o LF ASCII só DEVEM aparecer no final de um campo.

    21. O operador de registro e o registrador DEVEM usar nomes de domínio totalmente qualificados. O operador de registro NÃO DEVE incluir o ponto final ao exibir nomes de domínio.

    22. O operador de registro e o registrador PODEM mostrar as informações do contrato de faturamento do nome de domínio. Caso sejam mostrados, os campos de contato DEVEM ser apresentados como campos adicionais, conforme definido no esclarecimento 11 deste documento, ou imediatamente depois dos campos de dados de contato técnico.

    23. De acordo com a AWIP (https://www.icann.org/resources/pages/policy-awip-2014-07-02-en), o resultado de WHOIS deve incluir um rodapé dizendo "Para saber mais sobre códigos de status de WHOIS, acesse https://icann.org/epp". O rodapé da AWIP DEVE ser exibido depois do rodapé de última atualização descrito no esclarecimento 17. No mínimo uma e no máximo três linhas vazias DEVEM preceder o rodapé da AWIP. O aviso legal DEVE vir depois do rodapé da AWIP, precedido por pelo menos uma e no máximo três linhas vazias. Por exemplo:

      Nome de Domínio: foobar.exemplo
      ID do Domínio do Registro: D1234567-exemplo

      URL do Sistema de Relatório de Problemas com Dados WHOIS da ICANN:
      http://wdprs.internic.net/
      >>> Última atualização do banco de dados de WHOIS: 2009-05-29T20:15:00Z <<<

      Para saber mais sobre códigos de status de WHOIS, acesse https://icann.org/epp

      Termos de uso: Os usuários deste serviço de WHOIS…

    24. Os campos da resposta de WHOIS NÃO DEVEM aparecer várias vezes, a menos que seja especificado o contrário de forma explícita.

    25. Em respostas a consultas de objetos de nome de domínio, os seguintes campos podem ter vários valores e, portanto, PODEM aparecer várias vezes:

      • Status do Domínio

      • Servidor de Nome

      • Endereço do Registrante/Administrador/Técnico/de Cobrança (isto é, de acordo com o uso do RFC 5733 de EPP)

    26. Ao receber uma consulta por um objeto que não existe no SRS, a parte contratada PRECISA retornar a chave "O objeto consultado não existe: ", opcionalmente seguida por uma mensagem de texto definida pelo registro (o valor) que forneça mais informações sobre a não existência do objeto. Nenhum outro campo DEVE ser exibido. O rodapé "última atualização", a linha em branco e o aviso legal DEVEM ser correspondentes a outras consultas de WHOIS.

  2. Os esclarecimentos a seguir se aplicam apenas a registros.

    1. Em respostas a consultas sobre servidor de nome, os campos abaixo são considerados opcionais e devem ser tratados conforme o esclarecimento 1:

      • Registrador

      • Servidor WHOIS

      • URL de Referência

    2. As consultas de WHOIS (porta 43) por objetos de servidor de nome NÃO DEVEM oferecer correspondências parciais ou outros recursos de pesquisa.

    3. Uma consulta por objeto de servidor de nome, usando o nome ou o endereço IP do servidor de nome, pois a cadeia de caracteres da consulta pode corresponder a mais de um objeto. Nesse caso, o registro DEVE retornar a linha "Consulta com correspondência com mais de um servidor de nome:" seguida pelos ROIDs correspondentes, com o nome do servidor de nome correspondente entre parêntesis, um por linha. Por exemplo, uma consulta por servidores de nome com o IP "203.0.113.7" que tem três objetos correspondentes retornará:

      Consulta com correspondência com mais de um servidor de nome:
      roid1abc-exemplorep (ns1.foo.exemplo)
      roid5jkl-exemplorep (ns2.exemplo.com)
      roid9mno-exemplorep (ns1.exemplo.net)
      >>> Última atualização do banco de dados de WHOIS: 2009-05-29T20:15:00Z <<<

    4. Um registro que implemente o esclarecimento 29 DEVE dar suporte a consultas por objetos de servidor de nome usando o ROID de um objeto de servidor de nome, por exemplo, consultas de um formulário: whois roid , em que é o ROID de um servidor de nome.

    5. Um Registro PODE oferece recursos de correspondência parcial para consultas de objetos de registrador. Ao receber uma consulta de um objeto de registrador que corresponda a mais de um objeto, o Registro DEVE retornar vários registros. Todos os objetos de registrador DEVEM ser separados por uma linha em branco, seguida pela chave "Nome do Registrador: " que indica o início de um novo registro. Por exemplo, uma consulta pelo registrador "Exemplo", que tem dois objetos correspondentes retornará (se houver recursos de pesquisa):

      Nome do registrador: Exemplo de Registrador, Inc.

      URL de Referência: http://www.exemplo-registrador.exemplo
      Contato do Administrador: José Registrador
      Telefone: +1. 5553101213
      Fax: +1. 5553101213
      E-mail: joseregistrador@exemplo-registrador.exemplo
      Contato do Administrador: Jane Registradora
      Telefone: +1. 5553101214
      Fax: +1. 5553101213
      E-mail: janeregistradora@exemplo-registrador.exemplo
      Contato Técnico: João Geek

      Nome do registrador: Exemplo de Registrador Dois, Inc.

      URL de Referência: http://www.exemplo-registrador-dois.exemplo
      Contato do Administrador: José Registrador Dois
      Telefone: +1. 5553101213
      Fax: +1. 5553101213
      E-mail: joseregistrador@exemplo-registrador-dois.exemplo
      Contato do Administrador: Jane Registradora
      Telefone: +1. 5553101214
      Fax: +1. 5553101213
      E-mail: janeregistradora@exemplo-registrador-dois.exemplo
      Contato Técnico: João Geek

      >>> Última atualização do banco de dados de WHOIS: 2009-05-29T20:15:00Z <<<

    6. Quando receber uma consulta por objeto de servidor de nome que corresponda a mais de um objeto, o Registro DEVE retornar vários registros, caso o esclarecimento 29 deste documento não tenha sido implementado. Todos os objetos de servidor de nome DEVEM ser separados por uma linha em branco, seguida pela chave "Nome do Servidor: " que indica o início de um novo registro. Por exemplo, uma consulta pelo servidor de nome "203.0.113.7" que tem dois objetos correspondentes retornará:

      Nome do Servidor: ns1.foo.exemplo
      Endereço IP: 203.0.113.7
      Registrador: Registrador de Exemplo, Inc.
      Servidor WHOIS: whois.exemplo-registrador.exemplo
      URL de Referência: http://www.exemplo-registrador.exemplo

      Nome do Servidor: ns3.foo.exemplo
      Endereço IP: 203.0.113.7
      Registrador: Registrador de Exemplo 2 Inc.
      Servidor WHOIS: whois.exemplo-registrador2.exemplo
      URL de referência: http://www.exemplo-registrador2.exemplo
      >>> Última atualização do banco de dados de WHOIS: 2009-05-29T20:15:00Z >>>

    7. O operador de registro PODE apresentar o ramal telefônico e/ou de fax nos contatos dos Dados do Registrador. Caso sejam mostrados, os campos de contato DEVEM ser apresentados como campos de dados adicionais, conforme definido no esclarecimento 11 deste documento, ou imediatamente depois dos campos de telefone ou fax de contato.

    8. Os registros PRECISAM dar suporte a consultas de objetos de registrador usando o ID IANA do registrador, por exemplo, consultas tipo: whois registrar-id .

    9. Em respostas a consultas de objetos de servidor de nome, o campo "Endereço IP" pode ter vários valores e, portanto, PODE aparecer várias vezes.

    10. Em caso de consultas por servidores de nome para os quais haja pelo menos um nome de domínio ativo que exija dados glue no DNS (consulte RFC 1034) e os registros tenham os dados, os registros DEVEM incluir nos dados de resposta de seus SRS (por exemplo, nome do servidor, endereços IP) os endereços IP relacionados pelo menos do nome de domínio que exige dados glue no DNS. Os registros também PODEM oferecer respostas com dados do SRS em outros casos.

      Por exemplo, se o nome de domínio "foo.exemplo" estiver ativo no DNS e tiver o servidor de nome "ns.foo.exemplo", então os endereços IP e dados relacionados do SRS do servidor de nome serão exibidos no resultado de WHOIS de uma consulta pelo servidor de nome "ns.foo.exemplo".

    11. Em respostas a consultas de objetos de registrador, os seguintes campos podem ter vários valores e, portanto, PODEM aparecer várias vezes:

      • Contato do Administrador

      • Contato Técnico

      • E-mail

      • Número de Fax

      • Número de Telefone

      • Ramal Telefônico

      • Ramal de Fax

      Quando uma consulta de objeto de registrador retorna vários contatos técnicos ou de administrador, os campos relacionados (E-mail, Número de Fax e Número de Telefone) DEVEM seguir o campo nome de contato (isto é, Contato do Administrador ou Contato Técnico). Por exemplo, uma consulta por um registrador que tem dois contatos de administrador retornará:

      Nome do registrador: Exemplo de Registrador, Inc.

      URL de Referência: http://www.exemplo-registrador.exemplo
      Contato do Administrador: José Registrador
      Telefone: +1. 5553101213
      Fax: +1. 5553101213
      E-mail: joseregistrador@exemplo-registrador.exemplo
      Contato do Administrador: Jane Registradora
      Telefone: +1. 5553101214
      Fax: +1. 5553101213
      E-mail: janeregistradora@exemplo-registrador.exemplo
      Contato Técnico: João Geek

      >>> Última atualização do banco de dados de WHOIS: 2009-05-29T20:15:00Z <<<

    12. Ao receber uma "consulta não qualificada" (isto é, uma cadeia de caracteres de consulta que não inclua os parâmetros "servidor de nome" ou "registrador") que corresponda a um nome de domínio e a um objeto de servidor de nome, o registro DEVE retornar as informações sobre o objeto de nome de domínio.

    13. Em respostas a consultas sobre objeto de registrador, os campos abaixo são considerados opcionais e devem ser tratados conforme o esclarecimento 1:

      • Estado/Província

      • Código postal

      • Número de Fax

    14. As respostas a consultas por objeto de registrador DEVEM apresentar pelo menos um contato de administrador e um contato técnico.

    15. A seção valor (isto é, a parte à direita dos dois pontos) dos campos DEVE estar em conformidade com o formato especificado nos RFCs de EPP: 5730-5734 e 3915. Os seguintes campos não são especificados nos RFCs de EPP: 5730-5734 ou 3915 e DEVEM seguir as especificações de formato abaixo:

      1. O valor "servidor de WHOIS" é definido como um nome de host (consulte RFC952 e RFC1123) e DEVE exibir o nome do servidor de WHOIS (porta 43) do registrador responsável/de referência, caso tal registrador ofereça (porta 43) serviço de WHOIS para o objeto consultado. Caso contrário, seria considerado opcional, conforme descrito no esclarecimento 1;

      2. O valor "URL de referência" é definido como uma URL (consulte o RFC3986). O valor DEVE mostrar um site do registrador responsável. A URL DEVE ser: a URL do WHOIS Web do objeto consultado, o serviço Web de WHOIS do registrador ou a página da Web principal do registrador responsável;

      3. O valor "ID IANA do Registrador Responsável" é definido como número inteiro decimal positivo;

      4. O valor "Registrador Responsável" é definido como token (consulte Linguagem de Marcação Extensível 1.1)

      5. Os elementos de objetos de contato para o objeto Registrador são definidos como elementos de objetos de contato de EPP.

    16. Em respostas a consultas por nome de domínio, registrador ou objeto de servidor de nome, os campos abaixo são considerados opcionais e devem ser tratados conforme o esclarecimento 1:

      • Servidor WHOIS (caso o registrador responsável/de referência não ofereça serviço de WHOIS (porta 43) para o objeto consultado)

    17. The Pre-delegation Testing (PDT) Specifications will be updated to incorporate these clarifications to validate that the requirements in Section I and Section II are being implemented correctly by registries as follows:

      1. Antes da data de vigência deste informe, as especificações de PDT serão atualizadas para validar os requisitos da especificação 4 do Contrato de registro, em consistência com estes esclarecimentos.

      2. Do período entre a data de publicação das especificações de PDT atualizadas que consideram este informe e a data de vigência deste informe, qualquer falta de conformidade com as especificações sobre resultados de RDDS (em consistência com este informe) será tratada como uma advertência para o registro.

      3. A partir da data de vigência deste informe, a falta de conformidade com as especificações sobre resultados de RDDS (em consistência com este informe) será tratada como não cumprimento, e o registro não terá permissão para passar por PDT até que a discrepância seja resolvida.

  3. Os esclarecimentos a seguir se aplicam apenas a registradores.

    1. Um registrador só PRECISA apresentar informações de WHOIS para nomes de domínio para os quais o registrador seja o registrador responsável.

    2. O campo "ID do Domínio de Registro:" se refere ao Identificador de Objetos de Repositório (ROID) do objeto de nome de domínio, conforme especificado no RFC 5730 (chamado de ID do Domínio na Especificação 4 do Contrato de Registro). Por exemplo, um Registrador poderia obter o ROID a partir do registro por meio de EPP e armazenar as informações localmente em cache depois de criar ou receber por transferência um nome de domínio.

    3. Os campos "ID do Registrante/Administrador/Técnico/de Faturamento" se referem ao Identificador de Objetos de Repositório (ROID) do objeto de contato, conforme especificado no RFC 5733 (chamado de ID do Registrante/Administrador/Técnico na Especificação 4 do Contrato de Registro). Por exemplo, um registrador poderia obter o ROID a partir do registro por meio de EPP e armazenar as informações localmente em cache. O RAA 2013 define que essas informações DEVEM ser exibidas caso o registro as possua. Caso o registro não possua essas informações (por exemplo, um registro "thin"), a cadeia de caracteres "não disponível no registro" DEVE ser exibida.

    4. O campo "Data de Atualização:" DEVE refletir a data e a hora da última atualização bem-sucedida conhecida pelo registrador. Os registradores não são obrigados a atualizar constantemente essa "Data de Atualização" pelo registrador.

    5. O requisito de nível de serviço "hora de atualização de RDDS" descrito na Seção 2.2 da Especificação do serviço de diretório de dados de registro (WHOIS) se refere apenas às alterações iniciadas pelo registrador.

    6. Os status de EPP do resultado de WHOIS DEVEM refletir o último conjunto conhecido de status de EPP no registro. Os registradores não são obrigados a atualizar constantemente os status de EPP do registro.

    7. A seção valor (isto é, a parte à direita dos dois pontos) dos campos DEVE estar em conformidade com o formato especificado nos RFCs de EPP: 5730-5734 e 3915. Os seguintes campos não são especificados nos RFCs de EPP: 5730-5734 ou 3915 e DEVEM seguir as especificações de formato abaixo:

      1. "E-mail de Contato do Registrador para Abuso" (conforme definido nos RFCs de EPP para campos de e-mail)

      2. "Telefone de Contato do Registrador para Abuso" (conforme definido nos RFCs de EPP para campos de e-mail)

      3. "Revendedor" é definido como token (consulte Linguagem de Marcação Extensível 1.1)

      4. O valor "servidor de WHOIS do registrador" é definido como nome de host (consulte RFC952 e RFC 1123) e é o nome do servidor WHOIS (porta 43) do registrador responsável.

      5. O valor "URL do registrador" é definido como uma URL (consulte o RFC 3986) e DEVE exibir o site do registrador responsável, mais especificamente a URL do WHOIS Web do objeto consultado ou pelo menos a URL do serviço de WHOIS Web do registrador.

      6. O valor "ID IANA do Registrador" é definido como número inteiro decimal positivo.

      7. O valor "Registrador" é definido como token (consulte Linguagem de Marcação Extensível 1.1).

    8. A seção valor do campo "Revendedor" DEVE ser exibido, mas PODE ser deixado em branco ou até mesmo não ser apresentado. Se exibido, o valor do campo DEVE ser o nome da organização, caso o Revendedor do nome seja uma entidade jurídica ou, caso contrário, o nome de uma pessoa física.

    9. Os campos abaixo PODEM ser exibidos imediatamente antes do último campo ("URL do Sistema de Relatório de Problemas com Dados WHOIS da ICANN") em vez de seguir o campo "ID IANA do Registrador":

      • E-mail de Contato do Registrador para Abuso

      • Telefone de Contato do Registrador para Abuso

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