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