Instalación de Servicios de Resolución de Nombres (DNS)

El DNS traduce nombres a IP y viceversa; es la “guía” que permite que www llegue a su IP sin memorizar números. Además, existe resolución directa (nombre→IP) e inversa (IP→nombre). Trabajaremos en Windows Server instalando el rol DNS, creando zonas y poblando registros, para terminar con pruebas de verificación y buenas prácticas de puertos/TTL.

Qué es DNS y por qué lo necesitas

DNS es jerárquico y distribuido, con dominios y zonas que contienen registros tipo A/AAAA, CNAME, MX, TXT, SRV, etc. Su valor: usabilidad (nombres), flexibilidad ante cambios de IP y soporte de resolución inversa para diagnósticos y seguridad.

Requisitos previos en Windows Server (IP estática, nombre de equipo, versiones)

Antes de instalar: Windows Server actual (2016/2019/2022), permisos de admin, IP estática y nombre de equipo definido (útil para NS si será autoritativo). Luego instalaremos el rol por GUI o PowerShell.

Instalar el rol DNS en Windows Server (GUI y PowerShell)

1. Administrador del servidor → Administrar → Agregar roles y características → Servidor DNS (acepta herramientas).
2. Instalar y cerrar el asistente (no requiere reinicio).
3. Verifica que aparezca el rol y la consola “Administrador DNS”.
   También es posible instalarlo con un cmdlet de PowerShell (ideal en Server Core y automatización).

Nota AD: en controladores de dominio, el asistente puede integrar DNS con Active Directory creando automáticamente la zona del dominio. Aquí nos centramos en la configuración manual.

Crear la zona de búsqueda directa: ejemplo con midominio.local

Objetivo: crear una zona primaria para midominio.local (almacenada en archivo) y sin actualizaciones dinámicas para un entorno pequeño.
Pasos: Administrador DNS → Zonas de búsqueda directa → Nueva zona… → Zona principal → nombre midominio.local → aceptar archivo propuesto → No permitir actualizaciones dinámicas. Se crean por defecto registros SOA y NS.

Política de actualizaciones dinámicas y archivo de zona

En entornos sin AD conviene desactivarlas y gestionar todo manualmente. El archivo de zona (p. ej. %SystemRoot%\System32\DNS\midominio.local.dns) guarda los registros.

Crear la zona de búsqueda inversa: in-addr.arpa y PTR

Para una red 192.168.1.0/24, la zona inversa será 1.168.192.in-addr.arpa.
Pasos: Zonas de búsqueda inversa → Nueva zona… → Principal → IPv4 → ID de red 192.168.1 (el asistente compone el nombre) → archivo y política de actualizaciones → Finalizar. Quedarán SOA y NS iniciales.

Añadir registros esenciales: A/AAAA, CNAME, MX, TXT y SRV

• A/AAAA (host): Nueva host (A o AAAA) → nombre servidor1 → IP 192.168.1.10. Marca “Crear registro PTR asociado” para que también se cree en la zona inversa.
• CNAME (alias): Nuevo alias (CNAME) → alias www → destino servidor1.midominio.local. (FQDN).
• MX (correo): Nuevo registro MX → destino servidor1.midominio.local. → prioridad 10 (menor = más prioridad). Asegúrate de que exista el A correspondiente.
• Otros (PTR/TXT/SRV): el asistente guía cada caso; un TXT típico: midominio.local TXT "v=spf1 mx -all".

Ejemplos prácticos: www, mail, y PTR asociado

Con lo anterior, www.midominio.local (CNAME) heredará la IP del A de servidor1. Si marcaste la casilla de PTR al crear el A, tendrás automáticamente 10.1.168.192.in-addr.arpa → servidor1.midominio.local.

Zonas primaria y secundaria: transferencias AXFR/IXFR y notificaciones

En producción, añade secundarios por redundancia. El secundario mantiene copia de solo lectura que obtiene mediante transferencia de zona (AXFR completa o IXFR incremental, controladas por el serial del SOA). Usa TCP/53 para transferencias; configura en la zona del primario qué IPs están autorizadas a recibir la transferencia y habilita notificaciones si quieres acelerar la sincronización.

Verificar que todo funciona: nslookup, ping (-a) y pruebas comunes

• nslookup: consulta directa e inversa al DNS (set type=MX, etc.).
• ping por nombre / ping -a IP: comprueba resolución aún si ICMP no responde.
• Clientes: asigna la IP del DNS en su config (manual o DHCP).
• Opcional: dig/host en Linux, o Resolve-DnsName en PowerShell.

Problemas habituales y soluciones rápidas (TTL, interfaces, permisos, caché)

• El servicio DNS debe estar iniciado (services.msc o Get-Service DNS).
• Si hay varias NICs, revisa Interfaces en las propiedades del servidor DNS.
• Comprueba que consultas en la zona correcta y que la inversa existe.
• Ajusta TTL según la frecuencia de cambios; recuerda la caché en resolutores.

Puertos, seguridad básica y buenas prácticas (UDP/TCP 53, firewall)

Permite UDP/53 para consultas y TCP/53 para respuestas grandes y transferencias de zona. Ajusta firewall/ACLs en consecuencia; limita transferencias a IPs permitidas.

Checklist final de despliegue DNS en producción

• Rol DNS instalado y consola accesible.
• Zona directa midominio.local y zona inversa 1.168.192.in-addr.arpa creadas.
• Registros A/CNAME/MX/TXT/SRV definidos; PTR creados (automático o manual).
• Secundario configurado y transferencias autorizadas (AXFR/IXFR).
• Pruebas con nslookup y ping -a OK; clientes apuntan al DNS.

---

Conclusión

Con una IP fija, el rol DNS instalado, zonas directa e inversa bien definidas y registros esenciales, ya tienes un DNS autoritativo local listo. Compleméntalo con un secundario para alta disponibilidad y documenta TTLs/reenviadores según tu política de red.

FAQs

¿Por qué necesito zona inversa si ya resuelvo por nombre?
Porque muchas comprobaciones y utilidades dependen de PTR (IP→nombre) para diagnósticos y validación.

¿Qué prioridad pongo al MX?
Si tienes un sólo servidor de correo, 10 es una buena base; con varios, el menor valor tiene mayor prioridad.

¿Recursivo o autoritativo puro?
Autoritativo responde sólo por sus zonas; recursivo resuelve cualquier dominio mediante consultas iterativas y caché.

¿Qué puertos abrir?
UDP/53 para la mayoría de consultas y TCP/53 para transferencias y respuestas grandes.

Práctica de diagnóstico: el nombre no resuelve

En un laboratorio, un equipo recibe la IP 192.168.1.50, pero no encuentra servidor.midominio.local. Antes de modificar la zona, ejecuta ipconfig /all y comprueba qué servidor DNS utiliza el cliente. Después compara nslookup servidor.midominio.local con nslookup servidor.midominio.local 192.168.1.10, suponiendo que esta última dirección sea la de tu DNS de laboratorio.

Cómo interpretar el resultado: si la consulta directa al DNS funciona y la consulta por defecto falla, revisa la configuración DNS del cliente y las opciones entregadas por DHCP. Si ambas fallan, comprueba el registro, la zona y la conectividad con el servidor. Un mensaje de nombre inexistente y un tiempo de espera agotado no indican el mismo problema.

Continúa con la instalación y configuración de DHCP para distribuir la configuración de red. Puedes consultar el resto de prácticas en el curso de Servicios en Red.