Domain Name System Security Extensions

Les extensions de seguritat per al sistema de noms de domini (Domain Name System Security Extensions o DNSSEC, per les seues sigles en anglés) són un conjunt d'especificacions de l'Internet Engineering Task Force (IETF) per a assegurar cert tipo d'informació proporcionada pel sistema de noms de domini (DNS) que s'usa en el protocol d'Internet (IP). Es tracta d'un conjunt d'extensions per al DNS que proporcionen als clients DNS (o resolvers), l'autenticació d'orige de les senyes DNS, refús d'existència d'autenticació i l'integritat de les senyes, pero no la disponibilitat o confidencialitat.

Descripció general

El disseny original del Domain Name System (DNS) no incloïa la seguritat puix el seu objectiu de desenroll va estar enfocat en ser un sistema distribuït escalable. Les Extensions de seguritat per al Sistema de Noms de Domini (DNSSEC) intenten aumentar la seguritat, i al mateix temps mantindre la compatibilitat en lo més antic. En el document RFC 3833 es documenten algunes amenaces conegudes en el DNS i cóm DNSSEC pot respondre a eixes amenaces.

DNSSEC va ser dissenyat per a protegir als resolutores de dominis d'Internet (a les seues clients) de senyes de DNS que hagen segut falsificats, tals com la creats per enverinament de caché DNS. Totes les respostes en DNSSEC són firmades digitalment. En comprovar la firma digital, el resoldre és capaç de comprovar si l'informació és idèntica (correcta i completa) a l'informació en el servidor DNS autorisat. Si be la protecció de les direccions IP és la preocupació immediata per a molts usuaris, DNSSEC pot protegir una atra informació també, com a certificats de sifrat de propòsit general almagasenades en registre CERTs en el DNS. RFC 4398 descriu cóm distribuir estos certificats, inclosos els de correu electrònic, fent possible l'us de DNSSEC en tot lo món com una infraestructura de clau pública per al correu electrònic.

DNSSEC no garantisa la confidencialitat de les senyes; en particular, totes les respostes de DNSSEC es autentican, pero no se sifren. DNSSEC no protegix directament contra els Atacs de refús de servici, encara que indirectament, proporciona algun benefici. Atres normes (no DNSSEC) s'utilisen per a protegir les senyes a granel (com la transferència de zona DNS) que s'envia entre els servidors DNS. Com es documenta en el IETF RFC 4367, alguns usuaris i desenrolladors fan suposicions falses sobre els noms DNS, com el supòsit de que el nom comú d'una empresa més ".com" és sempre el seu nom de domini. DNSSEC no pot protegir contra les falses suposicions, sino que solament pot autenticar que les senyes són verdaderament d'o no disponible en el propietari del domini.

Les especificacions de DNSSEC (cridades DNSSEC-bis), descriuen l'actual protocol DNSSEC en gran detall. Vore els RFC 4033, RFC 4034 i RFC 4035. En la publicació d'estos nous documents RFC (març de 2005), el RFC anterior, RFC 2535 ha quedat obsolet.

Es creu àmpliament que assegurar els DNS és de vital importància per a la seguritat en Internet com un tot, pero el desplegament de DNSSEC en concret s'ha vist obstaculisat per vàries dificultats:

• La necessitat de dissenyar un estàndart compatible en versions anteriors que pot escalar-se al tamany de l'Internet.
• Prevenció de la "enumeració de la zona" (vore avall) a on es desige.

• El desplegament de les implementacions DNSSEC en una àmplia varietat de servidors de DNS i resolvers (clients).
• El desacort entre els encarregats de l'eixecució sobre quí deu posseir les claus de raïl dels dominis de nivell superior.
• La superació de l'aparent complexitat de DNSSEC i el seu desplegament.

Els investigadors de l'indústria han treballat per a millorar el disseny del sistema de noms de domini per a reduir la provabilitat de que els atacants comprometen l'infraestructura. Ho han fet permetent diverses opcions i ajustant les pautes de cóm operen.

