Extensões de segurança do sistema de nomes de domínio

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar

O Domain Name System Security Extensions ( DNSSEC ) é um conjunto de especificações de extensão da Internet Engineering Task Force (IETF) para proteger dados trocados no Domain Name System (DNS) em redes de Internet Protocol (IP). O protocolo fornece autenticação criptográfica de dados, negação de existência autenticada e integridade de dados, mas não disponibilidade ou confidencialidade.

Visão geral

O design original do Domain Name System não incluía nenhum recurso de segurança. Foi concebido apenas como um sistema distribuído escalável. As Extensões de Segurança do Sistema de Nomes de Domínio (DNSSEC) tentam adicionar segurança, mantendo a compatibilidade com versões anteriores . A solicitação de comentários 3833 documenta algumas das ameaças conhecidas ao DNS e suas soluções no DNSSEC.

O DNSSEC foi projetado para proteger os aplicativos que usam DNS contra a aceitação de dados DNS falsificados ou manipulados, como os criados pelo envenenamento de cache DNS . Todas as respostas das zonas protegidas por DNSSEC são assinadas digitalmente . Ao verificar a assinatura digital, um resolvedor de DNS pode verificar se as informações são idênticas (ou seja, não modificadas e completas) às informações publicadas pelo proprietário da zona e veiculadas em um servidor DNS autoritativo. Embora a proteção de endereços IP seja a preocupação imediata de muitos usuários, o DNSSEC pode proteger qualquer dado publicado no DNS, incluindo registros de texto (TXT) e registros de troca de correio (MX), e pode ser usado para inicializar outros sistemas de segurança que publicam referências a dados criptográficos. certificados armazenados no DNS, como Registros de Certificados ( registros CERT, RFC 4398), impressões digitais SSH ( SSHFP , RFC 4255), chaves públicas IPSec (IPSECKEY, RFC 4025), âncoras de confiança TLS (TLSA, RFC 6698) ou cliente criptografado Hello (registros SVCB/HTTPS para ECH, [1] [ 2] ).

O DNSSEC não fornece confidencialidade de dados; em particular, todas as respostas DNSSEC são autenticadas, mas não criptografadas. O DNSSEC não protege diretamente contra ataques DoS , embora indiretamente forneça algum benefício (porque a verificação de assinatura permite o uso de partes potencialmente não confiáveis). [ citação necessária ]

Outros padrões (não DNSSEC) são usados ​​para proteger dados em massa (como uma transferência de zona DNS ) enviados entre servidores DNS. Conforme documentado no IETF RFC 4367, alguns usuários e desenvolvedores fazem falsas suposições sobre nomes DNS, como supor que o nome comum de uma empresa mais ".com" é sempre seu nome de domínio. O DNSSEC não pode proteger contra falsas suposições; ele só pode autenticar se os dados são realmente ou não estão disponíveis no proprietário do domínio. [ citação necessária ]

As especificações DNSSEC (chamadas DNSSEC-bis ) descrevem o protocolo DNSSEC atual em grande detalhe. Consulte RFC 4033, RFC 4034 e RFC 4035. Com a publicação dessas novas RFCs (março de 2005), uma RFC anterior, a RFC 2535, tornou-se obsoleta.

Acredita-se amplamente [3] que proteger o DNS é extremamente importante para proteger a Internet como um todo, mas a implantação do DNSSEC especificamente foi dificultada (em 22 de janeiro de 2010 ) por várias dificuldades:

  • A necessidade de projetar um padrão compatível com versões anteriores que possa ser dimensionado para o tamanho da Internet
  • Prevenção de "enumeração de zona" quando desejado
  • Implantação de implementações de DNSSEC em uma ampla variedade de servidores DNS e resolvedores (clientes)
  • Desacordo entre os implementadores sobre quem deve possuir as chaves raiz do domínio de nível superior
  • Superando a complexidade percebida da implantação de DNSSEC e DNSSEC

Operação

O DNSSEC funciona assinando digitalmente registros para pesquisa de DNS usando criptografia de chave pública . O registro DNSKEY correto é autenticado por meio de uma cadeia de confiança , começando com um conjunto de chaves públicas verificadas para a zona raiz do DNS que é o terceiro confiável . Os proprietários de domínio geram suas próprias chaves e as carregam usando seu painel de controle DNS em seu registrador de nomes de domínio, que por sua vez envia as chaves via secDNS para o operador da zona (por exemplo, Verisign para .com) que as assina e as publica no DNS.

Registros de recursos

O DNS é implementado pelo uso de vários registros de recursos. Para implementar o DNSSEC, vários novos tipos de registro DNS foram criados ou adaptados para uso com DNSSEC:

RRSIG (assinatura de registro de recurso)
Contém a assinatura DNSSEC para um conjunto de registros. Os resolvedores de DNS verificam a assinatura com uma chave pública, armazenada em um registro DNSKEY.
DNSKEY
Contém a chave pública que um resolvedor de DNS usa para verificar assinaturas DNSSEC em registros RRSIG.
DS (assinante da delegação)
Contém o nome de uma zona delegada. Faz referência a um registro DNSKEY na zona subdelegada. O registro DS é colocado na zona pai junto com os registros NS de delegação.
NSEC (próximo registro seguro)
Contém um link para o próximo nome de registro na zona e lista os tipos de registro que existem para o nome do registro. Os resolvedores de DNS usam registros NSEC para verificar a inexistência de um nome e tipo de registro como parte da validação de DNSSEC.
NSEC3 (próximo registro seguro versão 3)
Contém links para o próximo nome de registro na zona (na ordem de classificação de nome com hash) e lista os tipos de registro que existem para o nome coberto pelo valor de hash no primeiro rótulo do próprio nome do registro NSEC3. Esses registros podem ser usados ​​por resolvedores para verificar a inexistência de um nome e tipo de registro como parte da validação do DNSSEC. Os registros NSEC3 são semelhantes aos registros NSEC, mas o NSEC3 usa nomes de registro com hash criptográfico para evitar a enumeração dos nomes de registro em uma zona.
NSEC3PARAM (próximo registro seguro versão 3 parâmetros)
Os servidores DNS autoritativos usam esse registro para calcular e determinar quais registros NSEC3 devem ser incluídos nas respostas às solicitações DNSSEC para nomes/tipos inexistentes.

Quando o DNSSEC é usado, cada resposta a uma pesquisa de DNS contém um registro DNS RRSIG, além do tipo de registro solicitado. O registro RRSIG é uma assinatura digital do conjunto de registros de recursos DNS de resposta. A assinatura digital é verificada localizando a chave pública correta encontrada em um registro DNSKEY. Os registros NSEC e NSEC3 são usados ​​para fornecer evidência criptográfica da inexistência de qualquer Resource Record (RR). O registro DS é usado na autenticação de DNSKEYs no procedimento de pesquisa usando a cadeia de confiança. Os registros NSEC e NSEC3 são usados ​​para resistência robusta contra falsificação.

