Skip to main content
Resources

Documento de asesoramiento: Aclaraciones a los Requisitos del Registro y Registrador para el WHOIS (puerto 43) y los servicios de directorio basados en la Web

Fecha de publicación: 12 de septiembre de 2014; actualizado el 27 de abril de 2015; actualizado posteriormente el 25 de mayo de 2018

Documento con cambios resaltados

Tenga presente que la versión oficial de todos los contenidos y documentos traducidos es la versión en idioma inglés; las traducciones a otros idiomas son sólo a título informativo.

El presente Documento de asesoramiento tiene por objeto proporcionar aclaraciones a los registros y registradores con respecto a las especificaciones del WHOIS (puerto 43) y de los servicios de directorio basados en la Web (conjuntamente denominados WHOIS en este documento) que se requieren para cumplir con el Acuerdo de Registro y el Acuerdo de Acreditación de Registradores, respectivamente.

Las aclaraciones en la Sección I corresponden tanto a los registros como a los registradores; las de la Sección II corresponden únicamente a los registros; y las de la Sección III corresponden únicamente a los registradores.

Uno de los objetivos de estas aclaraciones es mantener la capacidad de analizar los resultados de WHOIS con facilidad. Se recomienda a los usuarios interesados que consideren las aclaraciones a continuación cuando desarrollen analizadores para los resultados del WHOIS.

