[1] El diseño original del Domain Name System (DNS) no incluía la seguridad pues su objetivo de desarrollo estuvo enfocado en ser un sistema distribuido escalable.
La firma digital puede ser verificada localizando la clave pública correcta se encuentra en un registro DNSKEY.
[11] Un stub resolver validante utiliza el CD bit para llevar a cabo su propia autenticación recursiva.
Para que los stub resolver no validante puedan confiar realmente en servicios DNSSEC, el stub resolver debe confiar tanto en los servidores de nombres recursivos en cuestión (los que suele ser controlados por el ISP) y los canales de comunicación entre él y los servidores de nombres, utilizando métodos tales como IPsec, SIG(0), o TSIG.
Cuando una nueva KSK se crea, el registro DS debe ser transferido a la zona superior y publicado allí.
Los nuevos protocolos permitirán a garantías adicionales y limitaciones para el modelo tradicional basado en la Infraestructura de clave pública.
Así comenzó la investigación para securitizar la información y aumentó drásticamente cuando su trabajo se hizo público en 1995.
Así, DNSSEC como se define en el RFC 2535 no pudo escalar hasta la Internet.
La IETF modificó sustancialmente DNSSEC, que se llama DNSSEC-bis cuando es necesario distinguirlo del enfoque original de la RFC 2535.
En el nuevo enfoque, cuando un dependiente cambia de clave pública maestra, en lugar de tener que enviar seis mensajes para cada registro, hay un simple mensaje: el dependiente envía la nueva clave pública a su superior (firmado, por supuesto).
La mayoría ve esto como un pequeño precio a pagar, ya que cambia DNSSEC y lo hace mucho más práctico de implementar.
[20] Cuando el protocolo DNS fue diseñado, no estaba destinado a ser un repositorio de información oculta.
El ampliamente utilizado libro de DNS and BIND (4 ª edición) por Albitz y Liu lo explica así: Además, la información de una zona enumerada se puede utilizar como una clave para múltiples consultas WHOIS, lo que podría revelar datos del registrante, lo que muchos registros deben proteger, ya que están bajo estrictas obligaciones legales en virtud de diversos contratos.
No está claro si es legal implementar DNSSEC en muchos países, a menos que dichas listas se puedan mantener en privado.
[22] DNSSEC presentó este problema, ya que debe ser capaz de informar cuando un nombre "no" es encontrado.
Sin embargo, los registradores y muchas organizaciones grandes dijeron a los miembros del grupo de trabajo que DNSSEC como se definía actualmente era inaceptable y que no haría o legalmente no podrían utilizarlo.
Si la consulta siguiente se refiere a 'ba.example.com', la respuesta podría ser "no hay nombres entre ba.example.com y baa.example.com '.
Algunos servidores autorizados deben ser accesibles desde Internet y, preferiblemente, éstas estarán muy dispersas, haciendo difícil mantener las claves bajo control.
Después de deliberar, se desarrolló una extensión: "DNSSEC Hashed Authenticated Denial of Existence" (informalmente llamado "NSEC3").
Internet es infraestructura crítica, sin embargo, su funcionamiento depende del DNS que es fundamentalmente inseguro.
DNSSEC se puede implementar en cualquier nivel de la jerarquía DNS, pero debe ser ampliamente disponible en una zona antes que muchos otros van a querer adoptarlo.
Las respuestas DNSSEC firmadas comunes son mucho más grandes que el tamaño por defecto UDP de 512 bytes.
Algunas extensiones de protocolo, como TCP Cookie Transactions, han sido desarrollados para reducir esta carga.
[27] en febrero de 2007 TDC se convirtió en el primer ISP sueco para comenzar a ofrecer esta característica para sus clientes.
[33] VeriSign hizo un proyecto piloto para permitir que los dominios .com y .net para inscribirse con el fin de experimentar con NSEC3.
[41] No está claro si los comentarios recibidos afectaron el diseño final del plan de implementación.
Esta zona contiene los registros DLV;[54] éstos tienen exactamente el mismo formato que los registros DS, pero en lugar de referirse a una sub-zona delegada, se refieren a una zona en otro lugar en el árbol DNS.
DHS también financia esfuerzos para madurar DNSSEC y conseguir que se despliegue dentro del gobierno federal de Estados Unidos.
[61] Varios proveedores de Internet han comenzado a implementar resolvers recursivas DNS con validación DNSSEC.
[66] Se ha sabido que Exchange 2013 y versiones anteriores tienen un problema, donde la búsqueda de registros MX causa errores #550 4.4.7 QUEUE.Expired.