DNSSEC i la seguretat del DNS a la teva xarxa local

Informatec Digital » Recursos » DNSSEC i la seguretat del DNS a la teva xarxa local

Internet se sosté sobre un grapat de peces clau que gairebé mai veiem, però que hi són cada vegada que obrim el navegador. Una de les més importants és el sistema de noms de domini, i quan parlem de DNSSEC i seguretat en una xarxa local , en realitat estem parlant de blindar aquest fonament per evitar redireccions fraudulentes, suplantacions i altres atacs força seriosos.

Abans la prioritat era que tot funcionés i punt; avui sabem que amb això no n'hi ha prou. El DNS va néixer als anys 80 sense pensar en ciberatacs massius, però ara necessitem que, a més de resoldre noms, validi l'autenticitat i la integritat de cada resposta . Aquí és on entra en joc DNSSEC i, més recentment, propostes com E-DNSSEC que busquen afegir també confidencialitat, cosa clau si et preocupa la seguretat de la teva xarxa local o corporativa.

Què és el DNS i per què és tan crític per a la seguretat

El sistema DNS ( Domain Name System ) és l'agenda telefònica d'Internet: s'encarrega de traduir noms fàcils de recordar (com ara www.exemple.es) a adreces IP numèriques que entenen els equips (per exemple, 192.168.2.15 o una IPv6). Sense aquest mecanisme, hauríem de memoritzar números en lloc de noms, una cosa totalment impràctica.

Aquesta infraestructura s'organitza com una base de dades distribuïda en forma d'arbre , amb una zona arrel a la part superior, seguida de dominis de nivell superior (TLD com .es, .com, .org) i, a sota, dominis i subdominis. Cada porció d'aquesta base de dades s'anomena “ zona ” i s'allotja en un o més servidors de noms autoritatius, que són els que publiquen la informació “oficial” de cada domini.

Quan el teu ordinador, mòbil o qualsevol dispositiu vol accedir a una web, comença preguntant a un resolutor mínim (stub resoldre) , que forma part del sistema operatiu. Aquest resolutor envia la consulta a un servidor DNS recursiu (habitualment el del teu operador, de la teva empresa o un públic com Google Public DNS , OpenDNS o Quad9). Aquest servidor recursiu s'encarrega d'anar cercant la resposta preguntant a diversos servidors autoritatius fins a trobar la IP correcta.

Els resolutors recursius guarden en memòria cau les respostes que obtenen per accelerar les consultes següents. Això és molt eficient, però també obre la porta que un atacant pugui “enverinar la memòria cau” del DNS i colar dades falses , de manera que moltes peticions posteriors es resolguin amb aquesta informació manipulada sense que l'usuari ho noti.

El gran problema és que, en el disseny original, el DNS no té forma sòlida de verificar l'autenticitat de les respostes . El resolutor bàsicament comprova que la resposta sembla venir de la mateixa adreça IP a què va preguntar, però aquesta IP d'origen es pot falsificar (suplantar) amb relativa facilitat. Això permet atacs de redirecció silenciosa cap a llocs fraudulents que imiten, per exemple, la web del teu banc.

Limitacions de seguretat del DNS tradicional

El protocol DNS va ser creat en una època en què la seguretat no era una preocupació central. Per això, avui sabem que les consultes i respostes DNS viatgen en text clar , sense xifratge, i que les dades dels registres poden ser falsificades si no hi ha un mecanisme addicional de protecció.

Això obre la porta a diversos tipus d'atacs, entre els quals destaquen l' enverinament de memòria cau DNS (DNS cau poisoning) i els atacs d'intermediari (Man-in-the-Middle). En tots dos casos, l'atacant introdueix respostes falsificades en el camí, fent que els usuaris acabin a webs sota el seu control sense percebre res estrany, ja que el nom del domini mostrat al navegador continua sent el legítim.

Imagina't que accedeixes a la web del teu banc: el teu equip demana al servidor recursiu la IP del domini del banc, però un atacant ha aconseguit que aquest recursiu accepti una resposta falsa amb la IP d'una web idèntica però controlada per ell . L'usuari introdueix les seves credencials pensant que tot és normal, i el ciberdelinqüent les rep en clar per fer-les servir al lloc real després.

