DNSSEC avançado

Há várias opções avançadas de configuração de DNSSEC que você pode usar ao ativar o DNSSEC para suas zonas gerenciadas. Elas variam desde diferentes algoritmos de assinatura e negação de existência até a capacidade de usar tipos de registro que exigem ou recomendam o DNSSEC. Todas essas opções são descritas abaixo.

Como delegar subdomínios assinados por DNSSEC

É possível ativar o DNSSEC para subdomínios delegados depois que você ativar o DNSSEC para seu domínio principal. Para ativar o DNSSEC para subdomínios delegados, primeiro crie um registro DS em uma zona do Cloud DNS. Também é necessário criar um ou mais registros NS. Para instruções sobre como criar registros NS, consulte Como adicionar ou remover um registro.

Console

Para criar registros DS para subdomínios delegados, você precisa receber o registro DS da zona. Se a zona delegada também estiver hospedada no Cloud DNS, você poderá receber o registro do DS no Console do Cloud.

  1. Navegue até a zona gerenciada.
  2. Para ver o registro DS da zona, clique no link Registrar Setup no canto superior direito da página Zone details.
  3. Depois de anotar as informações do registro do DS, continue o procedimento na etapa 2 da guia de comandos gcloud.

Pop-up de configuração do registrador

gcloud

  1. Para ver as informações de registro do DS dos subdomínios delegados, use o seguinte comando:

    $ gcloud dns dns-keys list --zone example_zone
    

    Substitua a seguinte opção de comando:

    • example_zone: o nome de uma zona DNS no seu projeto

    A saída será assim:

    ID  KEY_TAG  TYPE          IS_ACTIVE  DESCRIPTION
    0   1234     KEY_SIGNING   True
    1   12345    ZONE_SIGNING  True
    

  2. Para ver um registro completo do DS e todos os detalhes da chave, você precisa do código da chave KEY_SIGNING (KSK), que geralmente é zero (0). Use o seguinte comando:

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

    Substitua as seguintes opções de comando:

    • example_zone: o nome de uma zona DNS no seu projeto
    • ksk_id: o ID do código, geralmente 0
  3. Copie a saída do comando anterior para usá-la em uma etapa subsequente.

    A resposta será semelhante a:

    44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
    
  4. Para criar os registros DS para uma subdelegação segura, inicie a transação usando o seguinte comando:

    $ gcloud dns record-sets transaction start -z example_zone
    

    Substitua as seguintes opções de comando:

    • example_zone: o nome de uma zona DNS no seu projeto
    • subdomain.example.com: um subdomínio do nome DNS da zona

    A saída será assim:

    Transaction started [transaction.yaml].
    

  5. Em seguida, adicione um conjunto de registros usando o seguinte 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"
    

    Substitua as seguintes opções de comando:

    • example_zone: o nome de uma zona DNS no seu projeto
    • subdomain.example.com: um subdomínio do nome DNS da zona
    • DS_record-and_key: registro e chave do DS que você conseguiu na etapa 2

    A saída será assim:

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

  6. Para adicionar registros NS, use o seguinte comando:

    $ gcloud dns record-sets transaction add -z example_zone \
     --ttl 3600 --type NS --name subdomain.example.com \
    

    Substitua as seguintes opções de comando:

    • example_zone: o nome de uma zona DNS no seu projeto
    • subdomain.example.com: um subdomínio do nome DNS da zona
  7. Insira os seguintes dados:

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

    A saída será assim:

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

  8. Para executar a transação, use o seguinte comando:

    $ gcloud dns record-sets transaction execute -z example_zone
    

    Substitua a seguinte opção de comando:

    • example_zone: o nome de uma zona DNS no seu projeto

    A saída será assim:

    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
    

Opções de assinatura avançadas

Ao ativar a DNSSEC para uma zona gerenciada ou criar uma zona gerenciada com ela, é possível selecionar os algoritmos de assinatura da DNSSEC e o tipo de negação de existência.

