公開DNSリゾルバー選択ガイド

 (evilbit.de)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • 公開DNSリゾルバーは単純な速度よりも、プライバシー保護、フィルタリング、管轄、運営主体、暗号化転送をあわせて見る必要があり、このガイドでは30のグローバルサービスを要件別に比較する
  • 選択ツールは DoH・DoT・DoQ・DNSCrypt、DNSSEC検証、IPv6、管轄、運営者の種類、EDNS Client Subnet をハードフィルターとして使い、目的別の優先順位をスコア化する
  • ブラウザベースの DoHレイテンシテスト は現在地での相対的な速度を示すが、TLS/HTTPオーバーヘッドが含まれ、平文DNS専用リゾルバーは測定できない
  • 暗号化DNSは中間者による盗聴・改ざんを減らすが、選択した リゾルバー提供者 は問い合わせドメインを見られるため、ノーログ方針や oblivious 設計まで考慮する必要がある
  • 実務での選定では DNSSEC、ECS の速度とプライバシーのトレードオフ、DoQ の性能、DNSCrypt の特性、トラフィック分析の限界、標準準拠の違い、管轄と集中化リスクをあわせて検討する必要がある

選択ツールが比較する基準

  • 公開DNSリゾルバーは、ユーザーが重視する条件をチェックして見つける方式で比較する
  • ハードフィルター として使われる条件
    • 暗号化転送: DNS-over-HTTPS(DoH), DNS-over-TLS(DoT), DNS-over-QUIC(DoQ), DNSCrypt
    • DNSSEC検証のサポート
    • IPv6リゾルバーアドレスの提供
    • 運営者の管轄
    • 運営者の種類: 非営利・コミュニティ・公益、商用、すべて
    • EDNS Client Subnet(ECS): 使用しない、使用する、どちらでもよい
  • 優先順位のスコア化 に入る項目
    • 最大限のプライバシー保護とノーログまたは最小限のログ
    • マルウェア・フィッシングのブロック
    • 広告・トラッカーのブロック
    • ペアレンタルコントロールとアダルトコンテンツのブロック
    • 公開されたDNS応答をそのまま返す無フィルタリング
    • アカウントによるユーザー指定のブロックリスト・ルール
    • グローバルAnycastベースの低レイテンシ性能
    • 非商用の運営者

現在地基準のDoH速度テスト

  • 内蔵テストはブラウザで各 DoH対応リゾルバー までの往復時間を測定する
  • 平文DNSのみ対応するリゾルバーはこの方式ではテストできない
  • 結果は相対的な参考値であり、TLS と HTTP のオーバーヘッドが含まれるため、複数回実行することが前提となる
  • ブラウザが各リゾルバーに直接問い合わせるため、ユーザーの IPアドレスがそのリゾルバーに露出 する
  • テスト実装は Silviu Stroe のオープンソース DNS Speed Test から着想を得ているが独立実装であり、ページが HTTPS で提供される場合にのみ実行される

性能と暗号化転送の違い

  • DoH と DoT のような暗号化転送は問い合わせごとのレイテンシを追加するが、ページ全体の読み込み時間は平文DNSに近いことが多く、DoH のオーバーヘッドも実環境では小さい傾向にある
  • 損失がある、またはレイテンシが高いリンクでは、平文の Do53 が依然として有利である
  • 性能は提供者と地域によって変わるため、最速のリゾルバーはユーザーの位置に左右される
  • 暗号化DNSの大規模なエンドツーエンド測定では、平文DNSに比べて問い合わせが転送中に傍受・改変される可能性ははるかに低く、オーバーヘッドも小さかった
  • ただしその研究では DoT 提供者の約 25%が無効なTLS証明書 を提供していたため、運用品質の高い提供者を選ぶことが重要である

プライバシーの実際の限界

  • 暗号化DNSはネットワーク上で問い合わせを隠すが、選択した リゾルバー提供者 は参照したすべてのドメインを見られる
  • これが問題なら、ノーログの運営者を選ぶか、プロキシが身元と問い合わせを分離する ODoH のような oblivious 設計を検討すべきである
  • Cloudflare と Apple は ODoH を導入した事例である
  • 暗号化DNSだけで訪問サイトが完全に隠れるわけではない
    • DoH を使っても、トラフィック分析によって訪問ドメインを高い精度で識別できる
    • 標準の EDNS パディングでもこれを完全には防げない
    • この脅威モデルが当てはまるなら、パディングだけに依存せず、Tor や oblivious 設計をあわせて使うべきである

