BrbOS/Manual/DNS Reverso

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`.