Algoritmos

O DNSSEC foi projetado para ser extensível para que, à medida que os ataques sejam descobertos contra os algoritmos existentes, novos possam ser introduzidos de forma compatível com versões anteriores . A tabela a seguir define, a partir de abril de 2013, os algoritmos de segurança mais usados: [4]

Campo de algoritmo Algoritmo Fonte Assinatura DNSSEC Validação DNSSEC [5]
1 RSA / MD5 Não deve implementar Não deve implementar
3 DSA / SHA-1 Não deve implementar Não deve implementar
5 RSA/SHA-1 RFC 3110 Não recomendado Requeridos
6 DSA-NSEC3-SHA1 Não deve implementar Não deve implementar
7 RSASHA1-NSEC3-SHA1 RFC 5155 Não recomendado Requeridos
8 RSA/ SHA-256 RFC 5702 Requeridos Requeridos
10 RSA/ SHA-512 Não recomendado Requeridos
12 GOST R 34.10-2001 RFC 5933 Não deve implementar Opcional
13 ECDSA / SHA-256 RFC 6605 Requeridos Requeridos
14 ECDSA/ SHA-384 Opcional Recomendado
15 Ed25519 RFC 8080 Recomendado Recomendado
16 Ed448 Opcional Recomendado
Campo de resumo Digerir Fonte Status de implementação [6]
1 SHA-1 RFC 3658 Requeridos
2 SHA-256 RFC 4509 Requeridos
3 GOST R 34.10-2001 RFC 5933 Opcional
4 SHA-384 RFC 6605 Opcional

O procedimento de pesquisa

A partir dos resultados de uma pesquisa de DNS, um resolvedor de DNS com reconhecimento de segurança pode determinar se o servidor de nomes autoritativo do domínio que está sendo consultado oferece suporte a DNSSEC, se a resposta recebida é segura e se há algum tipo de erro. O procedimento de pesquisa é diferente para servidores de nomes recursivos , como os de muitos ISPs , e para resolvedores de stub , como os incluídos por padrão em sistemas operacionais convencionais. O Microsoft Windows usa um resolvedor de stub, e o Windows Server 2008 R2 e o Windows 7, em particular, usam um resolvedor de stub que não valida, mas reconhece DNSSEC. [7] [8]

Servidores de nomes recursivos

Usando o modelo de cadeia de confiança , um registro DS (Delegation Signer) em um domínio pai ( zona DNS ) pode ser usado para verificar um registro DNSKEY em um subdomínio , que pode conter outros registros DS para verificar outros subdomínios. Digamos que um resolvedor recursivo, como um servidor de nomes ISP, queira obter os endereços IP ( registros A e/ou registros AAAA ) do domínio " www.exemplo.com ".

  1. O processo é iniciado quando um resolvedor com reconhecimento de segurança define o bit de sinalizador "DO" ("DNSSEC OK" [9] ) em uma consulta DNS. Como o bit DO está nos bits de sinalizador estendidos definidos pelos Mecanismos de extensão para DNS (EDNS) , todas as transações DNSSEC devem oferecer suporte a EDNS. O suporte EDNS também é necessário para permitir tamanhos de pacotes muito maiores que as transações DNSSEC exigem.
  2. Quando o resolvedor recebe uma resposta por meio do processo normal de pesquisa de DNS, ele verifica se a resposta está correta. Idealmente, o resolvedor com reconhecimento de segurança começaria verificando os registros DS e DNSKEY na raiz do DNS . Em seguida, ele usaria os registros DS para o domínio de nível superior "com" encontrado na raiz para verificar os registros DNSKEY na zona "com". A partir daí, ele veria se há um registro DS para o subdomínio "example.com" na zona "com" e, se houvesse, usaria o registro DS para verificar um registro DNSKEY encontrado no arquivo "example. com" zona. Por fim, verificaria o registro RRSIG encontrado na resposta para os registros A para "www.example.com".

Existem várias exceções para o exemplo acima.

Primeiro, se "example.com" não suportar DNSSEC, não haverá registro RRSIG na resposta e não haverá registro DS para "example.com" na zona "com". Se houver um registro DS para "example.com", mas nenhum registro RRSIG na resposta, algo está errado e talvez um ataque man in the middle esteja acontecendo, removendo as informações DNSSEC e modificando os registros A. Ou pode ser um servidor de nomes alheio à segurança quebrado ao longo do caminho que removeu o bit de sinalizador DO da consulta ou o registro RRSIG da resposta. Ou pode ser um erro de configuração.

Em seguida, pode ser que não haja um nome de domínio chamado "www.example.com", nesse caso, em vez de retornar um registro RRSIG na resposta, haverá um registro NSEC ou um registro NSEC3. Esses são registros "próximos seguros" que permitem ao resolvedor provar que um nome de domínio não existe. Os registros NSEC/NSEC3 possuem registros RRSIG, que podem ser verificados conforme descrito acima.

Finalmente, pode ser que a zona "example.com" implemente DNSSEC, mas a zona "com" ou a zona raiz não, criando uma "ilha de segurança" que precisa ser validada de alguma outra forma. A partir de 15 de julho de 2010 , a implantação do DNSSEC na raiz foi concluída. [10] O domínio .com foi assinado com chaves de segurança válidas e a delegação segura foi adicionada à zona raiz em 1º de abril de 2011. [11]

Resolvedores de stubs

Os resolvedores de stub são "resolvedores de DNS mínimos que usam o modo de consulta recursiva para descarregar a maior parte do trabalho de resolução de DNS para um servidor de nomes recursivo". [12] Um stub resolver simplesmente encaminhará uma solicitação para um servidor de nomes recursivo e usará o bit de dados autenticados (AD) na resposta como uma "dica para descobrir se o servidor de nomes recursivo foi capaz de validar assinaturas para todos os dados nas seções Resposta e Autoridade da resposta." [13] O Microsoft Windows usa um resolvedor de stub, e o Windows Server 2008 R2 e o Windows 7 em particular usam um resolvedor de stub não validador, mas com reconhecimento de bits de AD. [7] [8]

Um resolvedor de stub de validação também pode potencialmente executar sua própria validação de assinatura definindo o bit Checking Disabled (CD) em suas mensagens de consulta. [13] Um resolvedor de stub de validação usa o bit CD para realizar sua própria autenticação recursiva. O uso desse resolvedor de stub de validação oferece ao cliente segurança DNS de ponta a ponta para domínios que implementam DNSSEC, mesmo que o provedor de serviços de Internet ou a conexão com eles não seja confiável.

