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 está alojada en Cloud DNS, puedes obtener el registro DS desde la consola de Google Cloud o desde Google Cloud CLI.

Consola

  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.

Página de configuración del registrador

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.
    

    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.

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.

Las opciones y argumentos del algoritmo 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 claves más largas son más lentas y las respuestas son más extensas (consulta los análisis de tamaño de respuesta para la 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 se aplica aunque en RFC 6840 se indique que "no deben insistir en que todos los algoritmos…en el DNSKEY RRset 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 analizar las respuestas negativas de los registros NSEC almacenados en caché sin consultar tu zona de Cloud DNS.

RFC 8624 contiene orientación adicional sobre la selección de algoritmos.

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

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.

La DANE (autenticación de dominio de entidades con nombre), como se especifica en la RFC 6698 y en las RFC relacionadas, usa los registros TLSA de maneras específicas para proteger muchos protocolos y aplicaciones. El IETF Journal y la Internet Society tienen un artículo introductorio útil y una 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 CA 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:

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 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 alice@an.example 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 instructions para generar estos registros TXT de Versión 1 PKA (como se llaman en Claves de publicación en DNS).

En la guía completa para publicar claves de PGP en DNS, se explica cómo crear registros CERT de OpenPGP (pero Cloud DNS no admite registros CERT ni 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, la sección 1.2 de la RFC 4025 requiere que las puertas de enlace de seguridad busquen los 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?