
O DNSSEC valida e autentica os dados da zona com o objetivo de garantir que, quaisquer que sejam os resultados do DNS, eles são genuínos.
Mesmo que um resolvedor DNS valide que um servidor de nomes autorizado enviou os dados corretos sem adulteração, como podemos evitar que o resolvedor DNS envie respostas DNS adulteradas ao cliente DNS?
Se o resolvedor DNS não suportar DNSSEC, ele ainda poderá enviar consultas DNS para um servidor de nomes autoritativo que tenha DNSSEC habilitado para sua zona?
Obrigado
Responder1
o DNSSEC é útil?
Isso não pode ser respondido (para qualquer palavra que você coloque em vez de "DNSSEC" nessa frase) até que você comece a descrever o que deseja defender.
Quando você tiver a lista de riscos/vulnerabilidades/ameaças contra os quais deseja se defender, poderá descobrir quais soluções existem e determinar para cada solução o quanto ela é útil ou não.
DNSSEC
é útil contra alguns tipos de problemas de DNS, mas não em todos eles. Ele apresenta novos problemas (manutenção contínua de assinaturas e chaves), mas também novos recursos (armazenamento em cache agressivo de tudo abaixo de a, NXDOMAIN
se devidamente validado pelo DNSSEC).
Mesmo que um resolvedor DNS valide que um servidor de nomes autorizado enviou os dados corretos sem adulteração - como podemos evitar que o resolvedor DNS envie respostas DNS adulteradas ao cliente DNS?
Isso não é nada diferente de hoje: se você usar qualquer resolvedor de DNS público ( 8.8.8.8
, 1.1.1.1
, 9.9.9.9
para citar alguns), você corre COMPLETAMENTE o risco de ele lhe enviar dados inúteis. Isso é uma troca. DoH/DoT não resolve nada aqui porque protegerá apenas a transmissão de conteúdo entre você e este resolvedor, não o conteúdo em si. Qual conteúdo é "protegido" por DNSSEC, desde que o nome de domínio para o qual você está fazendo consultas seja protegido por DNSSEC (que é uma parte que você esquece em suas perguntas e que torna o DNSSEC de fato difícil: o proprietário do nome de domínio deve habilitá-loEOs resolvedores de DNS precisam usar as novas assinaturas e fazer a validação; se uma parte desta equação de 2 variáveis não estiver lá, o DNSSEC não será útil porque simplesmente não funciona)
Portanto, a questão gira mais em torno de: qual servidor de nomes recursivo usar e onde ele deve ser executado. É claro que, para obter controle máximo, você deseja que o resolvedor seja executado em SUAS máquinas. Ele ainda pode usar recursos externos e resolvedores de DNS, mas a validação final do DNSSEC deve acontecer no seu servidor de nomes, não em outros. É claro que isso é mais trabalhoso do que apenas depender de qualquer outro recurso que faça todo o trabalho do DNSSEC “de graça” para você.
se o resolvedor DNS não suportar DNSSEC, ele ainda poderá enviar consultas DNS para um servidor de nomes oficial que tenha configuração DNSSEC para sua zona?
Sim. Um resolvedor que queira ter dados DNSSEC precisa mudar o sinalizador “DO” em sua solicitação.
Da dig
documentação:
+[no]dnssec
This option requests that DNSSEC records be sent by setting the DNSSEC OK (DO) bit in the OPT record in the additional section of the query.
O que você pode ver dessa forma:
$ dig +dnssec example.com
; <<>> DiG 9.16.18 <<>> +dnssec example.com
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40492
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
^^
Ou de §3.2.1 da RFC 4035:
3.2.1. A parte FAZER
O lado do resolvedor de um servidor de nomes recursivo com reconhecimento de segurança DEVE definir o bit DO ao enviar solicitações, independentemente do estado do bit DO na solicitação inicial recebida pelo lado do servidor de nomes. Se o bit DO em uma consulta inicial não estiver definido, o lado do servidor de nomes DEVE retirar quaisquer RRs DNSSEC de autenticação da resposta, mas NÃO DEVE remover quaisquer tipos de RR DNSSEC que a consulta inicial tenha solicitado explicitamente.
Se o cliente DNS (resolvedor recursivo) fizer isso E se o servidor de nomes autoritativo que está sendo consultado tiver DNSSEC habilitado (portanto, // RRSIG
tipos de registro nas zonas), então o resolvedor obterá esses registros e poderá fazer a validação de DNSSEC.NSEC
NSEC3
Quando você (um stub/cliente DNS que não é um resolvedor) consulta um resolvedor recursivo, você tem a opção de usar o CD
sinalizador, definido como tal:
+[no]cdflag
This option sets [or does not set] the CD (checking disabled) bit in the query. This requests the server to not perform DNSSEC validation of responses.
(cuidado com a possível dupla negação).
Se o cliente não usar CD
, então a validação DNSSEC NÃO está desabilitada, portanto ela está habilitada e o servidor de remoção servirá a resposta final (se o DNSSEC estiver habilitado para o registro E a validação foi um sucesso) ou responderá NXDOMAIN
se o DNSSEC falha na validação. O sinalizador AD
será definido para indicar que todos os registros foram validados como seguros, se for o caso (se a consulta vier de um servidor de nomes recursivo, esse sinalizador não pode existir em um servidor oficial, pois você precisa da cadeia DNSSEC completa da raiz da IANA para validar qualquer registro)
Responder2
- O ideal é que você valide localmente no cliente (não tão comum hoje em dia, mas longe de ser inédito) ou, de outra forma, confie em um caminho de rede seguro que possa preencher a lacuna entre o cliente e um resolvedor de validação confiável.
Esse caminho de rede seguro pode significar algo como DNS sobre TLS, DNS sobre HTTPS, DNSCrypt ou, até certo ponto, uma rede local (nível de confiança mais fraco, mas ainda útil para um subconjunto de cenários de ataque). - Sim