Os resolvedores de stub não validados devem contar com serviços de validação DNSSEC externos, como aqueles controlados pelo provedor de serviços de Internet do usuário ou um servidor de nomes recursivo público , e os canais de comunicação entre eles e esses servidores de nomes, usando métodos como DNS sobre TLS . [13] [14]

Âncoras de confiança e cadeias de autenticação

Para poder provar que uma resposta DNS está correta, é necessário conhecer pelo menos uma chave ou registro DS correto de outras fontes que não o DNS. Esses pontos de partida são conhecidos como âncoras de confiança e normalmente são obtidos com o sistema operacional ou por meio de alguma outra fonte confiável. Quando o DNSSEC foi originalmente projetado, pensava-se que a única âncora de confiança necessária era para a raiz do DNS . As âncoras de raiz foram publicadas pela primeira vez em 15 de julho de 2010. [15]

Uma cadeia de autenticação é uma série de registros DS e DNSKEY vinculados, começando com uma âncora de confiança para o servidor de nomes autoritativo do domínio em questão. Sem uma cadeia de autenticação completa, uma resposta a uma pesquisa de DNS não pode ser autenticada com segurança.

Assinaturas e assinatura de zona

Para limitar os ataques de repetição, existem não apenas os valores normais de DNS TTL para fins de armazenamento em cache, mas também carimbos de data e hora adicionais nos registros RRSIG para limitar a validade de uma assinatura. Ao contrário dos valores TTL que são relativos a quando os registros foram enviados, os timestamps são absolutos. Isso significa que todos os resolvedores de DNS com reconhecimento de segurança devem ter relógios bastante sincronizados, digamos, dentro de alguns minutos.

Esses carimbos de data/hora implicam que uma zona deve ser regularmente assinada novamente e redistribuída para servidores secundários, ou as assinaturas serão rejeitadas pelos resolvedores de validação.

Gerenciamento de chaves

O DNSSEC envolve muitas chaves diferentes, armazenadas em registros DNSKEY e de outras fontes para formar âncoras de confiança .

Para permitir a substituição de chaves, é necessário um esquema de substituição de chave . Normalmente, isso envolve primeiro a implantação de novas chaves em novos registros DNSKEY, além das chaves antigas existentes. Então, quando for seguro assumir que os valores de tempo de vida fizeram com que o cache de chaves antigas tenha passado, essas novas chaves podem ser usadas. Finalmente, quando for seguro assumir que o cache de registros usando as chaves antigas expirou, os registros DNSKEY antigos podem ser excluídos. Esse processo é mais complicado para coisas como chaves para âncoras de confiança, como na raiz, que podem exigir uma atualização do sistema operacional.

As chaves nos registros DNSKEY podem ser usadas para duas coisas diferentes e, normalmente, registros DNSKEY diferentes são usados ​​para cada um. Primeiro, existem chaves de assinatura de chave (KSK) que são usadas para assinar outros registros DNSKEY. Em segundo lugar, existem chaves de assinatura de zona (ZSK) que são usadas para assinar outros registros. Como os ZSKs estão sob controle total e são usados ​​por uma zona DNS específica , eles podem ser alternados com mais facilidade e frequência. Como resultado, as ZSKs podem ser muito mais curtas que as KSKs e ainda oferecer o mesmo nível de proteção, reduzindo o tamanho dos registros RRSIG/DNSKEY.

Quando uma nova KSK é criada, o registro DS deve ser transferido para a zona pai e publicado lá. Os registros DS usam um resumo da mensagem do KSK em vez da chave completa para manter o tamanho dos registros pequeno. Isso é útil para zonas como o domínio .com , que são muito grandes. O procedimento para atualizar as chaves DS na zona pai também é mais simples do que as versões anteriores do DNSSEC que exigiam que os registros DNSKEY estivessem na zona pai.

Grupo de Trabalho DANE

O DNS-based Authentication of Named Entities (DANE) é um grupo de trabalho da IETF [16] com o objetivo de desenvolver protocolos e técnicas que permitem que aplicativos da Internet estabeleçam comunicações criptograficamente seguras com TLS , DTLS , SMTP e S/MIME com base em DNSSEC.

Os novos protocolos permitirão garantias e restrições adicionais para o modelo tradicional baseado em infraestrutura de chave pública . Eles também permitirão que os detentores de domínio reivindiquem certificados por si mesmos, sem referência a autoridades de certificação de terceiros .

O suporte para certificados grampeados DNSSEC foi ativado no Google Chrome 14, [17] mas foi removido posteriormente. [18] Para o Mozilla Firefox , o suporte foi fornecido por um add-on [19] enquanto o suporte nativo está aguardando alguém para começar a trabalhar nele. [20]

História

O DNS é um serviço crítico e fundamental da Internet, mas em 1990 Steve Bellovin descobriu sérias falhas de segurança nele. A pesquisa para protegê-lo começou e progrediu dramaticamente quando seu artigo foi tornado público em 1995. [21] A RFC 2065 inicial foi publicada pela IETF em 1997, e as tentativas iniciais de implementar essa especificação levaram a uma revisão (e acreditada totalmente viável) especificação em 1999 como IETF RFC 2535. Planos foram feitos para implantar DNSSEC com base no RFC 2535.

Infelizmente, a especificação IETF RFC 2535 teve problemas muito significativos ao expandir para a Internet completa; em 2001 ficou claro que esta especificação era inutilizável para grandes redes. Em operação normal, os servidores DNS geralmente ficam fora de sincronia com seus pais. Isso geralmente não é um problema, mas quando o DNSSEC está habilitado, esses dados fora de sincronia podem ter o efeito de uma grave negação de serviço auto-criada. O DNSSEC original exigia um protocolo complexo de seis mensagens e muitas transferências de dados para realizar alterações de chave para um filho (as zonas filho do DNS precisavam enviar todos os seus dados para o pai, fazer com que o pai assinasse cada registro e, em seguida, enviasse esses assinaturas de volta para a criança para que a criança armazene em um registro SIG). Além disso, as mudanças de chave pública podem ter efeitos absurdos; por exemplo, se a zona ".com" mudou sua chave pública, teria que enviar 22 milhões de registros (porque precisaria atualizar todas as assinaturas em todos os seus filhos). Assim, o DNSSEC, conforme definido na RFC 2535, não pôde ser dimensionado para a Internet.

