Domain Name System Security Extensions

Model TCP/IP per capes
5. Capa d'aplicació HTTP FTP TFTP SMTP POP3 IMAP DNS IRC SSH Telnet TLS i SSL NFS NNTP NTP SMB/CIFS SNMP Gopher RTP RTCP SOAP SIP XMPP
4. Capa de transport TCP UDP SCTP SPX NetBIOS
3. Capa de xarxa IP IPv4 IPv5 IPv6 ICMP IGMP AppleTalk IPX NetBEUI X.25
2. Capa d'enllaç de dades ARP RARP ATM DSL Ethernet Frame Relay HDLC NDP PPP SLIP Token Ring Wi-Fi
1. Capa física Cable coaxial Cable de fibra òptica Cable de parells trenats Microones Ràdio RS-232 RS-485
Xarxes informàtiques

Domain Name System Security Extensions (DNSSEC) és un conjunt d'especificacions de la IETF per tal de securitzar certs tipus d'informació que proporciona el sistema Domain Name System (DNS) en xarxes IP. Es tracta d'unes extensions del DNS que proporcionen als clients DNS (resolvers) autenticació en origen de les dades de DNS, denegació autenticada de l'existència dels registres, i integritat de dades. No garanteixen, en canvi, ni la disponibilitat ni la confidencialitat.

Resum

El disseny original del DNS no tenia en compte la seguretat; es va dissenyar per ser un sistema distribuït escalable. Les extensions DNSSEC intenten d'afegir-hi seguretat, tot mantenint compatibilitat amb la situació anterior. L'RFC 3833 documenta algunes de les amenaces conegudes contra el DNS i com hi respon DNSSEC.

L'objectiu de disseny de DNSSEC és protegir les aplicacions (i els resolvers que donen servei a aquestes aplicacions) perquè no utilitzin dades DNS falsificades o manipulades, com les que apareixen en atacs d'enverinament de DNS. Totes les respostes que provenen de zones protegides amb DNSSEC estan signades digitalment. Comprovant aquesta signatura digital, un resolver pot comprovar si la informació és idèntica (és a dir, no modificada i completa) a la informació que ha publicat el propietari de la zona i que serveix un DNS autoritatiu. Encara que la preocupació evident és la protecció de la resolució de les adreces IP, DNSSEC pot protegir qualsevol dada publicada al DNS, inclosos els registres TXT, els de correu (MX), i pot utilitzar-se com a origen d'altres sistemes de seguretat que publiquin referències a certificats criptogràfics emmagatzemats al DNS, com els registres de certificat (CERT, segons l'RFC 4398), empremtes SSH (SSHFP, RFC 4255), claus públiques IPSec (IPSECKEY, RFC 4025), i àncores de confiança de TLS (TLSA, RFC 6698).

DNSSEC no proporciona confidencialitat de dades; en concret, totes les respostes DNSSEC estan autenticades, però no encriptades. DNSSEC no protegeix contra atacs de denegació de servei directament. Per securitzar les transferències a l'engròs entre servidors DNS, s'utilitzen d'altres estàndards diferents de DNSSEC. Un altre risc que no es pot protegir amb DNSSEC són les falses suposicions. Com documenta l'RFC 4367, alguns usuaris suposen que el nom comú d'una empresa seguit de ".com" sempre correspon al seu nom de domini, però no sempre és així. DNSSEC no pot protegir d'això; tan sols pot assegurar que les dades provenen realment del propietari del domini.

DNSSEC està especificat en detall a les especificacions anomenades DNSSEC-bis. Són les RFC 4033, RFC 4034, i RFC 4035. Quan es van publicar aquestes RFCs, el març de 2005, l'RFC 2535 va quedar obsoleta.

Hi ha un acord generalitzat que la securització del DNS té una importància crítica per a la seguretat d'Internet en general, però a finals de 2013, el desplegament de DNSSEC no ha pres gaire volada degut a dificultats diverses:

• Necessitat que l'estàndard sigui compatible amb la situació anterior, i pugui escalar a la mida d'Internet
• Evitar el problema de l'"enumeració de zona" (vegeu més endavant).
• Implementar i desplegar DNSSEC en una gran diversitat de servidors i clients DNS
• Desacord entre els implementadors osbre qui ha de ser el propietari de les claus de l'arrel del sistema DNS
• Superar la complexitat aparent de DNSSEC i el seu desplegament.

