Quais são os possíveis problemas de segurança com o TLD não sendo protegido com DNSSEC, mesmo se o subdomínio for?

Question

Estamos trabalhando em uma rede estabelecida com um servidor BIND9 em execução (assim como muitos outros serviços). Eu estou aprendendo e tentando reorganizar os arquivos de configuração antigos para estar em conformidade com os dias atuais (muitas máquinas inoperantes, nomes não utilizados, mapeamento reverso e assim por diante).

Nesse meio tempo, eu adoraria seguir as práticas recomendadas e proteger o DNS com o DNSSEC. Ao verificar a configuração, deparei-me com o fato de que o TLD que usamos não é protegido com DNSSEC.

Minha pergunta: Existe algum ponto (eu aposto que seja) em proteger nosso DNS com DNSSEC se no andar de cima (em super-domínios) ninguém estiver fazendo isso?

Nosso espaço de zona / domínio está sob nosso domínio de universidade, diretamente sob ve. space (TLD Venezuela). Ou seja, algo como example.university.ve. nem ve ou o DNS da nossa universidade estão protegidos.

Se quisermos proteger nosso subdomínio de qualquer maneira, ainda gostaria de saber quais problemas os TLDs inseguros causariam se um invasor aparecesse.

PS: usei ferramentas como o link e o link para verificar os confins do DNSSEC.

    

Answer 1

A segurança do DNSSEC vem de uma cadeia de delegação verificada criptograficamente de alguns dados (como um conjunto de registros A) para uma chave pública conhecida e confiável (conhecida como "âncora de confiança"). Para DNSSEC hoje, a âncora de confiança normalmente usada é a chave da zona raiz . Se sua zona pai não estiver assinada, a cadeia da sua zona para a zona raiz será quebrada e a garantia de segurança do DNSSEC falhará totalmente. Não importa se você assina sua zona, porque ninguém mais tem uma razão para confiar na chave que você usou para assinar. Assim como você pode criar uma chave e assinar a zona com ela, um vilão pode criar uma chave e assinar seus dados (presumivelmente levemente modificados) com isso. Sem uma cadeia assinada para uma âncora de confiança, uma terceira parte não tem como saber se deve confiar na sua chave ou na chave do vilão.

Agora, se você quiser que outras pessoas específicas confiem em sua assinatura, forneça a elas uma chave que elas possam usar como âncora de confiança para seu domínio. Isso é chamado de "look-aside validation", e não foi muito usado desde que a zona raiz foi assinada, mas os padrões e implementações ainda estão lá. Se isso for interessante para você, dê uma olhada em RFC 5074 .

Mas, em geral, se a sua zona pai não estiver assinada, não faz sentido assinar a sua.

    

Answer 2

Seu objetivo (de habilitar o DNSSEC) é louvável, mas

• é muito trabalhoso fazer o DNSSEC corretamente; ainda mais porque não é oneshot, você precisa mantê-lo (rodar chaves, etc…) e monitorá-lo
• Desde que você escreve começando com muitos outros problemas, aconselho primeiro limpar tudo e ter uma boa zona em execução por algumas semanas / meses antes de iniciar novos projetos, como habilitar DNSSEC
• como declarado por Calle, e de fato .VE parece completamente fora de qualquer mapa em relação ao DNSSEC, sem DNSSEC em todos os níveis (e desde agora você não pode mais usar DLV como afirmei no meu comentário), é inútil adicionar na sua zona

Você deve tentar pesquisar porque o .VE não o faz: ele poderia ter decidido não fazer isso, ou decidiu iniciá-lo, mas ainda está em fase preliminar. Você terá, naturalmente, o mesmo problema com seu registrador.

Você poderia usar para si mesmo e apontá-los para esses recursos que devem fornecer dados e documentação amplos: link

BTW, no link , vejo que mais de 10% dos resolvedores na Venezuela validam os registros do DNSSEC. Isso poderia ajudar o TLD .VE a decidir ativar o DNSSEC.