Curso de servidores linux

¿Qué es una zona inversa?

Hasta ahora hicimos:

web.lab.local  →  192.168.1.50

Eso es resolución directa (registro A).

La zona inversa permite lo contrario:

192.168.1.50 → web.lab.local

Se usa para:

  • Logs profesionales
  • Servidores de correo (MX)
  • Seguridad
  • Auditorías
  • Herramientas como ping, traceroute, ssh (a veces)

¿Cómo funciona técnicamente?

DNS no guarda IPs como normales.

Las invierte y las mete en el dominio especial:

in-addr.arpa

Ejemplo:

IP:

192.168.1.50

Se convierte en:

50.1.168.192.in-addr.arpa

Pero como trabajamos por red /24:

Red:

192.168.1.0/24

La zona será:

1.168.192.in-addr.arpa

PASO 1 - Confirmar tu red

Ejecuta:

1ip a

Si tienes algo como:

inet 192.168.1.50/24

Entonces tu red es:

192.168.1.0/24

Y tu zona inversa será:

1.168.192.in-addr.arpa

PASO 2 - Declarar la zona inversa

Edita:

1sudo nano /etc/bind/named.conf.local

Añade debajo de tu zona directa:

1zone "1.168.192.in-addr.arpa" {
2  type master;
3  file "/etc/bind/db.192.168.1";
4};

⚠️ Ojo: Si tu red fuera 192.168.0.x sería:

0.168.192.in-addr.arpa

PASO 3 - Crear archivo de zona inversa

1sudo nano /etc/bind/db.192.168.1

Contenido ejemplo (ajusta IP si es distinta):

1$TTL    300
2@       IN      SOA     ns1.lab.local. admin.lab.local. (
3                        2026021101
4                        3600
5                        1800
6                        604800
7                        300 )
8
9@       IN      NS      ns1.lab.local.
10
1150      IN      PTR     web.lab.local.

Explicación línea por línea

50 IN PTR web.lab.local.

Significa:

192.168.1.50 → web.lab.local

Porque:

  • La zona ya representa 192.168.1
  • Solo ponemos el último octeto (50)

Validar antes de reiniciar

Muy importante:

1sudo named-checkconf
2sudo named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192.168.1

Si no hay errores:

1sudo systemctl restart bind9

Probar desde tu servidor

1dig -x 192.168.1.50 @127.0.0.1

Debería aparecer:

ANSWER SECTION:
50.1.168.192.in-addr.arpa. 300 IN PTR web.lab.local.

También puedes probar:

1nslookup 192.168.1.50 127.0.0.1

Probar desde otro equipo (Windows)

1nslookup 192.168.1.50 192.168.1.50

Si tu DNS está configurado como principal en el cliente, basta con:

1nslookup 192.168.1.50

Mejora profesional (muy recomendable)

Si tu servidor también es:

  • api.lab.local
  • db.lab.local

Y apuntan a la misma IP, puedes elegir cuál será el PTR oficial.

⚠️ Buenas prácticas: Solo debería haber un PTR principal por IP.

Normalmente se usa el nombre principal del servidor:

server.lab.local

Y los demás son alias (CNAME).


Arquitectura profesional recomendada

En vez de:

web → 192.168.1.50
api → 192.168.1.50
db → 192.168.1.50

Mejor:

server.lab.local → 192.168.1.50
web → CNAME server.lab.local
api → CNAME server.lab.local
db → CNAME server.lab.local

Y el PTR:

50 IN PTR server.lab.local.

Mucho más limpio.


¿Qué acabas de montar?

Ahora tu servidor DNS:

✔ Resuelve nombres → IP ✔ Resuelve IP → nombre ✔ Está configurado como infraestructura real

¿Qué falta por implementar?

  • 🔥 Integrar DNS con DHCP
  • 🔥 Simular infraestructura de empresa (empresa.local)
  • 🔥 Montar subdominios internos
  • 🔥 Hacer split DNS
  • 🔥 Montar DNS secundario