Configurar un servidor DNS a Windows Server

Configurar un servidor DNS a Windows Server no és particularment difícil. El que sí que pot sortir malament és tot el que passa després si es deixen configuracions per defecte, se subestima l’impacte dels canvis o s’ignora com es comporta l’entorn real davant el laboratori. Aquesta entrada està escrita pensant en els qui ja porten temps lidiant amb entorns Windows, Active Directory, xarxes híbrides i altres entrebancs. No es tracta de seguir l’assistent pas a pas sense pensar, sinó de configurar un DNS que realment funcioni bé i no es converteixi en l’origen subtil de problemes intermitents.

1. El context importa: quin rol juga el teu servidor DNS?

Abans d’instal·lar res, cal tenir clar quin paper ha d’exercir aquest servidor DNS. Si és un DC, el més probable és que hagi de ser també DNS, i això no és negociable en la majoria d’entorns Active Directory. Però convé precisar més:

• Serà el servidor per a zones internes?
• Ha de reenviar consultes externes?
• És part d’una configuració multilloc?
• Ha de conviure amb servidors DNS d’altres plataformes (BIND, dnsmasq, etc.)?
• S’integrarà amb DHCP?
• Està darrere de NAT o en una DMZ?

Ignorar aquestes preguntes porta a errors subtils. Per exemple, he vist massa vegades servidors DNS interns reenviant peticions externes a Google (8.8.8.8), sense caché ni control, trencant split-horizon DNS i exposant noms interns a consultes externes indirectament. També és comú deixar zones mal delegades entre llocs i després culpar als “problemes de replicació” quan el problema real era DNS.

2. Instal·lació del rol DNS

En general, això es fa des de Server Manager o amb PowerShell:

Install-WindowsFeature -Nom DNS -IncludeManagementTools

No té misteri. Però sí que convé fer una revisió mèdica ràpida abans d’instal·lar:

1. Assegura’t que la IP del servidor està configurada manualment. Si el servidor obté la IP per DHCP i després instal·les el rol DNS, estàs sembrant una font d’inconsistències. Canviar la IP més endavant en un DC amb DNS porta problemes amb el registre de zones i el servei Netlogon.
2. Valida que no hi hagi programari de tercers interferint (antivirus que escanegi trànsit DNS, per exemple).

3. Zones: decisions que sí que importen

Zona directa (Forward Lookup Zone)

En un entorn amb Active Directory, la zona empresa.local (o la que correspongui) es crea en promoure el DC. El servidor es torna autoritatiu per a ella. Però hi ha punts clau que sovint es passen per alt:

1. Tipus de zona: Si no estàs replicant la zona amb l’àmbit adequat, la replicació pot ser innecessàriament àmplia o ineficaç. Revisa si s’ està replicant a tots els DCs del bosc, del domini o només a servidors DNS. Aquesta decisió afecta el trànsit de replicació i l’aïllament entre dominis.

• Seguretat en els registres: No tots els registres necessiten estar actualitzats dinàmicament. Deixa habilitada l’actualització dinàmica només on tingui sentit. Evitaràs el registre incontrolat de noms d’estacions que no haurien ni d’aparèixer al DNS.
• TTL per defecte: El TTL d’1 hora que ve per defecte pot ser massa alt o baix segons el teu entorn. En llocs amb canvis freqüents (com balancejadors, IP flotants, entorns en HA) baixa’l a 5 minuts. Però si ho fas, assegura’t que els teus clients i servidors intermedis no caiguin més del necessari.

Zona inversa (Reverse Lookup Zone)

Molts la ignoren, però quan tens scripts, logs o serveis que validen adreces IP, no tenir-la ben configurada complicat els diagnòstics.

Errors típics:

1. Oblidar-se de la zona 10.in-addr.arpa en fer servir adreces internes en el rang 10.0.0.0/8.
2. Crear zones per a rangs no alineats: si tens una subxarxa /22 però crees una zona per a /24, els PTR fora del /24 no resoldran.
3. Deixar que els registres PTR es creïn automàticament sense netejar. He vist zones amb milers de registres obsolets, cosa que complica les recerques inverses i genera falsos positius en eines de seguretat.

