Utilice DNSSEC avanzado

Esta página ofrece varias opciones avanzadas de configuración de las Extensiones de Seguridad del Sistema de Nombres de Dominio (DNSSEC) que puede usar si habilita DNSSEC para sus zonas administradas. Estas opciones abarcan desde diferentes algoritmos de firma y denegación de existencia hasta la posibilidad de usar tipos de registro que requieren o recomiendan DNSSEC.

Para obtener una descripción general conceptual de DNSSEC, consulte Descripción general de DNSSEC .

Delegar subdominios firmados por DNSSEC

Puede habilitar DNSSEC para subdominios delegados después de haberlo hecho para su dominio principal. Para habilitar DNSSEC para subdominios delegados, primero cree un registro DS dentro de una zona DNS en la nube. También debe crear uno o más registros NS.

Para crear registros DS para subdominios delegados, debe obtener el registro DS de la zona. Si la zona delegada también está alojada en Cloud DNS, puede obtener el registro DS desde Google Cloud consola o desde la CLI de Google Cloud.

Consola

  1. En el Google Cloud consola, vaya a la página Cloud DNS .

    Ir a Cloud DNS

  2. Navegue a la zona administrada para la cual desea ver el registro DS.

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

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

  5. Para crear registros NS, siga las instrucciones en Agregar un registro .

Página de configuración del registrador

nube g

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

    gcloud dns dns-keys list --zone EXAMPLE_ZONE

    Reemplace EXAMPLE_ZONE con el nombre de la zona DNS del subdominio delegado en su proyecto.

    El resultado se parece al siguiente:

    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, necesita el ID de la clave KEY_SIGNING (KSK), que suele ser cero (0). Ejecute el siguiente comando:

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

    Reemplace lo siguiente:

    • EXAMPLE_ZONE : el nombre de la zona DNS del subdominio delegado en su proyecto
    • KSK_ID : el número de identificación de KSK, normalmente 0

    El resultado será similar al siguiente:

    44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb

  3. Copie la salida del comando anterior para usarlo en un paso posterior.

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

    gcloud dns record-sets transaction start --zone EXAMPLE_ZONE

    Reemplace EXAMPLE_ZONE con el nombre de la zona DNS principal en su proyecto donde está creando los registros para el subdominio delegado.

    El resultado se parece al siguiente:

    Transaction started [transaction.yaml].

  5. A continuación, ejecute el siguiente comando 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"

    Reemplace lo siguiente:

    • EXAMPLE_ZONE : el nombre de la zona DNS principal en su proyecto
    • TIME_TO_LIVE : tiempo de vida de la zona en segundos, como 3600
    • subdomain.example.com : un subdominio del nombre DNS de la zona
    • DS_RECORD_AND_KEY : el registro DS y la clave que obtuvo en el paso 2, como 44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb

    El resultado se parece al siguiente:

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

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

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

    Reemplace lo siguiente:

    • EXAMPLE_ZONE : el nombre de la zona DNS principal en su proyecto
    • TIME_TO_LIVE : tiempo de vida de la zona en segundos, como 3600
    • subdomain.example.com : un subdominio del nombre DNS de la zona

  7. Introduzca los siguientes datos RRData: 

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

    El resultado se parece al siguiente: 

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

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

    gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE

    Reemplace EXAMPLE_ZONE con el nombre de una zona DNS en su proyecto.

    El resultado se parece al siguiente: 

    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

Utilice opciones de firma avanzadas

Al habilitar DNSSEC para una zona administrada, o crear una zona administrada con DNSSEC, puede seleccionar los algoritmos de firma DNSSEC y el tipo de denegación de existencia.

Puede cambiar la configuración de DNSSEC (por ejemplo, el algoritmo utilizado para firmar criptográficamente los registros) para una zona administrada antes de habilitar DNSSEC. Si DNSSEC ya está habilitado para una zona administrada, para realizar cambios, primero deshabilítelo, realice los cambios necesarios y luego use el siguiente comando para volver a habilitarlo: 

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

Reemplace EXAMPLE_ZONE con el nombre de una zona DNS en su proyecto.

Para obtener más detalles, consulte Habilitar DNSSEC para zonas administradas existentes .

El siguiente comando habilita DNSSEC con ECDSA de 256 bits y NSEC para los paquetes de respuesta firmados con DNSSEC más pequeños posibles utilizando 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

Reemplace EXAMPLE_ZONE con el nombre de una zona DNS en su proyecto.

