Usar DNSSEC avançadas

Nesta página, você verá várias opções avançadas de configuração do Sistema de Nome de Domínio (DNSSEC, na sigla em inglês) que podem ser usadas se você ativar a DNSSEC para suas zonas gerenciadas. Essas opções variam de diferentes algoritmos de assinatura e negação de existência para a capacidade de usar tipos de registro que exigem ou recomendam o DNSSEC para uso.

Consulte a visão geral das DNSSEC para ter uma visão geral conceitual das DNSSEC.

Delegar subdomínios assinados pelas 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 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, será possível acessar o registro de DS no Console do Google Cloud ou na Google Cloud CLI.

Console

1. No Console do Google Cloud, acesse a página do Cloud DNS.

   Acessar Cloud DNS

2. Navegue até a zona gerenciada em que você quer ver o registro DS.

3. Para ver o registro DS da zona, no canto superior direito da página Detalhes da zona, clique em Configuração do registrador.

4. O registro do DS está disponível na página Configuração do registrador.

5. Para criar registros NS, siga as instruções em Como adicionar um registro.

gcloud

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

   gcloud dns dns-keys list --zone EXAMPLE_ZONE
   

   Substitua EXAMPLE_ZONE pelo nome da zona de DNS de subdomínio delegado em 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 ter 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). Execute este comando:

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

   Substitua:

   • EXAMPLE_ZONE: o nome da zona de DNS de subdomínio delegado no seu projeto.
   • KSK_ID: o número do código da KSK, normalmente 0

   A resposta será semelhante a:

   44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
   

3. Copie a saída do comando anterior para usá-la em uma etapa subsequente.

4. Para criar os registros DS para uma subdelegação segura, execute o seguinte comando para iniciar a transação:

   gcloud dns record-sets transaction start --zone EXAMPLE_ZONE
   

   Substitua EXAMPLE_ZONE pelo nome da zona DNS pai no projeto em que você está criando os registros para o subdomínio delegado.

   A saída será assim:

   Transaction started [transaction.yaml].
   

5. Em seguida, execute o seguinte comando para adicionar um 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"
   

   Substitua:

   • EXAMPLE_ZONE: o nome da zona de DNS pai no seu projeto.
   • TIME_TO_LIVE: tempo de vida da zona em segundos, como 3.600.
   • subdomain.example.com: um subdomínio do nome DNS da zona.
   • DS_RECORD_AND_KEY: o registro e a chave do DS usados na etapa 2, como 44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb.

   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 --zone EXAMPLE_ZONE \
      --ttl TIME_TO_LIVE \
      --type NS \
      --name subdomain.example.com \
   

   Substitua:

   • EXAMPLE_ZONE: o nome da zona de DNS pai no seu projeto.
   • TIME_TO_LIVE: tempo de vida da zona em segundos, como 3.600.
   • subdomain.example.com: um subdomínio do nome DNS da zona.

7. Insira o seguinte RRData:

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

   Observação:a escolha dos servidores de nomes para o registro NS depende do fragmento do servidor de nomes em que o subdomínio delegado foi atribuído quando ele foi criado. Essas informações estão visíveis na caixa de diálogo Configuração do registrador anterior. Os detalhes necessários do registro DS e NS aparecem juntos.

   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 --zone EXAMPLE_ZONE
   

   Substitua EXAMPLE_ZONE pelo nome de uma zona de DNS no 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
   

Usar 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 use o seguinte comando para reativar a DNSSEC:

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

Substitua EXAMPLE_ZONE pelo nome de uma zona de DNS no projeto:

Para mais detalhes, veja Ativar as DNSSEC para zonas gerenciadas.

Observação: é possível que o domínio seja resolvido enquanto a DNSSEC estiver desativada. Para isso, primeiro desative a DNSSEC para sua zona no registrador de domínio, isso garante que os resolvedores de validação da DNSSEC ainda possam determinar nomes na zona. Para mais detalhes, consulte Desativar as 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.

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

Substitua EXAMPLE_ZONE pelo nome de uma zona de DNS no projeto:

Se você fornecer algoritmos de KSK ou ZSK ou comprimentos de chave, precisará fornecer todos eles e seus argumentos no comando:

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

Especifique a negação de existência como NSEC ou NSEC3, independentemente dos algoritmos.

Os argumentos e as opções de algoritmo aceitos estão listados na tabela a seguir. O Cloud DNS não permite o uso de outros algoritmos ou parâmetros.

Algoritmo	Comprimentos de KSK	Comprimentos de ZSK	Comentários
RSASHA256	2048	1024, 2048
RSASHA512	2048	1024, 2048	Sem suporte amplo
ECDSAP256SHA256	256	256
ECDSAP384SHA384	384	384	Sem suporte amplo

Se nenhum algoritmo for especificado, o Cloud DNS usará estes padrões:

Tipo de chave	Algoritmo padrão	Comprimento padrão da chave
Chave de assinatura de chave (KSK, na sigla em inglês)	RSASHA256	2048
Chave de assinatura de zona (ZSK, na sigla em inglês)	RSASHA256	1024

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 (ambos em inglês) e uma análise do desempenho do servidor no Windows (em inglês).

