A gairebé totes les xarxes que ens trobem hi ha dues adreces de DNS configurades, i a gairebé totes es dona per fet el mateix: que la segona hi és per quan la primera falli. La documentació de Microsoft és més precisa que això. Diu que «el client prova servidors nous només si els anteriors són inabastables», i que qualsevol resposta de nom inexistent atura el procés sense reintentar amb el següent. Llegeix-ho dues vegades, perquè canvia el disseny: la teva segona entrada cobreix el silenci. No cobreix l'error.
Una hora d'oficina per un nombre enter
L'11 d'octubre, a les 16:40 UTC, el servei de DNS de pagament de Control D va deixar de contestar. No en una regió: a totes les seves ubicacions, per tots els protocols i en tots els dispositius, segons el seu propi informe. Les consultes dels clients de pagament es van quedar sense resposta des de les 16:42. La recuperació va començar a les 17:31 i va quedar completa a les 17:35. El servei gratuït va continuar funcionant tota l'estona.
La causa, explicada per ells sense ornaments: una actualització de la seva API del 16 de setembre havia començat a desar una anul·lació per domini com a nombre enter on el programari de DNS esperava text. El canvi feia gairebé un mes que hi era sense molestar ningú, perquè encara ningú no havia desat cap d'aquells ajustos. L'11 d'octubre algú el va desar per primera vegada, el valor es va propagar de cop a tots els servidors de DNS del pla de pagament, i una fallada en la gestió d'errors va fer que el programari s'aturés en comptes de saltar-se el valor que no sabia llegir. El que van arreglar després ho expliquen igual de clar: ara els valors il·legibles s'aparten i es registren en comptes d'aturar el servei, l'API torna a desar text, i la configuració passarà a desplegar-se per fases, com ja feien amb el programari.
Ens interessa una cosa d'aquell paràgraf, i no és el bug. És que el canvi que va trencar el servei no era programari: era configuració, i la configuració no passava pel desplegament per fases que sí que tenia el codi. És exactament el mateix repartiment que hi ha a la majoria de les cases: el codi va amb revisió, proves i finestra; l'ajust va en calent i a tot arreu. Ells ho han corregit. La pregunta honesta és quants de nosaltres podem dir el mateix.
El rellotge que no mira ningú
Tot post-mortem explica el que va trencar el proveïdor. Cap no explica el que va fer la teva xarxa durant aquells 54 minuts, i això és el que decideix si la teva gent va notar un parpelleig o es va quedar mirant la pantalla. Aquella part també està escrita, només que en un document de suport que no surt a cap titular. Windows, amb dos servidors DNS configurats a l'adaptador, es comporta així:
La bona notícia és aquell 1: si el primari es queda callat, Windows passa al segon en un segon, i una oficina normal gairebé no ho nota. La dolenta és tota la resta. Si tens tres o més servidors apuntats, el quart i següents no es pregunten fins als 4 segons —la documentació mateixa avisa que, si l'únic abastable és a la posició 4 o posterior, hi ha un retard mínim de 4 segons i una aplicació amb un temps d'espera més curt fallarà sense que el DNS estigui caigut—. I a Linux el compte és pitjor de sèrie: el resolver de glibc espera 5 segons per servidor abans de passar al següent, amb dos intents per defecte i un màxim de tres servidors llegits de >/etc/resolv.conf. Un resolver mut hi costa cinc segons per consulta, i hi ha aplicacions que resolen desenes de noms per pintar una pantalla.
Aquells cinc segons porten una excepció grossa, i convé dir-la abans que algú la faci servir en una reunió: són els del resolver de glibc parlant amb servidors reals. En un Ubuntu o un Fedora de sèrie, /etc/resolv.conf apunta a 127.0.0.53 i qui decideix és systemd-resolved, que porta el seu propi compte de reintents i la seva pròpia llista; allà el que val és el que digui resolvectl status, i els temps no són aquests. Mira-ho abans de donar per bona cap de les dues xifres al teu parc.
Hi ha un detall més que canvia el disseny. Quan el client de Windows es passa al servidor altern, s'hi queda fins que aquell altern falli o fins que venci >ServerPriorityTimeLimit, que són 15 minuts per defecte. És a dir: el proveïdor es recupera a les 17:35 i els teus equips poden continuar preguntant al segon servidor fins a un quart d'hora després. Per a disponibilitat és assenyat —evita anar i venir—. Per a una política de filtratge, com veurem, és just al contrari.
El silenci es cobreix; l'error, no
Aquí hi ha el cor de l'assumpte, i no és opinió nostra. El document de temps d'espera de Microsoft ho diu en dues frases seques, vàlides per a qualsevol client de Windows: «qualsevol resposta de nom inexistent farà que el procés s'aturi: el client no reintenta amb el següent servidor si la resposta va ser negativa» i «el client prova servidors nous només si els anteriors són inabastables». A la guia de recomanacions hi ha la versió llarga —«només una fallada en respondre farà que el client DNS canviï de servidor preferit; rebre una resposta autoritativa però incorrecta no fa que el client provi un altre servidor»—, escrita pensant en controladors de domini, però apuntant al mateix: el disparador de la commutació és el silenci, mai el contingut.
Traduït al que passa un dimarts a les nou: si el teu resolver contesta >NXDOMAIN al nom del teu ERP perquè una llista de filtratge es va passar de rosca, o torna una adreça vella perquè una zona no va replicar, el segon servidor no hi entra. No hi ha commutació. No hi ha alerta, perquè el port 53 respon i la teva monitorització ho veu verd. El que hi ha és gent que no pot treballar i un servei que, tècnicament, està disponible. Aquesta és la fallada que la redundància que vas comprar no cobreix. En el que ens arriba a nosaltres apareix més vegades que una caiguda global d'un proveïdor, encara que no tenim xifres públiques que ho sostinguin: pren-t'ho com el que és, una impressió de taller.
Dues adreces, un sol pla de configuració
Torna a l'11 d'octubre amb això al cap. El valor dolent es va propagar a tots els servidors del pla de pagament alhora. Si tenies les dues adreces d'aquell proveïdor apuntades al DHCP —que és exactament el que recomana qualsevol guia d'instal·lació—, no tenies dos servidors: tenies dues portes al mateix lloc. El repartiment geogràfic d'anycast et dona diversitat de camí, que és real i serveix per a un tall de fibra o per a un node caigut. No et dona diversitat de configuració, i la fallada d'aquell dia va ser de configuració.
No és un cas aïllat ni un proveïdor petit fent-ho malament. El 14 de juliol del 2025, el resolver públic 1.1.1.1 de Cloudflare va deixar de servir la majoria dels seus usuaris durant 62 minuts, de 21:52 a 22:54 UTC. La causa: un error de configuració intern introduït el 6 de juny que va estar més de cinc setmanes latent, sense efecte, fins que un altre canvi al mateix servei el va activar i va retirar globalment els prefixos del resolver. Les seves paraules: «aquesta caiguda va ser el resultat d'un error de configuració intern i no d'un atac ni d'un segrest BGP». En tots dos casos el canvi feia setmanes que estava desat sense fer res, i quan es va activar ho va fer a totes les ubicacions al mateix temps, que és justament el que el repartiment geogràfic no pot evitar.
Aquesta forma ja l'hem explicada dues vegades des d'altres angles, perquè es repeteix en capes diferents de la mateixa xarxa: quan la fallada és al cervell i no a les potes, el pla de control és el primer que cau; i a la factura de telefonia, on dos operadors a la factura poden ser un sol nucli a la xarxa. Canvia la tecnologia; la pregunta és sempre la mateixa: què comparteixen de debò els meus dos camins?
Quan NO cal posar un segon proveïdor
El reflex després de llegir tot l'anterior és posar un resolver públic d'una altra casa com a segona entrada de l'adaptador. En un domini d'Active Directory això és un error, i tampoc no ho diem nosaltres: «no configuris els ajustos de DNS del client perquè apuntin als servidors DNS del teu proveïdor d'Internet. Si ho fas, pots tenir problemes en intentar unir el servidor al domini o en iniciar sessió al domini des d'aquell equip. En lloc d'això, el servidor DNS intern ha de configurar el reenviament als servidors DNS del proveïdor per resoldre noms externs.»
A aquell motiu hi afegim el nostre, que és de seguretat i poques vegades es diu en veu alta. Si pagues un DNS que filtra —i hi ha qui el paga sense saber-ho, perquè ve dins d'un altre producte—, posar al costat un resolver públic sense filtrar és documentar el teu propi camí d'evasió. I ara ajunta les dues peces d'aquest post: un parpelleig d'un segon n'hi ha prou perquè l'equip es passi a l'altern, i un cop allà s'hi queda fins a 15 minuts. Un microtall a les 9:03 pot deixar un lloc de treball resolent fora de la teva política fins a les 9:18, sense que ningú se n'assabenti i sense una sola línia a cap registre.
On va la redundància, llavors: al resolver que controles tu. Dos resolutors interns, cadascun amb reenviament a dos proveïdors independents o als servidors arrel. El client veu dues adreces internes i una sola política; la diversitat de proveïdor viu a la capa on la pots raonar, mesurar i canviar en calent sense tocar 200 llocs de treball. I l'excepció honesta, perquè existeix: si ets una empresa de vuit persones sense servidor propi, dos resolutors públics al DHCP és un compromís raonable. L'única cosa que demanem és que sigui una decisió escrita —«acceptem que el filtratge és de millor esforç»— i no un descuit que descobreixes el dia de l'incident.
La comprovació de quinze minuts
Això es contesta avui, amb el que ja tens instal·lat i sense comprar res. Comença per mirar el que de debò reparteix el teu DHCP, no el que creus que reparteix:
# Windows: la lista real y su orden, por interfaz
Get-DnsClientServerAddress -AddressFamily IPv4
# Linux: si resolv.conf apunta a 127.0.0.53, la lista buena es la segunda
cat /etc/resolv.conf
resolvectl status
# Cuánto tarda cada resolver, uno por uno
for s in 10.0.0.1 10.0.0.2; do
echo -n "$s "
dig +tries=1 +time=2 @$s everywan.com +noall +stats | grep "Query time"
done- Escriu la llista per seu, en ordre. Una taula de tres columnes: adreça, qui l'opera i —la que ningú no omple— qui controla el seu pla de configuració. Dues adreces del mateix proveïdor són una entrada en aquella tercera columna, per molt que estiguin a continents diferents.
- Mesura el silenci, no el suposis. Bloqueja el primari al tallafocs del lloc de treball (una regla que descarti udp/53 cap a aquella adreça) i cronometra una resolució real amb la memòria cau buida, que si no mesuraràs la cau i et sortirà zero:
Clear-DnsClientCache; Measure-Command { Resolve-DnsName el-teu-erp.intern }a Windows,time getent hosts el-teu-erp.interna Linux (i comprova abans si tens nscd o resolved cachejant per sota). El número que surti és el que notarà la teva gent. - Compara les respostes, no només que responguin. Pregunta el mateix nom intern a cada resolver de la llista i posa els resultats l'un al costat de l'altre. Si un torna una adreça i un altre un nom inexistent, acabes de trobar la fallada que la teva segona entrada no cobreix, i l'has trobada un dia tranquil en comptes d'un dilluns a les nou.
- Alerta sobre la resposta. La comprovació que val és «aquest nom resol a aquesta adreça des d'aquesta seu», no «el port 53 contesta». Nosaltres monitoritzem amb Zabbix i SmokePing, i la regla de la casa és que una alerta ha de fer mal: aplicada al DNS, això vol dir comprovar el registre que torna, no que el port contesti. La caiguda silenciosa la veu qualsevol; la resposta equivocada no la veu ningú.
- Decideix i escriu què vols quan el teu resolver no sàpiga contestar. O no contesta i l'oficina s'atura, o contesta sense filtrar i perds la política durant l'incident. No hi ha tercera opció, i la decisió no és tècnica: és del negoci. El greu no és triar l'una o l'altra, és arribar a l'incident sense haver triat.
On encaixa això en el que fem
Operem xarxa pròpia —amb BGP, trànsit i peering—, i d'allà surt aquest post: la part difícil del DNS mai no ha estat muntar-lo, sinó decidir què passa quan contesta malament i tenir manera d'assabentar-te'n. És el que fem a xarxes i comunicacions, i gairebé sempre comença per la mateixa pregunta avorrida: a qui pregunta de debò cada seu, i on és posada la diversitat. Poques vegades és on diu el plànol.
Si vols que fem junts la taula de tres columnes de les teves seus i mesurem de debò quant costa un resolver callat als teus llocs de treball, en parlem. És una tarda. Si surt que ja estava ben muntat, t'ho diem i aquí no ha passat res.
Fonts. Les dates, la durada, l'abast i la causa de l'incident de l'11 d'octubre del 2026 (16:40–17:35 UTC; consultes sense resposta des de les 16:42; restauració iniciada a les 17:31; afectats tots els plans de pagament a totes les ubicacions i protocols, no el servei gratuït; actualització de l'API del 16 de setembre que desava l'anul·lació per domini com a enter en comptes de text; fallada de gestió d'errors que aturava el servei en lloc de saltar-se el valor; i les mesures posteriors) procedeixen de l'informe públic de l'incident publicat per Control D. Els temps d'espera del client DNS de Windows (0-1-2-4-8-10 segons, el comportament amb un, dos i tres o més servidors, i l'avís sobre els servidors en posició 4 o posterior) són a «DNS client resolution timeouts» de Microsoft Learn. Les dues citacions sobre quan canvia de servidor el client, el valor per defecte de 15 minuts de ServerPriorityTimeLimit i la recomanació de no apuntar els clients als DNS del proveïdor d'Internet sinó usar reenviament des del DNS intern són a «Recommendations for DNS client settings», del mateix lloc. Els valors per defecte del resolver de glibc —temps d'espera de 5 segons, 2 intents i un màxim de tres servidors— són a la pàgina de manual resolv.conf(5). La caiguda d'1.1.1.1 del 14 de juliol del 2025 (62 minuts, de 21:52 a 22:54 UTC, amb l'error de configuració introduït el 6 de juny i la citació sobre que no va ser un atac ni un segrest BGP) és a l'informe públic de Cloudflare. Les traduccions de les citacions són nostres. Són criteri nostre, i no afirmacions de cap d'aquelles fonts: la lectura que el pla de configuració d'un proveïdor és un domini de fallada compartit per les seves adreces, la conseqüència d'ajuntar el canvi a servidor altern amb els 15 minuts de permanència en una política de filtratge, la recomanació de posar la diversitat de proveïdor al reenviament i no a l'adaptador, i la comprovació de quinze minuts. everyWAN presta serveis gestionats de xarxa i seguretat: el conflicte d'interès queda declarat. No revenem ni som partner de cap dels proveïdors de DNS esmentats. Foto de portada: «The inside of a wiring closet at a small public university, 2014», de SnopdouS, Wikimedia Commons, CC0 1.0.
Microsoft 365
ES 
CAT 
EN