Si proporciona algún algoritmo KSK o ZSK o longitudes de clave, debe proporcionarlos todos y sus argumentos en el comando: 

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

Puede especificar la negación de existencia como NSEC o NSEC3 independientemente de los algoritmos.

Las opciones y argumentos de algoritmos compatibles se enumeran en la siguiente tabla. Cloud DNS no permite el uso de otros algoritmos ni parámetros.

Algoritmo Longitudes KSK Longitudes ZSK Comentarios
RSASHA256 2048 1024, 2048
RSASHA512 2048 1024, 2048 No cuenta con amplio apoyo
ECDSAP256SHA256 256 256
ECDSAP384SHA384 384 384 No cuenta con amplio apoyo

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

Tipo de clave Algoritmo predeterminado Longitud de clave predeterminada
Clave de firma de clave (KSK) RSASHA256 2048
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 respuesta firmados son idénticos. La longitud de las claves es importante: las claves más largas son más lentas y las respuestas son más largas (véanse los análisis del 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 resolvedores con ECDSA se limita a sistemas relativamente recientes. Los resolvedores más antiguos que no pueden validar zonas firmadas con ECDSA las consideran sin firmar, lo cual puede resultar inseguro si se utilizan nuevos tipos de registro que dependen de DNSSEC . La compatibilidad de registradores y registros con ECDSA de 256 bits es común, pero no universal. Solo unos pocos registros, e incluso menos, admiten ECDSA de 384 bits. Usar ECDSA puede ser eficaz si no se necesita compatibilidad con clientes más antiguos; las firmas son mucho más pequeñas y se calculan con mayor rapidez.

Evite usar algoritmos diferentes para KSK y ZSK en sus zonas administradas; esto reduce la compatibilidad y puede comprometer la seguridad. Algunos resolutores de validación DNSSEC pueden fallar la validación en zonas con algoritmos DNSKEY que no se utilizan para firmar todos los registros de la zona. Esto es cierto a pesar de que la RFC 6840 indica que « no deben insistir en que todos los algoritmos... del conjunto de registros DNSKEY funcionen». Si esto no le preocupa (la mayoría de los resolutores de validación cumplen con la RFC 6840), puede usar RSASHA256 para KSK y ECDSA para ZSK si su registrador de dominio o registro de TLD no admite ECDSA y necesita tamaños de respuesta reducidos.

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

NSEC ofrece respuestas ligeramente menores, pero no ofrece protección contra el desplazamiento de zona. Usar NSEC también puede reducir las consultas a dominios inexistentes. Google Public DNS y otros solucionadores que validan DNSSEC pueden sintetizar respuestas negativas de registros NSEC en caché sin consultar la zona de Cloud DNS.

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

Utilice nuevos tipos de registros DNS con zonas protegidas por DNSSEC

Una vez que su dominio esté completamente protegido con DNSSEC, puede comenzar a utilizar varios tipos de registros DNS nuevos que utilizan las garantías de autenticidad e integridad de las zonas firmadas con DNSSEC para mejorar la seguridad de otros servicios.

SSHFP

Los registros SSHFP contienen la huella digital de la clave pública de un servidor SSH, que las aplicaciones cliente SSH pueden usar para validar los servidores SSH. Los clientes SSH suelen requerir la interacción del usuario para confirmar la clave pública del servidor en la primera conexión y generar advertencias si se modifica. Un cliente SSH configurado para usar SSHFP siempre utiliza la clave del registro SSHFP de un servidor; solo se guardan para su reutilización las claves de los servidores sin registro SSHFP.

El formato de registro SSHFP es el siguiente:

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

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

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

Los tipos de huellas dactilares son los siguientes:

  • SHA-1 ( obsoleto, solo por compatibilidad )
  • SHA-256

StackExchange ofrece sugerencias para crear SSHFP y existen herramientas para generarlos mediante el escaneo de servidores, el uso de archivos de host conocidos o la gestión de la configuración . Para más ejemplos y enlaces, consulte 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 utilizados por HTTPS) sin depender de una de un conjunto preconfigurado de autoridades de certificación (CA) que los firmen.

Esto le permite configurar sus propias CA y generar certificados para HTTPS. También permite la validación de certificados para protocolos como SMTP, donde normalmente no hay compatibilidad de aplicaciones con CA de confianza preconfiguradas.