O IETF modificou fundamentalmente o DNSSEC, que é chamado de DNSSEC-bisquando necessário, diferenciá-lo da abordagem DNSSEC original da RFC 2535. Essa nova versão usa "registros de recursos de assinante de delegação (DS)" para fornecer um nível adicional de indireção em pontos de delegação entre uma zona pai e filha. Na nova abordagem, quando a chave pública mestra de um filho muda, em vez de ter seis mensagens para cada registro no filho, há uma mensagem simples: o filho envia a nova chave pública para seu pai (assinado, é claro). Os pais simplesmente armazenam uma chave pública mestra para cada filho; isso é muito mais prático. Isso significa que alguns dados são enviados para o pai, em vez de grandes quantidades de dados sendo trocadas entre o pai e os filhos. Isso significa que os clientes precisam fazer um pouco mais de trabalho ao verificar as chaves. Mais especificamente, verificar uma zona DNS' s KEY RRset requer duas operações de verificação de assinatura em vez da exigida pela RFC 2535 (não há impacto no número de assinaturas verificadas para outros tipos de RRsets). A maioria vê isso como um pequeno preço a pagar, pois torna a implantação do DNSSEC mais prática.

Autenticação de respostas NXDOMAIN e NSEC

A comprovação criptográfica da ausência de um domínio requer a assinatura da resposta a cada consulta de um domínio inexistente. Isso não é um problema para servidores de assinatura online, que mantêm suas chaves disponíveis online. No entanto, o DNSSEC foi projetado para usar computadores offline para assinar registros para que as chaves de assinatura de zona pudessem ser mantidas em armazenamento a frio. Isso representa um problema ao tentar autenticar respostas a consultas para domínios inexistentes, pois é impossível pré-gerar uma resposta para todas as consultas de nome de host possíveis.

A solução inicial foi criar registros NSEC para cada par de domínios em uma zona. Assim, se um cliente consultasse um registro no inexistente k.example.com, o servidor responderia com um registro NSEC informando que nada existe entre a.example.come z.example.com. No entanto, isso vaza mais informações sobre a zona do que os erros tradicionais de NXDOMAIN não autenticados porque expõe a existência de domínios reais.

Impedindo o acesso ao domínio

Os registros NSEC3 (RFC 5155) foram criados como uma alternativa que faz o hash do nome ao invés de listá-los diretamente. Com o tempo, os avanços no hash usando GPUs e hardware dedicado significavam que as respostas NSEC3 poderiam ser forçadas de forma barata usando ataques de dicionário offline. O NSEC5 foi proposto para permitir que servidores autorizados assinem respostas NSEC sem ter que manter uma chave privada que pode ser usada para modificar a zona. Assim, roubar um NSEC5KEY resultaria apenas na capacidade de enumerar mais facilmente uma zona. [22]

Devido à evolução confusa do protocolo e ao desejo de preservar a compatibilidade com versões anteriores, os servidores de assinatura DNSSEC online retornam uma "mentira branca" em vez de autenticar uma negação de existência diretamente. A técnica descrita na RFC 4470 retorna um registro NSEC no qual os pares de domínios cercam lexicalmente o domínio solicitado. Por exemplo, a solicitação de k.example.comresultaria em um registro NSEC provando que nada existe entre os domínios (fictícios) j.example.come l.example.com. Isso também é possível com registros NSEC3. [23]

CloudFlare foi pioneira em um par de abordagens alternativas, que conseguem alcançar o mesmo resultado em um terço do tamanho da resposta. [24] A primeira é uma variação da abordagem de "mentiras brancas", chamada "mentiras negras", que explora o comportamento comum do cliente DNS para declarar a inexistência de forma mais compacta. [25] A segunda abordagem opta por provar que "o registro existe, mas o tipo de registro solicitado não", que eles chamam de "espingarda DNS". [26] [24]

Implantação

A Internet é uma infraestrutura crítica, mas sua operação depende do DNS fundamentalmente inseguro. Assim, há um forte incentivo para proteger o DNS, e a implantação do DNSSEC é geralmente considerada uma parte crítica desse esforço. Por exemplo, a Estratégia Nacional dos EUA para Proteger o Ciberespaço identificou especificamente a necessidade de proteger o DNS. [27] A implantação em larga escala do DNSSEC também pode resolver muitos outros problemas de segurança, como a distribuição segura de chaves para endereços de e-mail.

A implantação de DNSSEC em redes de grande escala também é um desafio. Ozment e Schechter observam que o DNSSEC (e outras tecnologias) tem um "problema de inicialização": os usuários normalmente só implantam uma tecnologia se receberem um benefício imediato, mas se um nível mínimo de implantação for necessário antes de qualqueros usuários recebem um benefício maior do que seus custos (como é o caso do DNSSEC), é difícil de implantar. O DNSSEC pode ser implantado em qualquer nível de uma hierarquia DNS, mas deve estar amplamente disponível em uma zona antes que muitos outros queiram adotá-lo. Os servidores DNS devem ser atualizados com software que suporte DNSSEC e os dados DNSSEC devem ser criados e adicionados aos dados da zona DNS. Um cliente que usa TCP/IP deve ter seu resolvedor de DNS (cliente) atualizado antes de poder usar os recursos do DNSSEC. Além disso, qualquer resolvedor deve ter, ou ter uma maneira de adquirir, pelo menos uma chave pública em que possa confiar antes de começar a usar o DNSSEC.

A implementação de DNSSEC pode adicionar carga significativa a alguns servidores DNS. As respostas comuns assinadas por DNSSEC são muito maiores do que o tamanho UDP padrão de 512 bytes. Em teoria, isso pode ser tratado por meio de vários fragmentos de IP, mas muitas "caixas intermediárias" no campo não lidam com isso corretamente. Isso leva ao uso de TCP em vez disso. No entanto, muitas implementações TCP atuais armazenam uma grande quantidade de dados para cada conexão TCP; servidores muito carregados podem ficar sem recursos simplesmente tentando responder a um número maior de solicitações DNSSEC (possivelmente falsas). Algumas extensões de protocolo, como TCP Cookie Transactions , foram desenvolvidas para reduzir esse carregamento. [28] Para enfrentar esses desafios, um esforço significativo está em andamento para implantar o DNSSEC, porque a Internet é tão vital para muitas organizações.

Implantações iniciais

Os primeiros a adotar incluem Brasil ( .br ), Bulgária ( .bg ), República Tcheca ( .cz ), Namíbia ( .na ) [29] Porto Rico ( .pr ) e Suécia ( .se ), que usam DNSSEC como código de país domínios de nível superior ; [30] RIPE NCC , que assinou todos os registros de pesquisa inversa (in-addr.arpa) que lhe são delegados pela Internet Assigned Numbers Authority (IANA). [31] ARIN também está assinando suas zonas reversas.[32] Em fevereiro de 2007, a TDC tornou-se o primeiro ISP sueco a começar a oferecer esse recurso a seus clientes. [33]

A IANA testou publicamente uma raiz assinada de amostra desde junho de 2007. Durante esse período anterior à assinatura de produção da raiz, também havia várias âncoras de confiança alternativas. O IKS Jena introduziu um em 19 de janeiro de 2006, [34] o Internet Systems Consortium introduziu outro em 27 de março do mesmo ano, [35] enquanto a própria ICANN anunciou um terceiro em 17 de fevereiro de 2009. [36]