É possível alterar as configurações de DNSSEC para uma zona gerenciada antes de habilitar a DNSSEC. Por exemplo, para o algoritmo usado para assinar os registros criptograficamente. Se você quiser fazer alterações e a DNSSEC já estiver ativada para uma zona gerenciada, primeiro desative a DNSSEC. Em seguida, faça as alterações necessárias e reative a DNSSEC usando o comando abaixo. Substitua example_zone pelo nome de uma zona de DNS no seu projeto:

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

Para mais detalhes, veja Como ativar a DNSSEC para zonas gerenciadas.

O comando a seguir ativa o DNSSEC com ECDSA de 256 bits e NSEC para os menores pacotes de resposta assinada por DNSSEC da utilização do Cloud DNS. Substitua example_zone pelo nome de uma zona de DNS no projeto:

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

Se você fornecer algoritmos de KSK ou ZSK ou comprimentos de chave, precisará fornecer todos eles (--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length) e seus argumentos no comando. Especifique a negação de existência como NSEC ou NSEC3, independentemente dos algoritmos.

Os argumentos e as opções de algoritmos compatíveis estão listados na tabela a seguir, em que são mostrados os padrões e os valores fracos, disponibilizados apenas mediante solicitação:

Algoritmo Comprimentos de KSK Comprimentos de ZSK Comentários
RSASHA1 1024, 2048 1024, 2048 SHA-1 considerado fraco
RSASHA256 1024, 2048 1024, 2048
RSASHA512 1024, 2048 1024, 2048 Sem suporte amplo
ECDSAP256SHA256 256 256 Pode não ser compatível
ECDSAP384SHA384 384 384 Sem suporte amplo

Não use RSASHA1 a menos que você precise dele por razões de compatibilidade. Não há vantagem de segurança para usá-lo com comprimentos de chave maiores.

As diferenças de segurança e desempenho entre RSASHA256 e RSASHA512 são mínimas e os tamanhos de resposta assinada são idênticos. Os comprimentos de chave de fato são importantes: chaves mais longas são mais lentas e têm respostas maiores. Veja as análises do tamanho da resposta da zona raiz e de TLDs e uma análise do desempenho do servidor no Windows (todos os links em inglês).

O suporte ao cliente para ECDSA está limitado a sistemas recentes. Clientes antigos, que não podem validar zonas assinadas por ECDSA, as consideram sem assinaturas, o que pode não ser seguro se você usar novos tipos de registro que dependem da DNSSEC. O suporte ao registrador e ao registro para ECDSA de 256 bits é comum, mas não universal. O ECDSA de 384 bits é compatível com poucos registros e com ainda menos registradores. O uso de ECDSA pode ser eficaz se você não precisa oferecer suporte a clientes mais antigos. As assinaturas são bem menores e a computação delas é mais rápida.

Evite o uso de diferentes algoritmos de KSK e ZSK nas zonas gerenciadas. Isso reduz a compatibilidade e pode comprometer a segurança. Alguns resolvedores de validação da DNSSEC podem falhar na validação de zonas com algoritmos da DNSKEY que não são usados para assinar todos os registros na zona, mesmo que o RFC 6840 (em inglês) diga que eles "NÃO PODEM insistir para que todos os algoritmos ... na DNSKEY RRset funcionem". Se isso não for uma preocupação, sendo que a maioria dos resolvedores de validação segue a RFC 6840, use RSASHA256 para KSK e ECDSA para ZSK se seu registrador de domínio ou TLD não suportar ECDSA e você precisar de tamanhos de resposta reduzidos.

NSEC3 é o tipo de negação de existência padrão. Ela oferece proteção limitada contra os intrusos que tentam descobrir todos os registros na sua zona. As configurações de NSEC3PARAM são fixas: a opção de "desativar" o NSEC3 fica desabilitada por questões de segurança e há uma iteração de hash extra (de duas no total) com um sal de 64 bits.

NSEC tem respostas um pouco menores, mas nenhuma proteção contra os invasores da zona. O uso de NSEC também pode reduzir consultas para domínios inexistentes. O DNS público do Google e vários outros resolvedores de validação da DNSSEC podem sintetizar (em inglês) respostas negativas de registros NSEC armazenados em cache sem consultar sua zona do Cloud DNS.

Como usar novos tipos de registro DNS com zonas protegidas por DNSSEC

