En esta página, se proporcionan varias opciones de configuración avanzadas de las extensiones de seguridad del sistema de nombres de dominio (DNSSEC) que puedes usar si habilitas DNSSEC en tus zonas administradas. Estas opciones abarcan desde distintos algoritmos de firma y denegación de existencia hasta la capacidad de usar tipos de registros que requieren o recomiendan las DNSSEC para su uso.
Para ver una descripción general conceptual de las DNSSEC, consulta Descripción general de las DNSSEC.
Delega subdominios con firma de DNSSEC
Puedes habilitar las DNSSEC para los subdominios delegados después de haber habilitado las DNSSEC en tu dominio principal. Para habilitar las 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 de 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 Google Cloud o desde Google Cloud CLI.
Consola
En la consola Google Cloud , dirígete a la página de Cloud DNS.
Navega a la zona administrada para la cual deseas ver el registro DS.
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.
El registro DS está disponible en la página Configuración del registrador.
Para crear registros NS, sigue las instrucciones en Agrega un registro.
gcloud
Para obtener la información del registro DS de los subdominios delegados, ejecuta el siguiente comando:
gcloud dns dns-keys list --zone EXAMPLE_ZONE
Reemplaza
EXAMPLE_ZONEpor el nombre de la zona del DNS del subdominio delegado en tu proyecto.El resultado se ve de la siguiente manera:
ID KEY_TAG TYPE IS_ACTIVE DESCRIPTION 0 1234 KEY_SIGNING True 1 12345 ZONE_SIGNING True
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 del DNS del subdominio delegado de tu proyectoKSK_ID: el número de ID de KSK que, por lo general, es 0
El resultado es similar al siguiente:
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
Copia el resultado del comando anterior para usarlo en un paso posterior.
Si desear 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_ZONEpor el nombre de la zona del DNS superior en tu proyecto en la que crees los registros para el subdominio delegado.El resultado se ve de la siguiente manera:
Transaction started [transaction.yaml].
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 del DNS superior en tu proyectoTIME_TO_LIVE: tiempo de actividad para la zona en segundos, como 3,600subdomain.example.com: un subdominio del nombre de DNS de la zonaDS_RECORD_AND_KEY: el registro DS y la clave que usaste en el paso 2, como44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb.
El resultado se ve de la siguiente manera:
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb Record addition appended to transaction at [transaction.yaml].
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 del DNS superior en tu proyectoTIME_TO_LIVE: tiempo de actividad para la zona en segundos, como 3,600subdomain.example.com: un subdominio del nombre de DNS de la zona
Ingresa los siguientes datos de registro de recursos:
ns-cloud-e1.googledomains.com. \ ns-cloud-e2.googledomains.com. \ ns-cloud-e3.googledomains.com. \ ns-cloud-e4.googledomains.com.
El resultado se ve de la siguiente manera:
Record addition appended to transaction at [transaction.yaml].
Para ejecutar la transacción, usa el siguiente comando:
gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE
Reemplaza
EXAMPLE_ZONEpor el nombre de una zona del DNS de tu proyecto.El resultado se ve 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 habilitan las DNSSEC para una zona administrada o se crea una zona administrada con DNSSEC, puedes seleccionar los algoritmos de firma de las DNSSEC y el tipo de denegación de existencia.
Puedes cambiar la configuración de las DNSSEC (por ejemplo, al algoritmo utilizado para firmar los registros criptográficamente) de una zona administrada antes de habilitar las DNSSEC. Si las DNSSEC ya están habilitadas para una zona administrada, a fin de realizar cambios, primero inhabilita las DNSSEC, realiza los cambios necesarios y, luego, usa el siguiente comando para volver a habilitar las DNSSEC:
gcloud dns managed-zones update EXAMPLE_ZONE --dnssec-state on
Reemplaza EXAMPLE_ZONE por el nombre de una zona del DNS
de tu proyecto.
Si deseas conocer más detalles, consulta Habilita las DNSSEC para zonas administradas.
Este comando habilita las DNSSEC con ECDSA de 256 bits y NSEC para los paquetes de respuesta con firma de 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
Reemplaza EXAMPLE_ZONE por el nombre de una zona del DNS
de tu proyecto.
Si proporcionas cualquiera de los algoritmos KSK o ZSK, o las longitudes de clave, debes proporcionarlos a todos y a sus argumentos en el siguiente 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 | 1,024, 2,048 | |
| RSASHA512 | 2,048 | 1,024, 2,048 | 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 con firmas 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 grandes (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 que validan 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 cierto aunque en el RFC 6840, se indica que "no se debe insistir en que todos los algoritmos…en el DNSKEY RRset funcionen". 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: opt-out de NSEC3 está inhabilitado por seguridad,
y hay una iteración de hash adicional (para un total de dos) con una sal
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. El DNS público de Google y varios otros agentes de resolución que validan DNSSEC pueden sintetizar las respuestas negativas de los registros NSEC almacenados en caché sin consultar tu zona de Cloud DNS.
El RFC 8624 contiene orientación adicional sobre la selección de algoritmos.
Usa los nuevos tipos de registro DNS a través de las zonas protegidas con DNSSEC
Una vez que tu dominio esté totalmente protegido por las DNSSEC, puedes comenzar a usar varios tipos nuevos de registros DNS que aprovechan las garantías de autenticidad y 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 utiliza la clave almacenada en el registro SSHFP correspondiente al servidor. Solo se guardan para reutilización posterior las claves de los servidores que no tienen un registro SSHFP.
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:
- RSA
- DSA
- ECDSA
- 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 a través del análisis de servidores, el uso de archivos hosts conocidos existentes o la administración de configuraciones. 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 certificadoras (AC) preconfiguradas.
Esto te permite configurar tus propias AC y generar certificados para HTTPS. Esto también permite la validación de certificados para protocolos como SMTP en los que las AC 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. La Internet Society y el IETF Journal publicaron un artículo introductorio muy útil con una descripción general de DANE.
HTTPS
La DANE te permite configurar de forma segura servidores HTTPS a través de 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 cambio a una versión anterior 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 excelentes consejos (y un validador de dominios de DANE para HTTPS y SMTP) en Errores comunes. En Prueba tu validador de correos electrónicos también se 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 AC 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 codificación ASCII en el URI, Bob puede buscar una clave OpenPGP para alice@an.example
con un nivel de seguridad razonable. (Esto no reemplaza la validación a través de la red de confianza,
pero permite la encriptación con OpenPGP entre partes que antes no se conocían).
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).
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 los usuarios que están detrás de los firewalls que bloquean el puerto 11371 no tengan alcance
(algunos servidores de clave proporcionan URLs 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é AC públicas pueden generar TLS o, también, otros certificados para tu dominio. Esto es más útil (y eficaz) si deseas asegurarte de que una AC pública que emite certificados validados por el dominio (DV) (como LetsEncrypt.org) no emita certificados para tu dominio.
Un registro CAA típico tiene un formato simple como 0 issue "best-ca.example"
que permite que la AC best-ca.example (y ninguna otra AC) emita
certificados para los nombres del dominio en el que se encuentra el conjunto de registros de CAA.
Si quieres permitir que varias AC 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 las DNSSEC.
IPSECKEY
También puedes habilitar la encriptación oportunista a través de túneles IPsec publicando registros IPSECKEY. La implementación de VPN con IPsec de StrongSwan incluye 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 las 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 habituales 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.