Usa DNSSEC avanzadas

En esta página, se proporcionan varias opciones de configuración de las extensiones de seguridad del sistema de nombres de dominio (DNSSEC) avanzadas que puedes usar si habilitas DNSSEC en tus zonas administradas. Estas opciones abarcan desde algoritmos de firma diferentes y denegación de existencia hasta la capacidad de usar tipos de registros que requieren o recomiendan DNSSEC para su uso.

Para ver una descripción general conceptual de DNSSEC, consulta Descripción general de DNSSEC.

Delega subdominios con firma de DNSSEC

Puedes habilitar DNSSEC para los subdominios delegados después de haber habilitado DNSSEC en tu dominio principal. Para habilitar DNSSEC en subdominios delegados, primero crea un registro DS dentro de una zona de Cloud DNS. También debes crear uno o más registros NS.

A fin de crear registros DS para subdominios delegados, debes obtener el registro DS para la zona. Si la zona delegada también se aloja en Cloud DNS, puedes obtener el registro DS desde la consola de Google Cloud o desde Google Cloud CLI.

Console

1. En la consola de Google Cloud, ve a la página de Cloud DNS.

   Ve a Cloud DNS

2. Navega a la zona administrada para la cual deseas ver el registro DS.

3. Para ver el registro DS de la zona, en la esquina superior derecha de la página Detalles de la zona, haz clic en Configuración de registrador.

4. El registro DS está disponible en la página Configuración del registrador.

5. Para crear registros NS, sigue las instrucciones en Agrega un registro.

gcloud

1. Para obtener la información del registro de DS de los subdominios delegados, ejecuta el siguiente comando:

   gcloud dns dns-keys list --zone EXAMPLE_ZONE
   

   Reemplaza EXAMPLE_ZONE por el nombre de la zona DNS del subdominio delegado en tu proyecto.

   El resultado luce de la siguiente manera:

   ID  KEY_TAG  TYPE          IS_ACTIVE  DESCRIPTION
   0   1234     KEY_SIGNING   True
   1   12345    ZONE_SIGNING  True
   

2. Para obtener un registro DS completo y todos los detalles de la clave, necesitas el ID de la clave KEY_SIGNING (KSK), que suele ser cero (0). Ejecuta el siguiente comando:

   gcloud dns dns-keys describe --zone EXAMPLE_ZONE KSK_ID \
      --format "value(ds_record())"
   

   Reemplaza lo siguiente:

   • EXAMPLE_ZONE: el nombre de la zona DNS del subdominio delegado de tu proyecto
   • KSK_ID: el número de ID de KSK, por lo general, es 0

   El resultado es similar al siguiente:

   44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
   

3. Copia el resultado del comando anterior para usarlo en un paso posterior.

4. Para crear los registros DS para una subdelegación segura, ejecuta el siguiente comando a fin de iniciar la transacción:

   gcloud dns record-sets transaction start --zone EXAMPLE_ZONE
   

   Reemplaza EXAMPLE_ZONE por el nombre de la zona DNS superior en tu proyecto en la que crees los registros para el subdominio delegado.

   El resultado luce de la siguiente manera:

   Transaction started [transaction.yaml].
   

5. Luego, ejecuta el comando siguiente para agregar un conjunto de registros:

   gcloud dns record-sets transaction add --zone EXAMPLE_ZONE \
      --ttl TIME_TO_LIVE \
      --type DS \
      --name subdomain.example.com \
      "DS_RECORD_AND_KEY"
   

   Reemplaza lo siguiente:

   • EXAMPLE_ZONE: el nombre de la zona DNS superior en tu proyecto
   • TIME_TO_LIVE: tiempo de actividad para la zona en segundos, como 3,600
   • subdomain.example.com: un subdominio del nombre de DNS de la zona
   • DS_RECORD_AND_KEY: el registro DS y la clave que usaste en el paso 2, como 44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb

   El resultado luce de la siguiente manera:

   44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
   Record addition appended to transaction at [transaction.yaml].
   

