dnsmasq retorna (falso) resultado “falso” para validação do DNSSEC

Question

Estou executando uma instalação local do Debian 8.1 com um Resolvedor de DNS com validação DNSSEC chamado dnsmasq (versão 2.72-3+deb8u1 ).

Configurei-o para retornar um SERVFAIL se ele não puder validar um domínio habilitado para DNSSEC, ou seja, se o domínio tiver uma entrada DNSSEC, ele deverá ser validado corretamente para ser encaminhado ao cliente.

Enquanto eu estava navegando hoje, quis visitar o famoso site da IETF , mas não consegui porque o domínio não podia estar resolvido. Eu verifiquei com a linha de comando para verificar isso e eu realmente tenho um SERVFAIL . Eu verifiquei com o servidor DNS do Google (8.8.8.8) e não obtive nenhum SERVFAIL , mas o endereço IP.

Depois disso, ativei o registro para cada solicitação de DNS e verifiquei os resultados. Parece que meu sentimento estava certo e a validação do DNSSEC falhou, embora tenha recebido a mesma resposta dos encaminhadores do DNS, como eu recebi do Google.

Aqui as linhas correspondentes do meu syslog :

Sep  5 13:27:13 dnsmasq: query[A] www.ietf.org from 192.168.1.10
Sep  5 13:27:13 dnsmasq: forwarded www.ietf.org to 81.3.21.188
Sep  5 13:27:13 dnsmasq: forwarded www.ietf.org to 178.63.73.246
Sep  5 13:27:13 dnsmasq: dnssec-query[DNSKEY] ietf.org to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DS] ietf.org to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DNSKEY] org to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DS] org to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DNSKEY] . to 81.3.21.188
Sep  5 13:27:13 dnsmasq: reply . is DNSKEY keytag 1518
Sep  5 13:27:13 dnsmasq: reply . is DNSKEY keytag 19036
Sep  5 13:27:13 dnsmasq: reply org is DS keytag 21366
Sep  5 13:27:13 dnsmasq: reply org is DS keytag 21366
Sep  5 13:27:13 dnsmasq: reply org is DNSKEY keytag 19629
Sep  5 13:27:13 dnsmasq: reply org is DNSKEY keytag 21366
Sep  5 13:27:13 dnsmasq: reply org is DNSKEY keytag 9795
Sep  5 13:27:13 dnsmasq: reply org is DNSKEY keytag 12023
Sep  5 13:27:13 dnsmasq: reply ietf.org is DS keytag 45586
Sep  5 13:27:13 dnsmasq: reply ietf.org is DS keytag 45586
Sep  5 13:27:13 dnsmasq: reply ietf.org is DNSKEY keytag 45586
Sep  5 13:27:13 dnsmasq: reply ietf.org is DNSKEY keytag 40452
Sep  5 13:27:13 dnsmasq: dnssec-query[DNSKEY] cloudflare-dnssec.net to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DS] cloudflare-dnssec.net to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DNSKEY] net to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DS] net to 81.3.21.188
Sep  5 13:27:13 dnsmasq: reply net is DS keytag 35886
Sep  5 13:27:13 dnsmasq: reply net is DNSKEY keytag 45464
Sep  5 13:27:13 dnsmasq: reply net is DNSKEY keytag 35886
Sep  5 13:27:13 dnsmasq: reply cloudflare-dnssec.net is DS keytag 537
Sep  5 13:27:13 dnsmasq: reply cloudflare-dnssec.net is BOGUS DNSKEY
Sep  5 13:27:13 dnsmasq: validation result is BOGUS
Sep  5 13:27:13 dnsmasq: reply www.ietf.org is <CNAME>
Sep  5 13:27:13 dnsmasq: reply www.ietf.org.cdn.cloudflare-dnssec.net is 104.20.0.85
Sep  5 13:27:13 dnsmasq: reply www.ietf.org.cdn.cloudflare-dnssec.net is 104.20.1.85

Agora, não tenho certeza se o domínio está temporariamente configurado incorretamente ou se minha conexão está sendo adulterada ou se meu servidor DNS está configurado incorretamente, embora todos os outros domínios tenham funcionado bem, incluindo "ietf.org" (sem www) .

Se alguém pudesse me ajudar a rastrear o problema, eu ficaria grato.

    

Answer 1

Isso se deve ao CloudFlare (fornecedor de CDN do IETF), escolhendo o ECDSAP256SHA256 como seu algoritmo de assinatura. O Dnsmasq implementou o ECDSA desde 2.69, no entanto, ele foi quebrado e não foi corrigido até o 2.73 que foi lançado em março de 2015. Assim, você precisará de uma versão mais recente do dnsmasq ou corrigida para resolvê-lo corretamente.

No dnsmasq altere o log na seção 2.73:

Fix broken DNSSEC validation of ECDSA signatures.

Do conjunto de registros do Cloudflare DS:

cloudflare.net. 86400 IN DS 2371 13 2 90F710A107DA51ED78125D30A68704CF3C0308AFD01BFCD7057D4BD0 3B62C68B

O 13 é o tipo de algoritmo. Cada algoritmo permitido no DNSSEC tem um número especificado. Algoritmo 13 é ECDSA com uma curva P-256 usando SHA-256.

Finalmente, dig +trace ds www.ietf.org inclui um registro CNAME passando pela Cloudflare.

www.ietf.org. 1800 IN CNAME www.ietf.org.cdn.cloudflare-dnssec.net.

    

Answer 2

Está acontecendo comigo usando o mais recente dnscrypt 2.0.8 e o mais recente dnssec 2.79; Isso foi temporário e durou apenas 12 minutos.

Portanto, não está limitado a versões anteriores. De acordo com a seção "DNS Pitfalls" em Um caso para ferramentas abrangentes de monitoramento e análise de DNSSEC (ênfase adicionada):

B. Bogus validation caused by misconfiguration

In this section we describe some of the causes of validation failures from a perspective of misconfiguration. In any case, an RRset deemed bogus also invalidates any dependent RRsets. For example, a bogus DNSKEY RRset means that all of the RRsets whose RRSIGs would be potentially validated by those DNSKEYs are also bogus.

...

Bogus: The validator is unable to form a chain of trust between the RRset and a trust anchor and is unable to securely show that no such chain should exist. Example: an expired RRSIG covering an RRset in the secure.com results a bogus response; likewise, the presence of a DS for the broken.com zone, in which there are no DNSKEYs present, results in a bogus status for any RRset in the zone

While a secure validation is ideal, an insecure outcome is also usable and is equivalent to normal, unauthenticated name resolution. However, a bogus outcome is an indicator that validation failed—either because the DNS data has been tampered with or because of misconfiguration. The response returned to a recursive (i.e., on behalf of another client) query which a validator renders bogus has SERVFAIL error status and contains no DNS data, an indication of general name resolution failure. An end user cannot distinguish a SERVFAIL response caused by data tampering from one caused by misconfiguration. In either case, however, the end result is the same: the name in question cannot be resolved. This study focuses on bogus validation caused by misconfiguration.