Funcionament

DNSSEC treballa firmant digitalment estos registres per a la busca de DNS per mig de criptografia de clau pública. El registre DNSKEY correcte s'autèntica a través d'una cadena de confiança, que comença en un conjunt de claus públiques de la zona raïl del DNS, que és la tercera part de confiança.

Registres

El DNS s'implementa per mig de l'us de varis registres de recursos. Per a implementar DNSSEC, varis dels nous tipos de registre DNS s'han creat o adaptat per al seu us en DNSSEC:

• RRSIG
• DNSKEY
• DS
• NSEC
• NSEC3
• NSEC3PARAM

Quan s'usa DNSSEC, cada resposta a una busca de DNS contindrà un registre RRSIG DNS ademés del tipo de registre que es va solicitar. El registre RRSIG és una firma digital de la resposta de DNS registre de recursos conjunt. La firma digital pot ser verificada localisant la clau pública correcta es troba en un registre DNSKEY. El registre DS s'utilisa en l'autenticació de DNSKEYs en el procediment de busca usant la cadena de confiança. Els registres NSEC i NSEC3 s'utilisen per a una resistència forta contra la suplantació d'identitat.

Algoritmes

DNSSEC va ser dissenyat per a ser extensible i per a que quan es descobrixquen atacs contra els algoritmes existents, nous poden ser introduïts en una forma compatible en versions anteriors. A juliol de 2009, es varen definir els següents algoritmes de seguritat que són utilisats en major freqüència:

Camp de el Algoritme	Algoritme	RFC
0	Borrat	RFC 4034, RFC 4398, RFC 8078
1	RSA/MD5 Desaprovat	RFC 3110, RFC 4034
3	DSA/SHA-1	RFC3755, RFC2536
5	RSA/SHA-1	RFC 3110, RFC 4034
7	RSASHA1-NSEC3-SHA1	RFC 5155
8	RSA/SHA-256	RFC 5702
10	RSA/SHA-512
12	GOST R 34.10-2001	RFC 5933
15	EdDSA ED25519	RFC 8080
16	EdDSA ED448

El procediment de busca

Dels resultats d'una busca de DNS, un resoldre de DNS conscient de la seguritat pot determinar si la resposta que va rebre va ser segura, o si era insegura i el servidor de noms autoritativo per al domini consultat no soporta DNSSEC o si hi ha algun tipo d'error. El procediment de busca és diferent per a servidor de noms recursivos, com els de molts ISPs, que per a resolvers stub, com els inclosos per defecte en els sistemes operatius principals. Microsoft Windows utilisa un resoldre stub, i Windows Server 2008 R2 i Windows 7, en particular, utilisen un stub resoldre que no valida DNSSEC, pero que és capaç d'entendre els mensages.

Servidors de noms recursivos

Usant el model de la cadena de confiança, un registre de firmant delegat (DS) d'un domini principal (zona DNS) es pot utilisar per a verificar un registre DNSKEY en un subdomini, que a la seua volta pot contindre atres registres DS per a verificar subdominis adicionals. Digam que un resoldre recursivo, com un servidor de nom d'un ISP desija obtindre les direccions IP (registre A i / o registre AAAA s) del domini "www.example.com".

1. El procés comença quan un resoldre que soporte seguritat establix el bit del paràmetro "DO" en una consulta DNS. Ya que el bit DO està en els bits dels paràmetros estesos definits per EDNS, totes les transaccions deuen soportar DNSSEC EDNS. El soport d'EDNS també és necessari per a permetre paquets de tamany molt més gran com les transaccions DNSSEC requerixen.
2. Quan el resoldre rep una resposta a través del procés normal de busca de DNS, la comprova per a assegurar-se de que la resposta és correcta. Lo ideal seria que el resoldre que soporte seguritat escomençarà en la verificació de la DS i el registre DNSKEY en el Servidor Raïl. A continuació, s'utilisa el registre DS per al domini de nivell superior "com" trobat en la raïl per a verificar els registres DNSKEY en la zona "com". A partir d'ahí, revisaria si hi ha un registre DS per al subdomini "example.com" en la zona "com", i si ho hi haguera, llavors utilisaria el registre DS per a verificar el registre DNSKEY troba en la zona "example.com". Per últim, seria verificar el registre RRSIG trobat en la resposta dels registres A para "www.example.com".

