Visão geral do DNSSEC (Versão Prévia)
Este artigo fornece uma visão geral das Extensões de Segurança do Sistema de Nomes de Domínio (DNSSEC) e inclui uma introdução à terminologia do DNSSEC. Os benefícios da assinatura de zona DNSSEC são descritos e exemplos são fornecidos para exibir registros de recursos relacionados ao DNSSEC. Quando estiver pronto para assinar sua zona DNS pública do Azure, confira os seguintes guias de instruções:
- Como assinar sua zona DNS pública do Azure com DNSSEC (Versão Prévia)
- Como cancelar a assinatura da sua zona DNS Pública do Azure (Versão Prévia)
Observação
A assinatura de zona DNSSEC está atualmente em VERSÃO PRÉVIA
Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.
O que é DNSSEC?
DNSSEC é um conjunto de extensões que adicionam segurança ao protocolo Sistema de Nomes de Domínio (DNS) permitindo que as respostas DNS sejam validadas como genuínas. A DNSSEC oferece autoridade de origem, integridade dos dados e negação de existência autenticada. Com o DNSSEC, o protocolo DNS fica muito menos suscetível a determinados tipos de ataques, particularmente os ataques de falsificação de DNS.
As principais extensões de DNSSEC estão especificadas nas RFCs (Request For Comments) a seguir.
- RFC 4033: "Introdução e requisitos de segurança de DNS"
- RFC 4034: "Registros de recursos para as extensões de segurança de DNS"
- RFC 4035: "Modificações de protocolo para as extensões de segurança de DNS"
Para obter um resumo dos RFCs DNSSEC, consulte RFC9364: Extensões de Segurança DNS (DNSSEC).
Como o DNSSEC funciona
As zonas DNS são protegidas com DNSSEC usando um processo chamado assinatura de zona. Assinar uma zona com DNSSEC adiciona suporte de validação a uma zona sem alterar o mecanismo básico de uma consulta e resposta DNS. Para assinar uma zona com DNSSEC, o servidor DNS autoritativo principal da zona deve dar suporte ao DNSSEC.
Assinaturas de Registro de Recurso (RRSIGs) e outros registros criptográficos são adicionados à zona quando ela é assinada. A figura a seguir mostra os registros de recursos DNS na zona contoso.com antes e depois da assinatura da zona.
Avalidação DNSSEC de respostas DNS ocorre usando essas assinaturas digitais com uma cadeia de confiança ininterrupta.
Observação
Os registros de recursos relacionados ao DNSSEC não são exibidos no portal do Azure. Para obter mais informações, consulte Visualizar registros de recursos relacionados ao DNSSEC.
Por quê Assinar uma zona com DNSSEC?
A assinatura de uma zona com DNSSEC é necessária para conformidade com algumas diretrizes de segurança, como SC-20: Serviço de Resolução de Endereço/Nome Seguro.
A validação DNSSEC de respostas DNS pode impedir tipos comuns de ataques de sequestro de DNS, também conhecidos como redirecionamento de DNS. O sequestro de DNS ocorre quando um dispositivo cliente é redirecionado para um servidor mal-intencionado usando respostas DNS incorretas (falsificadas). Envenenamento por cache DNS é um método comum usado para falsificar respostas DNS.
Um exemplo de como o sequestro de DNS funciona é mostrado na figura a seguir.
Resolução DNS normal:
- Um dispositivo cliente envia uma consulta DNS para contoso.com para um servidor DNS.
- O servidor DNS responde com um registro de recurso DNS para contoso.com.
- O dispositivo cliente solicita uma resposta de contoso.com.
- O aplicativo contoso.com ou servidor Web retorna uma resposta ao cliente.
Sequestro de DNS
- Um dispositivo cliente envia uma consulta DNS para contoso.com para um servidor DNS sequestrado.
- O servidor DNS responde com um registro de recurso DNS inválido (falsificado) para contoso.com.
- O dispositivo cliente solicita uma resposta para contoso.com do servidor mal-intencionado.
- O servidor mal-intencionado retorna uma resposta falsificada ao cliente.
O tipo de registro de recurso DNS falsificado depende do tipo de ataque de sequestro de DNS. Um registro MX pode ser falsificado para redirecionar emails do cliente ou um registro A falsificado pode enviar clientes para um servidor Web mal-intencionado.
O DNSSEC funciona para impedir o sequestro de DNS executando a validação em respostas DNS. No cenário de sequestro de DNS mostrado aqui, o dispositivo cliente poderá rejeitar respostas DNS não validadas se o domínio contoso.com for assinado com DNSSEC. Para rejeitar respostas DNS não validadas, o dispositivo cliente deve impor a validação DNSSEC para contoso.com.
O DNSSEC também inclui o Next Secure 3 (NSEC3) para impedir a enumeração de zona. A enumeração de zona, também conhecida como caminhada de zona, é um ataque pelo qual o invasor estabelece uma lista de todos os nomes em uma zona, incluindo zonas filho.
Antes de assinar uma zona com DNSSEC, certifique-se de entender como o DNSSEC funciona. Quando estiver pronto para assinar uma zona, confira Como assinar sua zona DNS pública do Azure com DNSSEC.
Validação de DNSSEC
Se um servidor DNS estiver ciente de DNSSEC, ele poderá definir o sinalizador DNSSEC OK (DO) em uma consulta DNS para um valor de 1. Esse valor informa ao servidor DNS que está respondendo para incluir registros de recursos relacionados ao DNSSEC com a resposta. Esses registros DNSSEC são registros de Assinatura de Registro de Recurso (RRSIG) usados para validar que a resposta DNS é genuína.
Um servidor DNS recursivo (não autoritativo) executa a validação DNSSEC em registros RRSIG usando uma âncora de confiança (DNSKEY). O servidor usa um DNSKEY para descriptografar assinaturas digitais em registros RRSIG (e outros registros relacionados ao DNSSEC) e, em seguida, calcula e compara valores de hash. Se os valores de hash forem iguais, ele fornece uma resposta para o cliente DNS com os dados de DNS solicitados, como um registro de recurso de host (A). Confira o seguinte diagrama:
Se os valores de hash não forem os mesmos, o servidor DNS recursivo responderá com uma mensagem SERVFAIL. Dessa forma, servidores DNS com capacidade para DNSSEC resolvendo (ou encaminhando) servidores DNS com uma âncora de confiança válida instalada podem proteger contra o sequestro de DNS no caminho entre o servidor recursivo e o servidor autoritativo. Essa proteção não exige que os dispositivos cliente DNS sejam com reconhecimento DNSSEC ou imponham a validação de resposta DNS, desde que o servidor DNS recursivo local (último salto) esteja seguro contra o sequestro.
Os dispositivos cliente Windows 10 e Windows 11 são resolvedores de stub com reconhecimento de segurança sem validação. Esses dispositivos cliente não executam a validação, mas podem impor a validação DNSSEC usando a Política de Grupo. ONRPT pode ser usado para criar e impor a política de validação DNSSEC baseada em namespace.
Âncoras de confiança e validação DNSSEC
Observação
A validação de resposta DNSSEC não é executada pelo resolvedor padrão fornecido pelo Azure. As informações nesta seção serão úteis se você estiver configurando seus próprios servidores DNS recursivos para validação DNSSEC ou solução de problemas de validação.
As âncoras de confiança operam com base na hierarquia do namespace DNS. Um servidor DNS recursivo pode ter qualquer número de âncoras de confiança ou nenhuma âncora de confiança. Âncoras de confiança podem ser adicionadas para uma única zona DNS filho ou qualquer zona pai. Se um servidor DNS recursivo tiver uma âncora de confiança raiz (.), ele poderá executar a validação DNSSEC em qualquer zona DNS. Para obter mais informações, consulte Informações do Operador de Zona Raiz.
O processo de validação DNSSEC funciona com âncoras de confiança da seguinte maneira:
- Se um servidor DNS recursivo não tiver uma âncora de confiança DNSSEC para uma zona ou o namespace hierárquico pai da zona, ele não executará a validação DNSSEC nessa zona.
- Se um servidor DNS recursivo tiver uma âncora de confiança DNSSEC para o namespace pai de uma zona e receber uma consulta para a zona filho, ele verificará se um registro DS para as zonas filho está presente na zona pai.
- Se o registro DS for encontrado, o servidor DNS recursivo executará a validação DNSSEC.
- Se o servidor DNS recursivo determinar que a zona pai não tem um registro DS para a zona filho, ele pressupõe que a zona filho seja insegura e não execute a validação DNSSEC.
- Se vários servidores DNS recursivos estiverem envolvidos em uma resposta DNS (incluindo encaminhadores), cada servidor deverá ser capaz de executar a validação DNSSEC na resposta para que haja uma cadeia de confiança ininterrupta.
- Servidores recursivos que têm a validação DNSSEC desabilitada ou que não estão cientes de DNSSEC não executam a validação.
Cadeia de confiança
Uma cadeia de confiança ocorre quando todos os servidores DNS envolvidos no envio de uma resposta para uma consulta DNS são capazes de validar que a resposta não foi modificada durante o trânsito. Para que a validação DNSSEC funcione de ponta a ponta, a cadeia de confiança deve ser ininterrupta. Essa cadeia de confiança se aplica a servidores autoritativos e não autoritativos (recursivos).
Servidores Autoritativos
Os servidores DNS autoritativos mantêm uma cadeia de confiança por meio do uso de registros DS (signatários de delegação). Os registros DS são usados para verificar a autenticidade de zonas filho na hierarquia DNS.
- Para que a validação DNSSEC ocorra em uma zona assinada, o pai da zona assinada também deve ser assinado. A zona pai também deve ter um registro DS para a zona filho.
- Durante o processo de validação, o pai de uma zona é consultado para o registro DS. Se o registro DS não estiver presente ou se os dados de registro DS no pai não corresponderem aos dados DNSKEY na zona filho, a cadeia de confiança será interrompida e a validação falhará.
Servidores recursivos
Servidores DNS recursivos (também chamados de servidores DNS de resolução ou cache) mantêm uma cadeia de confiança por meio do uso de âncoras de confiança DNSSEC.
- A âncora de confiança é um registro DNSKEY ou um registro DS que contém um hash de um registro DNSKEY. O registro DNSKEY é criado em um servidor autoritativo quando uma zona é assinada e removido da zona se a zona não estiver assinada.
- As âncoras de confiança devem ser instaladas manualmente em servidores DNS recursivos.
- Se uma âncora de confiança para uma zona pai estiver presente, um servidor recursivo poderá validar todas as zonas filho no namespace hierárquico. Isso inclui consultas encaminhadas. Para dar suporte à validação DNSSEC de todas as zonas DNS assinadas por DNSSEC, você pode instalar uma âncora de confiança para a zona raiz (.).
Sobreposição de chave
A chave de assinatura de zona (ZSK) em uma zona assinada por DNSSEC é distribuída periodicamente (substituída) automaticamente pelo Azure. Não deve ser necessário substituir a KSK (chave de assinatura de chave), mas essa opção está disponível entrando em contato com o suporte da Microsoft. Substituir o KSK requer que você também atualize seu registro DS na zona pai.
Novo algoritmo de assinatura
As zonas são assinadas por DNSSEC usando o Algoritmo de Assinatura Digital de Curva Elíptica (ECDSAP256SHA256).
Registros de recursos relacionados à DNSSEC
A tabela a seguir fornece uma breve descrição dos registros relacionados ao DNSSEC. Para obter informações mais detalhadas, consulte RFC 4034: Registros de Recurso para Extensões de Segurança do DNS e RFC 7344: Automatização da Manutenção de Confiança da Delegação DNSSEC.
| Registro | Descrição |
|---|---|
| RRSIG (Assinatura de registro de recurso) | Um tipo de registro de recurso DNSSEC usado para manter uma assinatura, que abrange um conjunto de registros DNS para um nome e um tipo específicos. |
| DNSKEY | Um tipo de registro de recurso DNSSEC usado para armazenar uma chave pública. |
| Signatário da Delegação | Um tipo de registro de recurso DNSSEC usado para proteger uma delegação. |
| NSEC (Next Secure) | Um tipo de registro de recurso DNSSEC que é usado para provar a inexistência de um nome DNS. |
| NSEC3 (Next Secure 3) | O registro de recurso NSEC3 que fornece negação de existência autenticada e com hash para conjuntos de registros de recursos DNS. |
| Parâmetros Next Secure 3 (NSEC3PARAM) | Especifica parâmetros para registros NSEC3. |
| Signatário de delegação filho (CDS) | Esse registro é opcional. Se presente, o registro CDS pode ser usado por uma zona filho para especificar o conteúdo desejado do registro DS em uma zona pai. |
| DNSKEY filho (CDNSKEY) | Esse registro é opcional. Se o registro CDNSKEY estiver presente em uma zona filho, ele poderá ser usado para gerar um registro DS de um registro DNSKEY. |
Registros de recursos relacionados à DNSSEC
Os registros relacionados ao DNSSEC não são exibidos no portal do Azure. Para exibir registros relacionados ao DNSSEC, use ferramentas de linha de comando, como Resolve-DnsName ou dig.exe. Essas ferramentas estão disponíveis usando o Cloud Shell ou localmente, se instaladas em seu dispositivo. Certifique-se de definir o sinalizador DO em sua consulta usando a opção -dnssecok em Resolve-DnsName ou a opção +dnssec em dig.exe.
Importante
Não use a ferramenta de linha de comando nslookup.exe para consultar registros relacionados ao DNSSEC. A ferramenta usa um cliente DNS interno que não dá suporte à DNSSEC.
Veja os exemplos a seguir:
PS C:\> resolve-dnsname server1.contoso.com -dnssecok
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
server1.contoso.com A 3600 Answer 203.0.113.1
Name : server1.contoso.com
QueryType : RRSIG
TTL : 3600
Section : Answer
TypeCovered : A
Algorithm : 13
LabelCount : 3
OriginalTtl : 3600
Expiration : 9/20/2024 11:25:54 PM
Signed : 9/18/2024 9:25:54 PM
Signer : contoso.com
Signature : {193, 20, 122, 196…}
C:\>dig server1.contoso.com +dnssec
; <<>> DiG 9.9.2-P1 <<>> server1.contoso.com +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61065
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;server1.contoso.com. IN A
;; ANSWER SECTION:
server1.contoso.com. 3600 IN A 203.0.113.1
server1.contoso.com. 3600 IN RRSIG A 13 3 3600 20240920232359 20240918212359 11530 contoso.com. GmxeQhNk1nJZiep7nuCS2qmOQ+Ffs78Z2eoOgIYP3j417yqwS1DasfA5 e1UZ4HuujDk2G6GIbs0ji3RiM9ZpGQ==
;; Query time: 153 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Sep 19 15:23:45 2024
;; MSG SIZE rcvd: 179
PS C:\> resolve-dnsname contoso.com -Type dnskey -dnssecok
Name Type TTL Section Flags Protocol Algorithm Key
---- ---- --- ------- ----- -------- --------- ---
contoso.com DNSKEY 3600 Answer 256 DNSSEC 13 {115, 117, 214,
165…}
contoso.com DNSKEY 3600 Answer 256 DNSSEC 13 {149, 166, 55, 78…}
contoso.com DNSKEY 3600 Answer 257 DNSSEC 13 {45, 176, 217, 2…}
Name : contoso.com
QueryType : RRSIG
TTL : 3600
Section : Answer
TypeCovered : DNSKEY
Algorithm : 13
LabelCount : 2
OriginalTtl : 3600
Expiration : 11/17/2024 9:00:15 PM
Signed : 9/18/2024 9:00:15 PM
Signer : contoso.com
Signature : {241, 147, 134, 121…}
C:\>dig contoso.com dnskey
; <<>> DiG 9.9.2-P1 <<>> contoso.com dnskey
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46254
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;contoso.com. IN DNSKEY
;; ANSWER SECTION:
contoso.com. 3600 IN DNSKEY 256 3 13 laY3Toc/VTyjupgp/+WgD05N+euB6Qe1iaM/253k7bkaA0Dx+gSDhbH2 5wXTt+uLQgPljL9OusKTneLdhU+1iA==
contoso.com. 3600 IN DNSKEY 257 3 13 LbDZAtjG8E9Ftih+LC8CqQrSZIJFFJMtP6hmN3qBRqLbtAj4JWtr2cVE ufXM5Pd/yW+Ca36augQDucd5n4SgTg==
contoso.com. 3600 IN DNSKEY 256 3 13 c3XWpTqZ0q9IO+YqMEtOBHZSzGGeyFKq0+3xzs6tifvD1rey1Obhrkz4 DJlEIxy2m84VsG1Ij9VYdtGxxeVHIQ==
;; Query time: 182 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Sep 19 16:35:10 2024
;; MSG SIZE rcvd: 284
Terminologia DNSSEC
Essa lista é fornecida para ajudar a entender alguns dos termos comuns usados ao discutir o DNSSEC. Veja também: Registros de recursos relacionados à DNSSEC
| Termo | Descrição |
|---|---|
| Bit de dados autenticados (AD) | Um bit de dados que indica em uma resposta que todos os dados incluídos nas seções de resposta e autoridade da resposta foram autenticados pelo servidor DNS de acordo com as políticas desse servidor. |
| Cadeia de autenticação | Uma cadeia de registros DNS assinados e validados que se estende de uma âncora de confiança pré-configurada para alguma zona filho na árvore DNS. |
| Extensão DNS (EDNS0) | Um registro DNS que contém informações de cabeçalho DNS estendidas, como o bit DO e o tamanho máximo do pacote UDP. |
| Extensões de Segurança de DNS (DNSSEC) | Extensões para o serviço DNS que fornecem mecanismos para assinatura e para resolver dados DNS com segurança. |
| Bit DNSSEC OK (DO) | Um bit na parte EDNS0 de uma solicitação DNS que sinaliza que o cliente está ciente de DNSSEC. |
| Validação de DNSSEC | A validação DNSSEC é o processo de verificar a origem e a integridade dos dados DNS usando chaves criptográficas públicas. |
| Ilha de segurança | Uma zona assinada que não tem uma cadeia de autenticação de sua zona pai delegada. |
| Chave KSK | A KSK é uma chave de autenticação que corresponde a uma chave privada usada para assinar uma ou mais outras chaves de autenticação. Normalmente, a chave privada que corresponde a um KSK assina uma ZSK (chave de assinatura de zona), que, por sua vez, tem uma chave privada correspondente que assina outros dados de zona. A política local pode exigir que o ZSK seja alterado com frequência, enquanto o KSK pode ter um período de validade mais longo para fornecer um ponto de entrada mais estável e seguro para a zona. Designar uma chave de autenticação como um KSK é puramente um problema operacional: a validação DNSSEC não distingue entre KSKs e outras chaves de autenticação DNSSEC. É possível usar uma única chave como um KSK e um ZSK. |
| Resolvedor de stub sem avaliação de segurança | Um resolvedor de stub com reconhecimento de segurança que confia em um ou mais servidores DNS com reconhecimento de segurança para executar a validação DNSSEC em seu nome. |
| Chave ponto de entrada seguro (SEP) | Um subconjunto de chaves públicas dentro do RRSet DNSKEY. Uma chave SEP é usada para gerar um DS RR ou é distribuída para resolvedores que usam a chave como uma âncora de confiança. |
| Servidor DNS com reconhecimento de segurança | Um servidor DNS que implementa as extensões de segurança DNS conforme definido nos RFCs 4033 [5], 4034 [6] e 4035 [7]. Em particular, um servidor DNS com reconhecimento de segurança é uma entidade que recebe consultas DNS, envia respostas DNS, dá suporte à extensão de tamanho da mensagem EDNS0 [3] e ao bit DO e dá suporte aos tipos de registro DNSSEC e aos bits de cabeçalho da mensagem. |
| Zona Assinada | Uma zona cujos registros são assinados conforme definido pelo RFC 4035 [7] Seção 2. Uma zona assinada pode conter registros de recursos DNSKEY, NSEC, NSEC3, NSEC3PARAM, RRSIG e DS. Esses registros de recursos permitem que os dados DNS sejam validados por resolvedores. |
| Âncora de Confiança | Uma chave pública pré-configurada associada a uma zona específica. Uma âncora de confiança permite que um resolvedor DNS valide os registros de recursos DNSSEC assinados para essa zona e crie cadeias de autenticação em zonas filho. |
| Zona sem sinal | Qualquer zona DNS que não tenha sido assinada conforme definido pelo RFC 4035 [7] Seção 2. |
| Assinatura de zona | A assinatura de zona é o processo de criação e adição de registros de recursos relacionados ao DNSSEC a uma zona, tornando-a compatível com a validação DNSSEC. |
| Desassociamento de zona | O desassociamento de zona é o processo de remoção de registros de recursos relacionados ao DNSSSEC de uma zona, restaurando-os para um status não assinado. |
| Chave ZSK | Uma chave de autenticação que corresponde a uma chave privada usada para assinar uma zona. Normalmente, uma chave de assinatura de zona faz parte do mesmo DNSKEY RRSet que a chave de assinatura de chave cuja chave privada correspondente assina esse DNSKEY RRSet, mas a chave de assinatura de zona é usada para uma finalidade ligeiramente diferente e pode diferir da chave de assinatura de chave de outras maneiras, como no tempo de vida de validade. Designar uma chave de autenticação como uma chave de assinatura de zona é apenas um problema operacional; A validação DNSSEC não distingue entre chaves de assinatura de zona e outras chaves de autenticação DNSSEC. É possível usar uma única chave como uma chave de assinatura de chave e uma chave de assinatura de zona. |