Hi ha mecanismes com TSIG (Transaction Signatures) , recollit al RFC 2845, que serveixen per protegir determinades operacions entre servidors DNS (per exemple, transferències de zona entre servidors mestre i esclau i actualitzacions dinàmiques). TSIG permet que dues màquines que comparteixen una clau secreta verifiquin la identitat de laltre extrem i la integritat dels missatges en trànsit.

Tot i això, TSIG té un abast molt limitat: no autentica l'origen “real” de les dades DNS , només assegura que l'intercanvi entre dos servidors concrets no ha estat manipulat. Si la informació original d'una zona ja s'ha compromès o s'ha manipulat abans d'arribar a aquests servidors, TSIG no ho detecta. Per això, encara que es fa servir de forma habitual per a les transferències de zona, no resol el problema de fons de l'autenticitat de les dades DNS publicades.

Què és DNSSEC i què aporta a la seguretat

Com a resposta a totes aquestes debilitats, es van desenvolupar les Extensions de Seguretat per al Sistema de Noms de Domini (DNSSEC, Domain Name System Security Extensions) . DNSSEC no reemplaça el DNS clàssic, sinó que l'amplia amb una capa de seguretat que permet verificar que les dades rebudes són legítimes i no han estat alterades.

DNSSEC es basa en criptografia de clau pública (criptografia asimètrica) . Cada zona DNS disposa d'un parell de claus: una clau privada, que es manté en secret, i una clau pública, que es publica al mateix DNS. El propietari de la zona utilitza la clau privada per signar digitalment els registres de la zona; la clau pública es fa servir per comprovar aquestes signatures.

Quan un servidor recursiu fa una consulta sobre un domini que utilitza DNSSEC, juntament amb la informació habitual (per exemple, la IP associada a un nom) rep també signatures digitals i claus públiques necessàries per a la seva validació . El servidor recursiu valida les signatures amb les claus públiques publicades; si la comprovació és correcta, les dades es consideren autèntiques i no modificades des que es van signar.

Si la validació falla, el resolutor entén que alguna cosa va malament (per exemple, un intent de suplantació o una manipulació en trànsit) i respon al client amb un codi derror, típicament SERVFAIL . D'aquesta manera, l'usuari no arriba a rebre dades potencialment malicioses, encara que des del punt de vista l'únic que veurà és que la pàgina “no carrega” o dóna error.

DNSSEC introdueix a més el concepte de cadena de confiança , que aprofita la jerarquia ja existent del DNS. La zona arrel signa les claus dels dominis de nivell superior (com .es, .com), signen les claus dels seus dominis secundaris, i així successivament, de manera que es pot validar qualsevol domini a partir d'un únic ancoratge de confiança: la clau pública de la zona arrel.

Claus KSK i ZSK, registres i cadena de confiança

Per organitzar millor la seguretat, DNSSEC utilitza dos tipus de claus diferents: la Key Signing Key (KSK) i la Zone Signing Key (ZSK) . Encara que tècnicament són iguals (criptogràficament parlant), la seva funció és diferent dins del sistema.

La clau ZSK és la que es fa servir per signar tots els registres de recursos de la zona (A, AAAA, MX, etc.). Se sol rotar amb certa freqüència per minimitzar riscos, ja que qualsevol compromís d'aquesta clau afectaria tots els registres de la zona. La KSK, en canvi, té com a comesa principal signar la pròpia clau de zona (ZSK), i la seva empremta digital (hash) és la que es publica com a registre DS (Delegation Signer) a la zona pare.

Gràcies a aquesta separació de rols, canviar la ZSK és més senzill: només cal generar una nova ZSK, signar-la amb la KSK, publicar-la als registres DNSKEY de la zona i deixar que els resolutors actualitzin la seva informació. No cal tocar la zona pare, ja que el DS segueix apuntant a la mateixa KSK, que roman estable durant més temps.

DNSSEC afegeix diversos tipus de registres específics al protocol DNS, destinats a suportar la signatura i la validació de dades. Entre els més importants es troben DNSKEY, RRSIG, DS, NSEC/NSEC3 i NSEC3PARAM . Tots permeten construir la lògica d'autenticació sense canviar el funcionament bàsic de les consultes.

El registre DNSKEY emmagatzema la clau pública de la zona necessària per verificar les signatures. El registre RRSIG conté la signatura digital associada a un conjunt de registres concret (un “Resource Record Set”). El registre DS és un hash de la DNSKEY de la zona filla que es publica a la zona pare i serveix com a anella a la cadena de confiança.