O suporte ao resolvedor para ECDSA está limitado a sistemas recentes. Resolvedores mais antigos que não podem validar zonas assinadas por ECDSA as consideram não assinadas, 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. Apenas alguns registradores e até menos registradores são compatíveis com ECDSA de 384 bits. 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. Isso acontece mesmo que o RFC 6840 (em inglês) diga que eles não podem insistir que todos os algoritmos ... no DNSKEY RRset funcionem. Se isso não for uma preocupação (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 for compatível com 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 opt-out NSEC3 está desativada por questões de segurança e há uma iteração de hash extra (de dois 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 do 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 synthesize respostas negativas de registros NSEC armazenados em cache sem consultar sua zona do Cloud DNS.

A RFC 8624 contém mais orientações sobre a seleção de algoritmos.

Usar novos tipos de registro DNS com zonas protegidas por DNSSEC

Depois que seu domínio for completamente protegido por DNSSEC, será possível 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 que pode ser usada pelos aplicativos cliente 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.

Este é o formato de registro SSHFP:

• Número do algoritmo
• Número do tipo de impressão digital
• Impressão digital da chave do servidor

Os números de 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:

• SHA-1 (obsoleto, apenas para compatibilidade)
• SHA-256

Cuidado: o uso inadequado dos registros SSHFP pode ter sérias consequências de segurança. Siga estas regras para evitar a criação de vulnerabilidades de segurança:

• Não crie registros SSHFP em uma zona que não esteja protegida por DNSSEC.
• Nunca configure clientes SSH para usarem SSHFP com um domínio que não esteja protegido pela DNSSEC.
• Nunca configure clientes SSH para usarem SSHFP, a menos que eles validem a DNSSEC ou usem um resolvedor de validação como o DNS público do Google.

Não seguir essas regras pode permitir que usuários mal-intencionados criem registros de SSHFP falsos para imitar seus servidores, o que torna as conexões SSH com os servidores inseguras e vulneráveis a ataques.

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). Para mais exemplos e links, consulte Registros SSHFP: DNS fornecendo chaves de host SSH públicas.

TLSA e DANE

Os registros TLSA contêm informações que podem ser usadas para validar certificados X.509 (como certificados usados por HTTPS) sem depender de um conjunto pré-configurado de autoridades de certificação (CAs) que os assinam.

Isso permite que você configure suas próprias CAs e gere certificados para HTTPS. Isso também permite a validação de certificados para protocolos como o SMTP, em que geralmente não há suporte a aplicativos para CAs confiáveis pré-configuradas.

Cuidado: não crie registros TLSA em uma zona que não esteja protegida pela DNSSEC. A maioria dos aplicativos que usam registros TLSA requerem validação por DNSSEC. Portanto, criar esses registros não tem efeito. No entanto, isso pode criar uma vulnerabilidade em aplicativos mal configurados.

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 com sua própria infraestrutura de AC 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 é vulnerável a ataques de downgrade que desativam a criptografia, e o DANE fornece uma maneira de evitar esses ataques.

A Internet Society oferece um tutorial em duas partes sobre o uso do DANE para SMTP com os certificados gratuitos e automatizados disponibilizados pela Let's Encrypt, incluindo conselhos para evitar o uso de determinados formatos de registro TLSA com os certificados da Let's Encrypt:

• Parte 1
• Parte 2

Você encontra recomendações excelentes (e um validador de domínio DANE para HTTPS e SMTP) em Erros comuns. O Teste seu validador de e-mail 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.

Por exemplo, se a Alice publicar um registro TXT como o seguinte na zona an.example assinada por DNSSEC, e hospedar uma cópia da chave pública protegida por ASCII no URI, Bob poderá procurar uma chave OpenPGP para [e-mail] com segurança razoável. Isso não substitui a validação da rede de confiança, mas possibilita a criptografia do OpenPGP com grupos desconhecidos anteriormente:

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

Use estas instruções (em inglês) para gerar os registros TXT da Versão 1 PKA, como são chamados em Chaves de publicação no DNS.

O guia completo para publicar chaves PGP no DNS explica como criar registros CERT do OpenPGP, mas o Cloud DNS não aceita registros CERT ou OPENPGPKEY.

Se você registrou sua chave OpenPGP em Keybase.io (em inglês), não precisará hospedar a chave no seu próprio servidor. Em vez disso, é possível usar um URL como https://keybase.io/KEYBASE_USERNAME/key.asc (substitua KEYBASE_USERNAME pelo 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 HTTP da porta 80.

TXT (SPF, DKIM e DMARC)

Veja a seguir 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-mails de 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 protege 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.

Para verificar se seu domínio está configurado corretamente para usar todos esses três tipos de registro, use o Teste seu validador de e-mail. Para conselhos úteis sobre a configuração de registros SPF, consulte Perguntas frequentes sobre erros comuns.

Outros tipos de conjuntos de registros aprimorados pelas 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, na sigla em inglês) permitem controlar quais CAs públicas podem gerar TLS ou outros certificados para seu domínio. Esse controle é mais útil e eficaz se você quer garantir que uma CA pública que está emitindo certificados validados pelo domínio (DV, na sigla em inglês), como a LetsEncrypt.org, não emitem certificados para seu domínio.

Um registro CAA típico tem um formato simples como 0 issue "best-ca.example", que permite que a CA best-ca.example emita certificados para nomes no domínio em que o conjunto de registros CAA está localizado. Se você quiser permitir que várias CAs emitam certificados, crie 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, publicando registros IPSECKEY (em inglês). A implementação da VPN IPsec strongSwan 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 reversas ip6.arpa e in-addr.arpa.

A compatibilidade com DNSSEC para zonas reversas é menos comum que para zonas de encaminhamento e requer um provedor de acesso à Internet (ISP, na sigla em inglês) que implemente a DNSSEC. No entanto, alguns ISPs podem oferecer suporte a DNSSEC para delegações na zona reversa.

As zonas reversas dos endereços IP externos de VM do Compute Engine ainda não são compatíveis com a delegação.

A seguir

• Para criar, atualizar, listar e excluir zonas gerenciadas, consulte Gerenciar zonas.
• Para achar soluções de problemas comuns que podem ser encontrados ao usar o Cloud DNS, consulte Solução de problemas.
• Para uma visão geral do Cloud DNS, consulte Visão geral do Cloud DNS.