Los términos "PUEDE", "DEBE", "NO DEBE", "REQUERIDO", "NO DEBERÍA" y "DEBERÍA" se utilizan para indicar el nivel de exigencia de acuerdo con la RFC 2119, que se encuentra disponible en http://www.ietf.org/rfc/rfc2119.txt [TXT, 5 KB].

  1. Las siguientes aclaraciones corresponden a las especificaciones de los Servicios de Directorio de Datos de Registración del Registro y del Registrador:

    1. Para cada tipo de consulta de objeto (nombre de dominio, registrador, servidor de nombre), el presente documento de asesoramiento identifica algunos campos como opcionales. Para los campos opcionales donde no existan datos en el Sistema de Registración (SRS) de una parte contratada, la parte contratada DEBE implementar cualquiera de las siguientes medidas: 1) la clave (es decir, la cadena de caracteres a la izquierda del signo de dos puntos) DEBE mostrarse sin información en la sección de valor (es decir, el lado derecho del signo de dos puntos) del campo; o bien, 2) NO DEBE mostrarse ningún campo. Si existen datos para un campo opcional dado, la clave y el valor con los datos DEBEN mostrarse.

    2. En las respuestas a consultas sobre el objeto nombre de dominio, los siguientes campos se consideran opcionales y deben ser tratados tal como se describe en la aclaración 1:

      • Fecha de actualización (si el nombre de dominio no se ha actualizado desde que se creó)
      • Organización del registratario/Contacto administrativo/Contacto técnico
      • Provincia/estado del Registratario/Contacto administrativo/Contacto técnico
      • Código postal del Registratario/Contacto administrativo/Contacto técnico
      • Extensión telefónica del Registratario/Contacto administrativo/Contacto técnico
      • Fax del Registratario/Contacto administrativo/Contacto técnico
      • Extensión de fax del Registratario/Contacto administrativo/Contacto técnico
      • Servidor de nombre

      Por ejemplo, una consulta para un nombre de dominio sin servidores de nombres (y sin registros de DS o DNSKEY) puede generar cualquiera de los siguientes dos resultados:


      Correo electrónico del Contacto Técnico: CORREOELECTRONICO@EJEMPLO.TLD
      Servidor de nombre:
      DNSSEC: sin firmar

      o bien


      Correo electrónico del Contacto Técnico: CORREOELECTRONICO@EJEMPLO.TLD
      DNSSEC: sin firmar

    3. Como se describe en la RFC 3912, el protocolo de WHOIS (puerto 43) no ha sido internacionalizado. Se recomienda a los Registros y Registradores que utilicen únicamente la codificación US-ASCII y el repertorio de caracteres para el resultado de WHOIS (puerto 43). Si el Operador de Registro/Registrador utiliza caracteres fuera del repertorio de US-ASCII, el resultado DEBE estar codificado en UTF-8 para maximizar las posibilidades de interoperabilidad.
    4. En los resultados de la búsqueda de WHOIS se PUEDE indicar una traducción del nombre de la clave correspondiente en otros idiomas; sin embargo, la primera entrada que se indique en la clave DEBE figurar tal como figura en el acuerdo y las traducciones DEBEN estar entre paréntesis (U+0028 y U+0029), precedidas por un espacio (U+0020) entre la clave del campo correspondiente (conforme a lo especificado por el RAA de 2013 o el Acuerdo de Registro, según sea el caso) y el paréntesis de apertura (U+0028). Las diferentes traducciones DEBEN estar separadas por una barra oblicua (U+002F). El paréntesis de cierre (U+0029) DEBE estar inmediatamente antes del signo de dos puntos. NO SE DEBE mostrar un espacio o espacios entre la traducción del nombre de la clave y el paréntesis (U+0028 y U+0029). NO SE DEBE mostrar un espacio o espacios entre la barra oblicua (U+002F).

      Por ejemplo, "Domain Name:" podría mostrarse en español y portugués como:

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

    5. Todas las etiquetas de nombres de dominio en los valores de cualquiera de los campos (por ejemplo, Nombre de dominio, Servidor de nombre, Correo electrónico) DEBEN mostrarse en formato compatible con ASCII (Etiqueta A).

      Por ejemplo, un servidor de nombres con una etiqueta de IDN debe mostrarse como:

      Servidor de nombre: ns1.xn--caf-dma.ejemplo

    6. Si el Nombre de dominio es un IDN, el Operador del Registro/Registrador PUEDE mostrar el IDN en formato de Etiqueta U usando la clave "Nombre de Dominio Internacionalizado:". Si se muestra, el campo DEBE aparecer como un campo adicional como se define en la aclaración 1, o inmediatamente después del campo "Nombre de dominio". Por ejemplo:

      Nombre de dominio: xn--caf-dma.ejemplo
      Nombre de Dominio Internacionalizado: café.ejemplo

      o bien


      DNSSEC: delegaciónFirmada
      Nombre de Dominio Internacionalizado: café.ejemplo

    7. Los estados de los dominios DEBEN ajustarse a las asignaciones especificadas en las RFC del EPP: 5730-5734, y 3915. Según la AWIP (https://www.icann.org/resources/pages/policy-awip-2014-07-02-en), el estado del EPP DEBE estar seguido inmediatamente de al menos uno y no más de nueve espacios (U+0020), y luego estar seguido de un URL correspondiente a la descripción del estado en el sitio web de la ICANN. Para ver un ejemplo, consulte la aclaración 1.
    8. La fecha y hora que se muestra en el pie de página ">>> Última actualización de la base de datos de WHOIS: <fecha y hora> <<< "hace referencia a la fecha y la hora (en formato RFC 3339) en que se actualizó la base de datos del Servicio de Directorio de Datos de Registración de Nombres de Dominio (RDDS) de la base de datos del SRS. Según el requisito de nivel de servicio descripto en la sección 1.4.2 del RAA de 2013 y la Especificación 10 del Acuerdo de Registro base, los servicios del RDDS se deben actualizar dentro de los 60 minutos de cualquier cambio. En el caso en que la parte contratada esté consultando su base de datos del SRS directamente y, por lo tanto, utilizando datos en tiempo real, esta fecha y hora mostrará la marca de tiempo de la respuesta a la consulta.
    9. Las direcciones IP para los servidores de nombres NO DEBEN mostrarse en el resultado de las consultas de WHOIS para los nombres de dominio. Si se muestra, las direcciones IP deben aparecer inmediatamente después del servidor de nombre correspondiente, tal como se hace para las respuestas del objeto servidor de nombre.
    10. "DNSSEC: DelegaciónFirmada" DEBE aparecer cuando haya uno o más registros de DS o DNSKEY en el SRS para el nombre de dominio que se está consultando. "DNSSEC: sin firmar" DEBE aparecer en todos los demás casos.
    11. Si se incluyen campos de datos adicionales en el resultado del WHOIS más allá de aquellos exigidos por contrato o política, los cambios de datos adicionales DEBEN colocarse al final de la respuesta, excepto cuando se describa de otro modo en el presente Documento de asesoramiento o se requiera por política o contrato.
    12. JavaScript u otro código de escritura del lado del cliente NO DEBE agregarse al resultado del WHOIS (puerto 43), y los datos de los objetos que podrían ser interpretados erróneamente como lenguaje de marcado DEBEN separarse correctamente con espacios en el WHOIS basado en la Web.
    13. El resultado del WHOIS basado en la Web DEBE seguir las mismas convenciones que aquel del WHOIS (puerto 43).
    14. Cada campo (par de clave/valor) DEBE terminar con ASCII CR y luego ASCII LF <U+000D, U+000A>. (Véase la Sección 2 de la RFC 3912, Especificación del protocolo de WHOIS). Esto se aplica a los párrafos utilizados para deslindes de responsabilidad legal o cualquier otra línea que se muestre en el resultado del WHOIS.
    15. La clave y los valores DEBEN estar separados por un signo de dos puntos seguido por un espacio, ": " <U+003A,U+0020>.

      Por ejemplo, un nombre debe mostrarse como:

      Servidor de nombre: ns1.xn--caf-dma.ejemplo

    16. Los espacios iniciales NO DEBEN aparecer en el resultado del WHOIS. Si se incluyen, no DEBEN aparecer más de 9 espacios iniciales. NO SE DEBEN incluir espacios finales.
    17. NO DEBERÍA haber líneas vacías entre el último campo de datos en la respuesta y el pie de página ">>> Última actualización de la base de datos de WHOIS: <fecha y hora> <<<". No más de tres líneas vacías DEBEN aparecer entre el último campo de datos en la respuesta y el pie de página "Última actualización".
    18. Las consultas del WHOIS (puerto 43) para objetos de nombre de dominio DEBERÍAN devolver sólo un registro por consulta (es decir, sin coincidencias parciales ni otras capacidades de búsqueda, sólo búsquedas de coincidencia exactas).
    19. Todos los campos distinguen entre mayúsculas y minúsculas. La clave (es decir, la cadena de caracteres a la izquierda del signo de dos puntos) distingue entre mayúsculas y minúsculas y DEBE mostrarse tal como es especificado por contrato o política.
    20. ASCII CR y/o ASCII LF <U+000D, U+000A> DEBE figurar únicamente al final de un campo.
    21. El Operador de Registro y el Registrador DEBEN utilizar nombres de dominio completos. El Operador de Registro NO DEBE incluir el punto final al mostrar nombres de dominio.
    22. El Operador de Registro y el Registrador PUEDEN mostrar la información de Contacto de facturación para el nombre de dominio, con sujeción a otros requisitos contractuales o en materia de política. Si se muestra, los campos de contacto se DEBEN mostrar como campos adicionales como se define en la aclaración 1 del presente documento o, inmediatamente después de los campos de datos de contacto técnico.
    23. Según la Política de Información Adicional de WHOIS (AWIP) (https://www.icann.org/resources/pages/policy-awip-2014-07-02-en), el resultado de WHOIS DEBE incluir un pie de página que diga: "Para obtener más información sobre los códigos de estado de WHOIS, visite https://icann.org/epp". El pie de página de AWIP se DEBE mostrar después del último pie de página de última actualización descripto en la aclaración 17. Por lo menos una línea vacía y no más de tres DEBE preceder al pie de página de AWIP. El deslinde de responsabilidad legal debe aparecer después del pie de página de AWIP, precedido por al menos una línea vacía y no más de tres. Por ejemplo:

      Nombre de Dominio: foobar.ejemplo
      ID del dominio de Registro: D1234567-ejemplo

      DNSSEC: delegaciónFirmada
      URL del formulario de la ICANN para reclamos por inexactitud de WHOIS: https://www.icann.org/wicf/
      >>> Última actualización de la base de datos de WHOIS: 2009-05-29T20:15:00Z <<<

      Para obtener más información sobre los códigos de estado de WHOIS, visite: https://icann.org/epp

      Términos de uso: Usuarios de este servicio de WHOIS…

    24. Los campos en el resultado del WHOIS NO DEBEN aparecer varias veces, a menos que se especifique lo contrario de forma explícita.
    25. En las respuestas a las consultas de objetos de nombre de dominio, los siguientes campos pueden tener múltiples valores y, por lo tanto, PUEDEN aparecer varias veces:
      • Estatus del dominio
      • Servidor de nombre
      • Registratario/Administrador/Técnico/Facturación Calle (es decir, siguiendo el uso de la RFC 5733 del EPP)
    26. Al recibir una consulta para un objeto que no existe en el SRS, la parte contratada DEBERÍA devolver la clave "El objeto consultado no existe: ", seguido opcionalmente por un mensaje de texto definido por el registro (el valor) que proporcione más información sobre la inexistencia del objeto. NO SE DEBE mostrar ningún otro campo. El pie de página "última actualización", la línea en blanco, y el deslinde de responsabilidad legal DEBEN seguir como con otras consultas del WHOIS.
  2. Las siguientes aclaraciones sólo corresponden a los Registros.

    1. En las respuestas a consultas sobre el servidor de nombre, los siguientes campos se consideran opcionales y deben ser tratados tal como se describe en la aclaración 1:
      • Registrador
      • Servidor WHOIS del Registrador
      • URL del Registrador
    2. Las consultas del WHOIS (puerto 43) para objetos de servidores de nombres NO DEBERÍAN ofrecer coincidencias parciales ni otras capacidades de búsqueda.
    3. Una consulta para un objeto de servidor de nombre, que utilice el nombre del servidor de nombre o la dirección IP como cadena de caracteres de consulta puede coincidir con más de un objeto. En ese caso, el registro DEBERÍA devolver la línea "La consulta coincide con más de un servidor de nombre." seguida de los ROID con el nombre del servidor de nombre correspondiente entre paréntesis, uno por línea. Por ejemplo, una consulta para servidores de nombres con IP "203.0.113.7" que tenga tres objetos coincidentes devolverá lo siguiente:

      La consulta coincide con más de un servidor de nombre:
      roid1abc-ejemplorep (ns1.foo.ejemplo)
      roid5jkl-ejemplorep (ns2.ejemplo.com)
      roid9mno-ejemplorep (ns1.ejemplo.net)
      >>> Última actualización de la base de datos de WHOIS: 2009-05-29T20:15:00Z <<<

    4. Un Registro que implemente la aclaración 29 DEBE admitir consultas para objetos de servidor de nombre que utilicen el ROID de un objeto de servidor de nombre, por ejemplo, consultas de la forma: whois roid <roid>, donde <roid> es el ROID de un servidor de nombre.
    5. Un registro PUEDE ofrecer funcionalidades de coincidencia parcial para las consultas de objetos del registrador. Al recibir una consulta para un objeto del registrador que coincida con más de un objeto, el Registro DEBE devolver varios registros. Cada objeto del registrador DEBE estar separado por una línea en blanco, seguido de la clave "Nombre del Registrador: " que indique el inicio de un nuevo registro. Por ejemplo, una consulta para el registrador "Ejemplo" que tenga dos objetos coincidentes devolverá (si proporciona capacidades de búsqueda):

      Registrador: Ejemplo Registrador, Inc.

      URL del Registrador: http://www.ejemplo-registrador.ejemplo
      Contacto administrativo: Registrador Joe
      Número de teléfono: +1. 5553101213
      Número de fax: +1. 5553101213
      Correo electrónico: registradorjoe@ejemplo-registrador.ejemplo
      Contacto administrativo: Registrador Jane
      Número de teléfono: +1. 5553101214
      Número de fax: +1. 5553101213
      Correo electrónico: registradorjane@ejemplo-registrador.ejemplo
      Contacto Técnico: John Geek

      Registrador: Ejemplo Registrador Dos, Inc.

      URL del Registrador: http://www.ejemplo-registrador-dos.ejemplo
      Contacto administrativo: Registrador dos Joe
      Número de teléfono: +1. 5553101213
      Número de fax: +1. 5553101213
      Correo electrónico: registradorjoe@ejemplo-registrador-dos.ejemplo
      Contacto administrativo: Registrador Jane
      Número de teléfono: +1. 5553101214
      Número de fax: +1. 5553101213
      Correo electrónico: registradorjane@ejemplo-registrador-dos.ejemplo
      Contacto Técnico: John Geek

      >>> Última actualización de la base de datos de WHOIS: 2009-05-29T20:15:00Z <<<

    6. Al recibir una consulta para un objeto de servidor de nombre que coincida con más de un objeto, el Registro DEBE devolver varios registros si la aclaración 29 del presente documento no se ha implementado. Cada objeto de servidor de nombre DEBE estar separado por una línea en blanco, seguido de la clave "Nombre del Servidor: " que indique el inicio de un nuevo registro. Por ejemplo, una consulta para el servidor de nombre con IP "203.0.113.7" que tenga dos objetos coincidentes devolverá lo siguiente:

      Nombre del servidor: ns1.foo.ejemplo
      Dirección IP: 203.0.113.7
      Registrador: Ejemplo Registrador, Inc.
      Servidor WHOIS del Registrador: whois.ejemplo-registrador.ejemplo
      URL del Registrador: http://www.ejemplo-registrador.ejemplo
      Nombre del servidor: ns3.bar.ejemplo
      Dirección IP: 203.0.113.7
      Registrador: Ejemplo Registrador 2, Inc.
      Servidor WHOIS del Registrador: whois.ejemplo-registrador2.ejemplo
      URL del Registrador: http://www.ejemplo-registrador2.ejemplo
      >>> Última actualización de la base de datos de WHOIS: 2009-05-29T20:15:00Z <<<

    7. El Operador de Registro PUEDE mostrar los elementos Extensión telefónica y/o Extensión de fax para los contactos en los Datos del Registrador. Si se muestran, cada campo de contacto se DEBE mostrar como campo adicional como se define en la aclaración 1 del presente documento o inmediatamente después del campo de teléfono o fax del contacto respectivo.
    8. Los Registros DEBERÍAN admitir consultas para objetos de registrador utilizando el ID de la IANA del registrador, por ejemplo, las consultas de la forma: whois registrador-id <ID de la IANA>.
    9. En las respuestas a las consultas de objetos de servidor de nombre, el campo "Dirección IP" puede tener múltiples valores y, por lo tanto, PUEDEN aparecer varias veces.
    10. En el caso de consultas para servidores de nombres para los cuales haya al menos un nombre de dominio activo que requiera datos de pegado en el DNS (véase la RFC 1034) y los Registros tengan los datos, los Registros DEBEN incluir en los datos de respuesta de su SRS (por ejemplo, Nombre de servidor, Direcciones IP) las direcciones IP relacionadas de al menos el nombre de dominio que requiera datos de pegado en el DNS. Los Registros PUEDEN proporcionar una respuesta con datos del SRS en otros casos.

      Por ejemplo, si el nombre de dominio "foo.ejemplo" está activo en el DNS y tiene el servidor de nombre "ns.foo.ejemplo", las direcciones IP y los datos relacionados del SRS para el servidor de nombre se mostrarán en el resultado del WHOIS de una consulta para el servidor de nombre "ns.foo.ejemplo".

    11. En las respuestas a las consultas de objetos de registrador, los siguientes campos pueden tener múltiples valores y, por lo tanto, PUEDEN aparecer varias veces:
      • Contacto administrativo
      • Contacto Técnico
      • Correo electrónico
      • Número de fax
      • Número de teléfono
      • Extensión telefónica
      • Extensión de fax
      • Calle

      Cuando una consulta de objeto de registrador devuelve varios contactos administrativos o técnicos, los campos relacionados (Correo electrónico, Número de fax y Número de teléfono) DEBEN seguir el campo del nombre de contacto (es decir, Contacto administrativo o Contacto técnico). Por ejemplo, una consulta para un registrador que tiene dos contactos administrativos devolverá:

      Registrador: Ejemplo Registrador, Inc.

      URL del Registrador: http://www.ejemplo-registrador.ejemplo
      Contacto administrativo: Registrador Joe
      Número de teléfono: +1. 5553101213
      Número de fax: +1. 5553101213
      Correo electrónico: registradorjoe@ejemplo-registrador.ejemplo
      Contacto administrativo: Registrador Jane
      Número de teléfono: +1. 5553101214
      Número de fax: +1. 5553101213
      Correo electrónico: registradorjane@ejemplo-registrador.ejemplo
      Contacto Técnico: John Geek

      >>> Última actualización de la base de datos de WHOIS: 2009-05-29T20:15:00Z <<<

    12. Al recibir una "consulta incompleta" (por ejemplo, una cadena de caracteres de consulta que no incluya los parámetros "servidor de nombre" o "registrador") que coincida con un objeto servidor de nombre y nombre de dominio, el registro DEBERÍA devolver la información sobre el objeto de nombre de dominio.
    13. En las respuestas a consultas sobre el objeto de registrador, los siguientes campos se consideran opcionales y deben ser tratados tal como se describe en la aclaración 1:
      • Estado/Provincia
      • Código postal
      • Número de fax
    14. Las respuestas a las consultas de objeto de registrador DEBERÍAN incluir al menos un contacto administrativo y un contacto técnico.
    15. A menos que exista estipulación en contrario por política o contrato, la sección correspondiente al valor (por ejemplo, lado derecho de los dos puntos) de los campos DEBE cumplir con el formato especificado en las RFC del EPP: 5730-5734 y 3915. Los siguientes campos no se especifican en las RFC de EPP: 5730-5734 o 3915, y DEBEN seguir las especificaciones de formato indicadas a continuación:

      1. El valor "Servidor WHOIS del Registrador" se define como un nombre de host (véase RFC952 y RFC1123) y DEBE mostrar el nombre de servidor del servidor de WHOIS (puerto 43) para el objeto consultado, de lo contrario sería considerado opcional como se describe en la aclaración 1;
      2. El valor "URL del Registrador" se define como un URL (véase RFC3986). El valor DEBE mostrar un sitio web del registrador patrocinador. El URL DEBE ser: el URL del WHOIS web del objeto consultado, el servicio WHOIS web del registrador o la página web principal del registrador patrocinador;
      3. El valor "ID de la IANA del Registrador" se define como un número entero decimal positivo;
      4. El valor "Registrador" se define como identificador; (véase Lenguaje de Marcas Extensible 1.1);
      5. Los elementos de objeto de contacto para el objeto de Registrador se definen como elementos de objetos de contacto de EPP.
    16. En las respuestas a consultas sobre el objeto de nombre de dominio, registrador o servidor de nombre, los siguientes campos se consideran opcionales y deben ser tratados tal como se describe en la aclaración 1:

      • Servidor WHOIS del Registrador (si el registrador patrocinador/referenciado no ofrece servicio de WHOIS (puerto 43) para el objeto consultado)
  3. Las siguientes aclaraciones sólo corresponden a los Registradores.

    1. Los registradores solo DEBEN mostrar la información de WHOIS correspondiente a los nombres de dominio que patrocinan.
    2. El campo "ID de dominio del Registro" se refiere al Identificador de Objetos del Repositorio (ROID) para el objeto Nombre de dominio, como se especifica en el documento RFC 5730 (denominado ID de dominio en la Especificación 4 del Acuerdo de Registro). Por ejemplo, un Registrador podría obtener el ROID del Registro a través del EPP y almacenar la información en la memoria caché de forma local después de crear u obtener un nombre de dominio a través de una transferencia.
    3. Los campos "ID de Contacto administrativo/Contacto técnico/Contacto de facturación/Registratario del Registro:" se refieren al identificador del objeto de repositorio (ROID) del objeto Contacto, según se indica en el documento RFC 5733. Por ejemplo, un Registrador podría obtener el ROID del Registro a través del EPP y almacenar la información en la memoria caché de forma local. El RAA de 2013 estipula que esta información DEBE mostrarse si está disponible en el Registro. Si esta información no está disponible en el Registro (por ejemplo, un registro "acotado"), la cadena de caracteres "No disponible en el Registro" DEBERÍA mostrarse en su lugar.
    4. El campo "Fecha de actualización:" debe indicar la fecha y la hora de la última actualización exitosa de la cual el Registrador tenga conocimiento. Los registradores no tienen la obligación de actualizar constantemente el campo "Fecha de actualización:" del Registro.
    5. El requisito de nivel de servicio "Fecha de actualización de RDDS" descripto en la Sección 2.2. de la Especificación sobre Servicios de Directorio de Datos de Registración (WHOIS) se refiere únicamente a los cambios iniciados por el registrador.
    6. Los estados de EPP en los resultados de WHOIS DEBEN indicar el último conjunto de estados de EPP conocidos en el Registro. Los registradores no tienen la obligación de actualizar constantemente los estados de EPP del registro.
    7. A menos que exista estipulación en contrario por política o contrato, la sección correspondiente al valor (por ejemplo, lado derecho de los dos puntos) de los campos DEBE cumplir con el formato especificado en las RFC del EPP: 5730-5734 y 3915. Los siguientes campos no se especifican en las RFC de EPP: 5730-5734 o 3915, y DEBEN seguir las especificaciones de formato indicadas a continuación:

      1. "Dirección de correo electrónico del registrador para informar instancias de uso indebido" (según la definición de campos de correo electrónico contenida en los documentos RFC sobre EPP)
      2. "Número telefónico de contacto del registrador para informar instancias de uso indebido" (según la definición de campos de números telefónicos contenida en los documentos RFC sobre EPP)
      3. "Revendedor" se define como identificador (token); (véase Lenguaje de Marcas Extensible 1.1)
      4. El valor "Servidor de WHOIS del Registrador" se define como nombre del host (véase RFC952 y RFC1123) y es el servidor de nombre del servidor de WHOIS (puerto 43) del Registrador patrocinador
      5. El valor "URL del Registrador" se define como un URL (véase RFC3986) y DEBE indicar el sitio web del registrador patrocinador; específicamente, el URL de WHOIS en la Web del objeto consultado, o al menos el URL del servicio de WHOIS en la Web correspondiente al registrador
      6. El valor "ID de la IANA del Registrador" se define como un número entero decimal positivo.
      7. El valor "Registrador" se define como identificador (token); (véase Lenguaje de Marcas Extensible 1.1).
    8. La sección correspondiente al valor en el campo "Revendedor" DEBERÍA mostrarse, pero PUEDE ser dejada en blanco, o bien se PODRÁ optar por no mostrar el campo en su totalidad. En caso de mostrarse el campo, el valor del campo DEBE ser el nombre de la organización, en caso de que el revendedor del nombre sea una entidad con personería jurídica o una persona física.
    9. Los campos que se indican a continuación PUEDEN figurar inmediatamente antes del último campo ("URL del formulario de reclamo por inexactitud de datos de WHOIS") en lugar de después del campo "ID de la IANA del Registrador":
      • Dirección de correo electrónico del registrador para informar instancias de uso indebido
      • Número telefónico de contacto del registrador para informar instancias de uso indebido
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."