Hi ha vàries excepcions a l'eixemple anterior.

En primer lloc, si "example.com" no és compatible en DNSSEC, no hi haurà cap registre RRSIG en la resposta i no hi haurà un registre DS per a "example.com" en la zona "com". Si hi ha un registre DS per a "example.com", pero cap registre RRSIG en la resposta, alguna cosa està mal i tal volta un Atac Man-in-the-middle està ocorrent, modificant els registres A i eliminant l'informació de DNSSEC. O be, podria ser un servidor de noms indolente a la seguritat en alguna part del camí que va eliminar el bit de paràmetro DO de la consulta o el registre RRSIG de la resposta. O be, podria ser un error de configuració.

Despuix, podria ser que no hi haja un domini cridat "www.example.com", en el cas del qual en lloc de tornar un registre RRSIG en la resposta, hi haurà o un registre NSEC o un registre NSEC3. Estos són registres "casi segurs" que permeten en resoldre demostrar que un nom de domini no existix. Els registres NSEC/NSEC3 tenen registres RRSIG, els que poden ser verificats com anteriorment.

Per últim, pot ser que la zona "example.com" implemente DNSSEC, pero ya siga la raïl o la zona "com" no ho faça, creant una "illa de seguritat", que deu ser validat d'alguna atra manera. En juliol de 2010 es va completar el desplegament de DNSSEC en la raïl El domini.com va ser firmat en claus de seguritat vàlides i es va afegir delegació segura a la zona de la raïl l'1 d'abril del 2011.

Stub resolvers

Stub resolvers són "resolvers DNS mínims que utilisen el modo de consulta recursiva per a descarregar la major part del treball de resolució de DNS a un servidor de noms recursivo". Un stub resoldre simplement enviarà una solicitut a un servidor de noms recursivo, i utilisarà el bit de senyes autenticados (Authenticated Data) (AD) en la resposta com una "pista per a averiguar si el servidor de noms recursivo va ser capaç de validar les firmes de totes les senyes de les seccions de resposta i l'Autoritat de la resposta." Microsoft Windows utilisa un stub resoldre, i Windows Server 2008 R2 i Windows 7 en particular usen un stub resoldre no validante, pero capaç de revisar el bit AD.

Un stub resoldre validante també pot potencialment portar a terme la seua pròpia validació de firma en fixar el bit de Checking Disabled (CD) en els seus mensages de consulta. Un stub resoldre validante utilisa el CD bit per a portar a terme la seua pròpia autenticació recursiva. Utilisar este tipo de stub resoldre validantes li dona al client DNS seguritat d'extrem a extrem per als dominis que hagen implementat DNSSEC, inclús si el proveïdor de servicis Internet o la conexió a ells no és de confiança.

Per a que els stub resoldre no validante puguen confiar realment en servicis DNSSEC, el stub resoldre deu confiar tant en els servidors de noms recursivos en qüestió (els que sol ser controlats pel ISP) i els canals de comunicació entre ell i els servidors de noms, utilisant métodos tals com IPsec, SIG(0), o TSIG. L'us de IPsec no està molt estés

Ancores de confiança i cadenes d'autenticació

Per a ser capaç de demostrar que una resposta DNS és correcta, és necessari conéixer a lo manco un registre de DS que és correcte a partir de fonts distintes de la DNS. Estos punts de partida són coneguts com ancores de confiança i s'obtenen normalment en el sistema operatiu o per alguna atra font de confiança. Quan DNSSEC va ser originalment dissenyat, es va pensar que l'única ancora de confiança que es necessitava era que la raïl del DNS. Les ancores de la raïl es varen publicar per primera volta el 15 de juliol de 2010.

