RDAP (Registration Data Access Protocol) es un protocolo que busca reemplazar a WHOIS.
Ambos sirven para conocer información de algunos objetos propios del internet, como lo son nombres de dominio o IPs. Para conocer aspectos básicos de RDAP, se puede consultar el artículo “Conociendo RDAP” , la primera parte de esta serie de tres artículos
Tal como se menciona en el artículo referido, “Conociendo RDAP” , una de las ventajas que este protocolo tiene sobre WHOIS es que «los datos se obtienen en un mismo formato, independientemente del servidor que los regrese». Precisamente aquí se hará énfasis en esa ventaja.
Primero hay que conocer cómo responde WHOIS, así que se pondrá como ejemplo la respuesta obtenida al consultar la información del dominio nic.mx:
¿Qué se puede ver en esta respuesta? En la imagen se ve el dominio que fue consultado, su fecha de creación, su fecha de expiración, información de contacto, sus servidores configurados, etc. Además de una notificación del servidor en la parte final. Por sí sola la información no es incorrecta ni inservible, al contrario, es información útil para conocer más sobre el nombre de dominio consultado.
Entonces, ¿cuál es la desventaja? Para una persona que ve la información: probablemente ninguna. Para un servicio o máquina: el formato de la información.
El formato es un problema porque cada servidor de WHOIS responde de manera distinta la información, cada uno de los servidores mostrará la información según sus propios criterios. Por ejemplo, alguno podrá poner el texto en inglés y otro en japonés, un servidor podría poner la información en “bloques” (como el caso de los contactos en la respuesta que se pone como ejemplo) mientras otro la puede poner sin separar y con distintas etiquetas.
Si un servicio o máquina quisiera interpretar esa información para poder mostrarla de otra manera más “amigable” para el usuario (ej. En una tabla con colores, o separada por categorías, tal vez con ligas en caso de que haya correos o teléfonos), la tarea será algo complicada porque necesitará conocer de antemano cómo muestra los datos el servidor WHOIS al que se haga la consulta.
Aquí es donde entra una de las ventajas de RDAP, que es la estandarización de las respuestas. Los servidores de RDAP están obligados a responder a las consultas con un formato común; así, sin importar a qué servidor se haga una pregunta (puede ser un servidor de Japón o uno de México), el servidor responderá con el mismo formato para facilitar la interpretación de la respuesta.
El formato definido para las respuestas de RDAP es JSON, que significa: “JavaScript Object Notation”. Este es un término técnico, y por lo tanto no se ahondará en el tema, pero a grandes rasgos lo que busca es «definir un pequeño conjunto de reglas de formato para la representación portable de datos estructurados» (Bray, 2017).
Un ejemplo muy sencillo para entender cómo sería una respuesta en JSON es:
{
“empresa”: “NIC México”,
“dirección”: “Eugenio Garza Sada 427 L4-6”
}
En el ejemplo se pueden ver dos propiedades: “empresa” y “dirección”, cada una con su respectivo valor y que se encuentra después de los dos puntos “:” localizados a la derecha de la propiedad relacionada. Por lo tanto, se conoce que la propiedad “empresa” tiene un valor de “NIC México” y la propiedad “dirección” tiene un valor de “Eugenio Garza Sada 427 L4-6”. Así es como se podría saber que NIC México tiene esa dirección.
El protocolo RDAP plantea claramente la manera en que debe responder a las consultas, esto se define en el documento (sí, muy técnico también) “RFC 7483 – JSON Responses for the Registration Data Access Protocol (RDAP)”. Por lo tanto, todas las peticiones que se realicen a un servidor de RDAP (ver artículo “Consultas RDAP”) responderán con un formato bien definido y que puede ser interpretado por la máquina o servicio que haya realizado la petición.
Tomando nuevamente un ejemplo para clarificar el párrafo anterior, la siguiente imagen podría ser una respuesta de un servidor RDAP por la información del dominio “foo.example”:
NIC México cuenta con un Servidor RDAP para Akky y uno para él .LAT. Debido a que estas implementaciones están reguladas por ICANN, las respuestas cuentan con mayor nivel de detalle que el mostrado anteriormente. Los ejemplos de respuesta se pueden consultar en:
En este artículo se mostró el formato de las respuestas de un servidor de WHOIS y de un servidor de RDAP para comprender y ver las diferencias que hay entre ellas.
Las ventajas de tener un estándar para la respuesta regresada por un servidor de RDAP son:
- La respuesta puede ser interpretada fácilmente por otra máquina o servidor para así darle un formato “a la medida “.
- El formato “a la medida” puede ser: presentar la información en una tabla con colores o dividida por secciones, mostrar la información en uno o más idiomas (ej. En lugar de mostrar la leyenda “domain” se puede mostrar “dominio” o “nombre de dominio” o “domain name”, etc.), clasificar la información a mostrar, entre otras cosas.
- Los servidores de RDAP están obligados a responder en el formato estándar.
- El formato JSON no es complejo y ya existen muchas herramientas para interpretarlo.
Se espera que esta serie de artículos sobre RDAP (“Conociendo RDAP” , “Consultas RDAP”, y el presente artículo) ayuden al lector a comprender y familiarizarse con este protocolo que es probable sea más utilizado con el paso del tiempo.
Referencias
Bray, Tim. “The JavaScript Object Notation (JSON) Data Interchange Format”. RFC 8259 – The JavaScript Object Notation (JSON) Data Interchange Format. Internet Engineering Task Force (IETF). Diciembre 2017. Web. 29 junio 2018 <https://tools.ietf.org/html/rfc8259>
Newton, A. et al. “JSON Responses for the Registration Data Access Protocol (RDAP)”. RFC 7483 – JSON Responses for the Registration Data Access Protocol (RDAP). Internet Engineering Task Force (IETF). Marzo 2015. Web. 29 junio 2018 <https://tools.ietf.org/html/rfc7483>
