DNSクエリは暗号化されているのでしょうか。もしそうなら、暗号化が行われると私が想定しているプロセスを簡単に説明できますが、少なくとも2つのパーティ間に最低限の共通基盤(キーの共有など)が必要ですが、DNSはUDPを使用し、コネクションレスであるため、この場合、ペイロードを暗号化する方法は想像できません。
ありがとう
標準DNSはどこでも暗号化されていません。 DNSSECには、暗号で署名された(ただし暗号化されていない)応答があります。長年にわたっていくつかの非標準的なアイデアと実装がありましたが、大きなことは何もありませんでした。
DNSはTCPでも動作するはずです。これは、DNSが大きすぎる回答を処理するための標準メカニズムであるためです(代替はIPフラグメンテーションです)。サーバーは本質的に、「応答が大きすぎます。TCPで再試行してください」というUDP応答を送信します。
あなたの質問に関して、簡単で遅いソリューションは、HTTPSが行うのと同じことをすることです-3ステップのTLSハンドシェイクを行い、何らかの方法で証明書を検証してから、データを交換します。真の課題は、何らかの形のセキュリティを提供しながら、ラウンドトリップの数を減らすことです。
DNSは、デフォルトでは、作成時に、信頼性(ゾーンの真の権威ネームサーバーからの応答を確実に取得)も機密性(ネットワーク上の誰もクエリや回答を理解できないようにすること)を提供しません。
DNSSECは、レコードに署名できるため、信頼性の問題を解決するために作成されました。また、キーのメカニズムを通じて信頼の連鎖を構築し、得られた答えを検証できます。これは、関係するゾーンが署名されている場合(これは 現在、すべてのゾーンの約0.53% )であり、誰かがそのようなゾーンの応答を変更しようとした場合に、中間者問題を解決します。 、変更を見つけることができます。
直感に反して、真正性は機密性よりも重要です。どうして?なぜなら、あなたが誰と話しているのかを保証できない場合、暗号化された答えが返ってきたとしても、それはどのような価値があるのですか?認証を行わなければ、悪意のある第三者と暗号化を行うことができます。
DNSSECなどの理由ですでに信頼性がある場合、DNSは機密情報または少なくとも個人情報を伝えることができるため、機密性が必要になる場合があります。これは、各ネームサーバーに送信される情報の量を減らすために QNAME最小化 が存在する理由でもあります。これはますますサポートされています( 間もなくBindで )
暗号化に関しては、最初のエラーはUDPについて考えることです。 DNSはUDPとTCPを使用しますが、最近ではTCPの理由で以下に説明します)。 UDPの場合でも暗号化オプションがあることに注意してください。基本的にはUDPのTLSである [〜#〜] dtls [〜#〜] を参照してください。 [〜#〜] quic [〜 #〜] は、Googleによって作成されました(基本的に、最適化されたHTTPを作成できるようになり、SPDYになった後にHTTP/2になりました)も、TLSが提供するものと同様のセキュリティでUDPを介して構築されました。この2つで、そのような場合にペイロードを暗号化できないという考えを明らかにします。
今日、暗号化されたDNSの場合、これらのオプションは順不同です。
odns
TLDだけでなく、それを使用するために新しいクライアントとサーバーの両方を必要とする、ブロックの最新の子です。もちろん、これらすべてのケースで、プロトコルを話す特定のサーバーが必要です。一部のオープンリゾルバーは既にDNS over TLSを提供しています。ただし、問題はシフトするだけです。接続はそれらまで「保護」されますが、特にDNSSECの検証では、それらが正しく機能し、嘘をつかないことを信頼する必要があります。
あなたはできる: