DNSSEC avanzada

Existen varias opciones de configuración avanzada de DNSSEC que puedes usar si habilitas DNSSEC en tus zonas administradas. Estas pueden ser desde diferentes algoritmos de firma y denegación de existencia hasta la capacidad de emplear tipos de registro que requieren o recomiendan DNSSEC para su uso. Todas se describen a continuación.

Delega subdominios con firma de DNSSEC

Puedes habilitar DNSSEC para subdominios delegados una vez que hayas 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. Si deseas obtener instrucciones para crear registros NS, consulta Agrega o quita un registro.

Console

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 Cloud Console.

  1. Navega a la zona administrada.
  2. Para ver el registro DS de la zona, haz clic en el vínculo Registrar Setup en la esquina superior derecha de la página Zone details.
  3. Después de anotar la información del registro DS, continúa con el procedimiento en el paso 2 de la pestaña de comandos gcloud.

Ventana emergente Configuración de registrador

gcloud

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

    $ gcloud dns dns-keys list --zone example_zone
    

    Reemplaza la siguiente opción de comando:

    • example_zone: Es el nombre de una zona DNS de tu proyecto

    El resultado será similar a esto:

    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). Usa el siguiente comando:

    $ gcloud dns dns-keys describe --zone example_zone ksk_id \
     --format "value(ds_record())"
    

    Reemplaza las siguientes opciones de comando:

    • example_zone: Es el nombre de una zona DNS de tu proyecto
    • ksk_id: Es el número de ID, generalmente 0
  3. Copia el resultado del comando anterior para usarlo en un paso posterior.

    El resultado es similar al siguiente:

    44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
    
  4. A fin de crear los registros DS para una subdelegación segura, inicia la transacción con el siguiente comando:

    $ gcloud dns record-sets transaction start -z example_zone
    

    Reemplaza las siguientes opciones de comando:

    • example_zone: Es el nombre de una zona DNS de tu proyecto
    • subdomain.example.com: Es un subdominio del nombre de DNS de la zona

    El resultado será similar a esto:

    Transaction started [transaction.yaml].
    

  5. A continuación, agrega un conjunto de registros con el siguiente comando:

    $ gcloud dns record-sets transaction add -z example_zone \
     --ttl 3600 --type DS --name subdomain.example.com \
     DS_record-and_key"44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb"
    

    Reemplaza las siguientes opciones de comando:

    • example_zone: Es el nombre de una zona DNS de tu proyecto
    • subdomain.example.com: Es un subdominio del nombre de DNS de la zona
    • DS_record-and_key: el registro DS y la clave que obtuviste en el paso 2

    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 -z example_zone \
     --ttl 3600 --type NS --name subdomain.example.com \
    

    Reemplaza las siguientes opciones de comando:

    • example_zone: Es el nombre de una zona DNS de tu proyecto
    • subdomain.example.com: Es un subdominio del nombre de DNS de la zona
  7. Ingresa los siguientes RData:

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

    El resultado será similar a esto:

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

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

    $ gcloud dns record-sets transaction execute -z example_zone
    

    Reemplaza la siguiente opción de comando:

    • example_zone: Es el nombre de una zona DNS de tu proyecto

    El resultado será similar a esto:

    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
    

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 las DNSSEC, haz los cambios necesarios y, luego, vuelve a habilitarlas con este comando (reemplaza example_zone por el nombre de una zona de DNS de tu proyecto):

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

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. Reemplaza example_zone por el nombre de una zona de DNS de tu proyecto:

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

Si proporcionas cualquiera de los algoritmos KSK o ZSK, o las longitudes de clave, debes proporcionarlos todos (--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length) y sus argumentos en el comando. Puedes especificar la denegación de existencia como NSEC o NSEC3, independientemente de los algoritmos.

Los argumentos y las opciones de algoritmos admitidos se detallan en la tabla siguiente, que muestra los valores predeterminados y los valores poco seguros solo disponibles mediante solicitud:

Algoritmo Longitudes de KSK Longitudes de ZSK Comentarios
RSASHA1 1024, 2048 1024, 2048 SHA-1 se considera poco segura.
RSASHA256 1024, 2048 1024, 2048
RSASHA512 1024, 2048 1024, 2048 No es ampliamente admitido.
ECDSAP256SHA256 256 256 Es posible que no se admita
ECDSAP384SHA384 384 384 No es ampliamente admitido.