Els registres NSEC i NSEC3 s'utilitzen per proporcionar denegació d'existència autenticada ; és a dir, per demostrar criptogràficament que un nom de domini o un registre no existeix, evitant atacs en què s'intenten colar respostes falses indicant que alguna cosa no existeix quan en realitat sí que existeix (o al revés).

Cadena de confiança i validació de respostes DNSSEC

L'anomenada cadena de confiança en DNSSEC es construeix encadenant registres DNSKEY i DS des de l'arrel fins al domini que volem validar . El punt de partida és la clau pública de la zona arrel, que actua com a ancoratge de confiança i sol estar configurada directament als resolutors recursius.

Per exemple, si vols validar un domini com a miweb.es, el procés lògic seria: el resolutor confia en la clau pública de l'arrel, que signa la clau de .es; la zona .es publica un registre DS corresponent a la clau KSK de miweb.es; en validar aquest DS amb la clau de .es, el resolutor confia a la DNSKEY de miweb.es i, a partir d'aquí, pot verificar els RRSIG sobre tots els registres.

Si en algun punt d'aquest encadenat falta una signatura correcta o no hi ha el DS on caldria, la cadena de confiança es trenca. En aquest cas, el servidor recursiu que realitza la validació no considera les dades com a assegurances i, depenent de la seva configuració, o bé no respon amb els registres sol·licitats o bé marca la resposta com a no validada.

Aquesta relació jeràrquica implica també que, perquè DNSSEC sigui realment efectiu, no n'hi ha prou de signar únicament la teva zona : la zona pare (per exemple, .es) i l'arrel també han d'estar signades i amb els seus DS correctament publicats. Avui dia, la zona arrel del DNS i pràcticament tots els dominis genèrics de primer nivell (gTLD) i molts dominis de país (ccTLD) ja estan signats.

Quan un servidor recursiu amb validació DNSSEC activa detecta que la signatura no quadra o que hi falta alguna baula, la resposta que torna al client sol anar acompanyada d'un codi d'error RCODE SERVFAIL. Per a l'usuari final pot resultar confús (“la web no funciona”), però des del punt de vista de seguretat és una mesura de protecció davant de dades potencialment manipulades.

DNSSEC introdueix a més dues característiques clau: l' autenticació de l'origen de les dades , que permet comprovar que els registres procedeixen realment de la zona esperada, i la protecció de la integritat , que garanteix que la informació no s'ha modificat des que va ser signada pel propietari de la zona amb la clau privada.

Atacs que mitiga DNSSEC i relació amb TLS/HTTPS

Implementar DNSSEC ajuda a protegir davant de diversos tipus d'amenaces molt habituals. En primer lloc, dificulta enormement la suplantació de respostes DNS , ja que l'atacant hauria de generar firmes vàlides sense conèixer la clau privada de la zona, cosa criptogràficament inviable si les claus es gestionen correctament.

A més, DNSSEC redueix el risc d' enverinament de memòria cau en servidors recursius , en impedir que s'acceptin respostes manipulades que no superin la validació de signatura. També complica els atacs d'intermediari (MITM) sobre el trànsit DNS, en què un atacant modifica les respostes en trànsit: si la resposta no valida, el resolutor la descarta.

És important entendre, això sí, allò que DNSSEC no fa. Aquestes extensions no estan pensades per xifrar el contingut de les consultes ni de les respostes . Tot el trànsit DNS, fins i tot amb DNSSEC, segueix viatjant en text clar tret que utilitzis altres tecnologies complementàries (com DoT, DoH o propostes tipus E-DNSSEC). DNSSEC se centra que el que reps sigui autèntic i no hagi estat alterat, no a amagar allò que preguntes.

Això ho diferencia clarament de protocols com TLS i HTTPS . Mentre que HTTPS xifra el trànsit entre el navegador i el servidor web per evitar que tercers espiïn o modifiquin la comunicació, DNSSEC simplement signa les dades DNS per detectar falsificacions. Un lloc pot tenir HTTPS sense DNSSEC o DNSSEC sense HTTPS, però la combinació de tots dos ofereix una protecció molt més completa davant de suplantacions i espionatge.

Fa anys que organismes com la ICANN i la IETF impulsen l'adopció massiva de DNSSEC per part de registres, registradors, ISPs i operadors de xarxes. L'objectiu és que cada cop més zones estiguin signades i que més resolutors validin activament, de manera que l'usuari mitjà, sense fer res d'especial, es beneficiï d'aquestes garanties criptogràfiques.

DNSSEC en dominis .es i obligacions del propietari

En el cas concret d'Espanya, la unitat de Dominis .es gestionada per Red.es ha incorporat des de fa temps tecnologies i procediments addicionals per millorar la qualitat i la seguretat del servei DNS sota el codi de país .es. Entre aquestes mesures hi ha la implantació d'un protocol de seguretat DNSSEC d'acord amb les especificacions de la IETF.

Dominis .es s'encarrega de signar la zona de nivell superior .ES i d'obtenir l'autorització des de l'arrel del DNS, integrant-se així a la cadena de confiança global. Això significa que, si sou titulars d'un domini .es, podeu donar-vos suport en aquesta infraestructura per assegurar el vostre propi domini amb DNSSEC.

Com a propietari d'un domini, el procediment general per habilitar DNSSEC passa per assegurar-vos que els vostres servidors DNS autoritatius publiquen la zona signada. Normalment, això suposa generar una clau pública per a la teva zona, signar els registres, publicar la DNSKEY i, a continuació, enviar el material de la clau (o directament el registre DS) al registre o al teu registrador perquè creï el corresponent DS a la zona pare.

A la pràctica, molts proveïdors d'allotjament DNS i registradors ja ofereixen una opció força senzilla per activar DNSSEC, de vegades tan simple com marcar una casella al tauler de control. Això no obstant, pot existir un petit cost anual associat a aquesta funcionalitat, depenent del proveïdor i del nivell de servei.

Quan la zona està signada i el DS s'ha publicat correctament, el teu domini passa a formar part de la cadena de confiança de DNSSEC. Des d'aquest moment, les resolucions DNS del teu domini poden ser validades criptogràficament pels resolutors que tinguin activada la validació DNSSEC, cosa que augmenta la confiança dels teus usuaris i redueix el risc d'atacs de suplantació.

DNSSEC a la xarxa local: validació del costat de l'usuari

Des de la perspectiva de l'usuari final o d'una empresa preocupada per la seguretat de la xarxa local, la pregunta clau és: què cal per beneficiar-se de DNSSEC? La bona notícia és que no necessites configurar res a cada ordinador de forma individual , sempre que el teu servidor DNS recursiu (el que usen els teus equips) validi DNSSEC.

Per fer-ho, només cal que el proveïdor de DNS que utilitzes (el teu ISP, un resolutor públic o el DNS intern de la teva organització) tingui un servidor recursiu amb validació DNSSEC habilitada i correctament configurada . Pràcticament tots els resolutors moderns suporten DNSSEC des de fa anys; activar-lo sol implicar només uns quants canvis al vostre fitxer de configuració i la inclusió de l'ancoratge de confiança de l'arrel.

Un cop activada la validació, quan un dels teus equips a la xarxa local fa una consulta sobre un domini signat, el resolutor recursiu s'encarrega de verificar totes les firmes i la cadena de confiança abans de tornar la resposta. Si alguna cosa no quadra, no torna registres i l'usuari veu un error, cosa que a la pràctica li impedeix connectar amb un lloc possiblement fraudulent.

Per comprovar si el vostre domini està protegit per DNSSEC, hi ha diverses eines en línia, com DNSSEC Analyzer i altres utilitats de validació . En introduir el teu domini, hauries de veure registres com RRSIG (firmes criptogràfiques), DNSKEY (claus públiques) i DS (hash de la DNSKEY a la zona pare). Si l'eina indica que no hi ha signatura digital associada als registres, el vostre domini es considerarà “no signat” o “insegur”.

Si després d'aquesta comprovació detectes que el teu domini o els DNS que utilitzes a la xarxa local no estan aprofitant DNSSEC, és recomanable contactar amb el proveïdor de serveis o el ISP per sol·licitar-ne l'activació. Si no ofereixen aquesta possibilitat, pot ser un bon moment per valorar un canvi a un proveïdor que sí que suporti la validació DNSSEC, elevant així el nivell de seguretat tant per a la teva empresa com per als teus clients.

Limitacions de DNSSEC: privadesa i altres aspectes

Tot i tots els seus avantatges, DNSSEC no és una solució màgica a tots els problemes de seguretat del DNS. Un aspecte fonamental és que no proporciona confidencialitat de les consultes . Els paquets DNS, fins i tot amb DNSSEC, continuen viatjant en text clar, de manera que qualsevol amb accés al trànsit (per exemple, en una xarxa WiFi pública poc segura ) pot veure quins dominis s'estan consultant.