Una cadena d'autenticació és una série de registres DS i registres vinculats DNSKEY, començant en l'ancora de confiança al servidor de noms autorisat per al domini en qüestió. Sense una cadena d'autenticació completa, una resposta a una busca de DNS no pot autenticar de manera segura.

Firmes i firmes de zona

Per a llimitar els atacs de repetició, no només hi ha valors TTL per a propòsits de caché, sino que també marques de temps adicionals en els registres RRSIG per a llimitar la validea d'una firma. A diferència de valors TTL que són relatius al moment de l'enviament del registre, les marques de temps són absolutes. Açò significa que tots els resolvers DNS que tinguen en conte la seguritat deuran tindre els rellonges sincronisats en un marge de minuts.

Estes marques de temps implica que una zona deu tornar a ser firmada i distribuïda als servidors secundaris, o les firmes seran rebujades pels resolvers que validen.

La gestió de claus

En la finalitat de permetre la substitució de claus, es requerix un esquema de desplegament de clau. Típicament, açò implica en primer lloc el desplegament de noves claus en nous registres DNSKEY, ademés de les claus antigues existents. Llavors, quan és segur assumir que els valors del temps per a viure han fet que les claus antigues almagasenades en caché que hagen expirat, es pot utilisar estes noves claus. Per últim, quan és segur assumir que els registres almagasenats en caché utilisant les claus velles han expirat, els vells registres DNSKEY es poden eliminar. Este procés és més complicat per a coses tals com les claus per a confiar en els anclajes, com en la raïl, els que poden requerir una actualisació del sistema operatiu.

Les claus en els registres DNSKEY es pot utilisar per a dos coses diferents i els normalment s'utilisen diferents registres per a cada u. En primer lloc, són les claus DNSKEY de firma de clau (KSK), que s'utilisen per a firmar els registres d'atres DNSKEY. En segon lloc, estan les claus de firma de la zona (ZSK) que s'utilisen per a firmar els registres d'uns atres. Ya que els ZSKs estan baix el control complet i són usats per una determinada zona DNS, ells es poden canviar més fàcilment i més a sovint. Com a resultat, ZSKs pot ser molt més curts que els KSKs i encara oferir el mateix nivell de protecció, pero reduint el tamany dels registres RRSIG / DNSKEY.

Quan una nova KSK es crea, el registre DS deu ser transferit a la zona superior i publicat allí. Els registres DS utilisen una síntesis del mensage de la KSK lloc de la clau completa en la finalitat de mantindre el tamany dels registres menuts. Açò és útil per a zones com el domini. Com, que són molt grans. El procediment per a actualisar les claus de DS en la zona principal també és més senzill que en versions anteriors DNSSEC les que requerien els registres DNSKEY estigueren en la zona principal.

Grup de Treball DANE

El grup de treball d'autenticació d'entitats en nom basat en DNS (de l'anglés DNS-based Authentication of Named Entities) (DANE) pertany a la IETF i té l'objectiu de desenroll de protocols i tècniques que permeten a les aplicacions d'Internet establir comunicacions criptográficamente segures (en IPsec, TLS, DTLS) basades en DNSSEC.

Els nous protocols permetran a garanties adicionals i llimitacions per al model tradicional basat en l'Infraestructura de clau pública. També permetrà als titulars de domini per a fer valdre els certificats per ells mateixos, sense fer referència a terceres Autoritat de certificació.

Soport per a certificats grapados DNSSEC s'ha habilitat en Google Chrome 14. Para Mozilla Firefox, el soport és proporcionat per un add-on, mentres que el soport natiu està actualment en desenroll.

Vore també

• Mecanismes d'extensió de DNS permeten els paquets més grans que DNSSEC utilisa i el bit de senyalisació DO
• DNSCurve
• Privacitat digital