プライベート ネットワーク内の IP 10.10.0.10 で DNS サーバーが稼働しています。DNS サーバーは、ネットワーク内のプライベート IP への URL も解決します。すべての URL の SSL は、.BIZ ドメインのワイルドカード証明書によって処理されます。しかし、最近のアップデートで Chrome と Firefox が DNS-over-HTTPS を有効にし始めました。DNS サーバーは DOH に準拠していないため、ユーザーはブラウザー内で DOH 機能を無効にしない限り、URL に移動できません。
理想的には、ユーザーがブラウザ内でDOHを有効にしたまま、ローカルDNSサーバーを利用してURLをプライベートIPに解決できるようにしたい。これを実現するために、私は次のことを検討した。dohプロキシIP 10.10.0.20 で Centos-7 VM を起動し、doh-proxy をインストールして、ポート 443 を開きました。次に、以下を実行しました。
/usr/local/bin/doh-proxy --upstream-resolver=10.10.0.10 --certfile=/etc/pki/public/mycompany.bundle.biz.crt --keyfile=/etc/pki/private/mycompany.biz.pem
netstat を使用して、ポート 443 がリッスンしていることを確認しました。次に、VPN 構成を変更して、DNS 設定を 10.10.0.10 から 10.10.0.20 (新しい doh-proxy サーバー) に変更しました。ただし、ブラウザーで DOH を有効にしても、URL に移動することはできませんでした。
doh-proxy の意図を誤解しているのでしょうか?
答え1
の背後にある意図を誤解しているとは思いません。doh-proxyこれは通常の DNS リゾルバ サーバーの DoH フロントエンドであり、DoH クライアントがリゾルバ サーバーにクエリを実行する方法を作成するものと思われます。
この特定の実装が何らかの理由で適切でないことが判明した場合、このようなプロキシ ソリューションは他にもいくつかあります。
ただし、誤解/見落としている可能性があるのは、DoH を構成するには、クライアントが DoH サーバーの URL ( https://dns.quad9.net/dns-query、https://dns.google/dns-queryなど) を知っている必要があり、IP アドレスだけでは DoH の設定に何の役にも立たないということです。
さらに、事態を難しくしているのは、DoH には現在適切な検出メカニズムが備わっていないことです。(これが、特に Mozilla のアプローチに関して、DoH をめぐる多くの論争の根本原因となっています。)
この時点で「DoH がデフォルトで有効」になっている場合の動作例:
- Firefox は、使用する DoH サーバーを認識するように設定されています (Mozilla は、OS の構成を無視して、ユーザーに代わって DoH サービスを選択します)。
- Chrome は、DNS サービスの既知の IP アドレスをキーとするマッピング テーブルに基づいて、プレーン DNS から DoH に選択的にアップグレードします
8.8.8.8 -> https://dns.google/dns-query(例: Google は既知の DNS サービスのマッピング テーブルを維持しており、マッピング テーブルによって OS 構成がプレーン DNS に示しているのと同じ DNS サービスのクエリが容易になる場合にのみ DoH アップグレードが行われます)。
全体として、独自の DoH サービスを実行するのは簡単ですが、クライアントにそれを使用させるのは必ずしも簡単ではありません。
必要なのは、何らかの方法でクライアントに https://dns.example.com/dns-query(これがプロキシの適切な URL であると仮定した場合) を DoH エンドポイントとして使用するように指示することです。これは、最も単純な形式では、クライアントでの手動構成 (アプリケーションごとに) を意味します。
既知のアプリケーションのセットの構成を自動化する方法は確かに見つかりますが、現時点では、たとえば DHCP がプレーン DNS のアドレスを配信する方法に匹敵する確立された検出方法はありません。