Esta página oferece várias opções de configuração avançadas das Domain Name System Security Extensions (Extensões de segurança do Sistema de Nomes de Domínio – DNSSEC) que pode usar se ativar as DNSSEC para as suas zonas geridas. Estas opções variam entre diferentes algoritmos de assinatura e negação de existência, até à capacidade de usar tipos de registos que requerem ou recomendam DNSSEC para a sua utilização.
Para uma vista geral conceptual das DNSSEC, consulte a vista geral das DNSSEC.
Delegue subdomínios com assinatura DNSSEC
Pode ativar as DNSSEC para subdomínios delegados depois de ativar as DNSSEC para o domínio principal. Para ativar as DNSSEC para subdomínios delegados, comece por criar um registo DS numa zona do Cloud DNS. Também tem de criar um ou mais registos NS.
Para criar registos DS para subdomínios delegados, tem de obter o registo DS para a zona. Se a zona delegada também estiver alojada no Cloud DNS, pode obter o registo DS a partir da Google Cloud consola ou da CLI Google Cloud.
Consola
Na Google Cloud consola, aceda à página Cloud DNS.
Navegue para a zona gerida para a qual quer ver o registo DS.
Para ver o registo DS da zona, no canto superior direito da página Detalhes da zona, clique em Configuração do registador.
O registo DS está disponível na página Configuração do registador.
Para criar registos NS, siga as instruções em Adicionar um registo.
gcloud
Para obter as informações do registo DS para subdomínios delegados, execute o seguinte comando:
gcloud dns dns-keys list --zone EXAMPLE_ZONE
Substitua
EXAMPLE_ZONEpelo nome da zona de DNS do subdomínio delegado no seu projeto.O resultado tem o seguinte aspeto:
ID KEY_TAG TYPE IS_ACTIVE DESCRIPTION 0 1234 KEY_SIGNING True 1 12345 ZONE_SIGNING True
Para obter um registo DS completo e todos os detalhes da chave, precisa do ID da chave de assinatura de chaves (KSK), que normalmente é 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 no seu projetoKSK_ID: o número de ID do KSK, normalmente 0
O resultado tem um aspeto semelhante ao seguinte:
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
Copie o resultado do comando anterior para o usar num passo subsequente.
Para criar os registos 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 de DNS principal no seu projeto onde está a criar os registos para o subdomínio delegado.O resultado tem o seguinte aspeto:
Transaction started [transaction.yaml].
Em seguida, execute o seguinte comando para adicionar um conjunto de registos:
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 principal no seu projetoTIME_TO_LIVE: tempo de vida da zona em segundos, como 3600subdomain.example.com: um subdomínio do nome DNS da zonaDS_RECORD_AND_KEY: o registo DS e a chave que obteve no passo 2, como44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
O resultado tem o seguinte aspeto:
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb Record addition appended to transaction at [transaction.yaml].
Para adicionar registos 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 principal no seu projetoTIME_TO_LIVE: tempo de vida da zona em segundos, como 3600subdomain.example.com: um subdomínio do nome DNS da zona
Introduza os seguintes dados RRData:
ns-cloud-e1.googledomains.com. \ ns-cloud-e2.googledomains.com. \ ns-cloud-e3.googledomains.com. \ ns-cloud-e4.googledomains.com.
O resultado tem o seguinte aspeto:
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.O resultado tem o seguinte aspeto:
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
Use opções de assinatura avançadas
Quando ativa as DNSSEC para uma zona gerida ou cria uma zona gerida com DNSSEC, pode selecionar os algoritmos de assinatura DNSSEC e o tipo de negação de existência.
Pode alterar as definições das DNSSEC (por exemplo, para o algoritmo usado para assinar registos criptograficamente) para uma zona gerida antes de ativar as DNSSEC. Se as DNSSEC já estiverem ativadas para uma zona gerida, para fazer alterações, primeiro desative as DNSSEC, faça as alterações necessárias e, em seguida, use o seguinte comando para reativar as DNSSEC:
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 o artigo Ative o DNSSEC para zonas geridas existentes.
O comando seguinte ativa as DNSSEC com ECDSA de 256 bits e NSEC para os pacotes de resposta assinados com DNSSEC mais pequenos possíveis através 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 DNS no seu projeto.
Se fornecer algoritmos ou comprimentos de chaves KSK ou ZSK, tem de fornecer todos eles e os respetivos argumentos no comando:
--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length
Pode especificar a negação de existência como NSEC ou NSEC3, independentemente dos algoritmos.
As opções e os argumentos de algoritmos suportados estão listados na tabela seguinte. O Cloud DNS não permite a utilização 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 não for especificado nenhum algoritmo, o Cloud DNS usa estas predefinições:
| Tipo de chave | Algoritmo predefinido | Comprimento da chave predefinido |
|---|---|---|
| Chave de assinatura de chaves (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 das respostas assinadas são idênticos. O comprimento das chaves é importante: as chaves mais longas são mais lentas e as respostas são maiores (consulte as análises do tamanho da resposta para a zona raiz e os TLDs, e uma análise do desempenho do lado do servidor no Windows).
O apoio técnico para ECDSA está limitado a sistemas relativamente recentes. Os resolvedores mais antigos que não conseguem validar zonas assinadas com ECDSA consideram-nas não assinadas, o que pode ser inseguro se usar novos tipos de registos que dependem das DNSSEC. O suporte de registo e registador para ECDSA de 256 bits é comum, mas não universal. Apenas alguns registos e ainda menos registadores suportam ECDSA de 384 bits. A utilização do ECDSA pode ser eficaz se não precisar de suportar clientes mais antigos; as assinaturas são muito mais pequenas e rápidas de calcular.
Evite usar algoritmos diferentes para o KSK e o ZSK nas suas zonas geridas; reduz a compatibilidade e pode comprometer a segurança. Alguns resolvedores de validação de DNSSEC podem falhar a validação de zonas com algoritmos DNSKEY que não são usados para assinar todos os registos na zona. Isto é verdade, apesar de a norma RFC 6840 indicar que "não devem insistir que todos os algoritmos … no RRset DNSKEY funcionem". Se isto não for um problema (a maioria dos resolvedores de validação segue a RFC 6840), pode usar RSASHA256 para a KSK e ECDSA para a ZSK se o registo de domínio ou o registo de TLD não suportarem ECDSA e precisar de tamanhos de resposta reduzidos.
O NSEC3 é o tipo de negação de existência predefinido; oferece proteção limitada
contra os zone walkers que tentam descobrir todos os registos na sua zona.
As definições NSEC3PARAM são fixas: o NSEC3 opt-out está desativado por motivos de segurança e existe uma iteração de hash adicional (para um total de duas) com um salt de 64 bits.
O NSEC tem respostas ligeiramente mais pequenas, mas não oferece proteção contra a análise de zonas. A utilização de NSEC também pode reduzir as consultas de domínios inexistentes. O DNS público da Google e vários outros resolvedores de validação de DNSSEC podem sintetizar respostas negativas a partir de registos NSEC em cache sem consultar a sua zona do Cloud DNS.
A RFC 8624 contém orientações adicionais sobre a seleção de algoritmos.
Use novos tipos de registos de DNS com zonas protegidas por DNSSEC
Depois de o seu domínio estar totalmente protegido pelas DNSSEC, pode começar a usar vários novos tipos de registos DNS que usam as garantias de autenticidade e integridade das zonas assinadas pelas DNSSEC para melhorar a segurança de outros serviços.
SSHFP
Os registos SSHFP contêm uma impressão digital da chave pública de um servidor SSH que as aplicações cliente SSH podem usar para validar os servidores SSH. Normalmente, os clientes SSH requerem a interação do utilizador para confirmar a chave pública do servidor na primeira ligação e geram avisos se a chave for alterada. Um cliente SSH configurado para usar SSHFP usa sempre a chave no registo SSHFP de um servidor para esse servidor. Só as chaves para servidores sem um registo SSHFP são guardadas para reutilização.
O formato do registo 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 dos algoritmos para SSH são os seguintes:
- RSA
- DSA
- ECDSA
- ED25519
Os tipos de pegadas digitais são os seguintes:
- SHA-1 (descontinuado, apenas para compatibilidade)
- SHA-256
O StackExchange tem sugestões para criar SSHFP, e existem ferramentas para os gerar através da análise de servidores, usando ficheiros de anfitriões conhecidos existentes ou gestão de configuração. Para mais exemplos e links, consulte o artigo Registos SSHFP: o DNS fornece chaves de anfitrião SSH públicas.
TLSA e DANE
Os registos TLSA contêm informações que podem ser usadas para validar certificados X.509 (como certificados usados pelo HTTPS) sem depender de um de um conjunto pré-configurado de autoridades de certificação (ACs) que os assinam.
Isto permite-lhe configurar as suas próprias ACs e gerar certificados para HTTPS. Isto também permite a validação de certificados para protocolos como SMTP, em que normalmente não existe suporte de aplicações para ACs fidedignas pré-configuradas.
O DANE (Domain Authentication of Named Entities), conforme especificado na RFC 6698 e RFCs relacionadas, usa registos TLSA de formas específicas para proteger muitos protocolos e aplicações. O IETF Journal e a Internet Society têm um artigo introdutório útil e uma vista geral da DANE.
HTTPS
O DANE permite-lhe configurar servidores HTTPS de forma segura através de certificados gerados com a sua própria infraestrutura de AC com base no OpenSSL ou no CFSSL da Cloudflare.
O validador DANE para servidores HTTPS da SIDNLabs é útil para testar uma implementação DANE para HTTPS.
Validação do certificado TLS SMTP (email)
O protocolo de email SMTP é vulnerável a ataques de alteração para uma versão anterior que desativam a encriptação, e o DANE oferece uma forma de impedir estes ataques.
A Internet Society tem um tutorial de duas partes sobre a utilização de DANE para SMTP com os certificados gratuitos e automatizados disponíveis em Let's Encrypt, incluindo sugestões para evitar a utilização de determinados formatos de registos TLSA com certificados Let's Encrypt:
Pode encontrar excelentes conselhos (e um validador de domínio DANE para HTTPS e SMTP) em Erros comuns. A opção Teste o seu validador de email também verifica o DANE.
Validação do certificado TLS do XMPP (chat Jabber)
O XMPP (e outros serviços que usam registos SRV) também podem tirar partido 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)
Os registos TXT podem ser usados sem DNSSEC, mas os registos TXT assinados com DNSSEC oferecem maior confiança na respetiva autenticidade. Isto é importante para a publicação baseada em DNS de chaves públicas OpenPGP (GnuPG), que não são assinadas por partes conhecidas, como as ACs X.509.
Por exemplo, se Alice publicar um registo TXT como o seguinte na zona an.example com assinatura DNSSEC e alojar uma cópia da chave pública com proteção ASCII no URI indicado, Bob pode procurar uma chave OpenPGP para alice@an.example com uma segurança razoável (isto não substitui a validação da rede de confiança, mas torna a encriptação OpenPGP possível com partes anteriormente desconhecidas):
alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"
Pode usar estas instruções para gerar estes registos TXT PKA versão 1 (como são denominados em Publicar chaves no DNS).
O guia completo para publicar chaves PGP no DNS explica como criar registos CERT OpenPGP (mas o Cloud DNS não suporta registos CERT nem OPENPGPKEY).
Se registou a sua chave OpenPGP em Keybase.io,
não precisa de alojar a chave no seu próprio servidor. Em alternativa, pode usar um URL, como https://keybase.io/KEYBASE_USERNAME/key.asc (substitua KEYBASE_USERNAME pelo seu nome de utilizador do Keybase.io).
Se tiver carregado a sua chave OpenPGP para um servidor de chaves, também pode usar um URI hkp: para esse servidor de chaves, como hkp://subkeys.pgp.net ou hkp://pgp.mit.edu, embora os utilizadores atrás de firewalls que bloqueiam a porta 11371 possam não conseguir aceder ao mesmo (alguns servidores de chaves fornecem URLs HTTP da porta 80).
TXT (SPF, DKIM e DMARC)
Seguem-se outros três tipos de registos TXT que pode usar para proteger os seus serviços de email e impedir que spammers e autores de esquemas enviem emails que parecem ser provenientes do seu domínio (embora não sejam):
SPF: Especifica os servidores SMTP (por nome do domínio ou endereço IP) que podem enviar emails para um domínio.
DKIM: Publica um conjunto de chaves públicas usadas para verificar se o email é enviado a partir de um domínio, e protege as mensagens contra modificações durante a transmissão.
DMARC: Especifica políticas de domínio e relatórios para a validação SPF e DKIM e relatórios de erros.
Para verificar se o seu domínio está configurado corretamente para usar todos estes três tipos de registos, pode usar a opção Testar o validador de email. Para encontrar sugestões úteis sobre a configuração de registos SPF, consulte as Perguntas frequentes sobre erros comuns.
Use outros tipos de conjuntos de registos melhorados pelas DNSSEC
Além do TXT, existem alguns outros tipos de conjuntos de registos que beneficiam da DNSSEC, apesar de não a exigirem.
CAA
Os conjuntos de registos de autorização da autoridade de certificação (CAA) permitem-lhe controlar que ACs públicas podem gerar TLS ou outros certificados para o seu domínio. Este controlo é mais útil (e eficaz) se quiser garantir que uma AC pública que emite certificados validados por domínio (DV) (como LetsEncrypt.org) não emite certificados para o seu domínio.
Um registo CAA típico tem um formato simples, como 0 issue "best-ca.example", que permite à AC best-ca.example (e a nenhuma outra AC) emitir certificados para nomes no domínio onde o conjunto de registos CAA está localizado.
Se quiser permitir que várias ACs emitam certificados, crie vários registos CAA.
A RFC 6844 fornece mais detalhes sobre a utilização do tipo de conjunto de registos CAA e recomenda vivamente a utilização de DNSSEC.
IPSECKEY
Também pode ativar a encriptação oportunista através de túneis IPsec publicando registos IPSECKEY. A implementação de VPN IPsec strongSwan tem um plug-in que usa registos IPSECKEY.
Além de colocar registos IPSECKEY nas zonas de encaminhamento habituais, como service.example.com, a secção 1.2 da RFC 4025 requer que os gateways de segurança procurem registos IPSECKEY nas zonas inversas ip6.arpa e in-addr.arpa.
O suporte de DNSSEC para zonas inversas é menos comum do que para zonas diretas e requer um fornecedor de serviços de Internet (ISP) que implemente DNSSEC. No entanto, existem alguns ISPs que podem suportar DNSSEC para delegações de zonas inversas.
As zonas inversas para endereços IP externos de VMs do Compute Engine ainda não suportam delegação.
O que se segue?
- Para criar, atualizar, listar e eliminar zonas geridas, consulte o artigo Gerir zonas.
- Para encontrar soluções para problemas comuns que pode encontrar ao usar o Cloud DNS, consulte a secção Resolução de problemas.
- Para obter uma vista geral do Cloud DNS, consulte o artigo Vista geral do Cloud DNS.