Em 2 de junho de 2009, Afilias , o provedor de serviços de registro para a zona .org do Public Interest Registry , assinou o TLD .org. [37] Afilias e PIR também detalharam em 26 de setembro de 2008, que a primeira fase, envolvendo grandes registradores com os quais tem uma forte relação de trabalho ("amigos e familiares") seria a primeira a poder assinar seus domínios, começando " início de 2009". [38] Em 23 de junho de 2010, 13 registradores foram listados como oferecendo registros DNSSEC para domínios .ORG. [39]

A VeriSign executou um projeto piloto para permitir que domínios .com e .net se registrem para fins de experimentação do NSEC3. Em 24 de fevereiro de 2009, eles anunciaram que implantariam o DNSSEC em todos os seus domínios de primeiro nível (.com, .net, etc.) em 24 meses, [40] e em 16 de novembro do mesmo ano, eles disseram que o . com e .net seriam assinados até o primeiro trimestre de 2011, após atrasos causados ​​por aspectos técnicos da implementação. [41] Essa meta foi alcançada dentro do prazo [42] e o vice-presidente de DNSSEC da Verisign, Matt Larson, ganhou o Prêmio de Liderança em Tecnologia da InfoWorld em 2011 por seu papel no avanço do DNSSEC. [43] [44]

Implantação na raiz DNS

O DNSSEC foi implantado pela primeira vez no nível raiz em 15 de julho de 2010. [45] Espera-se que isso simplifique bastante a implantação de resolvedores DNSSEC, já que a âncora de confiança raiz pode ser usada para validar qualquer zona DNSSEC que tenha uma cadeia completa de confiança de a raiz. Como a cadeia de confiança deve ser rastreada até uma raiz confiável sem interrupção para validar, as âncoras de confiança ainda devem ser configuradas para zonas seguras se alguma das zonas acima delas não for segura. Por exemplo, se a zona "signed.example.org" foi protegida, mas a zona "example.org" não, então, mesmo que a zona ".org" e a raiz estejam assinadas, uma âncora de confiança deve ser implantada em para validar a zona.

As questões políticas em torno da assinatura da raiz têm sido uma preocupação contínua, principalmente sobre algumas questões centrais:

  • Outros países estão preocupados com o controle dos EUA sobre a Internet e podem rejeitar qualquer codificação centralizada por esse motivo.
  • Alguns governos podem tentar banir a distribuição de chaves de criptografia apoiadas por DNSSEC.

Planejamento

Em setembro de 2008, ICANN e VeriSign publicaram propostas de implementação [46] e, em outubro, a Administração Nacional de Telecomunicações e Informações (NTIA) pediu comentários ao público. [47] Não está claro se os comentários recebidos afetaram a concepção do plano final de implantação.

Em 3 de junho de 2009, o Instituto Nacional de Padrões e Tecnologia (NIST) anunciou planos para assinar a raiz até o final de 2009, em conjunto com ICANN, VeriSign e NTIA. [48]

Em 6 de outubro de 2009, na 59ª reunião da RIPE Conference, ICANN e VeriSign anunciaram o cronograma de implantação planejado para implantar DNSSEC na zona raiz. [49] Na reunião foi anunciado que ele seria implantado de forma incremental em um servidor de nomes raiz por mês, começando em 1º de dezembro de 2009, com o servidor de nomes raiz final atendendo a uma zona assinada DNSSEC em 1º de julho de 2010, e o servidor raiz zona será assinada com uma DNSKEY RSA/SHA256. [49] Durante o período de implantação incremental, a zona raiz servirá uma zona raiz deliberadamente invalidada (DURZ) que usa chaves fictícias, com o registro DNSKEY final não sendo distribuído até 1º de julho de 2010. [50]Isso significa que as chaves que foram usadas para assinar o uso da zona são deliberadamente não verificáveis; o motivo dessa implantação foi monitorar as alterações nos padrões de tráfego causadas pelas respostas maiores às consultas que solicitam registros de recursos DNSSEC.

O domínio de nível superior .org foi assinado com o DNSSEC em junho de 2010, seguido por .com , .net e .edu posteriormente em 2010 e 2011. [51] [52] Os domínios de nível superior com código de país puderam depositar chaves começando em maio de 2010. [53] Em novembro de 2011, mais de 25% dos domínios de primeiro nível são assinados com DNSSEC. [54]

Implementação

Em 25 de janeiro de 2010, o servidor raiz L (ell) começou a servir uma Zona Raiz Deliberadamente Invalidada (DURZ). A zona usa assinaturas de um hash SHA-2 (SHA-256) criado usando o algoritmo RSA , conforme definido na RFC 5702. [55] [56] [57] Em maio de 2010, todos os treze servidores raiz começaram a servir o DURZ . [50] Em 15 de julho de 2010, foi assinada a primeira zona raiz DNSSEC de produção total de raiz, com a série SOA 2010071501. As âncoras de confiança raiz estão disponíveis na IANA . [45]

Implantação no nível de TLD

Abaixo da raiz, há um grande conjunto de domínios de nível superior que devem ser assinados para obter a implantação completa do DNSSEC. A Lista de domínios de nível superior da Internet fornece detalhes sobre quais domínios de nível superior existentes foram assinados e vinculados à raiz.

Validação DNSSEC Lookaside - histórico

Em março de 2006, o Internet Systems Consortium introduziu o registro DNSSEC Lookaside Validation. [58] O DLV tinha como objetivo tornar o DNSSEC mais fácil de implantar na ausência de uma âncora de confiança raiz. Na época, imaginava-se que um validador teria que manter um grande número de âncoras de confiança correspondentes às subárvores assinadas do DNS. [59] O objetivo do DLV era permitir que os validadores descarregassem o esforço de gerenciar um repositório de âncora de confiança para um terceiro confiável. O registro DLV manteve uma lista central de âncoras de confiança, em vez de cada validador repetir o trabalho de manter sua própria lista.

Para usar DLV, era necessário um validador que o suportasse, como BIND ou Unbound , configurado com uma âncora de confiança para uma zona DLV. Essa zona continha registros DLV; [60] estes tinham exatamente o mesmo formato que os registros DS, mas em vez de se referirem a uma subzona delegada, eles se referiam a uma zona em outro lugar na árvore DNS. Quando o validador não conseguiu encontrar uma cadeia de confiança da raiz até o RRset que está tentando verificar, ele procurou um registro DLV que pudesse fornecer uma cadeia de confiança alternativa. [61]

Lacunas na cadeia de confiança, como domínios de nível superior não assinados ou registradores que não suportavam delegações DNSSEC, significavam que os administradores de domínios de nível inferior poderiam usar DLV para permitir que seus dados DNS fossem validados por resolvedores configurados para usar DLV . Isso pode ter dificultado a implantação do DNSSEC, tirando a pressão dos registradores e dos registros de TLDs para oferecer suporte adequado ao DNSSEC. O DLV também adicionou complexidade ao adicionar mais atores e caminhos de código para validação de DNSSEC.

