Compartir a través de

Validación y protección de respuestas DNS mediante DNSSEC

Los registros de recursos DNSSEC se usan para validar y proteger las respuestas DNS. Las zonas DNS se protegen con DNSSEC a través de la firma de zona. La firma de una zona agrega compatibilidad con la validación sin cambiar el mecanismo básico de una consulta y respuesta DNS. Para obtener una introducción de DNSSEC para el servidor DNS en Windows Server, consulte Introducción a DNSSEC.

Las firmas digitales se incluyen con respuestas DNS para proporcionar validación. Estas firmas digitales se incluyen en los registros de recursos relacionados con DNSSEC que se generan y se agregan a la zona durante la firma de zona.

DNS recursivo

Cuando un servidor DNSSEC recursivo o reenviado recibe una consulta de un cliente DNS para una zona firmada por DNSSEC, solicita al servidor DNS autoritativo que envíe también registros DNSSEC para validar la respuesta DNS. Un servidor DNS recursivo o reenviador reconoce que la zona admite DNSSEC si tiene una DNSKEY, también conocida como ancla de confianza, para esa zona.

Importante

Un servidor DNS no autoritativo puede usar recursividad o reenvío para resolver una consulta DNS. En este tema se hace referencia al servidor no autoritativo como un servidor DNS recursivo; si el servidor usa el reenvío, el proceso usado para la validación dnssec de las respuestas DNS es el mismo.

DNSKEY

Un servidor DNS recursivo usa el registro de recursos DNSKEY para validar las respuestas del servidor DNS autoritativo. Para validar las respuestas, el servidor DNS descifra las firmas digitales contenidas en los registros de recursos relacionados con DNSSEC y compara los valores hash. Si los valores hash son idénticos, proporciona una respuesta al cliente DNS con los datos DNS solicitados, como un registro de recursos de host (A). Si los valores hash no coinciden, responde con un mensaje de SERVFAIL. De este modo, un servidor DNS compatible con DNSSEC y con un delimitador de confianza válido instalado protege frente a ataques de suplantación de identidad DNS, independientemente de que los clientes DNS sean compatibles con DNSSEC o no.

Si el cliente DNS es compatible con DNSSEC, se puede configurar para requerir que el servidor DNS realice la validación de DNSSEC.

En la ilustración siguiente se muestra el proceso de validación.

Diagrama que muestra un resumen del proceso de validación de DNSSEC.

DNSKEYs se usan para calcular valores hash y descifrar registros RRSIG. La ilustración no muestra todos los procesos de validación que se realizan. También se lleva a cabo más validación para asegurarse de que los DNSKEY son válidos y que los registros DS son válidos, si existen (no se muestran en la captura de pantalla).

Proceso de consulta y respuesta de DNS

Un ejemplo sencillo muestra cómo puede incorporar DNSSEC en el proceso de consulta y respuesta dns para proporcionar validación.

En el ejemplo siguiente, un equipo cliente DNS consulta un servidor DNS recursivo (almacenamiento en caché), que a su vez consulta servidores DNS autoritativos antes de devolver una respuesta. En este ejemplo se supone que los datos DNS aún no se almacenan en caché en el cliente o servidor. Los datos DNSSEC validan las respuestas DNS como originales solo cuando se firma una zona y se usan clientes y servidores compatibles con DNSSEC.

En la ilustración siguiente se muestra el proceso de consulta DNS recursivo.

Diagrama que muestra el proceso de consulta DNS recursivo como se resume en la tabla siguiente.

En la tabla siguiente se muestran los pasos de una consulta y respuesta DNS con datos DNSSEC opcionales.

paso consulta-respuesta Datos opcionales de DNSSEC
1 Un cliente DNS envía una consulta DNS a un servidor DNS recursivo. El cliente DNS puede indicar que es compatible con DNSSEC (DO=1).
2 El servidor DNS recursivo envía una consulta DNS a los servidores DNS de dominio raíz y de nivel superior (TLD). El servidor DNS recursivo puede indicar que es compatible con DNSSEC (DO=1).
3 Los servidores raíz y TLD devuelven una respuesta DNS al servidor DNS recursivo que proporciona la dirección IP del servidor DNS autoritativo para la zona. Los servidores autoritativos de la zona padre pueden indicar que la zona hija está firmada usando DNSSEC e incluye una delegación segura (registro DS).
4 El servidor DNS recursivo envía una consulta DNS al servidor DNS autoritativo para la zona. El servidor DNS recursivo puede indicar que es compatible con DNSSEC (DO=1) y es capaz de validar los registros de recursos firmados (CD=1) que se enviarán en la respuesta.
5 El servidor DNS autoritativo devuelve una respuesta DNS al servidor DNS recursivo, proporcionando los datos del registro de recursos. El servidor DNS autoritativo puede incluir firmas DNSSEC en forma de registros RRSIG en la respuesta DNS, para su uso en la validación.
6 El servidor DNS recursivo devuelve una respuesta DNS al cliente DNS, proporcionando los datos del registro de recursos. El servidor DNS recursivo puede indicar si se validó o no la respuesta DNS (AD=1) mediante DNSSEC.

