En esta página se ofrecen varias opciones de configuración avanzada de las extensiones de seguridad del sistema de nombres de dominio (DNSSEC) que puedes usar si habilitas DNSSEC en tus zonas gestionadas. Estas opciones van desde diferentes algoritmos de firma y denegación de existencia hasta la posibilidad de usar tipos de registros que requieren o recomiendan DNSSEC para su uso.
Para obtener una descripción general conceptual de DNSSEC, consulta la información general sobre DNSSEC.
Delegar subdominios firmados con DNSSEC
Puedes habilitar DNSSEC en subdominios delegados después de haber habilitado DNSSEC en tu dominio principal. Para habilitar DNSSEC en subdominios delegados, primero debes crear un registro DS en una zona de Cloud DNS. También debes crear uno o varios registros NS.
Para crear registros DS de subdominios delegados, debes obtener el registro DS de la zona. Si la zona delegada también está alojada en Cloud DNS, puedes obtener el registro DS desde la Google Cloud consola o desde la CLI de Google Cloud.
Consola
En la Google Cloud consola, ve a la página Cloud DNS.
Desplázate hasta la zona gestionada de la que quieras 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, haga clic en Configuración del registrador.
El registro DS está disponible en la página Configuración del registrador.
Para crear registros NS, siga las instrucciones que se indican en el artículo Añadir 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
Sustituye
EXAMPLE_ZONEpor el nombre de la zona DNS del subdominio delegado de tu proyecto.La salida tiene este aspecto:
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 de firma de claves (KSK), que suele ser cero (0). Ejecuta el siguiente comando:
gcloud dns dns-keys describe --zone EXAMPLE_ZONE KSK_ID \ --format "value(ds_record())"
Haz los cambios siguientes:
EXAMPLE_ZONE: el nombre de la zona DNS del subdominio delegado en tu proyectoKSK_ID: el número de ID de KSK, normalmente 0
El resultado es similar al siguiente:
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
Copia el resultado del comando anterior para usarlo en un paso posterior.
Para crear los registros DS de una subdelegación segura, ejecuta el siguiente comando para iniciar la transacción:
gcloud dns record-sets transaction start --zone EXAMPLE_ZONE
Sustituye
EXAMPLE_ZONEpor el nombre de la zona DNS principal de tu proyecto en la que vas a crear los registros del subdominio delegado.La salida tiene este aspecto:
Transaction started [transaction.yaml].
A continuación, ejecuta el siguiente comando para añadir 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"
Haz los cambios siguientes:
EXAMPLE_ZONE: el nombre de la zona DNS principal de tu proyectoTIME_TO_LIVE: tiempo de vida de la zona en segundos, como 3600subdomain.example.com: un subdominio del nombre de DNS de la zonaDS_RECORD_AND_KEY: el registro DS y la clave que has obtenido en el paso 2, como44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
La salida tiene este aspecto:
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb Record addition appended to transaction at [transaction.yaml].
Para añadir 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 \
Haz los cambios siguientes:
EXAMPLE_ZONE: el nombre de la zona DNS principal de tu proyectoTIME_TO_LIVE: tiempo de vida de la zona en segundos, como 3600subdomain.example.com: un subdominio del nombre de DNS de la zona
Introduce los siguientes datos de recursos:
ns-cloud-e1.googledomains.com. \ ns-cloud-e2.googledomains.com. \ ns-cloud-e3.googledomains.com. \ ns-cloud-e4.googledomains.com.
La salida tiene este aspecto:
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
Sustituye
EXAMPLE_ZONEpor el nombre de una zona DNS de tu proyecto.La salida tiene este aspecto:
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
Usar opciones de firma avanzadas
Cuando habilitas DNSSEC en una zona gestionada o creas una zona gestionada con DNSSEC, puedes seleccionar los algoritmos de firma de DNSSEC y el tipo de denegación de existencia.
Puedes cambiar la configuración de DNSSEC (por ejemplo, el algoritmo utilizado para firmar registros criptográficamente) de una zona gestionada antes de habilitar DNSSEC. Si DNSSEC ya está habilitado en una zona gestionada, para hacer cambios, primero inhabilita DNSSEC, haz los cambios necesarios y, a continuación, usa el siguiente comando para volver a habilitar DNSSEC:
gcloud dns managed-zones update EXAMPLE_ZONE --dnssec-state on
Sustituye EXAMPLE_ZONE por el nombre de una zona DNS de tu proyecto.
Para obtener más información, consulta el artículo Habilitar DNSSEC en zonas gestionadas.
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 mediante 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
Sustituye EXAMPLE_ZONE por el nombre de una zona DNS de tu proyecto.
Si proporcionas algún algoritmo o longitud de clave KSK o ZSK, debes proporcionar todos ellos y sus argumentos en el comando:
--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length
Puede especificar la denegación de existencia como NSEC o NSEC3 independientemente de los algoritmos.
En la siguiente tabla se muestran las opciones y los argumentos de algoritmo admitidos. Cloud DNS no permite el uso de ningún otro algoritmo ni parámetro.
| Algoritmo | Longitudes de KSK | Longitudes de ZSK | Comentarios |
|---|---|---|---|
| RSASHA256 | 2048 | 1024, 2048 | |
| RSASHA512 | 2048 | 1024, 2048 | No es un formato de amplia compatibilidad |
| ECDSAP256SHA256 | 256 | 256 | |
| ECDSAP384SHA384 | 384 | 384 | No es un formato de amplia compatibilidad |
Si no se especifica ningún algoritmo, Cloud DNS usa 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 las respuestas firmadas 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 grandes (consulta los análisis del tamaño de las respuestas de la zona raíz y los TLDs, así como un análisis del rendimiento del lado del servidor en Windows).
La asistencia para ECDSA se limita a sistemas relativamente recientes. Las resoluciones antiguas que no pueden validar zonas firmadas con ECDSA las consideran sin firmar, lo que puede ser inseguro si usas tipos de registros nuevos que dependen de DNSSEC. La compatibilidad con ECDSA de 256 bits por parte de registradores y registros es habitual, pero no universal. Solo unos pocos registros y aún menos registradores admiten ECDSA de 384 bits. Usar ECDSA puede ser eficaz si no necesitas admitir clientes antiguos, ya que las firmas son mucho más pequeñas y rápidas de calcular.
No uses algoritmos diferentes para la KSK y la ZSK en tus zonas gestionadas, ya que se reduce la compatibilidad y se puede poner en riesgo la seguridad. Es posible que algunos resolvers que validan DNSSEC no puedan validar zonas con algoritmos DNSKEY que no se usen para firmar todos los registros de la zona. Esto es así aunque en RFC 6840 se indique que "no deben insistir en que todos los algoritmos ... del conjunto de registros RR de DNSKEY funcionen". Si no te preocupa (la mayoría de los resolvers de validación siguen el RFC 6840), puedes usar RSASHA256 para la KSK y ECDSA para la ZSK si tu registrador de dominios o el registro de TLD no admiten ECDSA y necesitas reducir el tamaño de las respuestas.
NSEC3 es el tipo de denegación de existencia predeterminado. Ofrece una protección limitada contra los rastreadores de zonas que intentan descubrir todos los registros de tu zona.
Los ajustes de NSEC3PARAM son fijos: NSEC3 opt-out está inhabilitado por motivos de seguridad y hay una iteración de hash adicional (dos en total) con un salt de 64 bits.
NSEC tiene respuestas ligeramente más pequeñas, pero no ofrece protección contra el recorrido de zonas. Usar NSEC también puede reducir las consultas de dominios inexistentes. Google Public DNS y otros resoluciones que validan DNSSEC pueden sintetizar respuestas negativas a partir de registros NSEC almacenados en caché sin consultar tu zona de Cloud DNS.
La RFC 8624 contiene directrices adicionales sobre la selección de algoritmos.
Usar nuevos tipos de registros DNS con zonas protegidas con DNSSEC
Una vez que tu dominio esté totalmente protegido con DNSSEC, puedes empezar a usar 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 una 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 la clave cambia. Un cliente SSH configurado para usar SSHFP siempre usa la clave del registro SSHFP de un servidor. Solo se guardan para reutilizarlas las claves de los servidores que no tienen un registro SSHFP.
El formato del registro SSHFP es el siguiente:
- Número de algoritmo
- Tipo de huella digital: número
- Huella digital de la clave de servidor
Los números de algoritmo de SSH son los siguientes:
- RSA
- DSA
- ECDSA
- ED25519
Los tipos de huellas digitales son los siguientes:
- SHA-1 (obsoleto, solo para compatibilidad)
- SHA-256
StackExchange ofrece sugerencias para crear SSHFP. También hay herramientas para generarlos escaneando servidores, usando archivos de hosts conocidos o gestión de configuración. Para ver más ejemplos y enlaces, 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 uno de los conjuntos preconfigurados de autoridades de certificación (CAs) que los firman.
Esto te permite configurar tus propias CAs y generar certificados para HTTPS. También permite validar certificados de protocolos como SMTP, en los que normalmente no hay compatibilidad de aplicaciones con CAs de confianza preconfiguradas.
DANE (Domain Authentication of Named Entities), tal como se especifica en el RFC 6698 y en otros RFCs relacionados, usa registros TLSA de formas específicas para proteger muchos protocolos y aplicaciones. El IETF Journal y la Internet Society tienen un artículo introductorio y una descripción general de DANE muy útiles.
HTTPS
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 DANE para servidores HTTPS de SIDNLabs es útil para probar una implementación de DANE para HTTPS.
Verificación del certificado TLS de SMTP (correo electrónico)
El protocolo de correo electrónico SMTP es vulnerable a los ataques de downgrade que inhabilitan el cifrado, y DANE proporciona una forma de evitar estos ataques.
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 determinados formatos de registro TLSA con certificados de Let's Encrypt:
Puedes encontrar consejos muy útiles (y un validador de dominio DANE para HTTPS y SMTP) en Errores habituales. La prueba del validador de correo electrónico también comprueba DANE.
Verificación de certificados TLS de XMPP (chat de Jabber)
XMPP (y otros servicios que usan registros SRV) también pueden aprovechar DANE. En un ejemplo de XMPP se usa la configuración DANE-SRV tal como se especifica en el estándar RFC 7673.
Asociación de clave pública TXT (OpenPGP/GnuPG)
Los registros TXT se pueden usar sin DNSSEC, pero los registros TXT firmados con DNSSEC ofrecen una 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 conocidas, como las autoridades de certificación X.509.
Por ejemplo, si Alicia publica un registro TXT como el siguiente en la zona an.example firmada con DNSSEC y aloja una copia de la clave pública con cifrado ASCII en el URI indicado, Bob puede buscar una clave OpenPGP para alice@an.example con una seguridad razonable (no sustituye a la validación de la red de confianza, pero permite el cifrado OpenPGP con terceros desconocidos):
alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"
Puedes seguir estas instrucciones para generar estos registros TXT de PKA de la versión 1 (como se denominan en Publicar claves en DNS).
En la guía completa para publicar claves PGP en DNS se explica cómo crear registros CERT de OpenPGP (pero Cloud DNS no admite registros CERT ni OPENPGPKEY).
Si has registrado tu clave OpenPGP en Keybase.io,
no es necesario que alojes la clave en tu propio servidor. En su lugar, puedes usar una URL como https://keybase.io/KEYBASE_USERNAME/key.asc (sustituye KEYBASE_USERNAME por tu nombre de usuario de Keybase.io).
Si has subido tu llave OpenPGP a un servidor de llaves, también puedes usar un URI hkp: para ese servidor, como hkp://subkeys.pgp.net o hkp://pgp.mit.edu. Sin embargo, es posible que los usuarios que estén detrás de firewalls que bloqueen el puerto 11371 no puedan acceder a él (algunos servidores de llaves proporcionan URLs HTTP del puerto 80).
TXT (SPF, DKIM y DMARC)
A continuación, se indican otros tres tipos de registros TXT que puedes usar para proteger tus servicios de correo y evitar que los spammers y los estafadores envíen correos que parezcan proceder de tu dominio (aunque no sea así):
SPF especifica los servidores SMTP (por nombre de dominio o dirección IP) que pueden enviar correos en nombre de un dominio.
DKIM publica un conjunto de claves públicas que se utilizan para verificar que el correo se envía desde un dominio y protege los mensajes para que no se modifiquen durante el envío.
DMARC especifica las políticas de dominio y los informes de validación de SPF y DKIM y los informes de errores.
Para comprobar que tu dominio está configurado correctamente para usar los tres tipos de registros, puedes usar el validador de correo. Para obtener consejos útiles sobre cómo configurar registros SPF, consulta las preguntas frecuentes sobre errores habituales.
Usar otros tipos de conjuntos de registros mejorados con DNSSEC
Además de los registros TXT, hay 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) te permiten controlar qué ACs públicas pueden generar certificados TLS u otros certificados para tu dominio. Este control es más útil (y eficaz) si quieres asegurarte de que una AC pública que emite certificados validados por dominio (DV) (como LetsEncrypt.org) no emita certificados para tu dominio.
Un registro CAA típico tiene un formato sencillo, como 0 issue "best-ca.example"
que permite que la CA best-ca.example (y ninguna otra) emita
certificados para nombres del dominio en el que se encuentra el conjunto de registros CAA.
Si quieres permitir que varias AC emitan certificados, crea varios registros CAA.
El RFC 6844 proporciona más detalles sobre el uso del tipo de conjunto de registros CAA y recomienda encarecidamente el uso de DNSSEC.
IPSECKEY
También puedes habilitar el cifrado oportunista a través de túneles IPsec publicando registros IPSECKEY. La implementación de VPN IPsec strongSwan tiene un complemento que usa registros IPSECKEY.
Además de colocar registros IPSECKEY en las zonas directas habituales, como service.example.com, la sección 1.2 de RFC 4025 requiere que las pasarelas de seguridad busquen registros IPSECKEY en las zonas inversas ip6.arpa y in-addr.arpa.
La compatibilidad con DNSSEC para zonas inversas es menos habitual que para zonas directas y requiere un proveedor de Internet que implemente DNSSEC. Sin embargo, hay algunos proveedores de Internet que admiten DNSSEC para delegaciones de zonas inversas.
Las zonas inversas de las direcciones IP externas de las VMs de Compute Engine aún no admiten la delegación.
Siguientes pasos
- Para crear, actualizar, mostrar y eliminar zonas gestionadas, consulta Gestionar zonas.
- Para encontrar soluciones a problemas habituales que pueden surgir al usar Cloud DNS, consulta la sección Solución de problemas.
- Para obtener una descripción general de Cloud DNS, consulta el artículo Información general sobre Cloud DNS.