A ISC desativou seu registro DLV em 2017. [62] O suporte a DLV foi preterido no BIND 9.12 e completamente removido do BIND 9.16. [63] A versão não vinculada 1.5.4 (julho de 2015) marcou o DLV como desativado na configuração de exemplo e na página de manual. [64] Knot Resolver e PowerDNS Recursor nunca implementaram DLV.

Em março de 2020, o IETF publicou o RFC 8749, retirando o DLV como padrão e movendo o RFC 4432 e o RFC 5074 para o status "Histórico". [65]

Iniciativa de implantação de DNSSEC pelo governo federal dos EUA

A Diretoria de Ciência e Tecnologia do Departamento de Segurança Interna dos EUA (DHS) patrocina a "Iniciativa de Implantação de DNSSEC". Essa iniciativa incentiva "todos os setores a adotarem voluntariamente medidas de segurança que melhorarão a segurança da infraestrutura de nomes da Internet, como parte de um esforço global e cooperativo que envolve muitas nações e organizações dos setores público e privado". O DHS também financia esforços para amadurecer o DNSSEC e implantá-lo no governo federal dos EUA.

Foi relatado [66] que em 30 de março de 2007, o Departamento de Segurança Interna dos EUA propôs "ter a chave para assinar a zona raiz do DNS solidamente nas mãos do governo dos EUA". No entanto, nenhum funcionário do governo dos EUA estava presente na sala de reuniões e o comentário que desencadeou o artigo foi feito por outra parte. DHS comentou mais tarde [67] [68]sobre por que eles acreditam que outros chegaram à falsa conclusão de que o governo dos EUA havia feito tal proposta: "O Departamento de Segurança Interna dos EUA está financiando o desenvolvimento de um plano técnico para implementar o DNSSec, e em outubro passado distribuiu um rascunho inicial para um longa lista de especialistas internacionais para comentários. O rascunho apresenta uma série de opções para quem poderia ser o detentor, ou "operador", da Chave da Zona Raiz, essencialmente resumindo-se a uma agência governamental ou um contratado. "Em nenhum lugar do documento fazemos alguma proposta sobre a identidade do Root Key Operator", disse Maughan, gerente de pesquisa e desenvolvimento de segurança cibernética da Homeland Security".

Implantação de DNSSEC no governo federal dos EUA

O Instituto Nacional de Padrões e Tecnologia (NIST) publicou NIST Special Publication 800-81 Secure Domain Name System (DNS) Deployment Guide em 16 de maio de 2006, com orientações sobre como implantar o DNSSEC. O NIST pretendia lançar novos requisitos da Lei Federal de Gerenciamento de Segurança da Informação DNSSEC (FISMA) no NIST SP800-53-R1, fazendo referência a este guia de implantação. As agências dos EUA teriam então um ano após a publicação final do NIST SP800-53-R1 para atender a esses novos requisitos da FISMA. [69] No entanto, na época, o NSEC3 não havia sido concluído. O NIST sugeriu o uso de domínios divididos, uma técnica que se sabe ser possível, mas é difícil de implantar corretamente, e tem os pontos fracos de segurança mencionados acima.

Em 22 de agosto de 2008, o Office of Management and Budget (OMB) divulgou um memorando exigindo que as agências federais dos EUA implantassem DNSSEC em sites .gov; a raiz .gov deve ser assinada até janeiro de 2009, e todos os subdomínios sob .gov devem ser assinados até dezembro de 2009. [70] Embora o memorando se concentre em sites .gov, a Agência de Sistemas de Informação de Defesa dos EUA diz que pretende atender aos requisitos OMB DNSSEC também no domínio .mil (militar dos EUA). Carolyn Duffy Marsan, da NetworkWorld, afirmou que o DNSSEC "não foi amplamente implantado porque sofre de um dilema clássico da galinha e do ovo... com o mandato do OMB, parece que o ovo está quebrando". [71]

Implantação em resolvedores

Vários ISPs começaram a implantar resolvedores recursivos DNS que validam DNSSEC. A Comcast se tornou o primeiro grande ISP a fazê-lo nos Estados Unidos, anunciando suas intenções em 18 de outubro de 2010 [72] [73] e concluindo a implantação em 11 de janeiro de 2012. [74]

De acordo com um estudo da APNIC , a proporção de clientes que usam exclusivamente resolvedores de DNS que realizam validação de DNSSEC subiu para 8,3% em maio de 2013. [75] Cerca de metade desses clientes estava usando o resolvedor de DNS público do Google .

Em setembro de 2015, a Verisign anunciou seu serviço público gratuito de resolução de DNS, [76] e, embora não mencionado em seus comunicados à imprensa, também realiza a validação de DNSSEC.

No início de 2016, o monitoramento da APNIC mostrou que a proporção de clientes que usam exclusivamente resolvedores de DNS que realizam validação de DNSSEC havia aumentado para cerca de 15%. [77]

Suporte DNSSEC

O servidor DNS recursivo público do Google ativou a validação DNSSEC em 6 de maio de 2013. [78]

BIND , o software de gerenciamento de DNS mais popular, habilita o suporte a DNSSEC por padrão desde a versão 9.5.

O DNS recursivo público Quad9 realizou validação DNSSEC em seu endereço principal 9.9.9.9 desde que foi estabelecido em 11 de maio de 2016. O Quad9 também fornece um serviço alternativo que não realiza validação DNSSEC, principalmente para depuração. [79]

