web-dev-qa-db-ja.com

DNSでプライバシーと信頼性を取得するにはどうすればよいですか？

ローカルリゾルバーとしてpfSense（Unbound）を使用しています。歴史的に私はルート再帰解決でそれを指摘しました、なぜなら私は私の脅威をデータの信頼性と最新性（毒された/無効なDNS）とローカルISP DNS追跡として認識したからです。 （そうかどうかはわかりませんが、海外のルートDNSサーバーは個人的に接続されていない可能性があり、生成するクエリにはあまり興味がないと感じました。）主に関連性のあるIPv4を使用しています。

DNS追跡にすべての注意が払われて、いくつかの懸念と認識が生じました。

  • プライバシー/確実性のために、ある種のDNS暗号化または署名方式を使用する必要がありますか？ DNSSECまたはその他の拡張機能を使用していないため、DNSクエリは「平文」のプレーンテキストです。これらは、こことさまざまなDNSサーバーの間で監視でき、「ネットワーク上」での過剰な操作は確かにありません（可能性は低いですが、注意が必要です）。しかし、それは誰もがサポートしているわけではないので、何を使用するか、そしてそれがどれだけ役立つか。
  • ルートサーバーにクエリを実行する代わりに外部リゾルバを使用する必要がありますか？ルートサーバーに最初からクエリを実行しているため、ルートサーバーから実際の目的のサブネットまで、多くのクエリを発行しています。一部の既存のDNSリゾルバー/キャッシュの事前キャッシュされたエントリ。ただし、各DNSサーバーはドメインの1つのコンポーネントのみを認識し、ターゲット全体を認識することはできません。中間リゾルバー、特に署名/暗号化を使用するリゾルバーを使用する場合、発行するDNS要求ははるかに少なく、発行するものは常に暗号化および署名されます。しかし、それはかなりの信頼（キャッシングなど）を持つ選ばれた仲介者を必要とし、傍受のリスクに影響を与えません。
  • DNSをある種の匿名プロキシ経由でルーティングする必要がありますか？最初のリクエストの方が遅いですが、Unboundは応答をローカルにキャッシュし、キャッシュされたデータが期限切れになる前に更新データをリクエストします。 80/20ルールが適用されます（ほとんどのクエリは、既にデータをキャッシュしているドメインの同じサブセットに対して行われます）ので、速度の側面についてあまり心配していません。しかし、これはどれほど実用的ですか？最も有名な匿名化方法はtorです。 TorはUDPを実行しないため、出口ノードにDNSクエリを実行するように要求してDNSを処理し、その結果を信頼します。 TCPのみでDNSをクエリするようにUnboundを構成し、ローカルTor経由でルーティングすることで解決できる場合（= ifほとんどの出口ノードはポート53を許可し、 ifほとんどのDNSサーバーはTCPを話します。他の人に役立つ場合は、DNSに固有のtorの同等物がある場合は、DNS匿名化ノードを実行しても問題ありません（これにより、トラフィックを一般的なDNSクエリ）が、そのようなものは存在しますか？

だから私の現在のリスクモデルはおそらくこのようなものです-

  • 毒された/無効なデータ;
  • サーバーでのロギング/モニタリング、および「ネットワーク上の」変更/モニタリング;
  • クエリをソースIP/DNSの匿名化に結び付ける
    DNSプロキシ/匿名化を使用しない場合、2つのオプションしかありません。ルートサーバーからすべてを自分で解決できます。その場合、すべてのドメインのすべてのDNSサーバーがクエリをログに記録しないように信頼しますが、結果のサブドメインクエリは非常に広く分散されるため、クエリターゲットを特定するのは簡単ではありません。パブリックリゾルバーを使用する場合、ターゲットドメインの一部だけでなく全体が表示されるため、「すべての卵を1つのバスケットに入れる」ように配置し、ログに記録されないことを信頼します。これも非現実的です。したがって、DNSの匿名化は必要なようですが、それが現実的かどうかは明確ではありません。

私はこれを解決するために仕事を入れてうれしいです、そして私がしていることを改善できると確信しています。ただし、DNSは根本的に安全ではないため、回避策が必要になります。