Inclusión de datos DNSSEC

Las marcas relacionadas con DNSSEC (bits) se usan en una consulta y respuesta DNS para determinar si se incluyen los datos DNSSEC y se ha realizado la validación. Estas marcas se establecen activando o desactivando los bits de datos extendidos en el encabezado del paquete DNS. Cuando estas marcas están activadas, se denomina "configuración" del bit (el valor se establece en 1). Al desactivar una marca se le conoce como "borrar" el bit (el valor se establece en 0).

  • DO: el bit DO se incluye en una consulta DNS y es una abreviatura de "DNSSEC OK". Si el bit de DO se establece (DO=1), el cliente es compatible con DNSSEC y es seguro que el servidor DNS devuelva datos DNSSEC en una respuesta. Si el bit DO no se establece (DO=0), el cliente no es compatible con DNSSEC y el servidor DNS no puede incluir ningún dato DNSSEC en una respuesta DNS. Los clientes DNS todavía se pueden proteger mediante DNSSEC incluso si no son compatibles con DNSSEC. En este contexto, un cliente DNS es cualquier equipo que envíe una consulta DNS. Cuando un servidor DNS recursivo envía una consulta al servidor DNS autoritativo, el servidor DNS recursivo debe indicar que es compatible con DNSSEC para que el servidor DNS autoritativo envíe datos DNSSEC en la respuesta.
  • AD: el bit de AD se incluye en una respuesta DNS y es una abreviatura de "datos autenticados". Si el bit de AD se establece (AD=1), significa que la respuesta DNS es auténtica porque se validó mediante DNSSEC. Un equipo que no admite DNSSEC, como uno que ejecuta Windows 8, no realiza la validación DNSSEC, pero se puede configurar para requerir que las respuestas DNS sean auténticas. Si no se establece el bit AD (AD=0), la respuesta DNS no fue validada. Es posible que el bit de AD no se establezca porque no se intentó la validación o porque se produjo un error en la validación.
  • CD: el bit de CD se incluye en una consulta DNS y es una abreviatura de "comprobación deshabilitada". Si el bit de CD se establece (CD=1) en una consulta, significa que se debe enviar una respuesta DNS, independientemente de si la validación se realizó con éxito o no. Si el bit de CD no se establece (CD=0), no se envía una respuesta DNS si se requería la validación y se produjo un error. Si el bit de CD está claro (CD=0), esto significa "comprobación activada" y puede producirse la validación de DNSSEC. El bit de CD puede establecerse (CD=1) en una consulta porque el host es capaz de realizar la validación de DNSSEC y no requiere validación ascendente, como un servidor DNS recursivo que ejecute Windows Server 2012 o posterior. Un resolutor stub sin validación, como un equipo que ejecuta el cliente DNS de Windows, emite consultas con el bit CD desactivado CD=0. Para obtener más información, vea RFC4035, sección 3.2.2.

Una cuarta marca importante (bit) que puede estar presente en un encabezado de paquete DNS es el bit AA. Esta marca no es nueva con DNSSEC, pero se puede usar cuando se implementa DNSSEC:

  • AA: el bit AA se incluye en una respuesta DNS y es una abreviatura de "respuesta autoritativa". Si se establece el bit AA, significa que la respuesta DNS es auténtica porque procede directamente de un servidor DNS autoritativo. Un cliente que requiere la validación de DNSSEC (AD=1) acepta el bit AA en su lugar (AA=1, AD=0). Si el cliente consulta directamente un servidor autoritativo porque no es necesario validar las respuestas autoritativas. Sería redundante que un servidor autoritativo valide su propia respuesta.

Consultas DNS de ejemplo

En los ejemplos siguientes se muestran los resultados de la consulta DNS que se realizan desde un equipo cliente DNS que ejecuta Windows 8.1 mediante el cmdlet Resolve-DnsName. El cmdlet Resolve-DnsName se introdujo en Windows Server 2012 y Windows 8 y se puede usar para mostrar consultas DNS que incluyen datos DNSSEC.

