Búsqueda registro PTR

En modo de traza iterativa, se ignora el resolvedor.
Consulta varios resolvedores públicos para comparar las respuestas.

¿Cómo usar correctamente las diferentes opciones del motor de búsqueda DNS?

¿Qué es la traza iterativa?

La traza ejecuta la resolución paso a paso. El resolvedor consulta primero a los servidores raíz, luego a los del TLD (.com, .fr, .eu) y finalmente a los servidores autoritativos de la zona objetivo. En cada etapa la página muestra el servidor consultado, la respuesta, el RCODE y la latencia.

  1. 1. Raíz

    Descubrimiento de los servidores del TLD para el nombre solicitado.

  2. 2. TLD

    Referencia a los NS de la zona (delegación).

  3. 3. Autoritativos

    Respuesta final (o error) con TTL y latencia.

¿Para qué sirve?

  • Comparar respuestas según los resolvedores y las regiones
  • Detectar un caché caliente, un TTL demasiado largo o una delegación incompleta
  • Explicar una diferencia de latencia o un RCODE inesperado

Truco: deja la traza desactivada para las comprobaciones rápidas; actívala cuando investigues o prepares un ticket/post-mortem.

¿Qué es la traza clásica?

La traza clásica consulta únicamente el resolvedor seleccionado (UDP o DoH) y muestra la respuesta tal como se percibe desde ese punto de la red. Obtienes el RCODE, las secciones de la respuesta y la latencia del tramo cliente → resolvedor.

  1. 1. Resolvedor elegido

    Utiliza el preset o la configuración personalizada para lanzar la consulta exactamente como lo haría tu servicio.

  2. 2. Protocolo conservado

    Respeta el transporte seleccionado (UDP, TCP o DoH) para reproducir el comportamiento real.

  3. 3. Respuesta detallada

    Muestra las secciones question, answer y authority/additional cuando existen, con TTL y metadatos útiles.

¿Por qué usarla?

  • Comprobar la visión de un resolvedor específico antes de sospechar de la delegación
  • Confirmar los valores en caché y el impacto de un TTL o de un vaciado
  • Documentar una resolución tal como la ve un cliente o un microservicio

Truco: deja desactivada la opción de traza iterativa cuando audites un resolvedor concreto; actívala después para compararla con el recorrido raíz → TLD → autoritativo.

¿Cómo funciona la prueba de propagación?

La prueba consulta en paralelo un conjunto de resolvedores públicos (Google, Cloudflare, Quad9, OpenDNS, ISP…) y agrupa las respuestas por contenido y RCODE. Ves al instante quién ya aplicó la actualización.

  1. 1. Resolvedores multipunto

    Activa los presets de propagación para consultar a varios actores repartidos por el mundo.

  2. 2. Comparación automática

    Agrupa las respuestas idénticas y señala las divergencias o los errores propios de cada resolvedor.

  3. 3. Resumen accionable

    Ofrece un resumen claro, la lista de resolvedores, sus latencias y el estado de cada grupo.

¿Cuándo usarla?

  • Seguir la difusión de un cambio DNS a escala mundial
  • Identificar cachés aún antiguos y decidir un vaciado específico
  • Compartir un estado de propagación en un ticket o post-mortem

Truco: durante la prueba de propagación la selección de resolvedor queda bloqueada. Desactiva el modo para volver al diagnóstico unitario.

Información adicional sobre los registros DNS tipo PTR

Un registro PTR asocia una dirección IP a un nombre de host. Se habla de resolución inversa. Los sistemas lo utilizan para los logs, los controles de red y la mensajería. Para ir hacia una dirección, nos apoyamos en A o AAAA. Para volver hacia un nombre, nos apoyamos en PTR.
Un registro PTR contiene un nombre, un tipo, un objetivo y un TTL. El TTL indica cuánto tiempo la respuesta permanece en caché en el resolutor local.

Ejemplo registro DNS de tipo PTR para IPv4

NombreTipoObjetivoTTL en segundos
10.113.0.203.in-addr.arpa.PTRmail.ejemplo.net.3600

En este ejemplo el nombre corresponde a la dirección 203.0.113.10 escrita al revés en la zona in-addr.arpa. El objetivo es el nombre de host esperado. Un TTL a 3600 corresponde a una hora.

Ejemplo registro DNS de tipo PTR para IPv6

NombreTipoObjetivoTTL en segundos
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.PTRhost.ejemplo.net.3600