No uses RSASHA1 a menos que lo necesites por razones de compatibilidad; no tiene ninguna ventaja de seguridad frente a su uso con longitudes de clave mayores.

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 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 clientes con ECDSA se limita a los sistemas relativamente recientes. Los clientes 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; ECDSA de 384 bits solo es compatible con unos pocos registros y aún menos registradores. 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, aunque el protocolo RFC 6840 diga que NO SE DEBE insistir en que todos los algoritmos 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 "rechazo" de NSEC3 está inhabilitado por seguridad, y hay 1 iteración de hash adicional (para un total de 2) 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 de dominios no existentes. El DNS público de Google y muchos otros agentes de resolución que validan DNSSEC pueden sintetizar las respuestas negativas de registros NSEC almacenados en caché sin consultar a tu zona de Cloud DNS.

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 aprovechan 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, y las aplicaciones del cliente SSH pueden usarlos 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: número de algoritmo, número de tipo de huella digital y huella digital de clave de servidor. Los números de algoritmo para SSH son los siguientes:

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

Los tipos de huella digital son los siguientes:

  1. SHA-1 (obsoleta, solo para compatibilidad)
  2. 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. Estas notas incluyen más ejemplos y vínculos.

TLSA y DANE

Los registros TLSA contienen información que se puede usar para validar certificados X.509 (como los usados por HTTPS) sin depender de que estén firmados por una autoridad certificada (CA) de un conjunto preconfigurado de CA. Esto te permite configurar tus propias CA y generar certificados para HTTPS, así como permitir la validación de certificados de 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 autoridad certificada 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 particularmente vulnerable a los ataques de degradación que inhabilitan la encriptación, y la DANE proporciona una forma de prevenirlos. La Internet Society posee un instructivo de dos partes sobre el uso de la DANE para SMTP con los certificados gratuitos y automatizados disponibles en Let's Encrypt. (Presta atención al consejo para no usar ciertos formatos de registros TLSA con los certificados de Let's Encrypt).

También puedes encontrar excelentes consejos (y un validador de dominios de DANE para HTTPS y SMTP) en https://dane.sys4.de/common_mistakes. El validador "Test your email" (Prueba tu correo electrónico) 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 autoridades certificadas de X.509. Si Alice publica (en la zona an.example con firma de DNSSEC) un registro TXT como el siguiente:

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

y aloja una copia de la clave pública con blindaje ASCII en la URI en cuestión, Bob puede buscar una clave OpenPGP para alice@an.example con un nivel de seguridad razonable (esto no reemplaza la validación de Web de confianza, pero permite la encriptación de OpenPGP con las partes conocidas previamente).

Puedes usar estas instrucciones para generar estos registros TXT "PKA versión 1" (como se denominan en esta descripción general de claves en DNS). Otro instructivo también explica cómo crear registros CERT de OpenPGP (pero ni los registros CERT ni los registros OPENPGPKEY son compatibles con Cloud DNS).

Si registraste tu clave OpenPGP en Keybase.io, no necesitas alojar la clave en tu propio servidor y puedes usar simplemente una URL como https://keybase.io/KEYBASE_USERNAME/key.asc (reemplazando 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)

Hay otros tres tipos de registros TXT que se pueden usar para asegurar tus servicios de correo electrónico y evitar que los remitentes de spam y los estafadores envíen correo electrónico que aparenta provenir de tu dominio (aunque no sea así).

SPF
Especifica los servidores SMTP (por nombre de dominio o dirección IP) que pueden enviar correo electrónico desde 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 a fin de proteger los mensajes de su modificación cuando están 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.

Puedes usar el validador "Test your email" a fin de verificar si tu dominio está correctamente configurado para usar estos tres tipos de registros. En Preguntas frecuentes sobre errores comunes puedes encontrar consejos útiles sobre la configuración de los registros SPF.

Otros tipos de conjuntos de recursos mejorados por 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 certificada (CAA) te permiten controlar qué autoridades certificadas (CA) 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 CA 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 este: 0 issue "best-ca.example". El ejemplo permite que la CA best-ca.example (y ninguna otra CA) emita certificados para los nombres del dominio donde se ubica el conjunto de registros de CAA. Si deseas permitir que varias CA emitan certificados, solo tienes que crear 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 mediante 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 que implemente DNSSEC, pero en algunos casos se pueden admitir DNSSEC para delegaciones de zonas inversas.

Ten en cuenta que las zonas inversas para las IP externas de las VM de Google Compute Engine aún no admiten la delegación. Consulta la solicitud de funciones de Google Compute Engine.

Próximos pasos