Importante

No use la herramienta de línea de comandos nslookup.exe para probar la compatibilidad con DNSSEC para una zona. La herramienta nslookup.exe usa un cliente DNS interno que no es compatible con DNSSEC.

ejemplo 1: en el ejemplo siguiente, se envía una consulta a un servidor DNS recursivo para un registro de dirección (A) en la zona firmada secure.contoso.com con DO=0.

Resolve-DnsName finance.secure.contoso.com –type A -server dns1.contoso.com


Name Type TTL Section IPAddress

---- ---- --- ------- ---------

finance.secure.contoso.com A 2848 Answer 192.168.0.200

El bit DO no se ha establecido porque no se incluyó el parámetro dnssecok.

ejemplo 2: en el ejemplo siguiente, se establece la marca DO=1 añadiendo el parámetro dnssecok de.

Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com -dnssecok

Name Type TTL Section IPAddress

---- ---- --- ------- ---------

finance.secure.contoso.com A 2848 Answer 192.168.0.200

Name : finance.secure.contoso.com

QueryType : RRSIG

TTL : 2848

Section : Answer

TypeCovered : A

Algorithm : 8

LabelCount : 4

OriginalTtl : 3600

Expiration : 10/18/2013 8:23:41 PM

Signed : 10/8/2013 7:23:41 PM

Signer : secure.contoso.com

Signature : {86, 229, 217, 39...}

Name : .

QueryType : OPT

TTL : 32768

Section : Additional

Data : {}

Cuando DO=0, el servidor DNS no envía datos DNSSEC en la respuesta DNS. Cuando DO=1, el cliente indica que puede recibir datos DNSSEC si están disponibles. Dado que la zona secure.contoso.com está firmada, se incluyó un registro de recursos RRSIG con la respuesta DNS cuando ocurrió el evento DO=1.

En el ejemplo 1 y en el ejemplo 2, la validación no es necesaria para la zona de secure.contoso.com porque la tabla de directivas de resolución de nombres (NRPT) no está configurada para requerir validación.

Puede usar el cmdlet Get-DnsClientNrptPolicy para ver las reglas de NRPT actuales. Para obtener más información, vea Get-DnsClientNrptPolicy.

ejemplo 3: en el ejemplo siguiente, se muestra una regla NRPT para secure.contoso.com.

Get-DnsClientNrptPolicy

Namespace : .secure.contoso.com

QueryPolicy :

SecureNameQueryFallback :

DirectAccessIPsecCARestriction :

DirectAccessProxyName :

DirectAccessDnsServers :

DirectAccessEnabled :

DirectAccessProxyType : NoProxy

DirectAccessQueryIPsecEncryption :

DirectAccessQueryIPsecRequired : False

NameServers :

DnsSecIPsecCARestriction :

DnsSecQueryIPsecEncryption :

DnsSecQueryIPsecRequired : False

DnsSecValidationRequired : False

NameEncoding : Utf8WithoutMapping

En este ejemplo, el valor de DnsSecValidationRequired es False. Cuando el valor es false, no se requiere la validación de DNSSEC.

ejemplo 4: con la validación de DNSSEC habilitada para secure.contoso.com, NRPT muestra true para DnsSecValidationRequired. En este ejemplo solo se muestra el espacio de nombres secure.contoso.com y el parámetro DnsSecValidationRequired.

(Get-DnsClientNrptPolicy -NameSpace secure.contoso.com).DnsSecValidationRequired

True

Si el valor de DnsSecValidationRequired es True , los equipos cliente compatibles con DNSSEC siempre envían consultas con DO=1, incluso si no se incluye el parámetro dnssecok .

Ejemplo 5: Cuando se requiere la validación de DNSSEC en la tabla de directivas de resolución de nombres (NRPT), el bit OK de DNSSEC se establece automáticamente (DO=1) para los clientes compatibles con DNSSEC.

Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com

Name Type TTL Section IPAddress

---- ---- --- ------- ---------

finance.secure.contoso.com A 2848 Answer 192.168.0.200

Name : finance.secure.contoso.com

QueryType : RRSIG

TTL : 2848

Section : Answer

TypeCovered : A

Algorithm : 8

LabelCount : 4

OriginalTtl : 3600

Expiration : 10/18/2013 8:23:41 PM

Signed : 10/8/2013 7:23:41 PM

Signer : secure.contoso.com

Signature : {86, 229, 217, 39...}