DNSの現状と匿名化テクノロジの現状を踏まえると、DNSクエリの脅威を軽減するための最善の方法は何ですか？

privacydnstorsurveillancednssec
8
Stilez

つまり、QNAME最小化（ RFC 7816 ）を使用してDNSSEC対応のリゾルバーをコンピューターにインストールするか、DNS over TLS（ RFC 7858 ）あなたが信頼/制御するリモートサーバーに向けて。

以前のセットアップはさまざまなケースに対応しており、いくつかの方法で組み合わせることができるので、今より詳細に。

最初のDNSSECは、どこでも適用できるように自分の側で使用できるものではなく、プライバシーを保護するものでもありません。 DNSSECが有効になっている（署名がある）ゾーンの場合、リゾルバーがそれらを検証すると、信頼性（偽のデータを取得できなかった）と整合性（変更またはダウングレードできなかった）が保証されます。これは便利でいくつかの問題を解決しますが：

  1. すべてのドメイン名がDNSSEC対応であるとは限りません。
  2. 要求と応答の両方が平文のままであるため、DNSトラフィックの読み取りを妨げることはありません。

したがって、その場合は、ISPまたはネットワーク上の誰もがトラフィックを盗聴しないように信頼する必要があります。誰でもあなたのDNSメッセージを監視し、DNSSECが有効になっていないメッセージを変更することができます。

もう1つのオプションは、この新しいプロトコルを使用するリモートDNSサーバーにTLSで接続することです。これには2つの利点があります。

  1. dNSメッセージはすべてTLSで保護されているため、DNSメッセージをスヌープしたり変更したりすることはできません。これは、DNSSEC対応ドメインとDNSSEC対応ドメインの両方に適用されます
  2. クエリを実行する権限のあるネームサーバーには、他のネームサーバーのIPのみが表示され、自分のネームサーバーは表示されません。

もちろん、貧しい人の代替策は、UDPとTCPの両方を処理する必要があるため、IPSECまたはSSHトンネルを実行してほぼ同じ利点を得ることですが、複雑さはありません。またはSOCKSプロキシ。しかし、DNS over TLSは現在標準になっているため（少なくともRFC）、代わりにこの方法を採用する方が理にかなっている可能性があります。

私はあなたがこのリモートDNSサーバーを信頼/制御する必要があると言ったのは、明らかにすべてのDNSトラフィックを見るからです。したがって、信頼できるかどうかを定義するかどうかは、あなた次第です。パブリックオープンDNSプロバイダーの中には、最近CloudTLSのようにTLS over DNSを提供するものもあります：CloudFlare： https://developers.cloudflare.com/1.1.1.1/dns-over-tls/ しかしあなたはここで他の多くのものを見つけることができます： https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers

完全に制御できないようなネームサーバーを使用する必要がある場合は、複数のものを使用し、それらの間でクエリを分散させて、1つではDNS全体を再構築できないように設定するようにアドバイスする人もいます。セッション。これは、ネームサーバーのリストがデフォルトで動作する標準的な方法ではないため、配置するのが少し複雑です。

補足として、HTTPSを介したDNSの標準は現在準備中であり、「すぐに」届くはずです。多くのプロバイダーがこのサービスを提供することになると思いますので、VPNプロバイダーの現在と同じジレマ（信頼する人など）になるでしょう。

また、「各DNSサーバーはドメインの1つのコンポーネントしか認識せず、ターゲット全体を認識することはできません。」今日は実際には間違っています。プロトコルはそれを可能にしますが、再帰ネームサーバーが名前全体（各ラベル）を各ステップで各権威ネームサーバーに送信していた時期を誰も覚えていないため、さまざまな理由によります。 QNAME最小化標準（RFC 7816）を使用して初めて、リゾルバーは毎回1つのラベルのみを送信してトラバーサルを実行できます。一部のネームサーバーはそれに対応していないため、これには問題がないわけではありません（したがって、一部の再帰型サーバーはフォールバック戦略を実装しています：最初にQNAMEの最小化を試み、失敗した場合は以前のようにフルネームで再度開始してください）

1
Patrick Mevzek