web-dev-qa-db-ja.com

dnsmasqは、DNSSEC検証に対して（false）「偽の」結果を返します

dnsmasq（バージョン2.72-3+deb8u1）と呼ばれるDNSSEC検証DNSリゾルバーを使用してローカルのDebian8.1インストールを実行しています。

DNSSEC対応ドメインを検証できない場合、つまりドメインにDNSSECエントリがある場合は、クライアントに転送するために正しく検証する必要がある場合に、SERVFAILを返すように設定しました。

今日ブラウジングしているときに、 [〜＃〜] ietf [〜＃〜] のかなり有名なサイトにアクセスしたかったのですが、ドメインを解決できなかったため、アクセスできませんでした。これを確認するためにコマンドラインで確認したところ、確かにSERVFAILが得られました。 Google DNSサーバー（8.8.8.8）で確認したところ、SERVFAILは取得できませんでしたがIPアドレスを取得しました。

その後、DNSリクエストごとにログを有効にして、結果を確認しました。 Googleから受け取ったのと同じDNSフォワーダーからの応答があったにもかかわらず、私の気持ちは正しく、DNSSEC検証は失敗したようです。

ここに私の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

「ietf.org」（wwwなし）を含むこれまでの他のすべてのドメインが正常に機能していても、ドメインが一時的に誤って構成されているのか、接続が改ざんされているのか、DNSサーバーが誤って構成されているのかがわかりません。

誰かが私が問題を追跡するのを手伝ってくれるなら、私は感謝するでしょう。

dnsmasqdnssecdebian-jessie
3
comfreak

これは、CloudFlare（IETFのCDNプロバイダー）が署名アルゴリズムとしてECDSAP256SHA256を選択したためです。 Dnsmasqは2.69からECDSAを実装していますが、壊れており、2015年3月にリリースされた2.73まで修正されていません。したがって、正しく解決するには、新しいdnsmasqまたはパッチを適用したバージョンが必要です。

2.73セクションのdnsmasq 変更ログ から：

Fix broken DNSSEC validation of ECDSA signatures.

CloudflareからDSレコードセット：

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

13はアルゴリズムタイプです。 DNSSECで許可されている各アルゴリズムには、指定された番号があります。アルゴリズム13は、SHA-256を使用したP-256曲線を使用したECDSAです。

最後に Dig +trace ds www.ietf.orgCloudflareを通過するCNAMEレコードが含まれています。

www.ietf.org。 1800 IN CNAMEwww.ietf.org.cdn.cloudflare-dnssec.net。

5
DannyAAMtw

最新のdnscrypt2.0.8と最新のdnssec2.79を使用して私に起こっています。これは一時的なもので、12分間しか続きませんでした。

したがって、以前のバージョンに限定されません。 包括的なDNSSEC監視および分析ツールの事例 （強調を追加）の「DNSの落とし穴」のセクションによると：

B.設定ミスによる偽の検証

このセクションでは、構成ミスの観点から検証失敗の原因のいくつかについて説明します。いずれの場合も、偽物と見なされるRRsetは、依存するRRsetも無効にします。たとえば、偽のDNSKEY RRsetは、RRSIGがそれらのDNSKEYによって検証される可能性のあるすべてのRRsetも偽であることを意味します。

.。

偽物：バリデーターは、R​​Rsetとトラストアンカーの間に信頼の連鎖を形成することができず、そのような連鎖が存在してはならないことを安全に示すことができません。例：secure.comのRRsetをカバーする期限切れのRRSIGは、偽の応答をもたらします。同様に、DNSKEYが存在しないbroken.comゾーンにDSが存在すると、ゾーン内のRRsetのステータスが偽になります。

安全な検証が理想的ですが、安全でない結果も使用可能であり、通常の認証されていない名前解決と同等です。ただし、偽の結果は、DNSデータが改ざんされているか、構成の誤りが原因で、検証が失敗したことを示しています。バリデーターが偽のレンダリングを行う再帰的（つまり、別のクライアントに代わって）クエリに返される応答には、SERVFAILエラーステータスがあり、DNSデータが含まれていません。これは、一般的な名前解決の失敗を示します。 エンドユーザーは、データの改ざんによって引き起こされたSERVFAIL応答と、構成ミスによって引き起こされた応答を区別できません。ただし、どちらの場合も、最終結果は同じです。問題の名前は解決できません。この調査では、構成の誤りによって引き起こされる偽の検証に焦点を当てています。

2
zepplingradge