Depois que seu domínio for completamente protegido por DNSSEC, você poderá começar a usar vários novos tipos de registro DNS que aproveitam as garantias de autenticidade e integridade das zonas assinadas por DNSSEC para aumentar a segurança de outros serviços.

SSHFP

Os registros SSHFP contêm uma impressão digital da chave pública do servidor SSH e podem ser usados por aplicativos cliente de SSH para validar os servidores SSH. Os clientes SSH geralmente exigem a interação do usuário para confirmar a chave pública do servidor na primeira conexão e geram avisos se a chave é alterada. Um cliente SSH configurado para usar SSHFP sempre usa a chave no registro SSHFP de um servidor para esse servidor. Somente as chaves de servidores sem registro SSHFP são salvas para reutilização.

O formato do registro SSHFP é composta da seguinte maneira: número do algoritmo, número do tipo de impressão digital e impressão digital da chave do servidor. Os números do algoritmo para SSH são os seguintes:

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

Os tipos de impressão digital são os seguintes:

  1. SHA-1 (obsoleto, apenas para compatibilidade)
  2. SHA-256

O StackExchange tem sugestões de como criar o SSHFP (em inglês), e há ferramentas para gerá-lo por meio da verificação de servidores, pelo uso de arquivos de host conhecidos atuais ou pelo gerenciamento de configuração (ambos em inglês). Veja outros exemplos e links nesta página (em inglês).

TLSA e DANE

Os registros TLSA contêm informações que podem ser usadas para validar certificados X.509 (como os usados pelo HTTPS), sem depender da assinatura de um conjunto pré-configurado de autoridades de certificação (CAs). Isso permite que você configure suas próprias CAs e gere certificados para HTTPS, além de permitir a validação de certificados para protocolos como o SMTP, em que tipicamente não há suporte a aplicativos para CAs confiáveis pré-configuradas.

O DANE (Autenticação de Domínio de Entidades Nomeadas), conforme especificado na RFC 6698 (em inglês) e em RFCs relacionadas, usa registros TLSA de maneiras específicas para proteger muitos protocolos e aplicativos. O IETF Journal e a Internet Society oferecem um excelente artigo de introdução e uma visão geral do DANE (ambos em inglês).

HTTPS

O DANE permite configurar com segurança servidores HTTPS usando certificados gerados por sua própria infraestrutura de autoridade de certificação com base no OpenSSL ou no CFSSL do CloudFlare (ambos em inglês).

O validador DANE para servidores HTTPS da SIDNLabs é útil para testar uma implantação de DANE para HTTPS.

Verificação de certificado TLS para SMTP (e-mail)

O protocolo de e-mail SMTP é particularmente vulnerável a ataques de downgrade que desativam a criptografia (em inglês) e o DANE oferece uma forma de evitar isso. A Internet Society oferece um tutorial em duas partes (ambos em inglês) sobre o uso do DANE para SMTP com certificados gratuitos e automatizados disponibilizados pela Let's Encrypt (em inglês). Siga as recomendações (em inglês) para evitar o uso de determinados formatos de registro TLSA com os certificados da Let's Encrypt.

Informações importantes sobre erros comuns estão disponíveis em https://dane.sys4.de/common_mistakes (em inglês), além de um validador de domínios DANE para HTTPS e SMTP. O validador "Test your email" (em inglês) também verifica o DANE.

Verificação de certificado TLS para XMPP (chat do Jabber)

O XMPP e outros serviços que usam registros SRV também podem usar o DANE. Um exemplo de XMPP (em inglês) usa a configuração DANE-SRV conforme especificado na RFC 7673 (em inglês).

Associação de chave pública TXT (OpenPGP/GnuPG)

Registros TXT podem ser usados sem a DNSSEC, mas registros TXT assinados pela DNSSEC oferecem mais confiança de autenticidade. Isso é importante para a publicação baseada em DNS das chaves públicas OpenPGP (GnuPG), que não são assinadas por grupos bem conhecidos como autoridades de certificação X.509. Se a Alice publicar, na zona an.example assinada pela DNSSEC, um registro TXT como:

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