Tampoc no ofereix control d'accés ni defensa específica davant d'atacs de denegació de servei (DoS o DDoS) . De fet, en afegir més dades (firmes, claus, registres addicionals), augmenta la mida de les respostes DNS, cosa que pot ser aprofitada en atacs d'amplificació si la infraestructura no està ben configurada i protegida.

D'altra banda, DNSSEC introdueix certa complexitat operativa: cal gestionar parells de claus, rotar ZSK i KSK, coordinar la publicació de DS a la zona pare i vigilar que no hi hagi desajustos que trenquin la cadena de confiança. Un error en aquests procediments pot provocar que un domini deixi de validar correctament, generant errors aparents de “caiguda” del servei.

Dins del propi funcionament de DNSSEC hi ha bits de control als missatges (com el bit CD en consultes i el bit AD en respostes) que influeixen en com es realitza o s'informa la validació. Un atacant que pogués manipular aquests bits en un entorn insegur podria intentar degradar la protecció que ofereix un resolutor recursiu, per la qual cosa es recomana que les comunicacions entre resolutors i clients que manegen DNSSEC es facin sobre canals segurs.

Tot i aquestes limitacions, DNSSEC continua sent una peça essencial per reforçar l'autenticitat i la integritat del DNS. Tot i això, si es vol anar un pas més enllà i garantir també la confidencialitat de les consultes, cal combinar-lo amb altres tecnologies o evolucionar cap a propostes més avançades.

E-DNSSEC: cap a un DNS autenticat i xifrat

Per cobrir el buit que DNSSEC deixa al terreny de la privadesa, s'ha plantejat el concepte d' E-DNSSEC (DNSSEC encrypted) . La idea d'aquest enfocament és afegir xifrat a les consultes DNSSEC perquè, a més d'estar autenticades i signades, també estiguin protegides davant de la inspecció de tercers mentre viatgen per Internet oa través de la xarxa local.

L'objectiu d'E-DNSSEC és combinar les propietats de DNSSEC (autenticitat i integritat) amb mecanismes de xifratge que proporcionin confidencialitat de les consultes entre el client DNSSEC i el servidor DNSSEC . D'aquesta manera, s'incrementa el nivell de seguretat global del servei DNS, evitant que els observadors externs puguin veure quins noms de domini es resolen.

El funcionament conceptual passaria per analitzar la consulta al servidor recursiu, xifrar-la abans d'enviar-la al servidor autoritatiu i, un cop allà, desxifrar-la i processar-la de manera normal amb DNSSEC . La resposta, alhora, es podria tornar signada i xifrada de tornada al recursiu o al client, mantenint la confidencialitat en tot el trajecte.

Aquesta combinació permetria que el missatge DNS estigués assegurat des de l'inici fins al final de la resolució: autenticat i amb integritat gràcies a DNSSEC, i protegit davant de mirades indiscretes gràcies al xifratge addicional. En un context de xarxes locals o empresarials, aquest plantejament podria integrar-se amb altres solucions de seguretat perimetral.

A dia d'avui, propostes com E-DNSSEC s'emmarquen dins de l'esforç més ampli per reforçar la privadesa del DNS , juntament amb tecnologies com DNS over TLS (DoT) o DNS over HTTPS (DoH). La direcció de fons és clara: el DNS del futur ha de ser tant autèntic com confidencial, i no n'hi ha prou de resoldre noms de forma ràpida; també cal fer-ho de manera segura.

En un entorn on cada cop hi ha més ciberatacs sofisticats, suplantacions i amenaces dirigides a infraestructures bàsiques, comptar amb DNSSEC ja és un requisit de seguretat important per a qualsevol domini seriós, i avançar cap a solucions xifrades tipus E-DNSSEC o similars es perfila com un proper pas lògic per reforçar encara més la protecció de les xarxes, incloses.

Tot aquest ecosistema -des de DNS clàssic fins a DNSSEC i les propostes xifrades com a E-DNSSEC- mostra que la seguretat del DNS no és un “extra” opcional, sinó una part central de l'arquitectura d'Internet i de qualsevol xarxa local moderna. Disposar de resolutors que validin, zones signades, cadenes de confiança ben mantingudes i, en el futur, canals xifrats per a les consultes, marca la diferència entre una xarxa exposada i una infraestructura preparada per als reptes actuals i futurs.