Publicações IETF

  •  Extensões de segurança do sistema de nomes de domínio RFC 2535
  • RFC  3225 Indicando Suporte ao Resolvedor de DNSSEC
  • RFC  3226 DNSSEC e IPv6 A6 Aware Server/Resolver requisitos de tamanho de mensagem
  • RFC  3833 Uma Análise de Ameaças do Sistema de Nomes de Domínio
  • RFC  4033 DNS Security Introduction and Requirements ( DNSSEC-bis )
  • RFC  4034 Resource Records for the DNS Security Extensions ( DNSSEC-bis )
  •  Modificações do protocolo RFC 4035 para as extensões de segurança do DNS ( DNSSEC-bis )
  • RFC  4398 Armazenando Certificados no Sistema de Nomes de Domínio (DNS)
  • RFC  4431 O DNSSEC Lookaside Validation (DLV) DNS Resource Record
  • RFC  4470 cobrindo minimamente registros NSEC e assinatura on-line DNSSEC
  • RFC  4509 Uso de SHA-256 em DNSSEC Delegation Signer (DS) Resource Records (RRs)
  • RFC  4641 DNSSEC Práticas Operacionais
  •  Experiências de segurança de DNS (DNSSEC) RFC 4955
  • RFC  5011 Atualizações Automatizadas de Âncoras de Confiança de Segurança DNS (DNSSEC)
  • RFC  5155 DNSSEC Hashed Negação autenticada de existência
  • RFC  5702 Uso de algoritmos SHA-2 com RSA em registros de recursos DNSKEY e RRSIG para DNSSEC
  • RFC  6605 Algoritmo de Assinatura Digital de Curva Elíptica (DSA) para DNSSEC
  • RFC  6725 DNS Security (DNSSEC) DNSKEY Algorithm Atualizações do Registro IANA
  • RFC  6781 DNSSEC Práticas Operacionais, Versão 2
  • RFC  6840 Esclarecimentos e Notas de Implementação para Segurança do DNS (DNSSEC)
  • RFC  7129 Negação autenticada de existência no DNS
  • RFC  7344 Automatizando a Manutenção de Confiança de Delegação DNSSEC
  •  Considerações de tempo de rollover de chave DNSSEC RFC 7583
  • RFC  8080 Edwards-Curve Digital Security Algorithm (EdDSA) para DNSSEC
  • Requisitos de implementação do algoritmo RFC  8624 e orientação de uso para DNSSEC
  • RFC  8749 Movendo a validação DNSSEC Lookaside (DLV) para o status histórico

Ferramentas

A implantação de DNSSEC requer software no lado do servidor e do cliente. Algumas das ferramentas que suportam DNSSEC incluem:

Veja também