4. Reenviament de consultes externes

Aquest punt sembla trivial, però hi ha dos errors clàssics:

Error 1: fer servir forwarders públics (Google, Cloudflare) en servidors interns

Això sovint es fa per inèrcia. El raonament és: “vull resoldre dominis externs ràpid”. Però fer servir 8.8.8.8 en un DNS que també resol zones internes pot trencar split-horizon, exposar el teu domini a errors i empitjorar el rendiment.

Si el teu firewall ho permet, fes servir els resolvers del teu ISP o un DNS recursiu local. Una altra opció molt pràctica és tenir un DNS intermedi (un resolver que faci només caché i no sigui autoritatiu) i reenviar aquí.

Error 2: reenviar sense caché útil

Si reenvies però el teu servidor no fa caché efectiu, estàs saturant la xarxa amb peticions repetides. Revisa el paràmetre MaxCacheTtl en el registre:

Get-DnsServerCache

I si necessites ajustar-lo:

Set-DnsServerCache -MaxTtl 01:00:00

5. Integració amb DHCP: registres A i PTR automàtics

Una integració ben feta entre DHCP i DNS evita molts registres obsolets. Però he vist més configuracions dolentes que funcionals.

El que sovint funciona bé:

1. Configurar el servidor DHCP per registrar els noms en DNS en nom del client (només si el DHCP està autoritzat i té permisos).
2. Desactivar que els clients registrin els seus propis registres si no tenen permisos a la zona DNS.
3. Assegurar-se que l’usuari que corre el servei DHCP tingui permisos d’escriptura sobre la zona DNS (això es fa amb dnscmd o des de la GUI a les ACL de la zona).

Un detall útil: si treballes amb estacions no Windows, com impressores o dispositius IoT, aquests no solen registrar els seus noms. Tenir el DHCP configurat per registrar tots dos (A i PTR) et dona més visibilitat.

6. Neteja de registres obsolets (scavenging)

L’scavenging funciona, però mal configurat o mal entès, esborra el que no hauria o no esborra el que esperes. Assegura’t que entenen aquests punts abans d’activar-lo:

1. Només s’esborran registres amb la casella d’Eliminar automàticament.
2. Requereix que tant el servidor com la zona tinguin habilitat scavenging.
3. L’ interval no és immediat. Es basa en dos timers: el “No-refresh” i el “Refresh”. Recomano configurar-los amb 7 dies cadascun en entorns mitjans. Així s’evita registrar múltiples vegades el mateix equip i es garanteix que els obsolets desapareguin en un termini raonable.

Des del PowerShell:

Set-DnsServerScavenging -ScavengingState $true -NoRefreshInterval 7.00:00:00 -RefreshInterval 7.00:00:00

I per a una zona específica:

Set-DnsServerZoneAging -Name "miempresa.local" -Aging $true -NoRefreshInterval 7.00:00:00 -RefreshInterval 7.00:00:00

7. Diagnòstics i monitoratge que valen la pena

Configurar està bé, però diagnosticar bé és el que et salva quan l’entorn creix o falla.

Comandaments que es fan servir amb freqüència:

1. nslookup en mode interactiu, canviant de servidor (server x.x.x.x) per validar autoritat.
2. dcdiag /test:DNS per verificar integritat amb AD.
3. repadmin /showrepl i repadmin /replsummary per distingir problemes de replicació de problemes de resolució.
4. dnscmd /enumrecords per a recerques més detallades o scripts automatitzats.

Supervisió

Molts deixen el DNS fora del sistema d’alertes. Almenys recomano:

1. Alertes si el servei DNS Server s’atura.
2. Log d’esdeveniments crítics (ID 4010, 4004, 4013) que indiquen problemes amb la inicialització o replicació de zones.
3. Mètriques bàsiques: nombre de consultes, temps de resposta, errors de resolució.

8. Consideracions en entorns híbrids i Azure

Si tens un túnel VPN amb Azure o estàs en un entorn híbrid, val la pena recordar:

1. No posis els DNS d’Azure (168.63.129.16) com a forwarders directament. És una IP reservada per als serveis de plataforma, no per a resolució general.
2. En entorns híbrids, fes servir un servidor DNS a Azure (per exemple, una VM amb Windows Server) i configura’l com a reenviador en local si necessites resoldre noms d’Azure Private Link o zones privades DNS.

9. Automatitzar neteja i manteniment de zones DNS

Una de les tasques més ingrates del DNS és lidiar amb registres obsolets. Si scavenging està ben configurat, neteja una part, però hi ha molts registres que no tenen la casella d’eliminar automàticament, i aquí és on els scripts ajuden.

Script per identificar registres A sense PTR i viceversa

No sempre tens una correspondència 1: 1 entre A i PTR. Això pot indicar una configuració inconsistent, problemes amb DHCP, o simplement que algú es va saltar els passos en crear les zones.

# Paràmetres
$zoneName = "miempresa.local"
$reverseZone = "0.168.192.in-addr.arpa"  # Ajustar según el rango usado

# Obtenir registres A
$aRecords = Get-DnsServerResourceRecord -ZoneName $zoneName -RRType "A"

# Obtenir registres PTR
$ptrRecords = Get-DnsServerResourceRecord -ZoneName $reverseZone -RRType "PTR"

# Extreure IPs dels registres A
$ipListFromA = $aRecords | ForEach-Object {
    $_.RecordData.IPv4Address.IPAddressToString
}

# Extreure IPs dels registres PTR
$ipListFromPTR = $ptrRecords | ForEach-Object {
    [System.Net.IPAddress]::Parse(($_.HostName -replace '\.in-addr\.arpa$', '') -split '\.')[::-1] -join '.'
}

# Comparar i veure inconsistències
$onlyInA = $ipListFromA | Where-Object { $_ -notin $ipListFromPTR }
$onlyInPTR = $ipListFromPTR | Where-Object { $_ -notin $ipListFromA }

Write-Host "`nIPs con A pero sin PTR:"
$onlyInA

Write-Host "`nIPs amb PTR però sense A:"
$onlyInPTR

Aquest script no és per a fer-lo servir a diari, però sí com a part de revisions periòdiques en entorns on se sap que la neteja automàtica no està al 100 %.

10. Script per a registres vells (sense scavenging activat)

Quan scavenging no està activat per decisió d’arquitectura o per por a impactes col·laterals, pot ser útil buscar registres que no s’han actualitzat en mesos.

$zone = "empresa.local"
$cutoff = (Get-Date).AddDays(-90)

$records = Get-DnsServerResourceRecord -ZoneName $zone -ComputerName "." | Where-Object {
    $_.Timestamp -and $_.Timestamp -lt $cutoff
}

$records | Select-Object HostName, RecordType, Timestamp | Format-Table

Aquest script només retorna registres amb timestamp (és a dir, dinàmics) més vells de 90 dies. Amb això pots anar directe a revisar màquines que probablement ja no existeixen, però van deixar el seu rastre.

11. Verificació ràpida de zones delegades

Una causa habitual de fallades intermitents entre llocs és una mala delegació de zones secundàries o subzones.

Aquest petit script recorre subzones i prova la resolució des del servidor que les delega:

$parentZone = "seu1.empresa.local"
$subzones = @("seu2.empresa.local", "seu3.empresa.local")

foreach ($zone in $subzones) {
    Write-Host "`nProvant zona delegada: $zone"
    Resolve-DnsName -Name $zone -Server "192.168.10.10" -DnsOnly -ErrorAction SilentlyContinue | 
        Select-Object Name, Type, IPAddress
}

Si alguna cosa falla, retorna buit o llença un timeout, pots revisar amb dnscmd si el NS està mal apuntat o falta el registre glue.

12. Monitoritzar amb PowerShell + Registres d’esdeveniments

Alguns esdeveniments clau que cal tenir al radar i que pots convertir en tasques programades o alertes:

1. 4010: intent de registrar en una zona no autoritativa.
2. 4004: no es va poder carregar la zona des d’Active Directory.
3. 4013: DNS esperant que Active Directory s’iniciï (i es queda esperant).

Aquí un exemple bàsic per revisar esdeveniments del dia:

$dnsEvents = Get-WinEvent -LogName "DNS Server" -FilterHashtable @{Id=4013; StartTime=(Get-Date).AddDays(-1)} 
$dnsEvents | Format-Table TimeCreated, Id, Message -AutoSize

O bé, pots programar-lo i fer que t’enviï alertes per correu (si fas servir Send-MailMessage) quan apareguin certs esdeveniments més de X vegades per dia.

13. Validació periòdica de replicació de zones AD-Integrades

Aquest script no reemplaça a repadmin, però dona una visió útil de l’estat de replicació entre servidors DNS quan les zones estan integrades en AD.

$dnsServers = @("dc1.empresa.local", "dc2.empresa.local")
foreach ($server in $dnsServers) {
    Write-Host "`nValidant zones a: $server"
    Get-DnsServerZone -ComputerName $server | 
        Where-Object { $_.IsDsIntegrated } | 
        Select-Object -Property ZoneName, IsDsIntegrated, ReplicationScope
}

Et dona una visió ràpida de quines zones estan replicant, i en quin àmbit (tot el bosc, només servidors DNS, etc.). Si veus una diferència entre servidors, probablement tinguis una fallada de replicació o algú va crear la zona amb l’àmbit equivocat en un d’ells.

14. Automatitzar backups de zones DNS

Les zones no integrades en AD poden i s’ han d’ exportar de forma regular. Encara que sigui una pràctica cada vegada menys comuna, en entorns mixtos encara les veig.

$zones = Get-DnsServerZone | Where-Object { -not $_.IsDsIntegrated }
foreach ($zone in $zones) {
    $file = "C:\DNS-Backups\$($zone.ZoneName)_$(Get-Date -Format yyyyMMdd).dns"
    dnscmd /zoneexport $zone.ZoneName $(Split-Path -Leaf $file)
}

I si fas servir control de versions, és fàcil fer un diff entre dies i detectar canvis inesperats.

15. Bones pràctiques

Aquestes no venen en llibres ni en assistents, però m’han estalviat més d’una caiguda:

1. Mai delegar resolució externa des del DNS intern a Google/Cloudflare directament si hi ha split DNS. Millor, un resoldre intern amb control.
2. Sempre baixar el TTL dels registres clau (com els de balanceig o HA) a 5 minuts. I sempre pujar-lo a 1 hora en registres estàtics.
3. Verificar logs del client, no només del servidor DNS, quan alguna cosa no resol. Hi ha problemes de caixet local, sockets oberts, i errors en el qual windows que poden falsejar qualsevol diagnòstic.
4. Documentar l’ús de zones privades en entorns híbrids, perquè Azure DNS privat + VPN mal configurat és una font constant de sorpreses.
5. Tenir alertes de logs DNS al SIEM o eina de monitoratge, encara que sigui bàsica. DNS és l’origen de molts problemes subtils, i si no es mira, s’assumeix que “no va ser això”.

Conclusió pràctica

Aquest tipus d’automatitzacions i validacions són les que eviten que DNS es converteixi en una caixa negra. El pitjor del DNS no és que falli, sinó que falli només de vegades. I això és el que més costa depurar. Per això, tenir eines que ajudin a veure patrons, detectar inconsistències i mantenir net l’entorn és més útil que qualsevol botó de l’assistent gràfic.

Configurar DNS a Windows Server no és només instal·lar el rol i crear una zona. L’estabilitat de l’entorn depèn de com estigui muntat el DNS més del que molts admeten. L’experiència ensenya que el que més temps consumeix no és el muntatge, sinó corregir el que es va deixar passar sense pensar-ho dues vegades.

Qui ha hagut de perseguir errors de replicació durant hores només per descobrir que el problema estava en un DNS mal delegat, ho sap. L’objectiu no és només que funcioni avui, sinó que no doni sorpreses d’aquí sis mesos.