Esta página fornece diversas opções avançadas de configuração de Extensões de Segurança do Sistema de Nomes de Domínio (DNSSEC) que você pode usar se habilitar o DNSSEC para suas zonas gerenciadas. Essas opções variam de diferentes algoritmos de assinatura e negação de existência à capacidade de usar tipos de registro que exigem ou recomendam DNSSEC para seu uso.
Para uma visão geral conceitual do DNSSEC, consulte a Visão geral do DNSSEC .
Delegar subdomínios assinados por DNSSEC
Você pode habilitar o DNSSEC para subdomínios delegados depois de habilitar o DNSSEC para o seu domínio principal. Para habilitar o DNSSEC para subdomínios delegados, primeiro crie um registro DS dentro de uma zona do Cloud DNS. Você também precisa criar um ou mais registros NS.
Para criar registros DS para subdomínios delegados, você deve obter o registro DS da zona. Se a zona delegada também estiver hospedada no Cloud DNS, você poderá obter o registro DS do Google Cloud console ou do Google Cloud CLI.
Console
No Google Cloud console, acesse a página Cloud DNS .
Navegue até a zona gerenciada para a qual você deseja ver o registro DS.
Para ver o registro DS da zona, no canto superior direito da página Detalhes da zona , clique em Configuração do registrador .
O registro DS está disponível na página Configuração do Registrador .
Para criar registros NS, siga as instruções em Adicionando um registro .
gcloud
Para obter as informações do registro DS para subdomínios delegados, execute o seguinte comando:
gcloud dns dns-keys list --zone EXAMPLE_ZONE
Substitua
EXAMPLE_ZONEpelo nome da zona DNS do subdomínio delegado no seu projeto.A saída se parece com o seguinte:
ID KEY_TAG TYPE IS_ACTIVE DESCRIPTION 0 1234 KEY_SIGNING True 1 12345 ZONE_SIGNING True
Para obter um registro DS completo e todos os detalhes da chave, você precisa do ID da Chave de ASSINATURA DE CHAVE (KSK), que geralmente é zero (0). Execute o seguinte comando:
gcloud dns dns-keys describe --zone EXAMPLE_ZONE KSK_ID \ --format "value(ds_record())"
Substitua o seguinte:
-
EXAMPLE_ZONE: o nome da zona DNS do subdomínio delegado em seu projeto -
KSK_ID: o número de ID do KSK, geralmente 0
A saída é semelhante à seguinte:
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
-
Copie a saída do comando anterior para usá-la em uma etapa subsequente.
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_ZONEpelo nome da zona DNS pai no seu projeto onde você está criando os registros para o subdomínio delegado.A saída se parece com o seguinte:
Transaction started [transaction.yaml].
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 o seguinte:
-
EXAMPLE_ZONE: o nome da zona DNS pai em seu projeto -
TIME_TO_LIVE: tempo de vida da zona em segundos, como 3600 -
subdomain.example.com: um subdomínio do nome DNS da zona -
DS_RECORD_AND_KEY: o registro DS e a chave que você obteve na etapa 2, como44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
A saída se parece com o seguinte:
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb Record addition appended to transaction at [transaction.yaml].
-
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 o seguinte:
-
EXAMPLE_ZONE: o nome da zona DNS pai em seu projeto -
TIME_TO_LIVE: tempo de vida da zona em segundos, como 3600 -
subdomain.example.com: um subdomínio do nome DNS da zona
-
Insira os seguintes RRData:
ns-cloud-e1.googledomains.com. \ ns-cloud-e2.googledomains.com. \ ns-cloud-e3.googledomains.com. \ ns-cloud-e4.googledomains.com.
A saída se parece com o seguinte:
Record addition appended to transaction at [transaction.yaml].
Para executar a transação, use o seguinte comando:
gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE
Substitua
EXAMPLE_ZONEpelo nome de uma zona DNS no seu projeto.A saída se parece com o seguinte:
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 avançadas de assinatura
Ao habilitar o DNSSEC para uma zona gerenciada ou criar uma zona gerenciada com DNSSEC, você pode selecionar os algoritmos de assinatura DNSSEC e o tipo de negação de existência.
Você pode alterar as configurações de DNSSEC (por exemplo, o algoritmo usado para assinar registros criptograficamente) para uma zona gerenciada antes de habilitar o DNSSEC. Se o DNSSEC já estiver habilitado para uma zona gerenciada, para fazer alterações, primeiro desabilite o DNSSEC, faça as alterações necessárias e, em seguida, use o seguinte comando para reabilitá-lo:
gcloud dns managed-zones update EXAMPLE_ZONE --dnssec-state on
Substitua EXAMPLE_ZONE pelo nome de uma zona DNS no seu projeto.
Para obter detalhes, consulte Habilitar DNSSEC para zonas gerenciadas existentes .
O comando a seguir habilita o DNSSEC com ECDSA e NSEC de 256 bits para os menores pacotes de resposta assinados por DNSSEC possíveis usando o 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 DNS no seu projeto.
Se você fornecer quaisquer algoritmos KSK ou ZSK ou comprimentos de chave, deverá fornecer todos eles e seus argumentos no comando:
--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length
Você pode especificar negação de existência como NSEC ou NSEC3, independentemente de algoritmos.
As opções de algoritmo e argumentos suportados estão listados na tabela a seguir. O Cloud DNS não permite o uso de outros algoritmos ou parâmetros.
| Algoritmo | Comprimentos KSK | Comprimentos ZSK | Comentários |
|---|---|---|---|
| RSASHA256 | 2048 | 1024, 2048 | |
| RSASHA512 | 2048 | 1024, 2048 | Não amplamente suportado |
| ECDSAP256SHA256 | 256 | 256 | |
| ECDSAP384SHA384 | 384 | 384 | Não amplamente suportado |
Se nenhum algoritmo for especificado, o Cloud DNS usará estes padrões:
| Tipo de chave | Algoritmo padrão | Comprimento da chave padrão |
|---|---|---|
| Chave de assinatura de chave (KSK) | RSASHA256 | 2048 |
| Chave de assinatura de zona (ZSK) | RSASHA256 | 1024 |
As diferenças de segurança e desempenho entre RSASHA256 e RSASHA512 são mínimas, e os tamanhos de resposta assinados são idênticos. O comprimento das chaves importa: chaves mais longas são mais lentas e as respostas são maiores (veja análises do tamanho da resposta para a zona raiz e TLDs , e uma análise do desempenho do lado do servidor no Windows ).
O suporte do resolvedor para ECDSA é limitado a sistemas relativamente recentes. Resolvedores mais antigos que não conseguem validar zonas assinadas por ECDSA as consideram não assinadas, o que pode ser inseguro se você usar novos tipos de registro que dependem de DNSSEC . O suporte de registradores e registros para ECDSA de 256 bits é comum, mas não universal. Apenas alguns registros e um número ainda menor de registradores suportam ECDSA de 384 bits. Usar ECDSA pode ser eficaz se você não precisar oferecer suporte a clientes mais antigos; as assinaturas são muito menores e mais rápidas de calcular.
Evite usar algoritmos diferentes para KSK e ZSK em suas zonas gerenciadas; isso reduz a compatibilidade e pode comprometer a segurança. Alguns resolvedores de validação de DNSSEC podem falhar na validação de zonas com algoritmos DNSKEY que não são usados para assinar todos os registros na zona. Isso é verdade mesmo que a RFC 6840 diga que "eles não devem insistir que todos os algoritmos... no conjunto de RRs DNSKEY funcionem". Se isso não for um problema (a maioria dos resolvedores de validação segue a RFC 6840), você pode usar RSASHA256 para KSK e ECDSA para ZSK se o seu registrador de domínio ou registro de TLD não suportar ECDSA e você precisar de tamanhos de resposta reduzidos.
NSEC3 é o tipo padrão de negação de existência; ele oferece proteção limitada contra invasores de zona que tentam descobrir todos os registros na sua zona. As configurações de NSEC3PARAM são fixas: opt-out do NSEC3 é desabilitada por questões de segurança e há uma iteração de hash adicional (para um total de duas) com um salt de 64 bits.
O NSEC tem respostas um pouco menores, mas não oferece proteção contra zone walking. O uso do NSEC também pode reduzir consultas para domínios inexistentes. O Google Public DNS e vários outros resolvedores de validação de DNSSEC podem sintetizar respostas negativas de registros NSEC armazenados em cache sem consultar sua zona do Cloud DNS.
O RFC 8624 contém orientações adicionais sobre seleção de algoritmos.
Use novos tipos de registro DNS com zonas protegidas por DNSSEC
Depois que seu domínio estiver totalmente protegido por DNSSEC, você pode começar a usar vários novos tipos de registros DNS que usam 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 de um servidor SSH que os aplicativos clientes SSH podem usar para validar os servidores SSH. Os clientes SSH geralmente exigem interação do usuário para confirmar a chave pública do servidor na primeira conexão e gerar avisos se a chave for alterada. Um cliente SSH configurado para usar SSHFP sempre usa a chave no registro SSHFP de um servidor para aquele servidor; apenas as chaves de servidores sem um registro SSHFP são salvas para reutilização.
O formato do registro SSHFP é o seguinte:
- Número do algoritmo
- Número do tipo de impressão digital
- Impressão digital da chave do servidor
Os números do algoritmo para SSH são os seguintes:
- RSA
- DSA
- ECDSA
- ED25519
Os tipos de impressão digital são os seguintes:
- SHA-1 ( obsoleto, apenas para compatibilidade )
- SHA-256
O StackExchange tem sugestões para criar SSHFP e existem ferramentas para gerá-las escaneando servidores, usando arquivos de host conhecidos existentes ou gerenciamento de configuração . 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) para assiná-los.
Isso permite que você configure suas próprias CAs e gere certificados para HTTPS. Também permite a validação de certificados para protocolos como SMTP, onde normalmente não há suporte de aplicativo para CAs confiáveis pré-configuradas.
DANE (Autenticação de Domínio de Entidades Nomeadas), conforme especificado na RFC 6698 e RFCs relacionadas, utiliza registros TLSA de maneiras específicas para proteger diversos protocolos e aplicações. O IETF Journal e a Internet Society têm um artigo introdutório útil e uma visão geral do DANE .
HTTPS
O DANE permite que você configure com segurança servidores HTTPS usando certificados gerados com sua própria infraestrutura de CA baseada em OpenSSL ou CFSSL da Cloudflare.
O validador DANE da SIDNLabs para servidores HTTPS é útil para testar uma implantação DANE para HTTPS.
Verificação do certificado SMTP (e-mail) TLS
O protocolo de e-mail SMTP é vulnerável a ataques de downgrade que desabilitam a criptografia , e o DANE fornece uma maneira de evitar esses ataques.
A Internet Society tem um tutorial de duas partes sobre o uso do DANE para SMTP com os certificados gratuitos e automatizados disponíveis no Let's Encrypt , incluindo conselhos para evitar o uso de certos formatos de registro TLSA com certificados Let's Encrypt:
Você pode encontrar excelentes dicas (e um validador de domínio DANE para HTTPS e SMTP) em Erros Comuns . O validador de e-mail "Teste seu e-mail" também verifica o DANE.
Verificação do certificado XMPP (Jabber chat) TLS
O XMPP (e outros serviços que usam registros SRV) também podem tirar proveito do DANE. Um exemplo de XMPP usa a configuração DANE-SRV conforme especificado na RFC 7673 .
Associação de chave pública TXT (OpenPGP / GnuPG)
Registros TXT podem ser usados sem DNSSEC, mas registros TXT assinados por DNSSEC oferecem maior confiança em sua autenticidade. Isso é importante para a publicação baseada em DNS de chaves públicas OpenPGP (GnuPG), que não são assinadas por partes conhecidas, como CAs X.509.
Por exemplo, se 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 fornecido, Bob poderá procurar uma chave OpenPGP para alice@an.example com segurança razoável (isso não substitui a validação da web de confiança, mas torna a criptografia OpenPGP possível com partes previamente desconhecidas):
alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"
Você pode usar estas instruções para gerar esses registros PKA TXT da Versão 1 (como são chamados em Chaves de Publicação no DNS ).
O guia completo para publicar chaves PGP no DNS explica como criar registros OpenPGP CERT (mas o Cloud DNS não oferece suporte a registros CERT ou OPENPGPKEY).
Se você registrou sua chave OpenPGP no Keybase.io , não precisa hospedá-la em seu próprio servidor. Em vez disso, você pode usar uma URL como https://keybase.io/ KEYBASE_USERNAME /key.asc (substitua KEYBASE_USERNAME pelo seu nome de usuário do Keybase.io).
Se você tiver carregado sua chave OpenPGP em um servidor de chaves, também poderá usar um URI hkp: para esse servidor de chaves, como hkp://subkeys.pgp.net ou hkp://pgp.mit.edu , embora usuários atrás de firewalls bloqueando a porta 11371 possam não conseguir acessá-lo (alguns servidores de chaves fornecem URLs HTTP da porta 80).
TXT (SPF, DKIM e DMARC)
A seguir estão três outros tipos de registros TXT que você pode usar para proteger seus serviços de e-mail e impedir que spammers e golpistas enviem e-mails que pareçam 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 para um domínio.
DKIM : publica um conjunto de chaves públicas usadas para verificar se o e-mail é enviado de um domínio e protege as mensagens de serem modificadas em trânsito.
DMARC : especifica políticas de domínio e relatórios para validação de SPF e DKIM e relatórios de erros.
Para verificar se seu domínio está configurado corretamente para usar todos esses três tipos de registro, você pode usar o Testar seu validador de e-mail . Para encontrar dicas úteis sobre como configurar registros SPF, consulte as Perguntas frequentes sobre erros comuns .
Use outros tipos de conjuntos de registros aprimorados pelo DNSSEC
Além do TXT, há alguns outros tipos de conjuntos de registros que se beneficiam do DNSSEC, mesmo que não o exijam.
CAA
Os conjuntos de registros de Autorização de Autoridade Certificadora (CAA) permitem controlar quais CAs públicas podem gerar certificados TLS ou outros para o seu domínio. Esse controle é mais útil (e eficaz) se você quiser garantir que uma CA pública que emite certificados validados por domínio (DV) (como LetsEncrypt.org) não emita certificados para o seu domínio.
Um registro CAA típico tem um formato simples como 0 issue "best-ca.example" , que permite que a best-ca.example (e nenhuma outra CA) emita certificados para nomes no domínio onde o conjunto de registros CAA está localizado. Se você quiser permitir que várias CAs emitam certificados, crie vários registros CAA.
O RFC 6844 fornece mais detalhes sobre o uso do tipo de conjunto de registros CAA e recomenda fortemente o uso do DNSSEC.
IPSECKEY
Você também pode habilitar a criptografia oportunista por meio de túneis IPsec publicando registros IPSECKEY . A implementação do StrongSwan IPsec VPN possui um plugin que utiliza registros IPSECKEY.
Além de colocar registros IPSECKEY nas zonas de encaminhamento usuais, como service.example.com , a seção 1.2 do RFC 4025 exige que os gateways de segurança procurem registros IPSECKEY nas zonas reversas ip6.arpa e in-addr.arpa .
O suporte a DNSSEC para zonas reversas é menos comum do que para zonas de encaminhamento e requer um provedor de serviços de internet (ISP) que implemente DNSSEC. No entanto, existem alguns ISPs que podem oferecer suporte a DNSSEC para delegações de zonas reversas.
Zonas reversas para endereços IP externos de VM do Compute Engine ainda não oferecem suporte à delegação.
O que vem a seguir
- Para criar, atualizar, listar e excluir zonas gerenciadas, consulte Gerenciar zonas .
- Para encontrar soluções para problemas comuns que você pode encontrar ao usar o Cloud DNS, consulte Solução de problemas .
- Para obter uma visão geral do Cloud DNS, consulte Visão geral do Cloud DNS .
Esta página fornece diversas opções avançadas de configuração de Extensões de Segurança do Sistema de Nomes de Domínio (DNSSEC) que você pode usar se habilitar o DNSSEC para suas zonas gerenciadas. Essas opções variam de diferentes algoritmos de assinatura e negação de existência à capacidade de usar tipos de registro que exigem ou recomendam DNSSEC para seu uso.
Para uma visão geral conceitual do DNSSEC, consulte a Visão geral do DNSSEC .
Delegar subdomínios assinados por DNSSEC
Você pode habilitar o DNSSEC para subdomínios delegados depois de habilitar o DNSSEC para o seu domínio principal. Para habilitar o DNSSEC para subdomínios delegados, primeiro crie um registro DS dentro de uma zona do Cloud DNS. Você também precisa criar um ou mais registros NS.
Para criar registros DS para subdomínios delegados, você deve obter o registro DS da zona. Se a zona delegada também estiver hospedada no Cloud DNS, você poderá obter o registro DS do Google Cloud console ou do Google Cloud CLI.
Console
No Google Cloud console, acesse a página Cloud DNS .
Navegue até a zona gerenciada para a qual você deseja ver o registro DS.
Para ver o registro DS da zona, no canto superior direito da página Detalhes da zona , clique em Configuração do registrador .
O registro DS está disponível na página Configuração do Registrador .
Para criar registros NS, siga as instruções em Adicionando um registro .
gcloud
Para obter as informações do registro DS para subdomínios delegados, execute o seguinte comando:
gcloud dns dns-keys list --zone EXAMPLE_ZONE
Substitua
EXAMPLE_ZONEpelo nome da zona DNS do subdomínio delegado no seu projeto.A saída se parece com o seguinte:
ID KEY_TAG TYPE IS_ACTIVE DESCRIPTION 0 1234 KEY_SIGNING True 1 12345 ZONE_SIGNING True
Para obter um registro DS completo e todos os detalhes da chave, você precisa do ID da Chave de ASSINATURA DE CHAVE (KSK), que geralmente é zero (0). Execute o seguinte comando:
gcloud dns dns-keys describe --zone EXAMPLE_ZONE KSK_ID \ --format "value(ds_record())"
Substitua o seguinte:
-
EXAMPLE_ZONE: o nome da zona DNS do subdomínio delegado em seu projeto -
KSK_ID: o número de ID do KSK, geralmente 0
A saída é semelhante à seguinte:
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
-
Copie a saída do comando anterior para usá-la em uma etapa subsequente.
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_ZONEpelo nome da zona DNS pai no seu projeto onde você está criando os registros para o subdomínio delegado.A saída se parece com o seguinte:
Transaction started [transaction.yaml].
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 o seguinte:
-
EXAMPLE_ZONE: o nome da zona DNS pai em seu projeto -
TIME_TO_LIVE: tempo de vida da zona em segundos, como 3600 -
subdomain.example.com: um subdomínio do nome DNS da zona -
DS_RECORD_AND_KEY: o registro DS e a chave que você obteve na etapa 2, como44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
A saída se parece com o seguinte:
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb Record addition appended to transaction at [transaction.yaml].
-
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 o seguinte:
-
EXAMPLE_ZONE: o nome da zona DNS pai em seu projeto -
TIME_TO_LIVE: tempo de vida da zona em segundos, como 3600 -
subdomain.example.com: um subdomínio do nome DNS da zona
-
Insira os seguintes RRData:
ns-cloud-e1.googledomains.com. \ ns-cloud-e2.googledomains.com. \ ns-cloud-e3.googledomains.com. \ ns-cloud-e4.googledomains.com.
A saída se parece com o seguinte:
Record addition appended to transaction at [transaction.yaml].
Para executar a transação, use o seguinte comando:
gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE
Substitua
EXAMPLE_ZONEpelo nome de uma zona DNS no seu projeto.A saída se parece com o seguinte:
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 avançadas de assinatura
Ao habilitar o DNSSEC para uma zona gerenciada ou criar uma zona gerenciada com DNSSEC, você pode selecionar os algoritmos de assinatura DNSSEC e o tipo de negação de existência.
Você pode alterar as configurações de DNSSEC (por exemplo, o algoritmo usado para assinar registros criptograficamente) para uma zona gerenciada antes de habilitar o DNSSEC. Se o DNSSEC já estiver habilitado para uma zona gerenciada, para fazer alterações, primeiro desabilite o DNSSEC, faça as alterações necessárias e, em seguida, use o seguinte comando para reabilitá-lo:
gcloud dns managed-zones update EXAMPLE_ZONE --dnssec-state on
Substitua EXAMPLE_ZONE pelo nome de uma zona DNS no seu projeto.
Para obter detalhes, consulte Habilitar DNSSEC para zonas gerenciadas existentes .
O comando a seguir habilita o DNSSEC com ECDSA e NSEC de 256 bits para os menores pacotes de resposta assinados por DNSSEC possíveis usando o 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 DNS no seu projeto.
Se você fornecer quaisquer algoritmos KSK ou ZSK ou comprimentos de chave, deverá fornecer todos eles e seus argumentos no comando:
--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length
Você pode especificar negação de existência como NSEC ou NSEC3, independentemente de algoritmos.
As opções de algoritmo e argumentos suportados estão listados na tabela a seguir. O Cloud DNS não permite o uso de outros algoritmos ou parâmetros.
| Algoritmo | Comprimentos KSK | Comprimentos ZSK | Comentários |
|---|---|---|---|
| RSASHA256 | 2048 | 1024, 2048 | |
| RSASHA512 | 2048 | 1024, 2048 | Não amplamente suportado |
| ECDSAP256SHA256 | 256 | 256 | |
| ECDSAP384SHA384 | 384 | 384 | Não amplamente suportado |
Se nenhum algoritmo for especificado, o Cloud DNS usará estes padrões:
| Tipo de chave | Algoritmo padrão | Comprimento da chave padrão |
|---|---|---|
| Chave de assinatura de chave (KSK) | RSASHA256 | 2048 |
| Chave de assinatura de zona (ZSK) | RSASHA256 | 1024 |
As diferenças de segurança e desempenho entre RSASHA256 e RSASHA512 são mínimas, e os tamanhos de resposta assinados são idênticos. O comprimento das chaves importa: chaves mais longas são mais lentas e as respostas são maiores (veja análises do tamanho da resposta para a zona raiz e TLDs , e uma análise do desempenho do lado do servidor no Windows ).
O suporte do resolvedor para ECDSA é limitado a sistemas relativamente recentes. Resolvedores mais antigos que não conseguem validar zonas assinadas por ECDSA as consideram não assinadas, o que pode ser inseguro se você usar novos tipos de registro que dependem de DNSSEC . O suporte de registradores e registros para ECDSA de 256 bits é comum, mas não universal. Apenas alguns registros e um número ainda menor de registradores suportam ECDSA de 384 bits. Usar ECDSA pode ser eficaz se você não precisar oferecer suporte a clientes mais antigos; as assinaturas são muito menores e mais rápidas de calcular.
Evite usar algoritmos diferentes para KSK e ZSK em suas zonas gerenciadas; isso reduz a compatibilidade e pode comprometer a segurança. Alguns resolvedores de validação de DNSSEC podem falhar na validação de zonas com algoritmos DNSKEY que não são usados para assinar todos os registros na zona. Isso é verdade mesmo que a RFC 6840 diga que "eles não devem insistir que todos os algoritmos... no conjunto de RRs DNSKEY funcionem". Se isso não for um problema (a maioria dos resolvedores de validação segue a RFC 6840), você pode usar RSASHA256 para KSK e ECDSA para ZSK se o seu registrador de domínio ou registro de TLD não suportar ECDSA e você precisar de tamanhos de resposta reduzidos.
NSEC3 é o tipo padrão de negação de existência; ele oferece proteção limitada contra invasores de zona que tentam descobrir todos os registros na sua zona. As configurações de NSEC3PARAM são fixas: opt-out do NSEC3 é desabilitada por questões de segurança e há uma iteração de hash adicional (para um total de duas) com um salt de 64 bits.
O NSEC tem respostas um pouco menores, mas não oferece proteção contra zone walking. O uso do NSEC também pode reduzir consultas para domínios inexistentes. O Google Public DNS e vários outros resolvedores de validação de DNSSEC podem sintetizar respostas negativas de registros NSEC armazenados em cache sem consultar sua zona do Cloud DNS.
O RFC 8624 contém orientações adicionais sobre seleção de algoritmos.
Use novos tipos de registro DNS com zonas protegidas por DNSSEC
Depois que seu domínio estiver totalmente protegido por DNSSEC, você pode começar a usar vários novos tipos de registros DNS que usam 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 de um servidor SSH que os aplicativos clientes SSH podem usar para validar os servidores SSH. Os clientes SSH geralmente exigem interação do usuário para confirmar a chave pública do servidor na primeira conexão e gerar avisos se a chave for alterada. Um cliente SSH configurado para usar SSHFP sempre usa a chave no registro SSHFP de um servidor para aquele servidor; apenas as chaves de servidores sem um registro SSHFP são salvas para reutilização.
O formato do registro SSHFP é o seguinte:
- Número do algoritmo
- Número do tipo de impressão digital
- Impressão digital da chave do servidor
Os números do algoritmo para SSH são os seguintes:
- RSA
- DSA
- ECDSA
- ED25519
Os tipos de impressão digital são os seguintes:
- SHA-1 ( obsoleto, apenas para compatibilidade )
- SHA-256
O StackExchange tem sugestões para criar SSHFP e existem ferramentas para gerá-las escaneando servidores, usando arquivos de host conhecidos existentes ou gerenciamento de configuração . 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) para assiná-los.
Isso permite que você configure suas próprias CAs e gere certificados para HTTPS. Também permite a validação de certificados para protocolos como SMTP, onde normalmente não há suporte de aplicativo para CAs confiáveis pré-configuradas.
DANE (Autenticação de Domínio de Entidades Nomeadas), conforme especificado na RFC 6698 e RFCs relacionadas, utiliza registros TLSA de maneiras específicas para proteger diversos protocolos e aplicações. O IETF Journal e a Internet Society têm um artigo introdutório útil e uma visão geral do DANE .
HTTPS
O DANE permite que você configure com segurança servidores HTTPS usando certificados gerados com sua própria infraestrutura de CA baseada em OpenSSL ou CFSSL da Cloudflare.
O validador DANE da SIDNLabs para servidores HTTPS é útil para testar uma implantação DANE para HTTPS.
Verificação do certificado SMTP (e-mail) TLS
O protocolo de e-mail SMTP é vulnerável a ataques de downgrade que desabilitam a criptografia , e o DANE fornece uma maneira de evitar esses ataques.
A Internet Society tem um tutorial de duas partes sobre o uso do DANE para SMTP com os certificados gratuitos e automatizados disponíveis no Let's Encrypt , incluindo conselhos para evitar o uso de certos formatos de registro TLSA com certificados Let's Encrypt:
Você pode encontrar excelentes dicas (e um validador de domínio DANE para HTTPS e SMTP) em Erros Comuns . O validador de e-mail "Teste seu e-mail" também verifica o DANE.
Verificação do certificado XMPP (Jabber chat) TLS
O XMPP (e outros serviços que usam registros SRV) também podem tirar proveito do DANE. Um exemplo de XMPP usa a configuração DANE-SRV conforme especificado na RFC 7673 .
Associação de chave pública TXT (OpenPGP / GnuPG)
Registros TXT podem ser usados sem DNSSEC, mas registros TXT assinados por DNSSEC oferecem maior confiança em sua autenticidade. Isso é importante para a publicação baseada em DNS de chaves públicas OpenPGP (GnuPG), que não são assinadas por partes conhecidas, como CAs X.509.
Por exemplo, se 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 fornecido, Bob poderá procurar uma chave OpenPGP para alice@an.example com segurança razoável (isso não substitui a validação da web de confiança, mas torna a criptografia OpenPGP possível com partes previamente desconhecidas):
alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"
Você pode usar estas instruções para gerar esses registros PKA TXT da Versão 1 (como são chamados em Chaves de Publicação no DNS ).
O guia completo para publicar chaves PGP no DNS explica como criar registros OpenPGP CERT (mas o Cloud DNS não oferece suporte a registros CERT ou OPENPGPKEY).
Se você registrou sua chave OpenPGP no Keybase.io , não precisa hospedá-la em seu próprio servidor. Em vez disso, você pode usar uma URL como https://keybase.io/ KEYBASE_USERNAME /key.asc (substitua KEYBASE_USERNAME pelo seu nome de usuário do Keybase.io).
Se você tiver carregado sua chave OpenPGP em um servidor de chaves, também poderá usar um URI hkp: para esse servidor de chaves, como hkp://subkeys.pgp.net ou hkp://pgp.mit.edu , embora usuários atrás de firewalls bloqueando a porta 11371 possam não conseguir acessá-lo (alguns servidores de chaves fornecem URLs HTTP da porta 80).
TXT (SPF, DKIM e DMARC)
A seguir estão três outros tipos de registros TXT que você pode usar para proteger seus serviços de e-mail e impedir que spammers e golpistas enviem e-mails que pareçam 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 para um domínio.
DKIM : publica um conjunto de chaves públicas usadas para verificar se o e-mail é enviado de um domínio e protege as mensagens de serem modificadas em trânsito.
DMARC : especifica políticas de domínio e relatórios para validação de SPF e DKIM e relatórios de erros.
Para verificar se seu domínio está configurado corretamente para usar todos esses três tipos de registro, você pode usar o Testar seu validador de e-mail . Para encontrar dicas úteis sobre como configurar registros SPF, consulte as Perguntas frequentes sobre erros comuns .
Use outros tipos de conjuntos de registros aprimorados pelo DNSSEC
Além do TXT, há alguns outros tipos de conjuntos de registros que se beneficiam do DNSSEC, mesmo que não o exijam.
CAA
Os conjuntos de registros de Autorização de Autoridade Certificadora (CAA) permitem controlar quais CAs públicas podem gerar certificados TLS ou outros para o seu domínio. Esse controle é mais útil (e eficaz) se você quiser garantir que uma CA pública que emite certificados validados por domínio (DV) (como LetsEncrypt.org) não emita certificados para o seu domínio.
Um registro CAA típico tem um formato simples como 0 issue "best-ca.example" , que permite que a best-ca.example (e nenhuma outra CA) emita certificados para nomes no domínio onde o conjunto de registros CAA está localizado. Se você quiser permitir que várias CAs emitam certificados, crie vários registros CAA.
O RFC 6844 fornece mais detalhes sobre o uso do tipo de conjunto de registros CAA e recomenda fortemente o uso do DNSSEC.
IPSECKEY
Você também pode habilitar a criptografia oportunista por meio de túneis IPsec publicando registros IPSECKEY . A implementação do StrongSwan IPsec VPN possui um plugin que utiliza registros IPSECKEY.
Além de colocar registros IPSECKEY nas zonas de encaminhamento usuais, como service.example.com , a seção 1.2 do RFC 4025 exige que os gateways de segurança procurem registros IPSECKEY nas zonas reversas ip6.arpa e in-addr.arpa .
O suporte a DNSSEC para zonas reversas é menos comum do que para zonas de encaminhamento e requer um provedor de serviços de internet (ISP) que implemente DNSSEC. No entanto, existem alguns ISPs que podem oferecer suporte a DNSSEC para delegações de zonas reversas.
Zonas reversas para endereços IP externos de VM do Compute Engine ainda não oferecem suporte à delegação.
O que vem a seguir
- Para criar, atualizar, listar e excluir zonas gerenciadas, consulte Gerenciar zonas .
- Para encontrar soluções para problemas comuns que você pode encontrar ao usar o Cloud DNS, consulte Solução de problemas .
- Para obter uma visão geral do Cloud DNS, consulte Visão geral do Cloud DNS .