Referências

  1. ^ "Draft-ietf-dnsop-SVCB-HTTPS-10 - Ligação de serviço e especificação de parâmetros via DNS (DNS SVCB e HTTPS RRS)" .
  2. ^ "Draft-ietf-TLS-esni-14 - Cliente criptografado TLS Olá" .
  3. ^ Entrevista com Dan Kaminsky sobre DNSSEC (25 de junho de 2009) Entrevista com Kaminsky: DNSSEC aborda confiança e segurança entre organizações
  4. ^ "Números do algoritmo da segurança do sistema de nomes de domínio (DNSSEC)" . IANA . 2010-07-12 . Recuperado 2010-07-17 .
  5. ^ Wouters, Paul; Surý, Ondřej (junho de 2019). "RFC-8624" . IETF .
  6. ^ "RFC-4035" . IETF .
  7. ^ a b "Entendendo DNSSEC no Windows" . Microsoft . 7 de outubro de 2009. O cliente DNS do Windows é um stub resolvedor...
  8. ^ a b "Extensões de segurança DNS (DNSSEC)" . Microsoft . 21 de outubro de 2009. O cliente DNS no Windows Server 2008 R2 e Windows® 7 é um resolvedor de stub com reconhecimento de segurança não validado.
  9. ^ Conrad, D. "Indicando o apoio do Resolvedor de DNSSEC" . Força Tarefa de Engenharia de Internet . Recuperado em 27 de abril de 2017 .
  10. ^ "Raiz DNSSEC" .
  11. ^ "Computação - fonte líder do Reino Unido para a análise de tecnologia de negócios" .
  12. ^ Rosa, Scott; Larson, Matt; Massey, Dan; Austein, Rob; Arends, Roy (março de 2005). "RFC 4033: Introdução e requisitos de segurança do DNS" . A Sociedade da Internet : 11. Os resolvedores de stub, por definição, são resolvedores de DNS mínimos que usam o modo de consulta recursiva para descarregar a maior parte do trabalho de resolução de DNS para um servidor de nomes recursivo. {{cite journal}}:Cite journal requires |journal= (help) Uma definição anterior foi dada em um RFC anterior: Robert Braden (outubro de 1989). "RFC 1123 - Requisitos para hosts da Internet - Aplicativo e suporte" . IETF ( Internet Engineering Task Force ): 74. Um "stub resolver" depende dos serviços de um servidor de nomes recursivo [...] {{cite journal}}: Cite journal requires |journal= (help)
  13. ^ a b c Rosa, Scott; Larson, Matt; Massey, Dan; Austein, Rob; Arends, Roy (março de 2005). "RFC 4033: Introdução e requisitos de segurança do DNS" . A Sociedade da Internet : 12. {{cite journal}}: Cite journal requires |journal= (help)
  14. ^ Muñoz Merino, Pedro J.; García-Martínez, Alberto; Organero, Mario Muñoz; Kloos, Carlos Delgado (2006). Meersman, Robert; Tari, Zahir; Herrero, Herrero Martín (eds.). Habilitando a autenticação prática de IPsec para a Internet (PDF) . Em Movimento para Sistemas de Internet Significativos 2006: Workshops OTM 2006. Vol. 1. Springer . Arquivado a partir do original (PDF) em 26/04/2012.
  15. ^ âncoras de raiz
  16. ^ IETF: autenticação baseada em DNS de entidades nomeadas (dinamarquês)
  17. ^ "ImperialVioleta" . Recuperado em 26/11/2011 .
  18. ^ "cromo git" . Recuperado 2013-03-09 .
  19. ^ "Validador DNSSEC/TLSA" .
  20. ^ Bugzilla@Mozilla: Bug 672600 - Use a cadeia DNSSEC/DANE grampeada no handshake TLS na validação da cadeia de certificados
  21. ^ "Usando o sistema de nomes de domínio para invasões do sistema" por Steve Bellovin de 1995
  22. ^ "NSEC5: Impedindo Provably a enumeração da zona DNSSEC" .
  23. ^ Negação autenticada da existência no DNS . doi : 10.17487/RFC7129 . RFC 7129 .
  24. ^ a b "Econômico com a verdade: Tornando as respostas DNSSEC baratas" . 24-06-2016.
  25. ^ "Mentiras Negras" . Negação de existência compacta de DNSSEC ou mentiras negras . seg. 2. ID draft-valsorda-dnsop-black-lies.
  26. ^ "DNSSEC bem feito" . 2015-01-29.
  27. ^ Estratégia nacional dos EU para fixar o Cyberspace , p. 30 de fevereiro de 2003
  28. ^ Metzger, Perry; William Allen Simpson & Paul Vixie. "Melhorando a segurança TCP com cookies robustos" (PDF) . Usenix . Recuperado em 17/12/2009 .
  29. ^ https://ccnso.icann.org/de/node/7603 [ URL simples PDF ]
  30. ^ Centro de informação eletrônico da privacidade (EPIC) (27 de maio de 2008). DNSSEC
  31. ^ Política RIPE NCC DNSSEC arquivada em 22 de outubro de 2007, no Wayback Machine
  32. ^ Plano de implantação do ARIN DNSSEC
  33. Eklund-Löwinder, Anne-Marie (12 de fevereiro de 2012). "[dns-wg] Música TCD do ISP Sueco adota DNSSEC" . lista de discussão dns-wg . MADURA NCC . Recuperado em 2 de dezembro de 2012 .
  34. ^ arquivo dns-wg: lista de zonas assinadas Arquivado em 5 de março de 2007, no Wayback Machine
  35. ^ ISC lança registro DLV para iniciar a implantação mundial de DNSSEC Arquivado em 18 de novembro de 2008, no Wayback Machine
  36. ^ Repositório de âncora de confiança provisória
  37. ^ .ORG é o primeiro TLD aberto assinado com DNSSEC
  38. ^ Sean Michael Kerner. ".ORG o domínio mais seguro?" . www.internetnews.com . Recuperado 2008-09-27 .
  39. ^ "Lista de registradores .ORG — com DNSSEC ativado no topo" . Recuperado em 23-06-2010 .
  40. ^ VeriSign: Apoiaremos a segurança do DNS em 2011 Arquivado em 3 de março de 2009, no Wayback Machine
  41. ^ VeriSign: grande atualização de segurança na Internet em 2011
  42. ^ Domínio .com finalmente seguro
  43. ^ Matt Larson da Verisign ganha o Prêmio de Liderança Tecnológica InfoWorld 2011
  44. ^ O InfoWorld 2011 Technology Leadership Awards
  45. ^ a b "Atualização de status do DNSSEC raiz, 2010-07-16" . 16 de julho de 2010.
  46. ^ Singel, Ryan (8 de outubro de 2006). "Os federais começam a se mover no buraco de segurança da rede" . Notícias com fio . CondéNet . Recuperado em 2008-10-09 .
  47. ^ "Comunicado de imprensa: NTIA procura comentários públicos para a implantação da tecnologia de segurança dentro do sistema de nomes de domínio da Internet" (comunicado de imprensa). Administração Nacional de Telecomunicações e Informação, Departamento de Comércio dos EUA. 9 de outubro de 2008 . Recuperado em 2008-10-09 .
  48. ^ "Departamento de Comércio para trabalhar com ICANN e VeriSign para aumentar a segurança e estabilidade do nome de domínio e sistema de endereçamento da Internet" (comunicado à imprensa). Instituto Nacional de Padrões e Tecnologia. 3 de junho de 2009.
  49. ^ a b "DNSSEC para a zona raiz" (PDF) .
  50. ^ a b Hutchinson, James (6 de maio de 2010). "ICANN, Verisign colocam as últimas peças do quebra-cabeça na saga DNSSEC" . NetworkWorld. {{cite journal}}: Cite journal requires |journal= (help)
  51. ^ "DNSSEC se tornará padrão em domínios .ORG até o final de junho" . Arquivado a partir do original em 2010-03-15 . Recuperado 2010-03-24 .
  52. ^ The Inquirer: Verisign implanta DNSSEC em .com TLD
  53. ^ Mais segurança para servidores DNS raiz Heise Online, 24 de março de 2010
  54. ^ CircleID: Atualização DNSSEC da ICANN 42 em Dakar
  55. ^ "Arquitetura técnica de alto nível da zona raiz DNSSEC" (PDF) .
  56. ^ RFC 5702, §2.1. "As chaves públicas RSA para uso com RSA/SHA-256 são armazenadas em registros de recursos DNSKEY (RRs) com o algoritmo número 8."
  57. ^ RFC 5702, §3.1. "As assinaturas RSA/SHA-256 são armazenadas no DNS usando registros de recursos RRSIG (RRs) com algoritmo número 8."
  58. ^ ISC lança registro DLV para iniciar a implantação mundial de DNSSEC Arquivado em 14 de junho de 2011, no Wayback Machine
  59. ^ RFC 5011, "Atualizações automatizadas de âncoras de confiança de segurança DNS (DNSSEC)"
  60. ^ RFC 4431, "O DNSSEC Lookaside Validation (DLV) DNS Resource Record"
  61. ^ RFC 5074, "Validação de Lookaside DNSSEC (DLV)"
  62. ^ "DLV substituído com zona vazia assinada - consórcio de sistemas de Internet" . www.isc.org . 30 de setembro de 2017 . Recuperado 2020-06-05 .
  63. ^ "BIND 9.16.0, Ramo Estável para 2020 e Além - Consórcio de Sistemas de Internet" . www.isc.org . 20 de fevereiro de 2020 . Recuperado 2020-06-05 .
  64. ^ "Unbound 1.5.4 Alterações" . Laboratórios NLnet . Recuperado 2020-06-05 .
  65. ^ Mekking, W. ; Mahoney, D. (março de 2020). Movendo a validação DNSSEC Lookaside (DLV) para o status histórico . IETF . doi : 10.17487/RFC8749 . RFC 879 . Recuperado em 3 de junho de 2020 .
  66. ^ Departamento de Homeland and Security quer chave mestra para DNS arquivado 6 de abril de 2007, no Wayback Machine Heise News, 30 de março de 2007
  67. ^ Análise: de possuir as chaves para a Internet UPI , 21 de abril de 2007
  68. ^ Análise UPI: Possuindo as chaves para a Internet 24 de março de 2011 - O primeiro link está morto, acredita-se que este seja o mesmo conteúdo
  69. Boletim da Iniciativa de Implantação de DNSSEC - Volume 1, Número 2 Arquivado em 22 de novembro de 2007, no Wayback Machine , junho de 2006
  70. ^ Memorando para Chief Information Officers arquivado 2008-09-16 no Wayback Machine Executive Office Of The President - Office Of Management and Budget, 22 de agosto de 2008
  71. Os federais reforçam a segurança em .gov Arquivado em 25 de setembro de 2008, no Wayback Machine Network World, em 22 de setembro de 2008
  72. ^ Blog da Comcast - Início do lançamento da segurança do DNS , 18 de outubro de 2010
  73. ^ Vídeo de anúncio de serviço público Comcast DNSSEC arquivado em 21/10/2010 no Wayback Machine , 18 de outubro de 2010
  74. ^ Comcast conclui a implantação do DNSSEC , 11 de janeiro de 2012
  75. ^ Geoff Huston: DNS, DNSSEC e Serviço DNS Público do Google (CircleID)
  76. ^ Apresentando o DNS público da Verisign
  77. ^ Uso da validação DNSSEC para o mundo (XA)
  78. ^ Google Public DNS agora suporta validação DNSSEC Blog do Google Code, 1 de junho de 2013
  79. ^ "Quad9 FAQ" . Quad9 . Recuperado em 7 de julho de 2018 .
  80. Seshadri, Shyam (11 de novembro de 2008). "DNSSEC no cliente DNS do Windows 7" . Porta 53 . Microsoft.
  81. ^ DNSSEC no Windows Server

Leitura adicional

Links externos