DANE (Autenticación de Dominio de Entidades Nombradas), como se especifica en la RFC 6698 y RFC relacionadas, utiliza registros TLSA de maneras específicas para proteger numerosos protocolos y aplicaciones. La revista IETF y la Internet Society ofrecen un útil artículo introductorio y una descripción general de DANE .

HTTPS

DANE le permite configurar de forma segura servidores HTTPS mediante el uso de certificados generados con su propia infraestructura de CA basada en OpenSSL o CFSSL de Cloudflare.

El validador DANE de SIDNLabs para servidores HTTPS es útil para probar una implementación DANE para HTTPS.

Verificación del certificado TLS SMTP (correo electrónico)

El protocolo de correo electrónico SMTP es vulnerable a ataques de degradación que deshabilitan el cifrado , y DANE proporciona una forma de prevenir estos ataques.

La Internet Society tiene un tutorial de dos partes sobre el uso de DANE para SMTP con los certificados gratuitos y automatizados disponibles en Let's Encrypt , que incluye consejos para evitar el uso de ciertos formatos de registros TLSA con certificados Let's Encrypt:

Puedes encontrar excelentes consejos (y un validador de dominios DANE para HTTPS y SMTP) en Errores Comunes . El validador "Prueba tu correo electrónico" también verifica DANE.

Verificación del certificado TLS de XMPP (chat Jabber)

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

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

Los registros TXT pueden usarse sin DNSSEC, pero los firmados con DNSSEC ofrecen mayor confianza en su autenticidad. Esto es importante para la publicación basada en DNS de claves públicas OpenPGP (GnuPG), que no están firmadas por entidades reconocidas como las CA X.509.

Por ejemplo, si Alice publica un registro TXT como el siguiente en la zona an.example firmada con DNSSEC y aloja una copia de la clave pública protegida con ASCII en la URI dada, Bob puede buscar una clave OpenPGP para alice@an.example con una seguridad razonable (esto no reemplaza la validación de red de confianza, pero hace posible el cifrado OpenPGP con partes previamente desconocidas): 

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

Puede utilizar estas instrucciones para generar estos registros TXT PKA versión 1 (como se los llama en Claves de publicación en DNS ).

La guía completa para publicar claves PGP en DNS explica cómo crear registros CERT OpenPGP (pero Cloud DNS no admite registros CERT u OPENPGPKEY).

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

Si ha cargado su clave OpenPGP en un servidor de claves, también puede usar un URI hkp: para ese servidor de claves, como hkp://subkeys.pgp.net o hkp://pgp.mit.edu , aunque los usuarios detrás de firewalls que bloquean el puerto 11371 pueden no poder acceder a él (algunos servidores de claves proporcionan URL HTTP del puerto 80).

TXT (SPF, DKIM y DMARC)

A continuación se presentan otros tres tipos de registros TXT que puede utilizar para proteger sus servicios de correo electrónico y evitar que los spammers y estafadores envíen correos electrónicos que parezcan provenir de su dominio (aunque no sea así):

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

  • DKIM : publica un conjunto de claves públicas que se utilizan para verificar que el correo electrónico se envía desde un dominio y protege los mensajes para que no se modifiquen durante el tránsito.

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

Para verificar que su dominio esté configurado correctamente para usar estos tres tipos de registros, puede usar la herramienta "Probar su validador de correo electrónico" . Para obtener consejos útiles sobre la configuración de registros SPF, consulte las preguntas frecuentes sobre errores comunes .

Utilice otros tipos de conjuntos de registros mejorados por DNSSEC

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

CAA

Los conjuntos de registros de Autorización de Autoridad de Certificación (CAA) le permiten controlar qué CA públicas pueden generar certificados TLS u otros certificados para su dominio. Este control es especialmente útil (y eficaz) si desea asegurarse de que una CA pública que emite certificados validados por dominio (DV) (como LetsEncrypt.org) no emita certificados para su dominio.

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

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

Clave IPSEC

También puede habilitar el cifrado oportunista mediante túneles IPsec mediante la publicación de registros IPSECKEY . La implementación de VPN IPsec de strongSwan cuenta con un complemento que utiliza registros IPSECKEY.

Además de colocar registros IPSECKEY en las zonas de avance habituales, como service.example.com , la sección 1.2 del RFC 4025 requiere que los gateways de seguridad busquen registros IPSECKEY en las zonas inversas ip6.arpa e in-addr.arpa .

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

Las zonas inversas para direcciones IP externas de máquinas virtuales de Compute Engine aún no admiten la delegación.

¿Qué sigue?