BrbOS/Manual/DNS Reverso

De BrByte Latam
Ir a la navegación Ir a la búsqueda

DNS Reverso: Guía de Configuración

Introducción

El DNS Reverso es el mecanismo que permite resolver una dirección IP hacia un nombre de host (también llamado hostname).

Por ejemplo: 

200.10.20.3  →  mail.ejemplo.net

Mientras que el DNS directo (forward DNS) responde a la pregunta ¿qué IP corresponde a este nombre?, el DNS reverso responde a ¿qué nombre corresponde a esta IP?.

Esto se logra creando zonas inversas, que son espacios especiales en el DNS:

  • .in-addr.arpa → para direcciones IPv4
  • .ip6.arpa → para direcciones IPv6

Importancia

Configurar correctamente el DNS Reverso es fundamental por varias razones:

  • Correo electrónico (SMTP): la mayoría de los servidores de correo (ej: Gmail, Outlook, Yahoo) verifican que las direcciones IP de los remitentes tengan un registro PTR válido.
    • Sin PTR correcto, los correos suelen ser marcados como spam o directamente rechazados.
  • Diagnóstico de red: herramientas como ping, traceroute o mtr utilizan el DNS reverso para mostrar nombres de host en lugar de solo IPs, facilitando la identificación de equipos y rutas.
  • Buenas prácticas de Internet: según el RFC 1912, sección 2.1, todos los hosts deberían tener un registro PTR que apunte a un nombre válido.
  • Requisito de los registros regionales de Internet (RIRs): organismos como LACNIC (en América Latina y el Caribe), ARIN, RIPE NCC y otros, exigen que los bloques de direcciones IPv4 e IPv6 delegados tengan configurado un reverso válido.
    • En el caso de LACNIC, al recibir un bloque IP, el titular debe configurar o delegar la zona reversa correspondiente.
  • Imagen profesional: disponer de nombres reversos consistentes transmite organización y seriedad técnica ante clientes, proveedores y socios.


Conceptos básicos

Registro directo (A)

Un registro A asocia un nombre de host a una dirección IPv4. 

mail.ejemplo.net.   IN  A   200.10.20.3

Registro inverso (PTR)

Un registro PTR asocia una dirección IP a un nombre de host. 

3.20.10.200.in-addr.arpa.   IN  PTR   mail.ejemplo.net.

SOA (Start of Authority)

Es el registro principal de la zona. Define parámetros de control:

  • **Serial**: versión de la zona (debe incrementarse en cada cambio).
  • **Refresh**: intervalo de actualización entre master y slave.
  • **Retry**: tiempo de reintento si falla la actualización.
  • **Expire**: tiempo máximo que un slave mantiene datos sin actualizar.
  • **Minimum TTL**: tiempo de cacheo por defecto.

NS (Name Server)

Indica qué servidores son responsables de la zona DNS. Ejemplo: 

ejemplo.net.   IN  NS   ns1.ejemplo.net.
ejemplo.net.   IN  NS   ns2.ejemplo.net.

Método simplificado

El método recomendado actualmente es usar un dominio ya existente del cliente para simplificar el proceso. De esta forma, solamente se crea la **zona inversa** correspondiente al bloque IP delegado, evitando la necesidad de manejar una zona de dominio adicional.

Requisitos previos

  • El cliente debe contar con un **dominio propio** (ej: ejemplo.net).
  • Deben existir al menos **dos servidores DNS autoritativos**, cada uno con **IP pública distinta**.
  • Se deben agregar registros en el dominio del cliente:
ns1.ejemplo.net.   IN A   200.10.20.2
ns2.ejemplo.net.   IN A   200.10.20.3

Pasos de configuración en BrbOS

  1. Ingresar al panel de administración de BrbOS.
  2. Ir al menú **DNS Zone** y crear una nueva zona del tipo **Reversa** para el bloque /24 asignado.
  * Ejemplo para el bloque 200.10.20.0/24:  