Aquí el nombre retoma cada dígito hexadecimal de 2001:db8::10 al revés en la zona ip6.arpa. El objetivo es el nombre de host esperado.

Coherencia ida y vuelta

Una buena configuración hace corresponder PTR y A o AAAA. El nombre devuelto por PTR debe él mismo resolver hacia la dirección de origen. Esta coherencia ayuda a la mensajería y al diagnóstico.

TTL explicado claramente

Un TTL corto hace visible un cambio más rápido. Práctico durante un cambio de dirección.
Un TTL medio o largo reduce las consultas hacia los servidores autoritarios. Útil para una configuración estable.
Reducir el TTL algunas horas antes de una modificación luego subirlo después de la validación.

Bueno saber
Una dirección puede publicar un solo PTR útil. Multiplicar los PTR para la misma dirección crea ambigüedad. Es mejor un nombre claro que luego resuelve en A o AAAA.

Dónde usar un registro PTR

En la zona inversa proporcionada por el titular de las direcciones. Para IPv4 esto se hace bajo in-addr.arpa. Para IPv6 esto se hace bajo ip6.arpa. En bloques proporcionados por un operador, la gestión del PTR se ajusta a menudo en su panel de control.

A evitar
Apuntar un PTR hacia un nombre que no posee registro A o AAAA.
Dejar un objetivo antiguo después de un cambio de dirección.
Publicar un nombre genérico que no refleja el servicio real.

Verificar en línea

Una búsqueda DNS en línea permite introducir una dirección. El resultado muestra el nombre devuelto por PTR y el TTL visible desde Internet. Es un primer control útil. Hacer luego una prueba local desde su máquina.

Verificar bajo Windows

Windows proporciona nslookup. Se puede usar en modo interactivo.

Resolutor local
nslookup
set q=ptr
10.113.0.203.in-addr.arpa

O simplemente

nslookup 203.0.113.10
Resolutor específico
nslookup
set q=ptr
server 1.1.1.1
10.113.0.203.in-addr.arpa

El primer método sigue la configuración de red de la máquina. El segundo fuerza el uso de un resolutor tercero, aquí el de Cloudflare.

Verificar bajo Linux y bajo Mac

En estos sistemas el comando dig es práctico y fácil de usar.

Resolutor local
dig ptr 10.113.0.203.in-addr.arpa
Resolutor específico
dig ptr 10.113.0.203.in-addr.arpa @1.1.1.1

Para IPv6 se consulta la forma ip6.arpa del mismo nombre.

Lectura rápida de las respuestas

Una respuesta con NXDOMAIN indica la ausencia de PTR. Agregar la entrada en la zona inversa.
Un nombre devuelto que no resuelve en A o AAAA señala una incoherencia. Corregir la zona directa.
Un TTL elevado puede explicar un desfase después de un cambio.

Procedimiento de implementación simple

  1. Verificar el control de la zona inversa con el proveedor de acceso o el cloud.
  2. Elegir un nombre de host claro que resuelva en A o AAAA hacia la dirección.
  3. Crear el PTR con un TTL reducido.
  4. Probar con nslookup o con el comando dig desde varias redes.
  5. Subir el TTL cuando todo esté estable.

Consejo práctico
Para la mensajería hacer corresponder el registro PTR, el nombre usado por el servidor SMTP y el registro A o AAAA asociado. Esta coherencia mejora la entregabilidad.

Casos frecuentes

Servidor de mensajería

Exigir un PTR que devuelva un nombre dedicado. El nombre debe resolver hacia la dirección del servidor.

Rango de direcciones en un operador

Solicitar la delegación de la zona inversa o usar la interfaz prevista para gestionar los PTR.

Máquinas efímeras en cloud

Automatizar la creación y eliminación del PTR a la llegada y salida de las instancias.

Resolución de problemas rápida

  1. Si un servicio rechaza la conexión verificar la presencia de un PTR y la coherencia con A o AAAA.
  2. Si la respuesta sigue siendo antigua esperar la expiración del TTL y purgar la caché del resolutor local si es posible.
  3. Si el proveedor gestiona la zona inversa abrir un ticket y proporcionar la dirección y el nombre deseado.

En resumen, un registro PTR proporciona el nombre asociado a una dirección. Complementa los registros A y AAAA. Un TTL adaptado y una coherencia ida y vuelta simplifican los controles. La verificación pasa por una herramienta en línea luego por nslookup y por dig.
Con estas referencias la gestión permanece clara. Los cambios se desarrollan sin estrés. Los servicios se identifican correctamente en resolución inversa.