DNSSEC、ECS、管轄

  • DNSSEC検証 を行うリゾルバーだけが偽造レコードから保護する
  • Google、Cloudflare、Quad9 は DNSSEC を検証し、最初のルート鍵 KSK ロールオーバーをユーザー障害なしで処理した
  • 完全性が重要なら、DNSSEC検証を必須条件と見るべきである
  • EDNS Client Subnet(ECS) は、より良い地理的ルーティングのために IP の一部を CDN に送る
    • Google と OpenDNS はより精密な CDN マッピングのために ECS を送る
    • Cloudflare と標準の Quad9 はプライバシーのために ECS を無効化している
  • 運営者の法的所在地は、強制可能な措置やログに影響する
  • 少数の提供者が世界の再帰DNSトラフィックの大きな割合を処理している
  • 米国 NSA は外部リゾルバーが内部DNSフィルタリングや検査を回避すると警告しているため、利便性と統制のバランスを考える必要がある

DoQとDNSCrypt

  • 2022年の DoQ 測定では、DNS-over-QUIC が応答時間で DoT と DoH の両方を上回った
  • ただし QUIC のアドレス検証制限のため、ハンドシェイクの約 40%が遅くなった
  • クライアントとリゾルバーの両方が対応していれば、DoQ は優先される暗号化オプションである
    • 対応例: Quad9, AdGuard, NextDNS, Control D, Mullvad, UncensoredDNS, 中国の主要サービス
  • DNSCrypt は DoH、DoT、DoQ より古い暗号化オプションで、バージョン2は2013年に登場した
  • DNSCrypt はリゾルバーの事前共有公開鍵で最初のパケットから暗号化するため、平文のホスト名参照や認証局への依存がない
  • 2019年の Anonymized DNS モードではクライアントIPも隠せる
  • 比較対象のうち DNSCrypt 提供者は Quad9, OpenDNS, AdGuard, NextDNS, Control D, Yandex である
  • 信頼できる利用量の数値は不足しており、APNIC Labs のような大規模測定は DoH と DoT を追跡しているが DNSCrypt は追跡していない

リゾルバー実装品質と運用データ

  • 2023年の Extended DNS Errors 研究では、主要リゾルバーの診断エラー報告はテストケースの 94%で不一致 だった
  • Cloudflare はその研究で最も精密なエラー報告を示した
  • リゾルバーごとの実装品質と標準準拠の違いは、問題解決と信頼性に影響する
  • 参考にできる運用・コミュニティデータ