20.10.200.in-addr.arpa.
  1. Una vez creada la zona, añadir el registro **SOA** (Start of Authority).
  Ejemplo:

@ IN SOA ns1.ejemplo.net. admin.ejemplo.net. (
     2025090301 ; Serial
     3600       ; Refresh
     1800       ; Retry
     604800     ; Expire
     86400 )    ; Minimum TTL
  1. Agregar los registros **NS** de la zona:
@ IN NS ns1.ejemplo.net.
@ IN NS ns2.ejemplo.net.
  1. Crear los registros **PTR** para los hosts principales:
1   IN PTR router.ejemplo.net.
2   IN PTR ns1.ejemplo.net.
3   IN PTR mail.ejemplo.net.
  1. (Opcional) Usar la función **Generar PTR en lote** para crear automáticamente todos los registros de 0 a 255 en el bloque /24.

Configuración IPv6

En el caso de IPv6, las zonas inversas se crean bajo `.ip6.arpa`, normalmente por bloques /48.

Ejemplo: 

$ORIGIN 0.0.0.0.0.8.b.0.4.0.8.2.ip6.arpa.
@ IN SOA ns1.ejemplo.net. admin.ejemplo.net. (
     2025090301 ; Serial
     3600       ; Refresh
     600        ; Retry
     86400      ; Expire
     3600 )     ; Minimum TTL
@ IN NS ns1.ejemplo.net.
@ IN NS ns2.ejemplo.net.

2.0.0.0.d.d.0.0....ip6.arpa.   IN PTR host.ejemplo.net.
  • Solo se crean registros PTR para los hosts necesarios (ej: ns1, ns2).
  • No es necesario declarar todos los IPs del bloque, ya que sería inviable.


Delegación en LACNIC / Registro.br

Una vez configurados los servidores de nombres y la zona inversa, es necesario delegar el bloque en el portal de LACNIC o el NIC correspondiente.

Pasos en LACNIC

  1. Ingresar a [MiLACNIC].
  2. Seleccionar el bloque de direcciones IP.
  3. Ir a la opción **Delegación de DNS Reverso**.
  4. Indicar los servidores configurados:
ns1.ejemplo.net.   200.10.20.2
ns2.ejemplo.net.   200.10.20.3
  1. Confirmar la operación.

Validación

  • LACNIC valida automáticamente que ambos servidores respondan correctamente.
  • Si uno de ellos no funciona o no resuelve la zona, la delegación será rechazada.
  • Es obligatorio contar con **dos servidores distintos** (ns1 y ns2), cada uno con **IPs públicas diferentes**.

Nota

El proceso en **Registro.br** es equivalente: seleccionar el bloque, indicar los servidores, confirmar y esperar propagación.


Pruebas y validación

Después de delegar, es importante probar que los registros funcionan.

Linux/Unix

host 200.10.20.3 ns1.ejemplo.net

Windows

nslookup 200.10.20.3 ns1.ejemplo.net

Resultado esperado: 

3.20.10.200.in-addr.arpa.  IN PTR  mail.ejemplo.net.

Si la consulta devuelve el nombre configurado, la zona inversa está funcionando.


Buenas prácticas

  • Contar siempre con al menos **dos servidores DNS autoritativos**.
    • Esto no es solo una recomendación: LACNIC exige informar al menos 2 servidores para aprobar la delegación.
    • Los servidores deben estar en **IPs públicas distintas**.
  • Mantener los **seriales SOA sincronizados** entre el servidor maestro y los esclavos.
  • Verificar la consistencia entre los registros PTR y sus registros A correspondientes.
  • Documentar todos los bloques y zonas delegadas.
  • Realizar pruebas periódicas con herramientas como `dig`, `host` o `nslookup`.
Obtenido de «https://wiki.brbytelatam.com/index.php?title=BrbOS/Manual/DNS_Reverso&oldid=503»