Name : .

QueryType : OPT

TTL : 32768

Section : Additional

Data : {}

En este ejemplo, se envía un registro RRSIG en la respuesta DNS para cumplir los requisitos de validación de secure.contoso.com. También se configura un anclaje de confianza válido en el servidor DNS recursivo dns1.contoso.com.

Si un cliente DNS no es compatible con DNSSEC, la regla NRPT no se aplica y las consultas se envían con DO=0, incluso si existe una regla NRPT que requiere la validación de DNSSEC.

ejemplo 6: en el ejemplo siguiente, se realiza la misma consulta que en el ejemplo 5, pero sin un anclaje de confianza válido configurado en dns1.contoso.com.

Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com

Resolve-DnsName : finance.secure.contoso.com : Unsecured DNS packet

At line:1 char:1

+ Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.co ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : ResourceUnavailable: (finance.secure.contoso.com:String) [Resolve-DnsName], Win32Excepti

on

+ FullyQualifiedErrorId : DNS\_ERROR\_UNSECURE\_PACKET,Microsoft.DnsClient.Commands.ResolveDnsName

En este ejemplo, se produce un error en la resolución DNS con el mensaje DNS_ERROR_UNSECURE_PACKET. Se produce un error en la resolución porque la validación es necesaria en NRPT, pero no se puede realizar debido a la falta de un anclaje de confianza válido para la zona secure.contoso.com. El cmdlet Resolve-DnsName informa de los resultados detallados del tipo de error detectado. Si el cliente DNS intenta resolver finance.secure.contoso.com para conectarse a este host, se produce un error.

Escenarios de DNSSEC

DNSSEC se puede implementar en muchos entornos diferentes con una configuración de cliente y servidor únicas, es importante comprender cómo se ven afectadas las consultas y respuestas DNS.

Considere las cuatro declaraciones siguientes relacionadas con DNSSEC. Cada instrucción afecta al funcionamiento de DNSSEC en un escenario determinado:

  • El registro de recursos finance.secure.contoso.com está firmado correctamente con DNSSEC.
  • Un servidor DNS recursivo es capaz de validar las respuestas a una consulta para finance.secure.contoso.com.
  • Un cliente DNS es compatible con DNSSEC.
  • Un cliente DNS está configurado para requerir validación para todas las consultas del espacio de nombres secure.contoso.com.