小規模・コミュニティ・地域リゾルバー

  • 比較表の外にも、ホビー、コミュニティ、国別特化のリゾルバーがあり、利用前に現在の状況とポリシーを確認する必要がある
  • 欧州の項目は European Alternatives にまとめられている
  • 強い検閲や制裁がある地域のリゾルバーは、現地のコンテンツ規則を適用したり、地理的ブロック回避のために運営されていたりする可能性があるため、より慎重な確認が必要である
  • 例示サービス
    • DNS4all: 中立性と性能を重視する欧州の無フィルターリゾルバー
    • BlahDNS: 小規模な地域サーバーで運営されるオープンソースのホビー広告ブロックプロジェクト、DoH・DoT・DoQ 対応
    • LibreDNS: LibreOps のコミュニティリゾルバー、広告ブロックとノーログ方針、DoH・DoT 対応
    • Dismail.de: プライバシー重視のドイツのコミュニティリゾルバー、ノーログ、DoH・DoT 対応
    • IIJ Public DNS: Internet Initiative Japan の公開 DoH・DoT リゾルバー、児童性的虐待コンテンツのドメインをブロック
    • DNS for Family: アダルト、ギャンブル、マルウェア、広告・トラッカー、セーフサーチを含むファミリーフィルタリング DoH
  • 避けるべきレガシーまたは終了サービスとして Oracle Dyn、Level3(4.2.2.x)、Freenom World、dns0.eu、Norton ConnectSafe が挙げられている

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker News の意見

  • こういうリストや新サービスの発表を見るたびに、あまり感銘を受けない。Hacker News でも意外と似た反応が多いように見える
    25年近く自分で プロキシ DNS サービスを運用してきて、3種類のソフトウェア一式を6つの OS で使ってみたが、フィルタータブにある項目はすべて自分でできるし、実際にやっている
    このリストは、選択肢が興味深いというより、そこから見えてくる点が興味深い。例えば「China」と表示された項目はすべて「中国の規制下で運用」となっているが、2026年には中国の項目だけでなく、自分の大陸のユーザーにとっても気になる要素だ
    「デンマークの個人1人が運営」という文言は バスファクターを示す興味深い情報だが、他の項目がその点に触れていないからといって、より良いと仮定することはできない。DNS.Watch の背後に誰がいるのかについては Thomas Steen Rasmussen よりはるかに情報が少なく、ここ数年で少なくとも一度は落ちたようなので、正当な懸念だ
    Quad101 には利用可能地域の制限があるように見えるし、Gcore が AI 企業であることなど、このリストには載っていないがユーザーにとって重要になり得る要素も多い

    • 「デンマークの個人1人が運営」というのは、バスファクターよりも 組織的な監視という観点でより興味深い
      運用に複数人が関わっていれば互いに監視し合い、DNS リゾルバーが選択的にログを取ったり、結果に介入したりといったおかしなことが見えたときに問題提起できる。1人がすべて運用しているなら、その人を止める人はいない
      「その人は信念のある人だから絶対にそんなことはしない」と考えることもできるが、法執行機関からの圧力は強力になり得る
    • 2年ほど前に自分で リゾルバーを構成したが、普通にうまく動いている。一度も問題はなかった

  • ISP の公式 DNS を使えば、ISP のハンドオフ地点から CDN や海外トランクまで、可能な 最短経路を得られる。ISP の構造を知らない汎用 DNS は使うな、という話だ
    ISP: Cloudflare まで 1ms
    Cloudflare: Cloudflare まで 10ms
    ただし、この助言はプライバシー法が良く、国家監視がない国に当てはまる。つまり米国ではない

    • 検閲のない DNS が必要なら、その方法はよくない
    • 実際には 広告サーバーをブロックする DNSを使うほうが、全体的な性能は良くなる可能性が高い
    • そういう国が今も実際に存在するのか分からない。それにこれはプライバシーだけの問題ではなく、ほとんどすべての国はユーザーにアクセスしてほしくない場所へアクセスできないようにしようとする。そして多くの場合、ISP のデフォルト DNS が本来開こうとしていたサイトの代わりに警告ページへ送るという雑なやり方だ
      だから 8.8.8.8 のような DNS に変えることは、プライバシーを必ず高めるわけではないとしても、ブラウジング体験の改善に向けた最初の大きな一歩になる
    • Cloudflare はよく知られているように エニーキャストを使っているため、どこから来ても DNS 応答は同じだ。提示された数字が DNS のせいだとは考えにくい
      むしろ Cloudflare は自社サービスについて再帰問い合わせを短縮できるので、名前解決の段階で速くなり得るし、必要なら eDNS Client Subnet で位置ベースのルーティングも可能だ
    • DNS を変えてもプライバシーにはほとんど効果がない。依然として DNS クエリと SNIを読めるからだ

  • 公共 Wi-Fi で DNS リゾルバーを併用する方法について助言が必要だ
    多くの公共 Wi-Fi は、利用規約の同意画面へリダイレクトするために独自 DNS を使わせる必要があり、30〜60分ごとに再承認を求めることもある
    問題が起きると、インターネットが止まったことに気づき、google.com に ping を投げてタイムアウトを待ち、ISP の問題かと推測し、Wi-Fi セッションが期限切れになったらしいと気づき、DNS を変更してキャッシュを空にし、TLS ではないドメインにアクセスし、ゲートを承認して、また DNS を戻さなければならない
    こういうことを管理してくれる何かが、きっとあるはずだ

    • macOS なら /etc/resolver で解決できるかもしれない
      sudo sh -c 'echo "nameserver 192.168.1.1" > /etc/resolver/captive.apple.com'
      大学内のサイトがネットワークのネームサーバーでしか解決できないときに、この方法を使った。macOS が キャプティブポータル検出に使う URL にも適用できるのではないかと思い、次にカフェへ行ったら確認してみるつもりだ
    • macOS と iOS では、常に使う DNS サーバーを指定する プロファイルを作成できる。他の Wi-Fi やモバイルデータ通信にも適用される
      https://doh.lvv.me/
      何年もこれを使っていて、公共ホットスポットで問題に遭ったことはない
    • アドレスバーに単に IP アドレスを入れればよい。たいていは 80番ポートのトラフィックをすべて横取りしている
    • こういうものは OS が キャプティブポータル対応の一部として処理すべきだ。OS メーカーに連絡してバグを登録するのがよさそうだ

  • ローカルで Unbound を DoH サーバーとして使っている。Alpine Linux の Unbound パッケージは、内蔵 DoH リスナーに必要な libnghttp2 と一緒にコンパイルされていて、これで ECH を有効にするには十分。
    毎時 cron で、よく使うすべてのドメインを事前にキャッシュしている。ISP が自分の DNS リクエストをいじることはないだろうし、その社員たちは自分よりもっと変な人たちだ。携帯電話でウェブを見始めるなら、自分で公開 DoH サーバーを作るつもり。数分で済むし、変な問題をデバッグするときに自分の クエリログも手に入る。
    [1] - https://tls-ech.dev/

    • 約3年前から、自前の公開 powerdns、dnsdist、再帰/権威サーバーのインスタンスで DoH、DoT、DoQ、TCP、UDP を運用している。
      以前は bind、unbound、dnsmasq を使っていたので、設定には少し時間がかかった。非常に安定していて、モバイルや古い機器でも使え、unbound、adguard/dnsproxy、ローカルの resolve.conf のリゾルバーとしても利用できる。
    • なぜ事前にキャッシュするのか気になる。速度のためだとしても、せいぜい 30〜50ms では？権威サーバーの TTL が60分より短い場合、3600 に強制しているのかも気になる。
      訪問するすべてのウェブサイトの接続を監査して、アセットをホストしているドメインまで集めて全部事前キャッシュしているのか、それとも体感遅延に最も大きく影響するメインサイトのドメインだけが重要なのかも気になる。
    • Unbound には、期限切れが近いキャッシュレコードを更新する prefetch があり、キャッシュと TTL に関する調整オプションもいくつかある。serve-expired もうまく動いているようだった。
    • 「毎時 cron で、よく使うすべてのドメインを事前にキャッシュする」というのが、どんな形なのか気になる。ホスト名一覧を問い合わせるシェルスクリプトなのか、そして「使うドメイン」の基準が何なのか気になる。
    • こちらでも Unbound を動かしている。ドメインブロックに ワイルドカードを使える点が良い。大きなブロックリストを使い、その上に例外の許可リストを置いている。
      ayt7.ads.acme.com、afi6.ads.acme.com、foi5.ads.acme.com のような入力を ads.acme.com に単純化する小さなツールもある。
      さらに、使っているドメインの変種を生成するスクリプトも置いている。たとえば正規のドメインが mybank.com なら、myb4nk.com、mibank.com、mybank.{その他すべてのTLD} などをブロックする。
      こうした変種を何十万個も生成して、すべて Unbound でブロックしている。銀行から非常に本物らしいフィッシングサイトの例が送られてきた後、こうするようにした。
      数年にわたってこの構成を使っており、100万件のブロックドメインでも古い Pi 3 で問題なく動く。もっと強力なコンピューターなら、Unbound は数百万、もしかすると数千万ドメインのブロックリストも処理できるはず。まだ許可リスト専用方式には移行していない。
      Unicode ドメインもすべてブロックしている。名前に Unicode 文字を使うドメインにはアクセスできないが、気にしていない。

  • NextDNS を満足して使っている。どのフィルターリストを有効にするか、ロギングをどうするかなど、設定の自由度が高い。
    ほぼどこでも安定していて速い。クラウドで自前のリゾルバーを運用すると達成はより難しいし、そもそもメンテナンスしたくない。

    • 自分も NextDNS をうまく使っている。特に Pi-hole を何年かいじった後、メンテナンスに疲れてからは、より満足している。必要なときに Mullvad VPN とも簡単に併用できる。
    • 自分にとってもかなり良かった。

  • なぜ29個だけなのか分からない。
    筆者は、今日のインターネット上にあるオープンリゾルバーの実際の数がこの程度だと言っているのだろうか。
    DNS の「プライバシー」や「セキュリティ」を考えるのに、どうして SNI を一緒に考慮しないでいられるのか疑問だ。
    SNI は、ユーザーがどのドメイン名で公開アドレスへ接続しようとしているかを第三者に見せ、その接続を妨害することも可能にする。
    DNS は、ユーザーがどのドメイン名の公開アドレスを照会しているかだけを第三者に見せる。DNS 以外のトラフィックをこのクエリと結びつけるには、そのソフトウェアがどう動作するかについての仮定が必要になる。
    だから、人気ウェブブラウザーを支配する広告会社が、ユーザーにブラウザー内、あるいは企業向け OS で DoH を選ばせたがるのは驚くことではない。これを欺瞞的に「private DNS」と呼べば、第三者はブラウザーや企業向け OS で実行されるソフトウェアの非 DNS トラフィックとクエリを、より効果的に相関分析できる。
    こうした欺瞞的な主張のせいで訴訟を起こされる可能性もある。たとえば「private browsing」に関する欺瞞的な主張では、ユーザーが訴訟で勝ったことがある。

    • その29個は、多くの人が DNS クエリを任せてもよいとある程度信頼しているサービス、という意味だ。また、その29個はサービス属性に関する情報を公開している。
      ページ全体を読むと、言及に値する他の公開 DNS リゾルバーも別に列挙されている。
      知名度の低いロングテールのオープン DNS リゾルバーは Shodan を使えばよい。ただし、Shodan で見つけたものにインターネット利用を任せるほど信頼することは勧めたくない。
      SNI が一般的なインターネットのプライバシー問題であるのは確かだが、DNS の属性ではない。前向きに見れば、ECH は IETF を通過しており、一般ユーザーにもゆっくり提供されていくはずだ。
      — 筆者
    • ECH は、いくつかの「テスト」サイトを除けば、一般のウェブユーザーに広く提供されていない。
      筆者の回答にある “you” が誰を指しているのかも明確ではない。
      自分の場合、リモート DNS は大量の DNS データを定期的に取得するときだけ使う。HTTP サーバーにアクセスするときは、リモート DNS リクエストを行わない。必要な IP アドレス情報はすでに持っていて、この方式のほうが速く安定している。
      複数のソースから得た 大量 DNS データを、ローカル TLS フォワードプロキシのメモリに読み込んでいる。
      ユーザーは皆それぞれ違うので、各自で考えるべきだ。

  • カナダのユーザーなら、CIRA が IPv4、IPv6、DoH、DoT 経由の 公開リゾルバーを運用している。
    https://www.cira.ca/en/canadian-shield/configure/summary-cir...

    • カナダ人が、なぜ他の選択肢より CIRA を信頼すべきなのか分からない。それでも、デフォルトの ISP DNS を使うよりはましである可能性が高い。

  • DNScryptProxy は公開 DNS サーバーの膨大なリストを維持している。DNSSEC、フィルタリング、ロギングの対応有無も表示している
    https://download.dnscrypt.info/dnscrypt-resolvers/v3/public-...

  • こうしたサイトが、ローカルネットワーク基準の基本的な速度比較テストを提供してくれるとよさそう
    ランダムなクエリに対する P90 応答時間と中央値の応答時間を比較できるとよいと思う

    • 作者だが、いま追加した: https://evilbit.de/dns-resolver-guide2.html#speedtest
      ただし DoH でのみ動作する
    • このリポジトリをクローンして、ドメイン名とリゾルバを好きなように変更すれば、探しているものに近い結果が得られる
      [1] - https://github.com/cleanbrowsing/dnsperftest
    • この用途でローカルに smokeping インスタンスを動かしている。複数の DNS サーバーと ISP DNS、主要なウェブサイト数カ所に ping を送り、その結果に合わせてローカル DNS サーバーの upstream を定期的に更新している
      私の環境では、大手 DNS サーバーはいずれも 5〜6ms の範囲だが、常にそうだったわけではない。ISP DNS も平均は似ているが分散が大きく、50ms まで跳ねるスパイクがある。本来なら最も速いはずの場所なのにそうなっている

  • DNS はプライバシーとセキュリティにとって非常に重要なテーマだ。公開 DNS を選ぶより、自前のインフラをホストするほうがよいと思う
    公開インスタンスは必要ない。ルーターやマシン上で ADGUARD、unbound、dnsmasq、dnsdist を再帰モードで動かせばよい
    必要に応じて制限やブロックリストも設定できる

    • それでも ISP はすべてのクエリを記録できる