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.