Consideremos cada una de estas cuatro declaraciones en más detalle.

  1. estado de firma de DNSSEC: DNSSEC firma todos los registros de la zona, esta condición hace referencia al estado de la zona secure.contoso.com, no solo al registro de recursos finance.secure.contoso.com. No puede firmar algunos registros y no firmar otros registros. Por lo tanto, el estado DNSSEC de finance.secure.contoso.com depende del estado DNSSEC de secure.contoso.com.

    • Firmado correctamente: la zona secure.contoso.com se puede firmar de forma válida, lo que permite validar finance.secure.contoso.com como original. Para que sea válido, la zona debe estar firmada con claves válidas, no expiradas y todos los registros de recursos relacionados con DNSSEC necesarios deben estar presentes.

    • no firmado: es posible que la zona secure.contoso.com no esté firmada, en cuyo caso no se puede validar ningún registro RRSIG asociado a finance.secure.contoso.comy las respuestas DNS a las consultas de finance.secure.contoso.com no se pueden validar. Si un cliente requiere validación, se produce un error en una consulta DNS enviada a un servidor DNS recursivo porque el cliente DNS no acepta una respuesta no validada. Si un cliente consulta directamente un servidor autoritativo, no se produce un error en la validación porque la respuesta ya se considera auténtica.

    • No firmado correctamente: la zona secure.contoso.com podría estar firmada, pero no de forma válida. Por ejemplo, una o varias claves de firma DNSSEC podrían expirarse. Después de firmar inicialmente una zona, la zona debe volver a firmarse periódicamente con nuevas claves antes de que expire el período de validez de la clave de firma, con el fin de mantener un estado operativo DNSSEC seguro. El período de validez de las claves de firma DNSSEC debe ser lo suficientemente corto como para mantener la seguridad, pero lo suficientemente largo como para permitir una administración sencilla. DNSSEC en Windows Server 2012 y Windows Server 2012 R2 admite la sustitución automática de claves, lo que proporciona seguridad y facilidad de administración para las zonas firmadas por DNSSEC.

  2. estado de validación: un servidor DNS recursivo con un ancla de confianza válida (clave criptográfica pública) para la zona secure.contoso.com es capaz de validar una respuesta DNS para el registro de recursos de finance.secure.contoso.com. Un servidor DNS recursivo también debe admitir los estándares y algoritmos DNSSEC que se usan para firmar la zona.

    • Puede validar: si el servidor DNS recursivo admite todos los algoritmos criptográficos usados para firmar la zona secure.contoso.com y tiene un anclaje de confianza válido que puede usar para descifrar la firma DNSSEC asociada al registro de recursos firmado, puede validar el registro de recursos finance.secure.contoso.com como original.

    • No se puede validar: un servidor DNS no compatible con DNSSEC no es capaz de validar. Del mismo modo, un servidor DNS que actualmente no tiene un delimitador de confianza válido para la zona secure.contoso.com, no es capaz de validar una respuesta DNS para finance.secure.contoso.com. Los anclajes de confianza deben actualizarse cuando se firma de nuevo una zona, por ejemplo, durante un cambio de claves. DNSSEC en Windows Server 2012 y Windows Server 2012 R2 admite la actualización automática de anclajes de confianza en la rotación de claves según el RFC 5011, "Actualizaciones automatizadas de anclajes de confianza de seguridad DNS (DNSSEC)".

  3. estado compatible con DNSSEC: el estado compatible con DNSSEC de un cliente DNS depende del sistema operativo que se está ejecutando. El servicio cliente DNS de Windows en Windows 7 o Windows Server 2008 R2 y sistemas operativos posteriores son solucionadores reconocedores de DNSSEC, pero no validan. Los sistemas operativos Windows anteriores no son compatibles con DNSSEC. El cliente DNS informa a un servidor DNS si es compatible o no con DNSSEC cuando envía una consulta DNS.

    • tanto el cliente como el servidor soncompatibles con DNSSEC: si tanto el cliente como el servidor son compatibles con DNSSEC, la respuesta DNS del servidor al cliente incluye la marca de datos autenticados (AD) de DNSSEC. Si la respuesta DNS se valida con DNSSEC, se envía AD=1. Si no se validó la respuesta DNS, se envía AD=0.

    • El servidor DNS no es compatible con DNSSEC: si el servidor DNS no es compatible con DNSSEC, no se realiza ninguna validación y la marca de AD no está establecida (AD=0) independientemente de si el cliente DNS es compatible con DNSSEC o no.

    • El cliente DNS no es compatible con DNSSEC: si el cliente DNS no es compatible con DNSSEC, el servidor DNS no establece la marca de AD en su respuesta al cliente aunque comprenda DNSSEC. Sin embargo, si el servidor DNS es compatible con DNSSEC y tiene un anclaje de confianza para la zona, el servidor intenta validar la respuesta del servidor autoritativo. Si se produce un error en la validación, devuelve un error de servidor DNS al cliente DNS. Si la validación se realiza correctamente, devuelve los resultados de la consulta al cliente. De este modo, un servidor DNS recursivo compatible con DNSSEC puede proteger clientes DNS no compatibles con DNSSEC. En este escenario, si la zona no está firmada, no se intenta validar y la respuesta se devuelve normalmente al cliente.

  4. requisito de validación: esta configuración determina el requerimiento de un cliente DNS consciente de DNSSEC para recibir datos DNSSEC (la señal AD) en una respuesta de un servidor DNS. Para que el cliente DNS requiera validación, debe tener en cuenta DNSSEC. Los clientes DNS no compatibles con DNSSEC no se pueden forzar para requerir la validación de DNSSEC. Si el cliente DNS está consultando directamente un servidor DNS autoritativo, la respuesta se valida, incluso si la zona no está firmada. Esto se debe a que los servidores DNS autoritativos siempre devuelven respuestas auténticas.

    • se requiere validación: si se requiere la validación, el cliente debe recibir AD=1 (validación correcta) o rechaza la respuesta DNS. Si la validación no se realizó correctamente o no se intentó (AD=0), se produce un error en la resolución dns. Esto es cierto incluso si la zona no está firmada. Esto solo se aplica a las consultas en un servidor DNS recursivo y no autoritativo.

    • validación no es necesaria: si no se requiere la validación, el cliente acepta una respuesta de un servidor DNS recursivo que no es compatible con DNSSEC. Sin embargo, si el servidor DNS recursivo es compatible con DNSSEC y se produce un error de validación, devuelve una conmutación por error de servidor al cliente aunque el cliente no requiera validación.

Pasos siguientes

Estos son algunos artículos para obtener más información sobre DNSSEC para el servidor DNS.