DNSCrypt
DNSCryptは、コンピュータと再帰ネームサーバ間のDomain Name System(DNS) トラフィックを認証および暗号化する通信プロトコルである。オリジナルは、Frank DenisとYecheng Fuによって設計された。 クライアントとサーバーの実装は複数存在するが、このプロトコルはRFCによってIETFに提案されたことはない。 DNSCrypt は、偽造を検出するために、クライアントとDNSリゾルバ間の変更されていないDNSトラフィックを暗号化構造でラップする。エンド ツー エンドのセキュリティは提供しないが、ローカル ネットワークを中間者攻撃から保護する[1]。 また、少なくとも対応する応答と同じ大きさの質問を要求することで、 UDPベースの増幅攻撃を軽減する。このようにして、DNSCryptはDNS 増幅攻撃の防止に役立つ。 DNSCryptプロトコルは、プライベートな展開に加えて、OpenNICネットワークのメンバーを中心としたいくつかのパブリックDNSリゾルバや、仮想プライベートネットワーク(VPN)サービスにも採用されている。 OpenDNS (現在はCiscoの一部門) は、2011年12月6日にDNSCrypt をサポートする最初のパブリックDNSサービスを発表し、その後すぐに CloudNS Australiaが続いた[2]。 2016年3月29日、Yandexは、パブリックDNSサーバおよび Yandex BrowserでDNSCryptプロトコルをサポートすることを発表した[3][4]。 2016年10月14日、 AdGuardはDNSフィルタリングモジュールにDNSCryptを追加し、ユーザーがISPからカスタムまたはAdGuard独自のDNSサーバーに移動して、オンラインプライバシーと広告ブロックを行えるようにした[5][6]。 2018年9月10日、非営利のパブリック再帰リゾルバーサービス、Quad9はDNSCryptのサポートを発表した[7]。 プロトコルDNSCryptは、UDPまたはTCPのいずれかで使用できる。どちらの場合も、デフォルトのポートは443である。プロトコルはHTTPSとは根本的に異なるが、どちらのサービスタイプも同じポートを使用する。ただし、 DNS over HTTPSとDNSCryptは同じポートで使用できるが、それらは異なるサーバで別々に実行する必要がある。両方が通信に同じポートを使用する場合、2つのサーバアプリケーションを同じサーバで同時に実行することはできない。多重化アプローチは理論的には可能である。 クライアントは、ウェブブラウザに搭載されている信頼できる認証局に頼るのではなく、選択したプロバイダの公開署名鍵を明示的に信頼する必要がある。この公開鍵は、従来のDNSクエリを使用して取得した一連の証明書を検証するために使用される。これらの証明書には、鍵交換に使用する短期公開鍵と、使用する暗号スイートの識別子が含まれている。クライアントは問い合わせのたびに新しい鍵を生成することが推奨され、サーバは24時間ごとに短期鍵ペアをローテーションすることが推奨される。。 DNSCryptプロトコルは、あらかじめ定義された公開鍵のセットのみを受け付けることで、アクセス制御やアカウンティングにも利用できる。これにより、商用DNSサービスでは、IPアドレスに依存せずに顧客を識別することができる[要出典]。 クエリと応答は同じアルゴリズムを使用して暗号化され、パケットサイズのリークを回避するために64バイトの倍数にパディングされる。 UDPを介して、応答がそれにつながる質問よりも大きい場合、サーバはTC(切り捨て)ビットが設定されている短いパケットで応答できる。その後、クライアントはTCPをって再試行し、後続のクエリのパディングを増やす必要がある。 バージョン1および2のプロトコルでは、鍵交換にX25519アルゴリズム、署名にEdDSA、認証付き暗号化にXSalsa20-Poly1305またはXChaCha20-Poly1305を使用している。 2020年の時点で、DNSCryptプロトコルに既知の脆弱性はなく、基盤となる暗号構造に対する実際的な攻撃もない。 匿名DNSCrypt匿名DNSCryptは、DNSのプライバシーをさらに改善するために2019年に提案されたプロトコル拡張である[8]。 リゾルバは、クライアントに直接応答する代わりに、別のリゾルバへの透過プロキシとして機能し、実際のクライアントIPを後者に隠すことができる。匿名DNSCryptは、TorおよびSOCKSプロキシの軽量な代替手段であり、DNSトラフィック用に特別に設計されている[8]。 匿名DNSCryptの展開は2019年10月に開始され、クライアントとサーバの実装が公開されてからわずか2週間で40台のDNSリレーが設置されるなど、プロトコルの採用は迅速に行われた[9]。 脚注
関連項目外部リンク |