Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Os registros de recursos DNSSEC são usados para validar e proteger respostas DNS. As zonas DNS são protegidas com DNSSEC por meio da assinatura de zona. Assinar uma zona adiciona suporte à validação sem alterar o mecanismo básico de uma consulta e resposta DNS. Para obter uma introdução do DNSSEC para DNS Server no Windows Server, consulte Visão geral do DNSSEC.
As assinaturas digitais são incluídas com respostas DNS para fornecer validação. Essas assinaturas digitais estão contidas em registros de recursos relacionados ao DNSSEC que são gerados e adicionados à zona durante a assinatura de zona.
DNS recursivo
Quando um servidor DNS recursivo ou de encaminhamento com suporte a DNSSEC recebe uma consulta de um cliente DNS para uma zona assinada com DNSSEC, ele solicita ao servidor DNS autoritativo enviar também os registros DNSSEC para validar a resposta DNS. Um servidor DNS recursivo ou de encaminhamento reconhece que a zona dá suporte a DNSSEC se tiver um DNSKEY, também chamado de âncora de confiança, para essa zona.
Importante
Um servidor DNS não autoritativo pode usar recursão ou encaminhamento para resolver uma consulta DNS. Este tópico refere-se ao servidor não autoritativo como um servidor DNS recursivo; se o servidor usar o encaminhamento, o processo usado para validação DNSSEC de respostas DNS será o mesmo.
Chave de DNS
Um servidor DNS recursivo usa o registro de recurso DNSKEY para validar respostas do servidor DNS autoritativo. Para validar as respostas, o servidor DNS descriptografa as assinaturas digitais contidas nos registros de recursos relacionados ao DNSSEC e compara os valores de hash. Se os valores de hash forem idênticos, ele fornecerá uma resposta ao cliente DNS com os dados DNS solicitados, como um registro de recurso de host (A). Se os valores de hash não corresponderem, ele responderá com uma SERVFAIL mensagem. Dessa forma, um servidor DNS com capacidade para DNSSEC com uma âncora de confiança válida instalada protege contra ataques de falsificação de DNS, independentemente de os clientes DNS estarem ou não cientes de DNSSEC.
Se o cliente DNS estiver ciente de DNSSEC, ele poderá ser configurado para exigir que o servidor DNS execute a validação DNSSEC.
A figura a seguir mostra o processo de validação.
DNSKEYs são usados para calcular valores de hash e descriptografar registros RRSIG. A figura não exibe todos os processos de validação executados. Mais validação também é realizada para garantir que os DNSKEYs sejam válidos e que os registros DS sejam válidos, se existirem (não mostrados na captura de tela).
Processo de consulta e resposta DNS
Um exemplo simples ilustra como você pode incorporar o DNSSEC ao processo de consulta e resposta DNS para fornecer validação.
No exemplo a seguir, um computador cliente DNS consulta um servidor DNS recursivo (cache), que, por sua vez, consulta servidores DNS autoritativos antes de retornar uma resposta. Este exemplo pressupõe que os dados DNS ainda não estão armazenados em cache no cliente ou servidor. Os dados DNSSEC validam as respostas DNS como genuínas somente quando uma zona é assinada e você está usando servidores e clientes com reconhecimento DNSSEC.
A figura a seguir mostra o processo de consulta DNS recursivo.
A tabela a seguir mostra as etapas em uma consulta E resposta DNS com dados DNSSEC opcionais.
| Passo | Consulta-resposta | Dados DNSSEC opcionais |
|---|---|---|
| 1 | Um cliente DNS envia uma consulta DNS para um servidor DNS recursivo. | O cliente DNS pode indicar que ele está ciente de DNSSEC (DO=1). |
| 2 | O servidor DNS recursivo envia uma consulta DNS para os servidores DNS de domínio raiz e de nível superior (TLD). | O servidor DNS recursivo pode indicar que ele está ciente de DNSSEC (DO=1). |
| 3 | Os servidores TLD e raiz retornam uma resposta DNS ao servidor DNS recursivo que fornece o endereço IP do servidor DNS autoritativo para a zona. | Servidores autoritativos para a zona pai podem indicar que a zona filha é assinada usando DNSSEC e inclui uma delegação segura (registro DS). |
| 4 | O servidor DNS recursivo envia uma consulta DNS para o servidor DNS autoritativo da zona. | O servidor DNS recursivo pode indicar que ele está ciente de DNSSEC (DO=1) e capaz de validar registros de recursos assinados (CD=1) a serem enviados na resposta. |
| 5 | O servidor DNS autoritativo retorna uma resposta DNS ao servidor DNS recursivo, fornecendo os dados de registro de recurso. | O servidor DNS autoritativo pode incluir assinaturas DNSSEC na forma de registros RRSIG na resposta DNS, para uso na validação. |
| 6 | O servidor DNS recursivo retorna uma resposta DNS ao cliente DNS, fornecendo os dados de registro de recurso. | O servidor DNS recursivo pode indicar se a resposta DNS foi validada (AD=1) ou não usando DNSSEC. |
Incluindo dados DNSSEC
Os sinalizadores relacionados ao DNSSEC (bits) são usados em uma consulta e resposta DNS para determinar se os dados DNSSEC estão incluídos e se a validação foi realizada. Esses sinalizadores são definidos ativando ou desativando bits de dados estendidos no cabeçalho do pacote DNS. Quando esses sinalizadores são ativados, isso é chamado de "configuração" do bit (o valor é definido como 1). Desativar um sinalizador é chamado de "limpar" o bit (o valor é definido como 0).
-
DO: O bit DO está incluído em uma consulta DNS e é uma abreviação de "DNSSEC OK". Se o bit DO estiver definido (
DO=1), o cliente estará ciente de DNSSEC e será seguro para o servidor DNS retornar dados DNSSEC em uma resposta. Se o bit DO não estiver definido (DO=0), o cliente não está ciente de DNSSEC e o servidor DNS não poderá incluir nenhum dado DNSSEC em uma resposta DNS. Os clientes DNS ainda podem ser protegidos usando DNSSEC mesmo que não estejam cientes de DNSSEC. Nesse contexto, um cliente DNS é qualquer computador que envia uma consulta DNS. Quando um servidor DNS recursivo envia uma consulta para o servidor DNS autoritativo, o servidor DNS recursivo deve indicar que ele está ciente de DNSSEC para que o servidor DNS autoritativo envie dados DNSSEC na resposta. -
AD: O bit do AD é incluído em uma resposta DNS e é uma abreviação para "dados autenticados". Se o bit do AD estiver definido (
AD=1), isso significa que a resposta DNS é autenticada porque foi validada usando DNSSEC. Um computador sem reconhecimento DNSSEC, como um que executa o Windows 8, não executa a validação DNSSEC, mas pode ser configurado para exigir que as respostas DNS sejam autenticadas. Se o bit do AD não estiver definido (AD=0), a resposta DNS não foi validada. O bit do AD pode não ser definido porque a validação não foi tentada ou porque a validação falhou. -
CD: O bit CD está incluído em uma consulta DNS e é uma abreviação de "verificação desabilitada". Se o bit de CD estiver definido (
CD=1) em uma consulta, isso significará que uma resposta DNS deve ser enviada se a validação foi executada com êxito ou não. Se o bit de CD não estiver definido (CD=0), uma resposta DNS não será enviada se a validação for necessária e falhar. Se o bit de CD estiver claro (CD=0), isso significa "verificação habilitada" e a validação DNSSEC poderá ocorrer. O bit CD pode ser definido (CD=1) em uma consulta porque o host é capaz de executar a validação DNSSEC e não requer validação upstream, como um servidor DNS recursivo executando o Windows Server 2012 ou posterior. Um resolvedor de stub não validador, como um computador executando o cliente DNS do Windows, emite consultas com o bit CD limpoCD=0. Para obter mais informações, consulte RFC4035, seção 3.2.2.
Um quarto sinalizador importante (bit) que pode estar presente em um cabeçalho de pacote DNS é o bit AA. Esse sinalizador não é novo com DNSSEC, mas pode ser usado quando DNSSEC é implantado:
-
AA: O bit AA é incluído em uma resposta DNS e é uma abreviação de "resposta autoritativa". Se o bit AA estiver definido, isso significa que a resposta DNS é autenticada porque veio diretamente de um servidor DNS autoritativo. Um cliente que requer a validação DNSSEC (
AD=1) aceita o bit AA em vez disso (AA=1,AD=0). Se o cliente consulta diretamente um servidor autoritativo porque as respostas autoritativas não precisam ser validadas. Seria redundante para um servidor autoritativo validar sua própria resposta.
Exemplo de consultas DNS
Os exemplos a seguir exibem os resultados da consulta DNS executados de um computador cliente DNS executando o Windows 8.1 usando o cmdlet Resolve-DnsName . O cmdlet Resolve-DnsName foi introduzido no Windows Server 2012 e no Windows 8 e pode ser usado para exibir consultas DNS que incluem dados DNSSEC.
Importante
Não use a ferramenta de linha de comando para testar o nslookup.exe suporte DNSSEC para uma zona. A nslookup.exe ferramenta usa um cliente DNS interno que não tem reconhecimento DNSSEC.
Exemplo 1: No exemplo a seguir, uma consulta é enviada a um servidor DNS recursivo para um registro de endereço (A) na zona assinada secure.contoso.com com DO=0.
Resolve-DnsName finance.secure.contoso.com –type A -server dns1.contoso.com
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
finance.secure.contoso.com A 2848 Answer 192.168.0.200
O bit DO não está definido porque o parâmetro dnssecok não foi incluído.
Exemplo 2: No exemplo a seguir, o DO=1 sinalizador é definido adicionando o parâmetro dnssecok .
Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com -dnssecok
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
finance.secure.contoso.com A 2848 Answer 192.168.0.200
Name : finance.secure.contoso.com
QueryType : RRSIG
TTL : 2848
Section : Answer
TypeCovered : A
Algorithm : 8
LabelCount : 4
OriginalTtl : 3600
Expiration : 10/18/2013 8:23:41 PM
Signed : 10/8/2013 7:23:41 PM
Signer : secure.contoso.com
Signature : {86, 229, 217, 39...}
Name : .
QueryType : OPT
TTL : 32768
Section : Additional
Data : {}
Quando DO=0, o servidor DNS não envia dados DNSSEC na resposta DNS. Quando DO=1, o cliente indica que é capaz de receber dados DNSSEC, se disponíveis. Como a zona secure.contoso.com é assinada, um registro de recurso RRSIG foi incluído com a resposta DNS quando DO=1.
No exemplo 1 e no exemplo 2, a validação não é necessária para a secure.contoso.com zona porque a NRPT (Tabela de Política de Resolução de Nomes) não está configurada para exigir validação.
Você pode usar o cmdlet Get-DnsClientNrptPolicy para exibir as regras NRPT atuais. Para obter mais informações, consulte Get-DnsClientNrptPolicy.
Exemplo 3: No exemplo a seguir, uma regra NRPT é exibida para secure.contoso.com.
Get-DnsClientNrptPolicy
Namespace : .secure.contoso.com
QueryPolicy :
SecureNameQueryFallback :
DirectAccessIPsecCARestriction :
DirectAccessProxyName :
DirectAccessDnsServers :
DirectAccessEnabled :
DirectAccessProxyType : NoProxy
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired : False
NameServers :
DnsSecIPsecCARestriction :
DnsSecQueryIPsecEncryption :
DnsSecQueryIPsecRequired : False
DnsSecValidationRequired : False
NameEncoding : Utf8WithoutMapping
Neste exemplo, o valor de DnsSecValidationRequired é False. Quando o valor é falso, a validação DNSSEC não é necessária.
Exemplo 4: com a validação DNSSEC habilitada para secure.contoso.com, o NRPT exibe True para DnsSecValidationRequired. Este exemplo exibe apenas o secure.contoso.com namespace e o parâmetro DnsSecValidationRequired .
(Get-DnsClientNrptPolicy -NameSpace secure.contoso.com).DnsSecValidationRequired
True
Se o valor de DnsSecValidationRequired for Verdadeiro, os computadores cliente compatíveis com DNSSEC sempre enviarão consultas com DO=1, mesmo que o parâmetro dnssecok não esteja incluído.
Exemplo 5: quando a validação DNSSEC é necessária na NRPT (Tabela de Política de Resolução de Nomes), o bit OK DNSSEC é definido automaticamente (DO=1) para clientes com reconhecimento DNSSEC.
Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
finance.secure.contoso.com A 2848 Answer 192.168.0.200
Name : finance.secure.contoso.com
QueryType : RRSIG
TTL : 2848
Section : Answer
TypeCovered : A
Algorithm : 8
LabelCount : 4
OriginalTtl : 3600
Expiration : 10/18/2013 8:23:41 PM
Signed : 10/8/2013 7:23:41 PM
Signer : secure.contoso.com
Signature : {86, 229, 217, 39...}
Name : .
QueryType : OPT
TTL : 32768
Section : Additional
Data : {}
Neste exemplo, um registro RRSIG é enviado na resposta DNS para atender aos requisitos de validação para secure.contoso.com. Uma âncora de confiança válida também é configurada no servidor dns1.contoso.comDNS recursivo.
Se um cliente DNS não estiver familiarizado com o DNSSEC, a regra NRPT não será aplicada e as consultas serão enviadas DO=0, mesmo que uma regra NRPT exija a validação DNSSEC.
Exemplo 6: No exemplo a seguir, a mesma consulta é executada como no exemplo 5, mas sem uma âncora de confiança válida configurada.dns1.contoso.com
Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com
Resolve-DnsName : finance.secure.contoso.com : Unsecured DNS packet
At line:1 char:1
+ Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.co ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (finance.secure.contoso.com:String) [Resolve-DnsName], Win32Excepti
on
+ FullyQualifiedErrorId : DNS\_ERROR\_UNSECURE\_PACKET,Microsoft.DnsClient.Commands.ResolveDnsName
Neste exemplo, a resolução DNS falha com a mensagem DNS_ERROR_UNSECURE_PACKET. A resolução falha porque a validação é necessária no NRPT, mas não pode ser executada devido à falta de uma âncora de confiança válida para a zona secure.contoso.com. O cmdlet Resolve-DnsName relata resultados detalhados para o tipo de falha encontrada. Se o cliente DNS tentar resolver finance.secure.contoso.com para se conectar a esse host, ele falhará.
Cenários DNSSEC
O DNSSEC pode ser implantado em muitos ambientes diferentes com configurações exclusivas de servidor e cliente, é importante entender como as consultas e respostas DNS são afetadas.
Considere as quatro instruções relacionadas ao DNSSEC a seguir. Cada instrução afeta como o DNSSEC funciona em um determinado cenário:
- O
finance.secure.contoso.comregistro de recurso é assinado corretamente com DNSSEC. - Um servidor DNS recursivo é capaz de validar respostas para uma consulta para
finance.secure.contoso.com. - Um cliente DNS é compatível com DNSSEC.
- Um cliente DNS é configurado para exigir validação para todas as consultas no
secure.contoso.comnamespace.
Vamos considerar cada uma dessas quatro declarações com mais detalhes.
Status de assinatura DNSSEC: DNSSEC assina todos os registros na zona, essa condição refere-se ao estado da zona como um todo, não apenas ao registro de recursos. Você não pode assinar alguns registros e não assinar outros registros. Portanto, o status DNSSEC de
finance.secure.contoso.comdepende do status DNSSEC desecure.contoso.com.Assinado corretamente: a
secure.contoso.comzona pode ser assinada de maneira válida, o que permitefinance.secure.contoso.comser validado como original. Para ser válida, a zona deve ser assinada com chaves válidas e não expiradas e todos os registros de recursos relacionados ao DNSSEC necessários devem estar presentes.Não assinado: A zona
secure.contoso.compode não estar assinada, caso em que não há nenhum registro RRSIG associado afinance.secure.contoso.com, e as consultas DNS parafinance.secure.contoso.comnão podem ser validadas. Se um cliente exigir validação, uma consulta DNS enviada para um servidor DNS recursivo falhará porque o cliente DNS não aceita uma resposta não avaliada. Se um cliente consultar diretamente um servidor autoritativo, ele não falhará na validação porque a resposta já é considerada autentica.Não assinado corretamente: a
secure.contoso.comzona pode ser assinada, mas não de maneira válida. Por exemplo, uma ou mais chaves de assinatura DNSSEC podem ter expirado. Depois de assinar inicialmente uma zona, a zona deve ser reassinada periodicamente com novas chaves antes que o período de validade da chave de assinatura expire, a fim de manter um status operacional DNSSEC seguro. O período de validade das chaves de assinatura DNSSEC deve ser curto o suficiente para manter a segurança, mas tempo suficiente para habilitar uma administração fácil. O DNSSEC no Windows Server 2012 e no Windows Server 2012 R2 dá suporte à substituição automática de chaves, fornecendo segurança e facilidade de administração para suas zonas assinadas por DNSSEC.
Status de validação: um servidor DNS recursivo com uma âncora de confiança válida (chave criptográfica pública) para a
secure.contoso.comzona é capaz de validar uma resposta DNS para o registro definance.secure.contoso.comrecurso. Um servidor DNS recursivo também deve dar suporte aos padrões DNSSEC e algoritmos usados para assinar a zona.Pode validar: se o servidor DNS recursivo der suporte a todos os algoritmos criptográficos usados para assinar a
secure.contoso.comzona e tiver uma âncora de confiança válida que ele possa usar para descriptografar a assinatura DNSSEC associada ao registro de recurso assinado, ele poderá validar ofinance.secure.contoso.comregistro de recurso como genuíno.Não é possível validar: um servidor DNS sem reconhecimento DNSSEC não é capaz de realizar validação. Da mesma forma, um servidor DNS que atualmente não tem uma âncora de confiança válida para a zona
secure.contoso.com, ele não é capaz de validar uma resposta DNS parafinance.secure.contoso.com. As âncoras de confiança devem ser atualizadas quando uma zona é assinada novamente, por exemplo, durante a substituição de chaves. O DNSSEC no Windows Server 2012 e no Windows Server 2012 R2 dá suporte à atualização automática das âncoras de confiança durante a rotação de chaves conforme RFC 5011, "Atualizações automatizadas das âncoras de confiança da Segurança DNS (DNSSEC)".
Status com reconhecimento de DNSSEC: o status com reconhecimento DNSSEC de um cliente DNS depende do sistema operacional em execução. O serviço Cliente DNS do Windows nos sistemas operacionais Windows 7 ou Windows Server 2008 R2 e posteriores são resolvedores de stub não validadores e com reconhecimento de DNSSEC. Os sistemas operacionais Windows anteriores não têm reconhecimento DNSSEC. O cliente DNS informa a um servidor DNS se ele está ou não ciente de DNSSEC quando envia uma consulta DNS.
O cliente e o servidor têm reconhecimento de DNSSEC: se o cliente e o servidor estiverem cientes de DNSSEC, a resposta DNS do servidor para o cliente incluirá o sinalizador de dados autenticados DNSSEC (AD). Se a resposta DNS for validada com DNSSEC,
AD=1será enviada. Se a resposta DNS não tiver sido validada, seráAD=0enviada.O servidor DNS não tem reconhecimento de DNSSEC: se o servidor DNS não estiver ciente de DNSSEC, nenhuma validação será executada e o sinalizador do AD não será definido (
AD=0) independentemente de o cliente DNS estar ou não ciente de DNSSEC.O cliente DNS não está ciente de DNSSEC: se o cliente DNS não estiver ciente de DNSSEC, o servidor DNS não definirá o sinalizador do AD em sua resposta ao cliente, mesmo que ele entenda o DNSSEC. No entanto, se o servidor DNS for compatível com DNSSEC e tiver um ponto de confiança para a zona, o servidor tentará validar a resposta do servidor de autoridade. Se a validação falhar, ela retornará uma falha de servidor DNS para o cliente DNS. Se a validação for bem-sucedida, ela retornará os resultados da consulta ao cliente. Dessa forma, um servidor DNS recursivo com reconhecimento DNSSEC pode proteger clientes DNS que não reconhecem DNSSEC. Nesse cenário, se a zona não estiver assinada, nenhuma validação será tentada e a resposta será retornada normalmente para o cliente.
Requisito de validação: essa configuração determina o requisito de um cliente DNS com reconhecimento DNSSEC para dados DNSSEC (o sinalizador do AD) em uma resposta de um servidor DNS. Para que o cliente DNS exija validação, ele deve estar ciente de DNSSEC. Clientes DNS que não reconhecem DNSSEC não podem ser forçados a exigir a validação DNSSEC. Se o cliente DNS estiver consultando diretamente um servidor DNS autoritativo, a resposta será validada, mesmo que a zona não esteja assinada. Isso ocorre porque os servidores DNS autoritativos sempre retornam respostas autenticas.
A validação é necessária: se a validação for necessária, o cliente deverá receber
AD=1(validação bem-sucedida) ou rejeitar a resposta DNS. Se a validação não tiver sido bem-sucedida ou não for tentada (AD=0), a resolução DNS falhará. Isso é verdade mesmo que a zona não esteja assinada. Isso só se aplica a consultas em um servidor DNS recursivo e não autenticativo.A validação não é necessária: se a validação não for necessária, o cliente aceitará uma resposta de um servidor DNS recursivo sem DNSSEC. No entanto, se o servidor DNS recursivo estiver com reconhecimento DNSSEC e a validação falhar, ele retornará um failover de servidor para o cliente mesmo que o cliente não exija validação.
Próximas etapas
Aqui estão alguns artigos para saber mais sobre o DNSSEC para servidor DNS.