6. Para agregar registros NS, usa el siguiente comando:

   gcloud dns record-sets transaction add --zone EXAMPLE_ZONE \
      --ttl TIME_TO_LIVE \
      --type NS \
      --name subdomain.example.com \
   

   Reemplaza lo siguiente:

   • EXAMPLE_ZONE: el nombre de la zona DNS superior en tu proyecto
   • TIME_TO_LIVE: tiempo de actividad para la zona en segundos, como 3,600
   • subdomain.example.com: un subdominio del nombre de DNS de la zona

7. Ingresa los siguientes RRData:

   ns-cloud-e1.googledomains.com. \
   ns-cloud-e2.googledomains.com. \
   ns-cloud-e3.googledomains.com. \
   ns-cloud-e4.googledomains.com.
   

   Nota: La elección de servidores de nombres para el registro NS depende en el que se fragmentó el servidor de nombres al que se asignó el subdominio delegado cuando se creó. Esta información se puede ver en el cuadro de diálogo anterior Configuración del registrador, los detalles de registro de DS y NS necesarios aparecen juntos.

   El resultado luce de la siguiente manera:

   Record addition appended to transaction at [transaction.yaml].
   

8. Para ejecutar la transacción, usa el siguiente comando:

   gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE
   

   Reemplaza EXAMPLE_ZONE por el nombre de una zona de DNS de tu proyecto.

   El resultado luce de la siguiente manera:

   Executed transaction [transaction.yaml] for managed-zone [dns-example].
   Created     [https://dns.googleapis.com/dns/v1/projects/example/managedZones/example_zone/changes/42].
   ID  START_TIME                STATUS
   42  2019-08-08T23:12:49.100Z  PENDING
   

Usa opciones de firma avanzadas

Cuando se habilita DNSSEC para una zona administrada o se crea una zona administrada con DNSSEC, puedes seleccionar los algoritmos de firma DNSSEC y el tipo de denegación de existencia.

Puedes cambiar la configuración de DNSSEC (por ejemplo, al algoritmo utilizado para firmar de forma criptográfica los registros) de una zona administrada antes de habilitar DNSSEC. Si las DNSSEC ya están habilitadas para una zona administrada, a fin de realizar cambios, primero inhabilita DNSSEC, realiza los cambios necesarios y, luego, usa el siguiente comando para volver a habilitar DNSSEC:

gcloud dns managed-zones update EXAMPLE_ZONE --dnssec-state on

Reemplaza EXAMPLE_ZONE por el nombre de una zona de DNS de tu proyecto.

Si deseas conocer más detalles, consulta Habilita DNSSEC para zonas administradas.

Nota: Si deseas que tu dominio se resuelva mientras las DNSSEC están inhabilitadas, primero debes desactivar las DNSSEC para tu zona en tu registrador de dominios para asegurarte de que los agentes de resolución que validan DNSSEC aún pueden resolver nombres en la zona. Si deseas conocer más detalles, consulta Inhabilita DNSSEC para zonas administradas.

El siguiente comando habilita DNSSEC con NSEC y ECDSA de 256 bits para los paquetes de respuesta con firma DNSSEC más pequeños posibles con Cloud DNS:

gcloud dns managed-zones update EXAMPLE_ZONE \
  --dnssec-state on \
  --ksk-algorithm ECDSAP256SHA256 --ksk-key-length 256 \
  --zsk-algorithm ECDSAP256SHA256 --zsk-key-length 256 \
  --denial-of-existence NSEC

Reemplaza EXAMPLE_ZONE por el nombre de una zona de DNS de tu proyecto.

Si proporcionas cualquiera de los algoritmos KSK o ZSK, o las longitudes de clave, debes proporcionarlos todos y sus argumentos en el comando:

--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length

Puedes especificar la denegación de existencia como NSEC o NSEC3, independientemente de los algoritmos.

Los argumentos y las opciones de algoritmos admitidos se enumeran en la siguiente tabla. Cloud DNS no permite el uso de ningún otro algoritmo o parámetro.

Algoritmo	Longitudes de KSK	Longitudes de ZSK	Comentarios
RSASHA256	2,048	1024, 2048
RSASHA512	2,048	1024, 2048	No es ampliamente admitido.
ECDSAP256SHA256	256	256
ECDSAP384SHA384	384	384	No es ampliamente admitido.

Si no se especifica ningún algoritmo, Cloud DNS usará estos valores predeterminados:

Tipo de clave	Algoritmo predeterminado	Longitud de la clave predeterminada
Clave de firma de claves (KSK)	RSASHA256	2,048
Clave de firma de zona (ZSK)	RSASHA256	1024

Las diferencias de seguridad y rendimiento entre RSASHA256 y RSASHA512 son mínimas, y los tamaños de las respuestas firmadas son idénticos. Las longitudes de las claves son importantes: las teclas más largas son más lentas y las respuestas son más grandes (consulta los análisis de tamaño de respuesta para las zona raíz y los TLD, y un análisis del rendimiento del servidor en Windows).

La compatibilidad de los agentes de resolución con ECDSA se limita a los sistemas relativamente recientes. Los agentes de resolución más antiguos que no pueden validar las zonas con firma ECDSA las consideran no firmadas, lo que puede resultar no seguro si usas tipos de registros nuevos que se basan en DNSSEC. La compatibilidad de los registradores y registros con ECDSA de 256 bits es común, pero no universal. Solo algunos registros y hasta menos registradores admiten el ECDSA de 384 bits. El uso de ECDSA puede ser eficaz si no necesitas la compatibilidad con los clientes más antiguos; las firmas son mucho más pequeñas y fáciles de procesar.

Evita usar algoritmos diferentes para KSK y ZSK en tus zonas administradas, ya que reduce la compatibilidad y puede comprometer la seguridad. Algunos agentes de resolución de validación de DNSSEC pueden fallar en la validación de zonas con algoritmos DNSKEY que no se usan para firmar todos los registros de la zona. Esto es así, aunque RFC 6840 dice: “no deben insistir en que todos los algoritmos ... en el RRset de DNSKEY funcionan”. Si esto no es un problema (la mayoría de los agentes de resolución de validación siguen el protocolo RFC 6840), puedes usar RSASHA256 para KSK y ECDSA para ZSK si el registrador de dominios o el registro de TLD no admite ECDSA y necesitas tamaños de respuesta reducidos.

NSEC3 es el tipo predeterminado de denegación de existencia; ofrece protección limitada contra los intrusos que intentan descubrir todos los registros de tu zona. La configuración de NSEC3PARAM es fija: el opt-out de NSEC3 está inhabilitado por seguridad, y hay una iteración de hash adicional (para un total de dos) con una falla de 64 bits.

NSEC tiene respuestas ligeramente más pequeñas, pero no dispone de protección contra las intrusiones en la zona. El uso de NSEC también puede reducir las consultas para dominios inexistentes. DNS público de Google y varios otros agentes de resolución que validan DNSSEC pueden synthesize de respuestas negativas de los registros de la NSEC almacenados en caché sin consultar Zona de Cloud DNS.

RFC 8624 contiene orientación adicional sobre la selección del algoritmo.

Usa los nuevos tipos de registro DNS con las zonas protegidas por DNSSEC

Una vez que tu dominio esté totalmente protegido mediante DNSSEC, puedes comenzar a usar varios tipos nuevos de registros DNS que usan la garantía de autenticidad y la garantía de integridad de las zonas con firma de DNSSEC para mejorar la seguridad de otros servicios.

SSHFP

Los registros SSHFP contienen una huella digital de una clave pública del servidor SSH que las aplicaciones cliente SSH pueden usar para validar los servidores SSH. Por lo general, los clientes SSH requieren la interacción del usuario para confirmar la clave pública del servidor en la primera conexión y generar advertencias si se cambia la clave. Un cliente SSH configurado para usar SSHFP siempre emplea la clave que se encuentra en un registro SSHFP del servidor para ese servidor. Solo las claves de los servidores sin un registro SSHFP se guardan para reutilizarlas.

El formato del registro SSHFP es el siguiente:

• Número de algoritmo
• Número de tipo de huella digital
• Huella digital de la clave del servidor

Los números de algoritmo para SSH son los siguientes:

1. RSA
2. DSA
3. ECDSA
4. ED25519

Los tipos de huellas digitales son los siguientes:

• SHA-1 (obsoleta, solo para compatibilidad)
• SHA-256

Precaución: El uso incorrecto de los registros SSHFP puede tener graves consecuencias para la seguridad. Sigue estas reglas a fin de evitar generar vulnerabilidades de seguridad:

• No crees registros SSHFP en una zona sin protección de DNSSEC.
• Nunca configures clientes SSH para que usen SSHFP en un dominio sin protección de DNSSEC.
• Nunca configures clientes SSH para que usen SSHFP, a menos que validen DNSSEC o empleen un agente de resolución de validación como DNS público de Google.

El incumplimiento de estas reglas podría permitir a los adversarios crear registros SSHFP falsos para tus servidores a fin de robarles la identidad, lo que hace que sus conexiones SSH a los servidores sean inseguras y vulnerables a ataques.

StackExchange tiene sugerencias para crear registros SSHFP y existen herramientas que los generan mediante el análisis de servidores, el uso de archivos de hosts conocidos existentes o la administración de la configuración. Para ver más ejemplos y vínculos, consulta Registros SSHFP: DNS que proporciona claves de host SSH públicas.

TLSA y DANE

Los registros TLSA contienen información que se puede usar para validar certificados X.509 (como los certificados que usa HTTPS) sin depender de la firma de uno de los conjuntos de autoridades certificadas (CA) preconfiguradas.

Esto te permite configurar tus propias CA y generar certificados para HTTPS. Esto también permite la validación de certificados para protocolos como SMTP en los que las CA de confianza preconfiguradas no suelen ser compatibles con las aplicaciones.

Precaución: No crees registros TLSA en una zona sin protección DNSSEC. La mayoría de las aplicaciones que usan registros TLSA requieren la validación de DNSSEC, por lo que la creación de tales registros no tiene efecto. Sin embargo, puede crear una vulnerabilidad en aplicaciones configuradas incorrectamente.

DANE (autenticación de dominio de entidades con nombre), como se especifica en RFC 6698 y relacionados, usa los registros TLSA de formas específicas para proteger muchos protocolos y aplicaciones. El IETF Journal and Internet Society tiene una guía introductoria útil artículo y la descripción general de la DANE.

HTTPS

La DANE te permite configurar de forma segura servidores HTTPS mediante certificados generados con tu propia infraestructura de AC basada en OpenSSL o CFSSL de Cloudflare.

El validador de DANE para servidores HTTPS de SIDNLabs permite realizar pruebas en una implementación de DANE destinada a HTTPS.

Verificación de certificados TLS SMTP (correo electrónico)

El protocolo de correo electrónico SMTP es vulnerable a ataques de reducción de nivel que inhabilitan la encriptación, y la DANE proporciona una forma de prevenir estos ataques.

La Internet Society posee un instructivo de dos partes sobre cómo usar la DANE para SMTP con los certificados gratuitos y automatizados disponibles en Let's Encrypt, incluidos los consejos para evitar usar ciertos formatos de registro TLSA con los certificados de Let's Encrypt:

• Parte 1
• Parte 2

Puedes encontrar consejos excelentes (y un validador de dominios de DANE para HTTPS y SMTP) en Errores comunes. El prueba tu validador de correos electrónicos también comprueba la DANE.

Verificación de certificados TLS XMPP (chat de Jabber)

XMPP (y otros servicios que usan registros SRV) también pueden aprovechar la DANE. Un ejemplo de XMPP usa la configuración DANE-SRV como se especifica en la RFC 7673.

Asociación de clave pública de TXT (OpenPGP/GnuPG)

Los registros TXT se pueden usar sin DNSSEC, pero los registros TXT con firma de DNSSEC proporcionan una mayor confianza en su autenticidad. Esto es importante para la publicación con base en DNS de claves públicas OpenPGP (GnuPG), que no están firmadas por partes conocidas como las CA de X.509.

Por ejemplo, si Alice publica un registro TXT como el siguiente en la zona an.example con firma de DNSSEC y aloja una copia de la clave pública con protección de ASCII en el URI, Bob puede buscar una clave OpenPGP para [e-mail] con seguridad razonable (esto no reemplaza la validación de Web de confianza, pero permite la encriptación de OpenPGP con partes antes desconocidas):

    alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"

Puedes usar estas instrucciones para generar estos registros TXT de Versión 1 PKA (como se llaman en Claves de publicación en DNS).

Guía completa para publicar claves de PGP en DNS explica cómo crear registros CERT de OpenPGP (pero Cloud DNS no admitir registros CERT o OPENPGPKEY).

Si registraste tu clave OpenPGP en Keybase.io, no necesitas alojar la clave en tu propio servidor. En su lugar, puedes usar una URL como https://keybase.io/KEYBASE_USERNAME/key.asc (reemplaza KEYBASE_USERNAME por tu nombre de usuario de Keybase.io).

Si subiste tu clave de OpenPGP a un servidor de claves, también puedes usar un URI hkp: para ese servidor de claves, como hkp://subkeys.pgp.net o hkp://pgp.mit.edu, aunque es posible que los usuarios que están detrás de los firewalls que bloquean el puerto 11371 no tengan acceso (algunos servidores de clave proporcionan URL HTTP para el puerto 80).

TXT (SPF, DKIM y DMARC)

A continuación, se muestran otros tres tipos de registros TXT que puedes usar para asegurar tus servicios de correo electrónico y evitar que los generadores de spam y los estafadores envíen un correo electrónico que aparente provenir de tu dominio (aunque no sea así):

• SPF: Especifica los servidores SMTP (por nombre de dominio o dirección IP) que pueden enviar correos electrónicos para un dominio.

• DKIM: Publica un conjunto de claves públicas que se usan para verificar que el correo electrónico se envíe desde un dominio y para evitar que los mensajes se modifiquen en tránsito.

• DMARC: Especifica las políticas de dominio, los informes para la validación de SPF y DKIM, y los informes de errores.

Si deseas verificar que tu dominio está correctamente configurado para usar estos tres tipos de registros, puedes usar Prueba tu validador de correos electrónicos. Para encontrar consejos útiles sobre cómo configurar registros SPF, consulta Preguntas frecuentes sobre errores comunes.

Otros tipos de conjuntos de recursos mejorados con DNSSEC

Además de TXT, existen algunos otros tipos de conjuntos de registros que se benefician de DNSSEC, aunque no lo requieren.

CAA

Los conjuntos de registros de autorización de la autoridad certificadora (CAA) te permiten controlar qué CA públicas pueden generar TLS o, también, otros certificados para tu dominio. Este control es más útil (y eficaz) si deseas asegurarte de que una Public CA que emite certificados validados por el dominio (DV) (como LetsEncrypt.org) no emite certificados para tu dominio.

Un registro CAA típico tiene un formato simple como 0 issue "best-ca.example" que permite que la CA best-ca.example (y ninguna otra CA) emita certificados para los nombres del dominio en el que se encuentra el conjunto de registros de CAA. Si quieres permitir que varias CA emitan certificados, crea varios registros de CAA.

La RFC 6844 proporciona más detalles sobre el uso del tipo de conjunto de registros de CAA y recomienda enfáticamente el uso de DNSSEC.

IPSECKEY

También puedes habilitar la encriptación oportunista a través de túneles IPsec con la publicación de registros IPSECKEY. La implementación de VPN con IPsec de strongSwan tiene un complemento que usa registros IPSECKEY.

Además de colocar registros IPSECKEY en las zonas de reenvío habituales, como service.example.com, RFC 4025 sección 1.2 requiere puertas de enlace de seguridad para buscar registros IPSECKEY en las zonas inversas ip6.arpa y in-addr.arpa.

La compatibilidad de DNSSEC con las zonas inversas es menos común que con las zonas de reenvío, y requiere un proveedor de servicios de Internet (ISP) que implemente DNSSEC. Sin embargo, existen algunos ISP que pueden admitir DNSSEC para delegaciones de zonas inversas.

Las zonas inversas para las direcciones IP externas de las VM de Compute Engine aún no admiten la delegación.

¿Qué sigue?

• Para crear, actualizar, enumerar y borrar zonas administradas, consulta Administra zonas.
• Para encontrar soluciones a problemas comunes que podrías tener cuando usas Cloud DNS, consulta Solución de problemas.
• Para obtener una descripción general de Cloud DNS, consulta Descripción general de Cloud DNS.