Registros PTR: ¿cómo funciona este tipo de registro DNS?

El sistema de nombres de dominio (DNS) facilita la co­mu­ni­ca­ción en Internet. Su función más conocida es pro­ba­ble­me­n­te la re­so­lu­ción de nombres, que permite a los usuarios in­tro­du­cir un URL en el navegador y que au­to­má­ti­ca­me­n­te se es­ta­ble­z­ca la conexión con una dirección IP. Para que este proceso funcione, el DNS (o, más bien, los se­r­vi­do­res de nombres en­ca­r­ga­dos) recurren a archivos de zona, que son simples archivos de texto en los que se enumeran los registros DNS línea por línea. La re­so­lu­ción de nombres se produce mediante los registros A o AAAA, mientras que la tra­n­s­mi­sión de correos ele­c­tró­ni­cos es posible gracias a los registros MX.

Los PTR records son, en cierto modo, lo opuesto a los registros A: no asignan un nombre de dominio a una dirección IP, sino viceversa. Por eso, se dice que los registros PTR hacen posible la búsqueda inversa o reverse DNS.

PTR es una abre­via­ción de pointer, lo cual ya da una idea de la función de este tipo de registro. Un registro PTR (DNS PTR record) apunta hacia el nombre del dominio, haciendo así posible la búsqueda inversa (reverse DNS, rDNS o reverse lookup). En la mayoría de casos se quiere es­ta­ble­cer conexión con un servidor cuyo nombre de dominio se conoce, pero no su dirección IP. En la búsqueda inversa sucede justo lo contrario: ya se conoce la dirección IP y se quiere averiguar el nombre del dominio, es decir, el URL mediante el cual se puede acceder a él.

La es­tru­c­tu­ra de un PTR record se parece mucho a la de los demás tipos de registros. Las distintas in­fo­r­ma­cio­nes se ordenan en campos, ordenados uno tras otro dentro del registro.

• <name>: el primer campo de un registro PTR indica la dirección IP.
• <ttl>: el time to live indica el tiempo, en segundos, durante el cual el registro es válido, antes de que deba ser so­li­ci­ta­do de nuevo.
• <class>: este campo contiene la abre­via­tu­ra de la clase de red utilizada.
• <type>: aquí se define el tipo de registro, que en este caso es PTR.
• <rdata>: el último campo contiene los datos de recurso, es decir, el nombre del dominio.

Los campos se ordenan uno tras otro en una misma línea y no se separan con ningún símbolo, sino si­m­ple­me­n­te con espacios. La línea, y con ella el registro, acaba solo con un salto de línea.

Se puede observar que la sintaxis es la misma que la de un registro A, úni­ca­me­n­te cambia el contenido de los campos. En primer lugar, se indica la dirección IP: son válidas tanto las IPv4 como las di­re­c­cio­nes IPv6. Sin embargo, hay una pa­r­ti­cu­la­ri­dad a tener en cuenta: se usa reverse mapping, es decir, la dirección IP se muestra en sentido opuesto (de derecha a izquierda).

Si se usa una dirección IPv4, sin embargo, solo hay que cambiar de orden los octetos enteros, de manera que el orden de cifras dentro de cada grupo no varía. Con las di­re­c­cio­nes IPv6 funciona de otra manera: el orden cambia a nivel de cifras y de letras y los valores se separan unos de otros con puntos. Los ceros iniciales, que en la notación he­xa­de­ci­mal no­r­ma­l­me­n­te se omiten, se incluyen también en los registros PTR.

Hay que indicar, además, la zona. Según si se trata de una dirección IPv4 o de una IPv6, la zona puede adquirir dos ex­te­n­sio­nes: in-addr.arpa. o ip6.arpa, re­s­pe­c­ti­va­me­n­te.

El time to live muestra durante cuánto tiempo el registro sigue siendo válido. Una vez tra­n­s­cu­rri­do este periodo, la in­fo­r­ma­ción debe ser so­li­ci­ta­da de nuevo. Con este sistema, el DNS evita la po­si­bi­li­dad de que registros des­ac­tua­li­za­dos se mantengan en el caché, lo que podría producir problemas de conexión. No obstante, este campo no suele aparecer en los registros en sí, sino que el tiempo se suele es­ta­ble­cer con la orden $TTL al principio del archivo y se aplica a la zona entera. El TTL se da en segundos.

El campo class, que se refiere a la clase de red, se mantiene úni­ca­me­n­te por razones hi­s­tó­ri­cas. Cuando se de­sa­rro­lló el DNS, aún se uti­li­za­ban otros dos proyectos de red, además de Internet: Hesiod (HS) y Chaosnet (CH). Puesto que hoy en día solo se usa Internet, este campo puede, o bien omitirse co­m­ple­ta­me­n­te, o bien contener la abre­via­tu­ra IN. En caso de omitirse, el sistema asume, por defecto, que se trata de Internet. En cuanto al tipo de registro, en este caso se trata, como ya sabemos, de PTR. El último campo indica el nombre del dominio, también en forma de FQDN.

Tomemos como ejemplo que un usuario conoce las di­re­c­cio­nes IP de example.org, pero no a qué dominio co­rre­s­po­n­den. Las di­re­c­cio­nes IP son 2606:2800:220:1:248:1893:25c8:1946 y 93.184.216.34. Para que el usuario pueda hacer una búsqueda inversa en el DNS, se pro­po­r­cio­nan registros PTR con la siguiente es­tru­c­tu­ra:

En este ejemplo hemos es­ta­ble­ci­do el time to live al principio del archivo para que se aplique a todos los registros. A co­n­ti­nua­ción aparecen ambos registros (PTR records), que contienen los nombres de dominio con los que están enlazadas las di­re­c­cio­nes IP, pe­r­mi­tie­n­do así la búsqueda inversa o reverse lookup.

Los re­su­l­ta­dos aparecen bajo el epígrafe Answer. El servicio muestra enseguida dos se­r­vi­do­res distintos, cuyos nombres se indican tras data. Se puede observar que ambos tienen el mismo valor en TTL, lo que apunta a que pro­ba­ble­me­n­te se ha es­ta­ble­ci­do un mismo tiempo para toda la zona.

En el campo type aparece una cifra en lugar de una abre­via­tu­ra, ya que la autoridad de números asignados en Internet (IANA) ha asignado a cada tipo de registro un valor in­di­vi­dual que lo ide­n­ti­fi­ca. El número 12 equivale, na­tu­ra­l­me­n­te, al registro PTR.

La dirección IP que se ha co­m­pro­ba­do pertenece en realidad al dominio google.com. Las re­s­pue­s­tas, sin embargo, muestran di­re­c­ta­me­n­te nombres internos del servidor que no están di­s­po­ni­bles para el uso público y que tampoco funcionan como URL.