DNS i DHCP en xarxes corporatives distribuïdes

Aquesta pàgina complementa les unitats de DNS i DHCP amb un cas d'ús real: com dissenyar aquests dos serveis quan l'organització no té una única seu, sinó una xarxa corporativa distribuïda en diverses ubicacions (per exemple, 10 seus connectades per WAN/SD-WAN a un datacenter central o al núvol).

Els criteris canvien respecte a un escenari d'una sola seu: cal decidir on viu la intel·ligència del servei (centralitzada, distribuïda o híbrida), quina és la dependència de la WAN, i com es manté la coherència de la configuració (rangs IP, zones, polítiques de seguretat) entre totes les ubicacions.

Visió general de l'arquitectura

El diagrama mostra el patró recomanat: el Grid Master (Infoblox) i el DNS Primari viuen al datacenter central, mentre que cada seu manté un DNS Secundari local (rèplica de les zones per AXFR/IXFR) i un Firewall/Router que pot fer de DHCP Relay cap al centre o bé oferir DHCP en local, segons la fiabilitat de la WAN i la criticitat de la seu (vegeu les seccions següents). Pots obrir el diagrama en mode edició (icona de la cantonada) per adaptar-lo al teu propi escenari.

El problema de fons: centralitzar vs distribuir

Amb 10 seus, dues estratègies oposades són possibles per a qualsevol servei d'infraestructura:

Cap dels dos extrems és la resposta correcta per a tots els casos: la decisió depèn de la fiabilitat de la WAN (MPLS redundant, SD-WAN amb dos operadors, o una única línia ADSL de baix cost) i de la criticitat de cada seu (una botiga que no pot facturar sense xarxa no és el mateix que una oficina administrativa).

Disseny de DNS multi-seu

Topologia recomanada

Per a un DNS intern corporatiu amb diverses seus, el patró habitual és:

flowchart TB
    subgraph DC[Datacenter Central / Núvol]
        M[DNS Primari<br/>Zones mestres]
    end

    subgraph S1[Seu 1]
        S1DNS[DNS Secundari local<br/>+ Cache]
    end
    subgraph S2[Seu 2]
        S2DNS[DNS Secundari local<br/>+ Cache]
    end
    subgraph S10[Seu 10]
        S10DNS[DNS Secundari local<br/>+ Cache]
    end

    M -->|Transferència de zona AXFR/IXFR| S1DNS
    M -->|Transferència de zona AXFR/IXFR| S2DNS
    M -->|Transferència de zona AXFR/IXFR| S10DNS

    S1DNS -.->|Forwarder si cal resoldre extern| M
    S2DNS -.->|Forwarder si cal resoldre extern| M
    S10DNS -.->|Forwarder si cal resoldre extern| M

Per què un secundari local a cada seu i no només un forwarder cap al central? Perquè si un secundari té una còpia local de la zona, la seu continua resolent els seus propis noms (impressores, servidors locals, controladors de domini) encara que la WAN caigui. Un forwarder pur, en canvi, deixa la seu completament cega a la resolució de noms interns si el link falla.

Resolució externa: un únic servidor intermedi controlat

Un error de disseny freqüent és deixar que cada servidor DNS intern (el primari, cada secundari de seu, cada controlador de domini) resolgui noms d'Internet directament, contactant ell mateix amb els servidors arrel o amb resolvers públics (8.8.8.8, 1.1.1.1...). Això multiplica el nombre de punts que surten cap a Internet: cadascun és una possible via de fuita de dades (un DNS és un canal habitual per a exfiltració i per a comunicacions de malware C2, ja que gairebé mai es filtra) i cap d'ells queda protegit pel mateix filtratge si no es configura repetidament pertot arreu.

La pràctica recomanada és exactament la mateixa lògica que ja apliquem amb el DHCP Relay: un únic servidor (o una parella en alta disponibilitat) fa d'intermediari cap a l'exterior, i és l'únic autoritzat a fer-ho:

flowchart TB
    I[Internet]

    subgraph DC[Datacenter Central]
        FWD[Forwarder DNS extern<br/>únic punt de sortida]
        M[DNS Primari<br/>Zones mestres]
    end

    subgraph S1[Seu 1]
        S1DNS[DNS Secundari local]
    end
    subgraph S2[Seu 2]
        S2DNS[DNS Secundari local]
    end

    M -->|Consulta externa| FWD
    S1DNS -->|Consulta externa| FWD
    S2DNS -->|Consulta externa| FWD

    FWD -->|"Únic servidor amb sortida a Internet<br/>(permès pel tallafoc)"| I