Microsoft Windows utilitza un resolver mínim, i a partir de Windows 7 el resolver és no-validador (però accepta DNSSEC). Perquè un resolver no validador pugui confiar en els serveis DNSSEC, el resolver ha de confiar tant els servidors de noms recursius que utilitza (que normalment estan controlats pel proveïdor d'Internet, com en els canals de comunicació entre ell i aquests servidors de noms, utilitzant mètodes com IPsec, SIG(0), o TSIG. L'ús d'IPsec, a finals de 2013, encara no és gaire estès.

Funcionament

DNSSEC funciona signant digitalment els registres de DNS amb criptografia de clau pública. El registre DNSKEY correcte s'autentica amb una cadena de confiança, que comença amb un conjunt de claus públiques verificades per a la zona arrel del DNS, que és el tercer en qui es confia.

Registres

El DNS s'implementa amb diferents registres de recurs. Per implementar DNSSEC, se n'han introduït o adaptat uns quants de nous.

• RRSIG - conté la signatura DNSSEC per a un conjunt de registre. Els resolvers DNS verifiquen la signatura amb una clau pública, emmagatzemada en un registre DNSKEY.
• DNSKEY - conté la clau pública que utilitza un resolver DNS per verificar les signatures DNSSEC dels registres RRSIG.
• DS - conté el nom d'una zona delegada. Es col·loca el registre DNS a la zona pare, juntament amb els registres NS de la delegació; referencia un registre DNSKEY de la zona que s'ha delegat.
• NSEC - Conté un enllaç cap al següent nom de registre de la zona, i llista els tipus de registre que hi ha per al nom del registre. Els resolvers DNS utilitzen registres NSEC per verificar la inexistència d'un nom/tipus de registre, com a part de la validació DNSSEC.
• NSEC3 - Conté enllaços al següent nom de registre de la zona (en ordre del nom hashejat) i llista els tipus de registre que existeixen per al nom que correspon al valor de hash de la primera etiqueta del registre NSEC3. Aquests registres els poden utilitzar els resolvers per verificar la inexistència d'un nom/tipus de registre, com a part de la validació DNSSEC. Els registres NSEC3 són semblants als NSEC, però NSEC3 utilitza noms de registre encriptats per evitar l'enumeració dels noms de registre de la zona.
• NSEC3PARAM - Els servidors DNS autoritatius utilitzen aquest registre per calcular i determinar quins registres NSEC3 s'han d'incloure a les respostes a consultes DNSSEC que es fan a noms/tipus que no existeixen.

Quan s'utilitza DNSSEC, cada resposta a una consulta DNS retorna, a part del registre sol·licitat, un registre RRSIG. El registre RRSIG és una signatura digital del conjunt de registres respost. La signatura digital es pot verificar mitjançant la clau pública correcta, que es troba en un registre DNSKEY. Els registres NSEC i NSEC3 es fan servir per donar una prova criptogràfica de la inexistència de cap registre. El registre DS s'utilitza per autenticar els registres DNSKEY durant el procediment de cerca, utilitzant la cadena de confiança. Els registres NSEC i NSEC3 es fan servir per evitar l'spoofing.

Algorismes

DNSSEC es va dissenyar perquè fos extensible, de manera que, a mesura que es descobrissin atacs contra els algorismes existents, se'n poguessin introduir de nous de forma compatible. L'abril de 2013, s'havien definit els següents algorismes de seguretat d'ús comú:

Ident. algorisme	Algorisme	Font	Estat de la implementació
1	RSA/MD5		Desestimat
3	DSA/SHA-1		Opcional
5	RSA/SHA-1		Requerit
7	RSASHA1-NSEC3-SHA1	RFC 5155	Recomanat
8	RSA/SHA-256	RFC 5702	Recomanat
10	RSA/SHA-512		Recomanat
12	GOST R 34.10-2001	RFC 5933	Opcional
13	ECDSA/SHA-256	RFC 6605	Recomanat
14	ECDSA/SHA-384		Recomanat

Mecanisme de consulta

A partir del resultat d'una consulta DNS, un resolver DNS que tingui seguretat incorporada pot determinar si el servidor autoritatiu del domini que s'està consultant suporta DNSSEC, si la resposta que rep és segura, i si hi ha algun tipus d'error. El mecanisme de consulta és diferent per als servidors de noms recursius (els que típicament proporcionen els ISPs, i per als clients DNS que estan inclosos per defecte als sistemes operatius habituals. Microsoft Windows utilitza un client DNS, i Windows Server 2008 R2 i Windows 7 en concret utilitzen un client DNS que no valida, però que distingeix DNSSEC.

Servidors de noms recursius

Utilitzant el model de cadena de confiança, un registre DS (Delegation Signer, firmant de la delegació) del domini superior es pot utilitzar per verificar un registre DNSKEY d'un subdomini seu; aquest subdomini també pot tenir d'altres registres DS que es poden utilitzar per verificar subdominis de nivell més alt. Suposem que un resolver recursiu, com el d'un ISP, vol obtenir l'adreça IP (registre A o AAAA) del domini "www.exemple.com".

1. El procés comença quan un resolver amb seguretat posa a "1" el bit "DO" en una consulta DNS. El bit "DO" és dels que es van definir a les extensions EDNS, i per tant, totes les transaccions amb DNSSEC han de complir EDNS. Igualment seria necessari per permetre les mides de paquet més gran que solen requerir les transaccions DNSSEC.
2. Quan el resolver rep una resposta mitjançant el procés normal de consulta al DNS, comprova que la resposta és correcta. En principi, el resolver ha de començar verificant els registres DS i DNSKEY de l'arrel del DNS. Llavors, hauria d'utilitzar els registres DS del domini de primer nivell "com" que es troben a l'arrel, per verificar els registres DNSKEY de la zona "com". A partir d'aquí, miraria si existeix un registre DS per al subdomini "exemple.com" a la zona "com", i si n'hi hagués, utilitzaria el registre DS per verificar un registre DNSKEY que estaria a la zona "exemple.com". Finalment, verificaria el registre RRSIG que es trobés a la resposta del registre A de "www.exemple.com".

Hi ha algunes excepcions a l'exemple anterior.

D'entrada, si "exemple.com" no suporta DNSSEC, no hi haurà registre RRSIG a la resposta, i no hi haurà registre DS per a "exemple.com" a la zona "com". Si hi ha un registre DS per a "exemple.com", però a la resposta no hi ha el registre RRSIG, alguna cosa ha anat malament, i potser estem patint un "atac Man-in-the-middle", que treu la informació de DNSSEC i modifica el registre A. O també podria ser que la consulta hagués passat per algun servidor de noms sense seguretat que hagués eliminat el bit "DO" de la consulta, o el registre "RRSIG" de la resposta. O podria ser un error de configuració.

Després, pot ser que no existeixi el nom "www.exemple.com"; en aquest cas, en comptes de retornar un registre RRSIG a la resposta, hi haurà o bé un registre NSEC o un NSEC3. Aquests registres indiquen "next secure" (el següent segur), que permeten que el resolver estigui segur que no existeix el nom de domini. Els registres NSEC/NSEC3 tenen registres RRSIG associats, que es poden verificar igual que abans.

Finalment, pot ser que la zona "exemple.com" implementi DNSSEC, però la zona "com" o la zona arrel no ho facin, creant una "illa de seguretat", que s'ha de validar d'alguna altra manera. Des del 15 de juliol de 2010, l'arrel del DNS d'Internet ja ha completat la transició a DNSSEC. El domini .com es va signar amb claus de seguretat vàlides i se'n va afegir la delegació a la zona arrel l'1 d'abril de 2011.

Clients DNS (stub resolvers)

Els clients DNS són "resolvers DNS mínims que utilitzen el mode recursiu de consulta perquè la major part de la feina de la resolució DNS la dugui a terme un servidor de noms recursiu". Un client DNS simplement traspassarà una consulta a un servidor de noms recursiu, i utilitzarà el bit AD (Authenticated Data, dades autenticades) del paquet de resposta per "esbrinar si el servidor de noms recursiu ha pogut validar signatures per a totes les dades de les seccions de "resposta" i d'"autoritat" del paquet de resposta". Microsoft Windows utilitza un resolver mínim, i Windows Server 2008 R2 i Windows 7 tenen un resolver que no valida, però que comprova el bit AD.

Un resolver que validi podria dur a terme la seva pròpia validació de signatura, posant a "1" el bit CD (Checking Disabled, inhabilitar la comprovació) als seus missatges de consulta. Amb aquest bit a 1, el resolver faria la seva pròpia autenticació recursiva. Amb un resolver validador, el host client obté seguretat en DNS des d'un extrem fins a l'altre, en dominis que implementin DNSSEC, encara que el proveïdor d'Internet de la seva connexió no sigui de confiança.

Perquè un client DNS que no valida pugui tenir una confiança significativa en els serveis DNSSEC, el client ha de poder confiar tant en els servidors recursius que utilitza (que sovint són els que proporciona l'ISP com en els canals de comunicació entre ell i aquests servidors de noms, utilitzant mètodes com ara IPsec, SIG(0), o TSIG. L'ús d'IPsec no és generalitzat.

Àncores de confiança i cadenes d'autenticació

Per poder provar que una resposta DNS és correcta, cal haver obtingut com a mínim una clau o registre DS que siguin correctes a partir d'alguna font diferent del DNS. Aquests punts de partida s'anomenen àncores de confiança i típicament s'obtenen juntament amb el sistema operatiu o alguna altra font de confiança. Quan es va dissenyar el DNSSEC, es va creure que l'única àncora que caldria seria la de l'arrel DNS. Les àncores de l'arrel es van publicar el 15 de juliol de 2010. Encara que l'arrel està signada, encara queden força dominis de primer nivell que no ho estan; per utilitzar DNSSEC en zones d'aquests dominis, cal obtenir les àncores de confiança corresponents. Alternativament, quan l'arrel encara no estava signada, calia obtenir per separat les àncores de les zones que sí que s'havien signat (com el .cat).

Una cadena d'autenticació és una sèrie de registres DS i DNSKEY enllaçats, que comencen amb una àncora de confiança cap al servidor de noms autoritatiu del domini en qüestió. Sense una cadena d'autenticació completa, no es pot garantir l'autenticitat d'una resposta del DNS.

Signatures i firma de zones

Per tal de limitar els atacs de repetició, a part dels valors de TTL habituals per guiar el temps de cache, hi ha marques horàries addicionals als registres RRSIG que limiten la validesa d'una signatura. Al contrari dels valors de TTL, que són relatius al moment en què s'havia enviat la resposta, les marques horàries de DNSSEC són absolutes. Això vol dir que tots els resolvers han de tenir rellotges relativament sincronitzats, almenys amb diferències de pocs minuts.

En ser valors absoluts, aquestes marques horàries "caduquen", i per tant, les zones protegides amb DNSSEC s'han de tornar a firmar i redistribuir amb regularitat, abans no caduquin; si els servidors autoritatius enviessin maques horàries obsoletes, els resolvers rebutjarien tots els registres.

Gestió de les claus

DNSSEC funciona gràcies a moltes claus diferents, que s'emmagatzemen als registres DNSKEY, però també en altres fonts de dades per formar àncores de confiança.

Per poder introduir les claus noves quan es canvien, cal un procediment de transició de claus. Típicament, això implica els següents passos:

1. Afegir les claus noves en registres DNSKEY nous, sense esborrar les existents.
2. Quan ja es pot assegurar que s'han distribuït les claus noves perquè ha caducat el TTL de les velles (cal tenir en compte el temps de distribució als DNS secundaris, a part del TTL màxim del registre DNSKEY), es pot passar a utilitzar les noves claus, tornant a signar la zona.
3. Finalment, quan es pot assegurar que ja han caducat tots els registres que utilitzaven les claus antigues (un altre cop, tenint en compte el temps de distribució als DNS secundaris, i el TTL màxim dels registres), es poden esborrar el registres DNSKEY antics. Aquest procés és més complicat per coses com les claus de les àncores de confiança, com la d'arrel, que poden requerir una actualització del sistema operatiu.

Les claus dels registres DNSKEY es poden utilitzar per a dues coses diferents, i normalment, es fan servir registres DNSKEY diferents per a cadascuna. Primer, hi ha Key Signing Keys (KSK, Claus per signar claus), que s'utilitzen per signar altres registres DNSKEY. Segon, hi ha Zone Signing Keys (ZSK, Claus per signar zones) que s'utilitzen per signar d'altres registres. Com les ZSKs estan totalment controlades i utilitzades des d'una mateixa zona DNS, es poden modificar més sovint, i amb més facilitat. Així, les ZSKs poden ser molt més curtes que les KSKs oferint el mateix nivell de protecció, i reduint la mida dels registres RRSIG/DNSKEY.

Quan es crea una nova KSK, el registre DS s'ha de passar a la zona pare, i publicar-s'hi. Els registres DS utilitzen un hash criptogràfic de la KSK en comptes de la clau completa per mantenir una mida de registre raonablement petita. Això és pràctic per a zones com el domini .com, que són molt grans. El procediment per actualitzar les claus DS de la zona pare també és ara més senzill que en versions anteriors de DNSSEC, que requerien que els registres DNSKEY fossin a la zona pare.

Grup de Treball DANE

DNS-based Authentication of Named Entities (DANE, autenticació basada en DNS d'entitats amb nom) és un grup de treball de la IETF que té l'objectiu de desenvolupar protocols i tècniques que permetin a les aplicacions d'establir comunicacions protegides criptogràficament amb TLS, DTLS, SMTP, i S/MIME basant-se en DNSSEC.

Els nous protocols permetran assegurances i restriccions noves per al model tradicional basat en Infraestructura de Clau Pública. També permetran que els propietaris de dominis s'autentiquin certificats sense referir-se a autoritats de certificació.

El suport per als certificats grapats amb DNSSEC es va activar a la versió 14 de Google Chrome, però després es va treure. Per Mozilla Firefox, funciona amb una extensió, mentre s'està treballant a donar-hi suport nadiu.

Història

El DNS és un servei crític i fonamental per al funcionament d'Internet, però el 1990, Steve Bellovin hi va descobrir problemes de seguretat molt greus. Llavors va començar la recerca per millorar-ne la seguretat, i aquesta recerca es va accelerar quan es va publicar el seu article, l'any 1995. L'IETF va publicar l'RFC 2065, la primera sobre el tema, el 1997, i els primers intents d'implementar-ne l'especificació van donar lloc l'any 1999 a l'RFC 2535, que era una especificació revisada, i que es creia que podia funcionar. Es van fer plans per desplegar DNSSEC basant-se en l'RFC 2535.

Malauradament, l'especificació de l'RFC 2535 tenia problemes molt greus que li impedien escalar a tot Internet; l'any 2001 va queda clar que no es podia utilitzar en xarxes grans. En un funcionament normal, els servidors DNS solen perdre la sincronització amb els seus pares. Normalment, això no és cap problema, però quan s'activa DNSSEC, aquestes dades no sincronitzades podrien provocar una denegació de servei autoprovocada. El DNSSEC original utilitzava un protocol complex amb sis missatges i necessitava moltes transferències de dades per fer canvis en una zona "filla" (les zones "filla" havien d'enviar totes les seves dades a la zona pare, la zona pare havia de signar cada registre, i llavors tornar aquestes signatures al fill perquè les emmagatzemés en un registre SIG). A més els canvis en la clau pública podia tenir efectes perversos; per exemple, per canviar la clau pública de la zona ".com", calia enviar 22 milions de registres (perquè hauria d'actualitzar totes les signatures a tots els seus fills). Per tant, la definició de DNSSEC segons l'RFC 2535 no podia escalar a tot Internet.

La IETF va fer canvis dràstics a DNSSEC, que s'anomenen DNSSEC-bis quan cal distingir-lo del DNSSEC inicial de l'RFC 2535. Aquesta versió nova utilitza registres "delegation signer" (DS, signatari de la delegació) per proporcionar un nivell extra d'indirecció als punts de delegació entre una zona mare i una zona filla. Amb el nou sistema, quan la clau mestra d'una zona filla canvia, en comptes d'haver de tenir sis missatges per a cada registre de la filla, n'hi ha un de sol i senzill: la filla envia la nova clau pública a la zona mare (signada, és clar). La zona mare simplement desa una clau pública mestra per a cada fill; això és molt més pràctic. Això implica que s'envien poques dades cap a la mare, en comptes d'intercanviar grans quantitats de dades entre mare i filles. A canvi, els clients han de fer una mica més de feina per verificar les claus. En concret, verificar els registres KEY d'una zona DNS requereix dues operacions de verificació de signatura en comptes d'una, tal com ho tenia l'RFC 2535 (en canvi, no hi ha cap impacte en el nombre de signatures que es verifiquen per a altres tipus de registres). La majoria opina que és un impacte raonable, a canvi de fer el desplegament de DNSSEC molt més pràctic.

Problemàtica de l'enumeració de zones, polèmica i NSEC3

Encara que l'objectiu de DNSSEC és augmentar la seguretat, la definició de DNSSEC a les RFCs 4033 fins a 4035 introdueix un problema nou que molta gent identifica com a vulnerabilitat: la problemàtica de l'enumeració de zones (o passeig per la zona). DNSSEC força l'exposició d'informació que segons les bones pràctiques de DNS s'ha de mantenir privada. Es va desenvolupar NSEC3 (RFC 5155) per solucionar aquest problema; es va completar el març de 2008. NSEC3 mitiga, però no elimina, l'enumeració de zones, perquè encara és possible de cercar exhaustivament el conjunt de noms possibles d'una zona.

Necessitat de mantenir privades les dades de la zona DNS

Quan es va dissenyar el protocol DNS, no es pensava com a repositori d'informació oculta. No obstant, com que el DNS conté informació sobre les interioritats d'una xarxa relacionada amb un cert domini, molta gent considera que el contingut de la base de dades DNS és privat. En concret, els sistemes DNS solen configurar-se de manera que la majoria d'usuaris no pugui baixar-se tota la llista de noms i informació que conté la zona. Una llista completa d'aquest tipus facilitaria la feina dels atacants, perquè els estalvia de recollir manualment la informació de quines màquines existeixen. Alguns administradors publiquen informació sensible a les bases de dades DNS que encara té més valor per als atacants. El llibre DNS and BIND (4ªedició), d'Albitz i Liu ho explica així:

«

Encara més important que controlar qui pot consultar el teu servidor de noms és assegurar que només els servidors secundaris poden fer-ne transferències de zona. Els usuaris d'ordinadors remots només poden consultar registres (és a dir, adreces) de dominis que ja coneguin, i d'un en un. És la diferència entre deixar que qualsevol persona truqui a la centraleta de la teva empresa i demani el telèfon d'algun empleat i enviar-los una còpia sencera del directori telefònic.

»

A més, la informació obtinguda d'una enumeració de zona es pot fer servir de clau per a múltiples consultes WHOIS; això podria revelar dades de qui ha fet el registre, que molts registres tenen obligació legal de protegir per contracte.

De fet, s'ha qüestionat si és legal desplegar DNSSEC en molts països, si no es poden mantenir privades aquestes llistes. El NIC alemany (DENIC) va declarar que el problema de l'enumeració de zona violava la Llei Federal de Protecció de Dades, i d'altres països europeus tenen lleis similars que prohibeixen la difusió de certs tipus d'informació.

Com DNSSEC revela les dades de la zona

El disseny original de DNSSEC requeria revelar la llista sencera de noms de zona. Com diu l'RFC 4033,

«

DNSSEC introdueix la capacitat perquè un atacant enumeri tots els noms de zona seguint la cadena de NSEC. Els registres NSEC indiquen que un nom no existeix en una zona enllaçant d'un nom que existeix al següent nom que existeix, seguint una ordenació canònica de tots els noms de zona. Així, un atacant pot anar consultant aquests registres en seqüència per obtenir tots els noms d'una zona. Encara que això no és un atac contra el propi DNS, permetria a un atacant de fer-se un mapa dels ordinadors o altres recursos de la xarxa enumerant el contingut d'una zona.

»

DNSSEC va introduir aquest problema perquè ha de poder informar quan un nom no existeix. Els servidors DNS que suporten DNSSEC han de poder signar aquesta resposta de no-trobat — si no, seria fàcil de falsificar una resposta de no-trobat. Però per raons de seguretat, la clau de signatura no ha d'estar disponible en línia, ni tan sols als DNS secundaris. Per tant, la decisió de disseny fou crear un missatge signat que indica que un cert rang de noms no existeix, perquè això sí que es pot signar fora de línia abans de publicar la zona. Malauradament, amb aquesta informació n'hi ha prou perquè un atacant obtingui molta més informació de la que hauria pogut obtenir d'altra manera — n'hi ha prou perquè un atacant obtingui ràpidament la llista de tots els noms de la zona, i després, amb consultes concretes pugui reconstruir pràcticament totes les dades de la zona.

Hi ha una solució "trivial", anomenada DNS amb horitzó partit, que és com se sol desplegar el DNS sense DNSSEC; però aquesta estratègia no funciona bé amb DNSSEC. Amb l'horitzó partit, el servidor DNS nega l'existència de noms a alguns clients, i dona la informació correcta als altres. No obstant, com que la informació de DNSSEC està signada criptogràficament com a autoritativa, un atacant podria demanar el registre signat que indica "no existeix", guardar-se'l, i retransmetre'l per provocar una denegació de servei. DNSSEC modifica els fonaments del DNS perquè pugui donar informació autoritativa; per tant, no funciona bé amb mètodes que es basin a donar informació falsa a alguns usuaris. Alguns investigadors han proporcionat recomanacions per combinar de manera apropiada aquestes dues propietats del DNS.

Com s'ha dit abans, DNSSEC es podria utilitzar com a base d'una infraestructura mundial de clau pública per adreces de correu, utilitzant el DNS per lliurar els certificats de l'email, i el DNSSEC per validar-los. No obstant, aquesta problemàtica del DNSSEC fa que sigui inviable per a la majoria d'organitzacions, com a mínim si s'utilitza directament. Tal com diu l'RFC 4398, "si una organització decideix de donar certificats als seus empleats, posant registres CERT al DNS per nom d'usuari, i si s'utilitza DNSSEC (amb NSEC), és possible que algú llisti tots els empleats de l'organització. Normalment, això no es considera desitjable, pel mateix motiu que els directoris telefònics de l'empresa no se solen fer públics i fins i tot es consideren confidencials".

Reaccions inicials

Molts dels participants al grup de treball de la IETF sobre el DNS van afirmar que el problema de l'enumeració de zones no era significatiu, argumentant que les dades del DNS ja eren—o haurien de ser—públiques. No obstant, els registradors i moltes organitzacions grans van avisar els membres del grup de treball que la definició del DNSSEC, tal com estava, era inacceptable, i que no el desplegarien, o no podrien fer-ho per motius legals.

Signatura en línia

L'RFC 4470 va proposar una solució per evitar l'enumeració de zones. En comptes de signar les respostes de no-trobat a l'avançada, es genera una resposta de no-trobat per a cada consulta. Per exemple, si la consulta que es rep és 'b.exemple.com', en comptes de servir una resposta signada amb anterioritat que digui que no hi ha cap nom entre 'a.exemple.com' i 'mail.exemple.com', cosa que revela automàticament l'existència de 'mail.exemple.com', la resposta podria ser 'no hi ha cap nom entre b.exemple.com i ba.exemple.com'. Si la següent consulta demana 'ba.exemple.com', la resposta podria ser 'no hi ha noms entre ba.exemple.com i baa.exemple.com'. Això fa que no sigui pràctic enumerar la zona sencera.

Aquesta solució té alguns problemes. Cal que cada servidor DNS tingui accessible en línia una clau de signatura. Moltes claus de signar zones es mantenen en línia de totes formes per poder tornar a signar la zona de forma automàtica quan hi ha una actualització (dinàmica, per exemple); però aquesta funció només cal al servidor DNS primari, mentre que per suportar la signatura en línia, la clau de signatura de zona s'ha de mantenir a tots els servidors autoritatius. Alguns servidors autoritatius han de ser per força accessibles des d'Internet, i idealment haurien d'estar dispersos al màxim, potser en organitzacions diferents, i això fa difícil mantenir el control de les claus. També caldria vigilar la possibilitat que un atacant inundés el servidor DNS amb peticions de noms inexistents, i forçant el servidor a fer operacions criptogràfiques de signatura, denegant el servei als usuaris legítims.

NSEC3

Després de moltes deliberacions, es va desenvolupar una nova extensió: "DNSSEC Hashed Authenticated Denial of Existence" ("Denegació Autenticada d'Existència Hashejada amb DNSSEC, anomenada de manera informal "NSEC3"). Amb aquesta solució, els servidors que tenen DNSSEC poden enviar un registre "NSEC3" en comptes d'NSEC quan no es troba un registre. El registre NSEC3 està signat, però en comptes d'incloure el nom directament (cosa que permetria l'enumeració de zona), el registre NSEC3 conté un hash criptogràfic del nom. El registre NSEC3 conté alhora un hash al cap d'un nombre determinat d'iteracions i una "sal" opcional; tots dos mecanismes redueixen l'efectivitat d'atacs de diccionari amb claus pre-calculades. El mecanisme de la "sal" augmenta el nombre de diccionaris necessari per fer un atac, mentre que les iteracions de hash addicionals augmenten el cost de calcular cada diccionari.

In March 2008, NSEC3 was formally defined in RFC 5155.

Desplegament

Internet és una infraestructura crítica, però tot el seu funcionament depèn del DNS, que és insegur per disseny. Per tant, hi ha molts incentius per securitzar el DNS, i hi ha un ampli consens que DNSSEC és un punt clau per tal d'aconseguir aquest objectiu. Als Estats Units, la National Strategy to Secure Cyberspace identifica concretament aquesta necessitat. Un desplegament generalitzat de DNSSEC també resoldria molts altres problemes de seguretat, com la distribució segura de claus per a adreces de correu electrònic.

Desplegar DNSSEC en xarxes a gran escala és un repte considerable. Ozment i Schechter observen que DNSSEC (i d'altres tecnologies) té un problema de "l'ou i la gallina": els usuaris típicament només despleguen una tecnologia si té un benefici immediat, però si cal un nivell mínim de desplegament abans que cap usuari rebi un benefici més gran que el seu cost (com passa amb DNSSEC), és difícil de desplegar-la. DNSSEC es pot desplegar en qualsevol nivell d'una jerarquia DNS, però ha d'estar generalitzat en una zona abans que molts d'altres ho vulguin adoptar. Els servidors DNS s'han d'actualitzar amb programari que suporti DNSSEC, i s'han de crear les dades de DNSSEC, que s'han d'afegir a la zona. Un client TCP/IP ha d'actualitzar el seu client DNS abans d'utilitzar les capacitats de DNSSEC. A més, qualsevol resolver ha de tenir, o ha de tenir una manera d'adquirir, una clau pública en què confiar com a mínim, abans de començar a utilitzar DNSSEC.

La implementació de DNSSEC pot afegir una càrrega significativa a alguns servidors DNS. Les respostes normals signades amb DNSSEC són molt més grans que la mida UDP per defecte de 512 bytes. En teoria, això es pot gestionar amb múltiples fragments IP, però moltes "caixes intermèdies" no els gestionen correctament, i per tant s'ha d'utilitzar TCP. Però moltes implementacions actuals de TCP emmagatzemen moltes dades per cada connexió TCP; els servidors que tenen molta càrrega es poden quedar sense recursos fàcilment, tractant de respondre un gran nombre de consultes DNS (possiblement malicioses). S'han desenvolupat algunes extensions al protocol, com TCP Cookie Transactions, per reduir aquesta càrrega.

Primers desplegaments

Els primers dominis a adoptar DNSSEC van ser els dominis de primer nivell del Brasil (.br), Bulgària (.bg), República Txeca (.cz), Puerto Rico (.pr) i Suècia (.se); Quant als dominis genèrics, els primers de signar-se foren el .org i el .cat, amb poques hores de diferència, el 2009. El RIPE NCC, que gestiona les adreces IP a Europa, ha signat tots els registres inversos (in-addr.arpa) que té delegats per la IANA. El registre regional nord-americà, ARIN també està signant les seves zones inverses. El febrer de 2007, l'ISP suec TDC va convertir-se en el primer que oferia DNSSEC als seus clients.

IANA havia organitzat una arrel signada de proves a partir de juny de 2007. Durant aquest període anterior a la signatura de l'arrel, també hi havia algunes àncores de confiança alternatives. L'IKS Jena en va presentar una el 19 de gener de 2006, l'Internet Systems Consortium (desenvolupadors del BIND) en va presentar un altre el 27 de març del mateix any, mentre que l'ICANN també en va anunciar un tercer el 17 de febrer de 2009.

El 2 de juny de 2009, el Public Interest Registry va signar la zona .org. Prèviament, el 26 de setembre de 2008, havien anunciat que la primera fase, amb els registres amb qui treballaven més, començaria a principis de 2009. El 23 de juny de 2010, 13 registradors constava que oferien registre DNSSEC per a dominis .ORG.

Tot i firmar la zona poc després del .org, el domini .cat encara va trigar un any a poder oferir DNSSEC. El 24 de juny de 2010 va firmar el contracte amb ICANN que ho permetia.

VeriSign va fer un projecte pilot per permetre que els dominis .com i .net s'autoregistressin per experimentar amb NSEC3. El 24 de febrer de 2009, van anunciar que desplegarien DNSSEC a tots els dominis genèrics de primer nivell que gestionaven (.com, .net, etc.) en 24 mesos, i el 16 de novembre del mateix any van anunciar que els dominis .com i .net estarien signats el primer trimestre de 2011, després d'alguns retards provocats per aspectes tècnics de la implementació. El calendari es va complir

Desplegament a l'arrel del DNS

DNSSEC es va desplegar per primer cop a l'arrel del DNS el 15 de juliol de 2010. Aquesta fita va simplificar molt el desplegament de resolvers DNSSEC, perquè l'àncora de confiança de l'arrel es pot utilitzar per validar qualsevol zona DNSSEC que tingui una cadena de confiança completa des de l'arrel. D'aquesta manera, només calen àncores de confiança addicionals pels casos on la cadena de confiança tingui alguna interrupció des de l'arrel. Per exemple, si la zona "signada.exemple.org" estigués securitzada, però "exemple.org" no, encara que la zona ".org" i l'arrel estan signades, caldria una àncora de confiança per poder validar la zona.

Hi ha hagut contínuament problemes polítics al voltant de la signatura de l'arrel, bàsicament relacionats amb dues preocupacions:

• Alguns països estan preocupats pel control d'Internet per part dels Estats Units, i poden rebutjar una clau central per aquest motiu.
• Alguns governs poden intentar prohibir la distribució de claus d'encriptació basades en DNSSEC.

Planificació

El setembre de 2008, ICANN i VeriSign van publicar per separat propostes d'implementació i l'octubre, l'administració nord-americana (NTIA) va demanar al públic que hi fes comentaris. No està clar si els comentaris que es van rebre van afectar el disseny final del pla de desplegament.

El 3 de juny de 2009, l'Institut Nacional d'Estàndards i Tecnologia dels Estats Units (NIST) va anunciar el seu pla de signar l'arrel a finals de 2009, juntament amb ICANN, Verisign i la NTIA.

El 6 d'octubre de 2009, a la 59a conferència del RIPE, ICANN i VeriSign van anunciar la planificació per al desplegament de DNSSEC a la zona arrel. A la conferència es va anunciar que es desplegaria de forma incremental, fent un servidor arrel cada mes, començant l'u de desembre de 2009, i arribant a l'últim l'u de juliol de 2010, i també que la zona arrel se signaria amb una DNSKEY RSA/SHA256. Durant el període de desplegament incremental, la zona arrel va servir una Deliberately Unvalidatable Root Zone (Zona Arrel Deliberadament No-validable, DURZ) que utilitzava claus postisses, i el registre DNSKEY final no es va distribuir fins a l'u de juliol de 2010. Això vol dir que les claus que s'havien fet servir per signar la zona no es podien verificar expressament; el motiu per fer aquest desplegament era monitorar canvis en els patrons de trànsit causats per l'augment de la mida de les respostes que demanaven recursos amb DNSSEC.

El domini de primer nivell .org va començar a funcionar el juny de 2010, seguit pel .com, .net, i .edu entre 2010 i 2011. Els dominis territorials de primer nivell van poder començar a instal·lar les claus a partir de maig de 2010. El novembre de 2011, més del 25% de dominis de primer nivell estaven signats amb DNSSEC.

Implementació

El 25 de gener de 2010, el servidor arrel L va començar a servir una Deliberately Unvalidatable Root Zone (Zona Arrel Deliberadament No-validable, DURZ). La zona utilitzava signatures d'un hash SHA-2 (SHA-256) creat amb l'algorismeRSA, definit a l'RFC 5702. El maig de 2010, tots 13 servidors arrel havien començat a servir la DURZ. El 15 de juliol, es va signar la primera zona arrel amb DNSSEC en producció, amb número de SOA 2010071501. Les àncores de confiança de l'arrel es poden obtenir al web d'IANA.

Desplegament en dominis de primer nivell

Sota l'arrel hi ha una colla de dominis de primer nivell que s'han de signar per aconseguir el desplegament total de DNSSEC.

DNSSEC Lookaside Validation

El març de 2006, Internet Systems Consortium (ISC) va presentar el registre de validacions laterals de DNSSEC (DNSSEC Lookaside Validation registry). La finalitat n'era fer més fàcil el desplegament de DNSSEC quan encara no hi havia l'àncora de confiança de l'arrel. En aquell moment, s'imaginava que els validadors haurien de mantenir un gran nombre d'àncores de confiança corresponents a diferents sub-arbres del DNS. Amb el DLV es facilitava als validadors la delegació de l'esforç de gestió del conjunt d'àncores de confiançar a un tercer de confiança. El registre DLV manté aquesta llista central d'àncores de confiança, i així, els validadors s'estalvien de mantenir-se cadascú la seva.

Per utilitzar DLV, cal un programari que ho suporti, com BIND o Unbound, configurat amb una àncora de confiança per una zona DLV. Aquesta zona especial conté registres DLV; tenen el mateix format que els registres DS, però en comptes de referir-se a una subzona delegada, es refereixen a una zona qualsevol de l'arbre DNS. Quan el validador no troba una cadena de confiança des de l'arrel fins al registre que vol validar, cerca un registre DLV que pot donar-li una cadena de confiança alternativa.

Després de la signatura de l'arrel, DLV continua sent útil. Mentre hi hagi "salts" a la cadena de confiança, com ara dominis de primer nivell sense signar, o registradors que no suportin delegacions amb DNSSEC, els gestors dels dominis de nivell més baix poden utilitzar DLV perquè els seus usuaris en validin les dades DNS.

Desplegament de DNSSEC als resolvers

Alguns ISPs han començat a desplegar servidors recursius que validen el DNSSEC. Comcast va ser el primer d'important que ho va fer als Estats Units, anunciant-ne la intenció el 18 d'octubre de 2010 i acabant el desplegament l'11 de gener de 2012.

Segons un estudi, la proporció de clients que només utilitzen resolvers DNS que fan validació DNSSEC ha pujat al 8,3% el maig de 2013. Aproximadament la meitat d'aquests clients utilitzava el DNS públic de Google.

El DNS públic de Google

Google Public DNS és un servei públic i gratuït de DNS que suporta DNSSEC de manera completa.

Quan es va llançar el 2009, no ho suportava. Es podien consultar els registres RRSIG, però el bit AD (Authenticated Data, dades autenticades, que significa que el servidor ha pogut validar les signatures per a totes les dades) no estava mai a "1".

El 28 de gener de 2013, els servidors DNS de Google van començar a donar informació de validació de DNSSEC, sense avisar, però només si el client posava el bit DNSSEC OK (DO) a la consulta.

El 6 de maig de 2013, Google Public DNS va activar la validació predeterminada de DNSSEC; això vol dir que totes les consultes es validaran si els clients no ho eviten explícitament.

Eines

Desplegar DNSSEC requereix programari tant a la banda del client com del servidor. Algunes eines que suporten DNSSEC són:

• Windows 7 i Windows Server 2008 R2 inclouen un client DNS "conscient de la seguretat", que pot diferenciar entre respostes segures i no segures d'un servidor recursiu. El DNSSEC de Windows Server 2012 és compatible amb les actualitzacions dinàmiques segures en zones integrades al Directori Actiu, amb replicació de les claus d'àncora via Directori Actiu amb altres servidors.
• BIND, el servidor DNS més estès (que inclou l'eina dig), permet els registres DS i també els NSEC3.
• Drill és una eina semblant al dig que suporta DNSSEC i ve juntament amb ldns.
• L'extensió Drill per a Firefox Arxivat 2009-02-14 a Wayback Machine. dona a Mozilla Firefox la capacitat de determinar si un domini es pot verificar amb DNSSEC.
• DNSSEC-Tools intenta donar eines fàcils d'utilitzar per ajudar els administradors a desplegar DNSSEC. Dona eines per administradors de zones autoritatives Arxivat 2009-09-18 a Wayback Machine., servidors autoritatius Arxivat 2009-09-14 a Wayback Machine., i servidors recursius Arxivat 2009-09-18 a Wayback Machine. així com una llibreria i eines per a desenvolupadors d'aplicacions Arxivat 2009-09-18 a Wayback Machine. i pegats per afegir la funcionalitat a aplicacions freqüents Arxivat 2009-09-11 a Wayback Machine..
• Phreebird és un proxy DNS que pot afegir suport DNSSEC per damunt de qualsevol altre servidor DNS.
• Zone Key Tool és un programari dissenyat per facilitar el manteniment de zones amb DNSSEC. Està dissenyat principalment per a entorns amb un nombre petit a mitjà de zones, i proporciona una transició de la signatura de zones completament automàtica, així com la signatura automàtica en cas de modificació.
• Unbound és un servidor DNS creat des de zero per funcionar amb conceptes de DNSSEC.
• GbDns Arxivat 2011-01-18 a Wayback Machine. és un servidor DNSSEC compacte i fàcil d'instal·lar per a Microsoft Windows.
• mysqlBind, el programari de gestió de DNS GPL també suporta DNSSEC.
• OpenDNSSEC és una eina per signar amb DNS que utilitza PKCS#11 per interaccionar amb mòduls de seguretat per maquinari.
• SecSpider Arxivat 2010-05-05 a Wayback Machine. segueix el desplegament de DNSSEC, monitora zones, i proporciona una llista de les claus públiques que ha observat.
• DNSViz i DNSSEC Analyzer són eines web que visualitzen la cadena d'autenticació d'un domini.
• DNSSEC/TLSA Validator és un connector de Mozilla Firefox per visualitzar l'estat DNSSEC del domini visitat; la versió 2.1 ha afegit suport per comprovar l'estat dels registres TLSA (DANE).
• DNSSHIM o DNS Secure Hidden Master és una eina de codi obert que automatitza el provisionament de zones amb DNSSEC.
• Net::DNS::SEC és un resolver DNS implementat en Perl.
• Knot DNS ha afegit suport per la signatura automàtica de DNSSEC a la versió 1.4.0.

Enllaços externs

• DNSSEC - Web d'informació sobre DNSSEC
• DNSEXT Grup de treball de la IETF: DNS Extensions
• Projecte DNSSEC-Tools
• Iniciativa de coordinació del desplegament de DNSSEC Arxivat 2018-04-04 a Wayback Machine.