Windows 10 Insider Preview、DNS over HTTPSがテスト可能に 16
ストーリー by headless
暗号 部門より
暗号 部門より
Microsoftが13日に提供開始したWindows 10 Insider Preview ビルド19628(アクティブな開発ビルド)では、DNS over HTTPS(DoH)の初期的なサポートが追加されている(Microsoft Tech Community - Networking Blogの記事、
BetaNewsの記事、
Softpediaの記事、
The Registerの記事)。
MicrosoftではDNSクエリを暗号化するDoHのサポート計画を昨年11月に発表していた。本ビルドのDoHサポートはデフォルトで無効になっており、テストするにはレジストリの「HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters」にDWORD値「EnableAutoDoh」を作成して値のデータに「2」をセットする必要がある。これでDoHクライアントが有効になり、ネットワーク接続で既知のDoHサーバーをDNSサーバーに指定すればDoHによる通信が行われるようになる。DNS(Client)サービスの再起動が必要になるとの記述もみられるが、手元の環境で試した限りでは上述のレジストリ値を設定/削除するとすぐ有効/無効になった。このレジストリ値はInsiderビルドでのテストを目的としたもので、一般リリースビルドではサポートされなくなるとのこと。
MicrosoftではDNSクエリを暗号化するDoHのサポート計画を昨年11月に発表していた。本ビルドのDoHサポートはデフォルトで無効になっており、テストするにはレジストリの「HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters」にDWORD値「EnableAutoDoh」を作成して値のデータに「2」をセットする必要がある。これでDoHクライアントが有効になり、ネットワーク接続で既知のDoHサーバーをDNSサーバーに指定すればDoHによる通信が行われるようになる。DNS(Client)サービスの再起動が必要になるとの記述もみられるが、手元の環境で試した限りでは上述のレジストリ値を設定/削除するとすぐ有効/無効になった。このレジストリ値はInsiderビルドでのテストを目的としたもので、一般リリースビルドではサポートされなくなるとのこと。
ブログ記事では既知のDoHサーバーとしてCloudflare/Google/Quad9を挙げているが、レジストリにはOpenDNSのDoHサーバーもセットされており、こちらも使用できた。既知のDoHサーバーの追加はレジストリで直接設定するよりも、ブログ記事で紹介されているようにnetshコマンドを使用する方が手間は少ない。DoHが有効かどうかを確認する方法としては、pktmonコマンドでクラシックDNSが使用するポート53のログを表示する方法(DoHが有効になるとログが出力されなくなる)が紹介されている。
なお、ビルド19628は「RS_PRERELEASE」ブランチから「MN_RELEASE」ブランチに変更されている。今回の変更はアクティブな開発ブランチを切り替えるテストのためのものであり、すぐにRS_PRERELEASEブランチに戻す予定だという。また、MN_RELEASEブランチのビルドは特定のWindows 10リリースに一致するものではないとのことだ。
Google/Cloudflare/IBM に情報を握られる (スコア:1)
(T/O)
DNSSEC 対応とか経路ハイジャック対策とかは力を入れてくれるでしょうが、セキュリティはそれだけではないですよね。誰がいつどのドメインを問い合わせたという記録が、電気通信事業の規制に掛からない会社に送られているわけです。 User-Agent の情報や TLS Session Ticket も含まれるので、 DNS (over 53) と比べると NAT 越しでも IP アドレスに加えて Web ブラウザひいては利用者を特定できる情報が送られています。
Public DNS サービスは DNS が速いことを売りにしているようですが、 Web ページの読み込み時間のうち DNS の占める割合はとても小さいのではないでしょうか。 Firefox は独自にキャッシュもしていますよね。たとえ DNS が速かったとしても、 CDN 事業者が 問い合わせ元のクライアントに一番近いサーバーの IP アドレスを返す仕掛けを使っていると、その恩恵を受けられないことになります。 DNS が速くても、その後のページの読み込みで太平洋の向こう側へアクセスすることになっては、本末転倒です。
# EDNS Client Subnet のことは存じていますが、 CDN 事業者の DNS サーバが対応してくれないと効果がありません
# Cloudflare の 1.1.1.1 はプライバシーの懸念から EDNS Client Subnet に対応しないと明言しています
Re: (スコア:0)
ツッコミどころ満載ですね
User-Agent は送る必要がない
（なんでワザワザ利用者が特定できる情報を送るんですか？）
TLS Session Ticketはランダムなものをつかうから、NAT越しなら、利用者までは特定できない
（あなたはTLSの仕組みを誤解しています。
あなたの考えているSession Ticketの使い方だと TLSを使う全てのアプリで利用者が特定できてしまいます）
Public DNS サービスを使って速くなるか遅くなるかは実際に測ってみれば済むことで
タラレバを言っても意味がない(速くなることもあれば遅くなることもある。だから何？)
Re: (スコア:0)
信用し過ぎでは？
Re: (スコア:0)
User-Agent について、 Firefox でも半年前まで送っていました (https://bugzilla.mozilla.org/show_bug.cgi?id=1543201) HTTP(S) 処理を既存の Web ブラウザのコードを使い回せば楽になるという発想があるので、あえて User-Agent を送らないようにするというコードを書かないといけない。他のクライアントは知りませんが、少なくとも Firefox は不注意な実装だったのは事実ですね。
Session Ticket は Webサーバが送った ticket をブラウザが次回接続時に返してくれるので、トラッキングに使えるのでは？ (https://svs.informatik.uni-hamburg.de/publicatio
Re: (スコア:0)
関連ストーリー [security.srad.jp]より
警戒するとしたら名前解決に相互運用性のない独自プロトコルを導入して囲い込みを図ろうとすることだろう
Re:Google/Cloudflare/IBM に情報を握られる (スコア:1)
DNS の囲い込みが問題あることは正しいですね。更なる問題は、 DNS over HTTPS のクライアントに直接ネットワーク管理者が DNS サーバの在り処を伝える手段が現時点では存在しないことです。 Chrome も MS と同じような方法を取るようですが、事前に「うちの ISP の DNS サーバはこれです」という情報をブラウザに登録しないといけません。 その登録作業を一体何社に 対してすれば良いのでしょう。 Firefox に至ってはそのような仕組みがありません。 Mozilla が決めた「trusted」なサーバか、自分で about:config を編集するしかありません。そもそも DNS over HTTPS 推進者の言い分が「ISP による不当なブロッキングや捻じ曲げを回避する」なので、特定の(彼らにとって信頼できる) DNS サーバに集中させる方向になるとしか思えません。
情報の補足 (スコア:1)
Mozilla が決めた「trusted」なサーバか、自分で about:config を編集するしかありません。
この情報はちょっと古いですね。
最近だと設定画面(about:preferences)で任意のURLをDoHのサーバーとして追加できるようになっています。
Firefox Nightlyでしか確認していないのでRelease版に実装されているのかは分かりませんが、それほど厳重なテストが必要な機能でもないので、仮に実装されていないとしても数か月でReleaseに降りてくると思いますよ。
Re: (スコア:0)
情報ありがとうございます。 76.0.1 ではまだですね。
about:config や about:preferences で追加できたとしても、現時点では DHCP で配るようにはいかず、 Mozilla が決めた「trusted」なサーバに囲い込まれやすいことには変わりないかと思います。
Re: (スコア:0)
> その登録作業を一体何社に 対してすれば良いのでしょう
難しくてわからないのですが、記事中のMSのブログは、設定手順でコントロールパネルか設定アプリで対応サーバーを指定するとあります。
ご家庭のパソコンなら、明示的に設定しないかぎりはレンタルされたモデムとDHCPを経由してISPのDNSサーバーになると思ったのですが、間違ってますでしょうか。
Re: (スコア:0)
念のためもう一度書きますと、「DNS over HTTPS のクライアントに直接ネットワーク管理者が DNS サーバの在り処を伝える手段が現時点では存在しない」のが問題です。現状ではごく少数の DNS over HTTPS サーバに囲い込まれることになります。
MS の実装は、レジストリに「DNS (over 53) のIPアドレス」と「DNS over HTTPS サーバ の URL」のマップを持っています。
プライマリ/セカンダリ DNS サーバとしてマップにマッチするエントリがあれば、そのエントリを利用して DNS over HTTPS するという仕掛けです。ですので、利用者が DHCP で指定されたアド
Re: (スコア:0)
> 「DNS over HTTPS サーバ の URL」のマップを持っています
ここ理解できてなかった。解説ありがとう。
証明書検証をしたいけど、マップに証明書の情報自体を入れるわけでもないみたいね。
ISPがDoHをやろうとするなら、DoHクライアントの作りを改修して、
・IPはDHCPの配布した値は特別扱い
・ホスト名はdohdns.comとかを特別扱い(現状でもルーターなどが独自のホスト名を名乗ることがある)
・パスは/dns-query決め打ち
にすれば行けることは行けると思う。
> DHCP サーバで指定された DNS サーバは 192.168.11.1 などモデムの LAN 側 IP アドレスです
これはモデムがルーターを兼ねてる場合だから、必ずしもそうじゃないはず。
単機能のモデムなんて今時ないかもしれないけど。
レンタルしてるのがモデム兼ルーターなら、モデム兼ルーター前提の対処ができることにもなる。
長々と書いたけど、ISPがやるほどの話じゃなさそうだね。
DNS over HTTPS(DoHc) (スコア:0)
ついにDNSもHTTPs化になるのかぁ
よりルートサーバは負荷があがりそうですな
Re:DNS over HTTPS(DoHc) (スコア:1)
DoHは今のところクライアントとキャッシュサーバー間の通信に使う規格で、ルートサーバー等の権威サーバーには関係ない
Re: (スコア:0)
なんでルートサーバの負荷が上がるの？
Re: (スコア:0)
指定されているDNS over HTTPS(DoH)対応のPublic DNSの負荷が上がるだけです。
Re: (スコア:0)
もしかして、「ルート」とは root (the domain name space の) ではなく route を指していますか？