e hospedar uma cópia da chave pública protegida por ASCII no URI especificado, Bob pode procurar uma chave OpenPGP para alice@an.example com segurança razoável. Isso não substitui a validação da rede de confiança, mas possibilita a criptografia OpenPGP com grupos anteriormente desconhecidos.

É possível usar estas instruções (em inglês) para gerar os registros TXT "PKA Version 1", como são chamados nesta visão geral das chaves no DNS (em inglês). Neste outro guia (em inglês), você também vê como criar registros CERT do OpenPGP, mas nem os registros CERT nem os OPENPGPKEYs são aceitos pelo Cloud DNS.

Se você registrou sua chave OpenPGP em Keybase.io (em inglês), não precisará hospedar a chave no seu próprio servidor e simplesmente usar um URL como https://keybase.io/KEYBASE_USERNAME/key.asc, substituindo KEYBASE_USERNAME por seu nome de usuário Keybase.io. Se você fez upload da sua chave OpenPGP em um servidor de chaves, também pode usar um hkp: URI para esse servidor de chaves, como hkp://subkeys.pgp.net ou hkp://pgp.mit.edu, embora os usuários atrás de firewalls que bloqueiam a porta 11371 não consigam alcançá-lo, alguns servidores de chaves fornecem URLs de HTTP da porta 80.

TXT (SPF, DKIM e DMARC)

Existem outros três tipos de registros TXT que podem ser usados para proteger seus serviços de e-mail e evitar que criadores de spam e golpistas enviem e-mails que parecem vir do seu domínio, mesmo que não venham.

SPF
Especifica os servidores SMTP, por nome de domínio ou endereço IP, que podem enviar e-mail para um domínio.
DKIM
Publica um conjunto de chaves públicas usadas para verificar se o e-mail foi enviado de um domínio e proteger as mensagens contra modificações em trânsito.
DMARC
Especifica políticas de domínio e geração de relatórios para a validação de SPF e DKIM e geração de relatórios de erro.

Use o validador "Testar seu e-mail" (em inglês) para verificar se seu domínio está configurado corretamente para usar todos esses três tipos de registro. Em Perguntas frequentes sobre erros comuns (em inglês) você encontra recomendações úteis sobre a configuração de registros SPF.

Outros tipos de conjuntos de registros aprimorados pela DNSSEC

Além de TXT, existem alguns outros tipos de conjuntos de registros que se beneficiam da DNSSEC, mesmo que não exijam o uso dele.

CAA

Os conjuntos de registros de autorização de autoridade de certificação (CAA) permitem que você controle quais autoridades de certificação (CAs) públicas podem gerar TLS ou outros certificados para seu domínio. Isso é mais útil e eficaz se você quer garantir que uma autoridade de certificação pública que emite certificados de validação de domínio (DV, na sigla em inglês), como a LetsEncrypt.org, não emita certificados para seu domínio.

Um registro CAA típico tem um formato simples como este: 0 issue "best-ca.example". Esse exemplo permite que somente a autoridade de certificação best-ca.example emita certificados para nomes no domínio em que o conjunto de registros CAA está localizado. Para permitir que várias autoridades emitam certificados, basta criar vários registros CAA.

A RFC 6844 oferece mais detalhes sobre o uso do tipo de conjunto de registros CAA e recomenda fortemente (em inglês) o uso da DNSSEC.

IPSECKEY

Também é possível ativar a criptografia oportunista por meio de túneis de IPSEC ao publicar registros IPSECKEY (em inglês). A implementação da VPN de IPSEC StrongSwan (em inglês) tem um plug-in que usa registros IPSECKEY.

Além de colocar registros IPSECKEY nas zonas de encaminhamento normais, como service.example.com, a seção 1.2 da RFC 4025 (em inglês) exige que os gateways de segurança procurem registros IPSECKEY nas zonas inversas ip6.arpa e in-addr.arpa.

O suporte à DNSSEC para zonas reversas é menos comum que para zonas de encaminhamento e requer um provedor de acesso à Internet que implemente a DNSSEC. No entanto, alguns oferecem compatibilidade com DNSSEC para delegações na zona reversa.

Observe que as zonas reversas para os IPs externos da VM do Google Compute Engine ainda não aceitam delegação. Veja a solicitação de recursos do Google Compute Engine.

Próximas etapas