☰

O DNSSEC é comumente quebrado ou é resolvido com excesso de zelo?

tag-icon • tag-icon dns systemd
O DNSSEC é comumente quebrado ou é resolvido com excesso de zelo?

Recentemente mudei meu resolvedor de DNS para systemd-resolvedcomeçar a aproveitar as vantagens do DNSSEC onde ele estiver disponível. Minha configuração é:

[Resolve]
DNS=8.8.8.8 8.8.4.4
DNSOverTLS=yes

(incluindo o padrão comentado de DNSSEC=allow-downgrade)

Tudo parece funcionar muito bem para a maioria dos sites, habilitados para DNSSEC ou não. No entanto, ocasionalmente encontro um site que não resolve:

$ resolvectl query savannah.gnu.org
savannah.gnu.org: resolve call failed: DNSSEC validation failed: failed-auxiliary
$ resolvectl query keys.mailvelope.com
keys.mailvelope.com: resolve call failed: DNSSEC validation failed: failed-auxiliary
$ resolvectl query d1dkupr86d302v.cloudfront.net
d1dkupr86d302v.cloudfront.net: resolve call failed: DNSSEC validation failed: failed-auxiliary

Eu tentei verificar isso viaAnalisador DNSSEC (para savannah.gnu.org). No entanto, tenho dificuldade em entender o resultado. Eu realmente não vejo como isso é diferente de qualquer outro domínio que não habilite DNSSEC.

Minha pergunta é: o DNSSEC é comumente quebrado ou o sistema resolveu fazer algo errado aqui?

Responder1

Provavelmente são ambos. No geral, com base em relatórios anteriores, eu me inclinaria para o último (a resolução do sistema é muito rigorosa em alguns casos). No entanto,de acordo com DNSViz, a configuração dos domínios também não passa em todas as verificações.

Também não tenho 100% de certeza sobre determinados mecanismos DNSSEC, mas aqui está a minha opinião:

savannah.gnu.org

É uma bagunça enorme. O Systemd-resolved detecta corretamente um problema com o domínio... mas o rejeita incorretamente com base em informações nas quais não deveria confiar.

  1. A gnu.org.zona tem assinaturas, mas sua delegação org.não inclui nenhuma chave para validá-las, então o resolvedor não deve sequer olhar para essas assinaturas – elas não fazem mais parte da cadeia de confiança. No entanto, o systemd-resolved analisa-os de qualquer maneira.

  2. O savannah.gnu.org.nome existe em dois lugares e eles não concordam entre si. Este problema passaria despercebido sem o DNSSEC, mas sempre falharia na validação com o DNSSEC. No entanto, devido ao problema nº 1, ele falha na validação, embora o systemd-resolved deva ignorá-lo silenciosamente.

Mais detalhes no nº 2:

Os mesmos servidores de nomes hospedam a zona pai assinada gnu.org.e a zona filho não assinada savannah.gnu.org.. O problema é que o primeiro carece de uma delegação real do NS para o segundo; em vez disso, ele possui apenas registros simples de não delegação com esse nome.

As coisas só funcionam porque ambas as zonas são hospedadas pelos mesmos servidores de nomes; portanto, a princípio, quando você consulta registros A ou AAAA em "savannah.gnu.org", a resposta é automaticamente servida pela zona filha não assinada.

É claro que é o início de uma zona separada porque possui um registro SOA. Mas o validador DNSSEC precisa saber se esta zona deve ser assinada ou não, então ele tenta consultar registros DS (ou a falta deles) e desta vez a resposta é sempre servida pela zona pai.

Uma subzona não assinada é aceitável se a zona pai não tiver nenhum registro DS para ela, o que é comprovado retornando um registro NSEC assinado no lugar da resposta; te NSEC "prova de inexistência" indicatodostipos de registro que estão presentes ou ausentes para este nome.

Portanto, a zona pai "gnu.org" afirma corretamente que os registros DS para "savannah.gnu.org" não existem... mas também afirma queOs registros NS também não existem,ou seja, o nome não é delegado a uma zona filha.(Aparentemente, há um registro SSHFP...)

Como o validador possui a resposta original não assinada indicando que veio de uma subzona e uma prova assinada indicando que hánãodelegação para uma subzona, a validação deverá falhar.

...Mas, como mencionado no item 1, nenhuma dessas verificações deve ser feita em primeiro lugar, porque a org.zona pai-paitambémprova que sua delegação gnu.org.não está assinada, o que significa que quaisquer registros NSEC provenientes de gnu.org são discutíveis. A resolução do Systemd não deveria estar olhando para eles - deveria tratar toda a zona gnu.org como não tendo nenhum DNSSEC.

informação relacionada