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' 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'), empremtes SSH (SSHFP, ), claus públiques IPSec (IPSECKEY, ), i àncores de confiança de TLS (TLSA, ).
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', 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 , , i . Quan es van publicar aquestes RFCs, el març de 2005, l' va quedar obsoleta.
Hi ha un acord generalitzatEntrevista amb Dan Kaminsky sobre DNSSEC (25 de juny de 2009) Kaminsky interview: DNSSEC addresses cross-organizational trust and security 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 Recomanat 8 RSA/SHA-256 Recomanat 10 RSA/SHA-512 Recomanat 12 GOST R 34.10-2001 Opcional 13 ECDSA/SHA-256 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".
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. 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". An earlier definition was given in an earlier RFC: 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.