En la pràctica:

• Cap servidor DNS intern (ni els DC, ni els secundaris de seu) té recursion activada cap a l'exterior ni forwarders apuntant a resolvers públics: tots reenvien (forwarders) exclusivament cap a aquest servidor intermedi.
• El tallafoc només permet trànsit sortint UDP/TCP 53 cap a Internet des de la IP d'aquest forwarder concret — la resta de servidors DNS interns tenen el port 53 sortint bloquejat cap a fora.
• Aquest únic forwarder és el lloc idoni per aplicar DNS Firewall/RPZ, DoH/DoT cap als resolvers upstream, i tot el logging de consultes externes: en comptes de vigilar N servidors, només cal vigilar-ne un.
• Si cal alta disponibilitat, es desplega com a parella (actiu/actiu o actiu/passiu), però segueix sent un rol clarament diferenciat de la resta de servidors DNS, no "qualsevol servidor pot sortir a Internet si cal".

Split-horizon (Split-brain DNS)

Quan la mateixa organització necessita respostes diferents segons si la consulta ve de dins o de fora de la xarxa (per exemple, intranet.empresa.cat només ha de resoldre's internament), s'utilitzen vistes (BIND view) o DNS Policies (Windows Server) — vegeu la configuració pràctica a les pàgines de BIND9 Linux i DNS Windows. En un entorn de 10 seus això s'aplica típicament a nivell central, i cada secundari de seu hereta la vista que li correspon segons la seva subxarxa.

Seguretat en un DNS distribuït

• DNSSEC a les zones internes crítiques, per evitar spoofing entre seus.
• DNS Firewall / RPZ (Response Policy Zones): llistes negres de dominis maliciosos aplicades de forma centralitzada i heretades per tots els resolvers de totes les seus — evita haver de configurar el filtratge seu per seu.
• DoH/DoT cap als forwarders externs, per xifrar les consultes que surten cap a Internet des de qualsevol seu.
• Restringir allow-transfer perquè només els secundaris legítims de cada seu puguin rebre còpies de les zones.

DNS d'Active Directory quan hi ha una DMZ

Un cas particularment delicat és quan l'organització té serveis exposats a Internet (web, correu, reverse proxy) allotjats en una DMZ, i alhora un domini d'Active Directory intern. La pregunta és: com ha de resoldre noms la DMZ sense convertir-se en una porta d'entrada cap a l'AD?

flowchart LR
    I[Internet] --> RP[Servidor públic<br/>Web / Correu / Reverse Proxy]

    subgraph DMZ[DMZ]
        RP
        DNSD[DNS de la DMZ<br/>Resolver / Forwarder]
    end

    RP --> DNSD

    DNSD -->|Consultes públiques| I
    DNSD -.->|"Només si cal (regla molt restrictiva,<br/>mai AXFR)"| FW

    subgraph FW[Tallafocs]
    end

    subgraph LAN[Xarxa interna]
        DC[Controlador de Domini<br/>+ DNS d'AD]
    end

    FW -.-> DC

Principis de la configuració més segura:

1. Dues zones DNS completament separades. La zona pública (empresa.cat, amb els registres A/MX/TXT que necessita el món exterior) no ha de viure mai al mateix servidor DNS que la zona interna d'AD. La zona d'AD conté informació molt sensible per a un atacant (registres SRV com _ldap._tcp.dc._msdcs.empresa.local, que revelen exactament on són els controladors de domini).

2. La DMZ no ha de resoldre mai directament contra el DNS d'AD. Cal un DNS propi dins la DMZ (un simple resolver/forwarder) que:

   • Resolgui noms públics reenviant cap a Internet.
   • Si —i només si— cal resoldre algun nom intern puntual, ho faci mitjançant una conditional forwarding molt restrictiva (un únic registre, no la zona sencera), mai apuntant directament al DNS d'AD sense passar pel tallafoc.

3. Els servidors de la DMZ, idealment, no han de ser membres del domini AD. Un servidor de la DMZ compromès que NO és membre del domini no dona a l'atacant credencials ni tiquets Kerberos reutilitzables cap a l'interior. Si cal integració (SSO, autenticació), la millor pràctica és un bosc de recursos (resource forest) separat amb una confiança unidireccional cap al bosc intern, en lloc d'unir la DMZ directament al domini de producció.

4. Tallafocs estricte entre DMZ i xarxa interna per al port 53:

   • Bloquejar per defecte tot el trànsit DNS (UDP/TCP 53) de la DMZ cap a l'interior.
   • Si cal alguna consulta puntual, permetre-la només des del resolver de la DMZ cap a una IP concreta del DNS intern, mai des de qualsevol host de la DMZ.
   • Mai permetre transferències de zona (AXFR/IXFR) cap a la DMZ.

5. Desactivar la recursió cap a Internet als controladors de domini. Els DC no haurien de resoldre noms externs directament; han de reenviar (forward) cap a un resolver intern controlat, que al seu torn ho faci a través del tallafoc. Això evita que un DC comprometès pugui exfiltrar dades disfressades de consultes DNS directament cap a l'exterior.

6. Split-horizon per al domini públic, si cal que resolgui diferent des de dins que des de fora (per exemple, www.empresa.cat apuntant a una IP interna quan es consulta des de la LAN, i a la IP pública/DMZ quan es consulta des de fora).

DDNS: actualització dinàmica del DNS des del DHCP

Amb centenars de dispositius obtenint IP per DHCP a cada seu, mantenir manualment els registres A/PTR del DNS és inviable. La solució és el DDNS (Dynamic DNS, RFC 2136): un mecanisme que permet crear o actualitzar registres DNS automàticament, sense editar la zona a mà, normalment disparat pel propi procés DHCP.

Qui fa l'actualització?

• El client la fa ell mateix (comportament clàssic dels clients Windows): el client actualitza el seu propi registre A, i sol·licita al servidor DHCP que actualitzi el PTR corresponent (opció FQDN del DHCP, RFC 4702).
• El servidor DHCP la fa en nom del client (recomanat en xarxes heterogènies): el servidor DHCP actualitza tant l'A com el PTR cada vegada que assigna o renova un lease. És l'única opció viable per a dispositius que no saben fer DDNS (IoT, impressores, molts equips Linux/embedded), i dona un comportament consistent independentment del tipus de client.

sequenceDiagram
    participant Client
    participant DHCP as Servidor DHCP
    participant DNS as Servidor DNS

    Client->>DHCP: DHCP Request
    DHCP-->>Client: DHCP ACK (IP assignada)
    DHCP->>DNS: Actualització dinàmica (DDNS)<br/>Crea/actualitza registre A i PTR
    DNS-->>DHCP: Confirmació

La part crítica: securitzar l'actualització. Un DDNS obert (qualsevol equip pot crear o sobreescriure qualsevol registre) és una porta d'entrada directa a atacs de suplantació i enverinament de zona — no és gaire diferent d'un rogue DHCP, però contra el DNS. Cal:

• A Active Directory, fer servir sempre "Secure only" a la zona (mai "Nonsecure and secure"): les actualitzacions s'autentiquen amb Kerberos/GSS-TSIG i només equips membres del domini poden actualitzar el seu propi registre.
• A BIND9 (Linux), restringir allow-update amb claus TSIG (mai allow-update { any; };), de manera que només el servidor DHCP (ISC DHCP o Kea, amb el mòdul dhcp-ddns) autenticat amb la clau correcta pugui escriure a la zona.
• Mai activar DDNS obert en una zona accessible des de la DMZ o des de xarxes no fiables — coherent amb el que ja hem vist a l'apartat de la DMZ: si un atacant hi pot escriure, pot desviar trànsit legítim cap a una IP maliciosa sense necessitat de cap altre atac de xarxa.

La configuració pràctica (opcions DNS del DHCP a Windows Server, i ddns-update-style/claus TSIG a ISC DHCP i Kea) es tracta a les pàgines d'instal·lació de DHCP Windows, ISC DHCP Linux i Kea DHCP Linux.

Disseny de DHCP multi-seu: relay centralitzat vs local

Aquesta és la decisió amb més impacte pràctic. Hi ha dues opcions:

Opció A — DHCP Relay cap a un servidor central

Cada router/firewall de seu actua només com a DHCP Relay Agent (ip helper-address a Cisco, o l'equivalent al firewall), reenviant les peticions DORA cap a un servidor DHCP central que té un àmbit (scope) definit per a cada subxarxa de seu.

Avantatges:

• Un únic punt de gestió: àmbits, reserves i opcions es configuren una sola vegada.
• Consistència garantida entre seus (no hi ha risc de rangs solapats o opcions divergents).

Inconvenients:

• Dependència total de la WAN: si el link de la seu cau, els clients nous no poden obtenir IP (els que ja en tenen poden seguir usant-la fins que expira el lease, i sovint aconsegueixen renovar-la per unicast si el servidor és accessible per una altra ruta, però no sempre).
• Latència afegida en cada DORA (petit impacte, normalment negligible amb una WAN raonable).
• El servidor central esdevé un punt únic de fallada per a totes les seus si no té alta disponibilitat (failover).

Opció B — DHCP local, delegat al firewall/router de cada seu

Cada seu té el seu propi servei DHCP (al firewall, al router, o a un servidor local), amb el seu àmbit gestionat de forma independent.

Avantatges:

• Resiliència total: la seu és autònoma encara que caigui la WAN.
• Sense latència de relay.

Inconvenients:

• Gestió descentralitzada: 10 configuracions a mantenir, amb risc real de rangs IP solapats si no hi ha un IPAM que ho controli.
• Sense una eina centralitzada, perds visibilitat global (quantes IPs lliures queden a la seu 7? qui té reservada la 192.168.7.50?).

Recomanació pràctica

En la majoria de desplegaments corporatius amb ~10 seus, la resposta no és "tot centralitzat" ni "tot distribuït", sinó:

1. Fer DHCP local a cada seu (al firewall/router, que ja hi és per fer de gateway) per garantir que una seu no queda sense xarxa si cau la WAN. Això és especialment important si la seu és operativa (botiga, magatzem, planta) i no només administrativa.
2. Centralitzar la gestió i el registre dels rangs mitjançant un IPAM, encara que el servei DHCP en si sigui local — així s'evita el solapament de subxarxes i es té visibilitat global sense sacrificar la resiliència.
3. Reservar el DHCP Relay pur (Opció A) per a seus petites, poc crítiques, amb una WAN molt fiable (SD-WAN redundant) on no val la pena l'esforç operatiu de mantenir un servei local.
4. Si el pressupost ho permet, valorar DHCP Failover (parelles de servidors en mode load-balance o hot-standby) allà on el DHCP sigui centralitzat, per eliminar el punt únic de fallada.

El paper d'una solució DDI: Infoblox

Gestionar 10 seus amb BIND9/ISC DHCP "a mà" (fitxer per fitxer, seu per seu) escala malament. Per això, en entorns corporatius de mida mitjana-gran s'acostuma a introduir una solució DDI (DNS, DHCP, IPAM) com Infoblox, que resol exactament el dilema "centralitzat vs distribuït":

• Grid Master + Grid Members: Infoblox permet desplegar un Grid Member (una appliance física, virtual, o al núvol) a cada seu, que executa el DNS i el DHCP localment (per tant, resilient a talls de WAN), però la seva configuració es defineix i es distribueix des d'un Grid Master central. És, en essència, "distribuït en execució, centralitzat en gestió".
• IPAM centralitzat: un únic mapa de totes les subxarxes i rangs de totes les seus, amb detecció automàtica de solapaments i d'IPs no gestionades ("IP discovery").
• DHCP Failover natiu entre Grid Members, sense necessitat de configurar-ho manualment servidor a servidor.
• DNS Firewall (RPZ) centralitzat, aplicat automàticament a tots els Grid Members de totes les seus.
• Auditoria i reporting unificats de tots els canvis de configuració a totes les ubicacions.

Alternatives amb un enfocament similar (DDI comercial) són BlueCat i Men&Mice/Micetro. Per a organitzacions amb pressupost més ajustat, es pot construir un equivalent amb eines obertes: Kea DHCP o ISC DHCP + BIND9/PowerDNS per servei, combinat amb NetBox com a IPAM/font de veritat, tot i que llavors l'orquestració entre seus (desplegar canvis a tots els Grid Members equivalents) s'ha de resoldre amb eines pròpies d'automatització (Ansible, per exemple) en lloc de venir integrada de fàbrica.

Taula resum de decisió

Referències

• Infoblox — Grid Architecture
• RFC 2131 — Dynamic Host Configuration Protocol (procés DORA i DHCP Relay)
• RFC 1035 — Domain Names, Implementation and Specification (transferències de zona)
• BlueCat Networks
• NetBox — IPAM/DCIM de codi obert