DNSブロッキングを再考する – SAC127

今回はSSAC（Security and Stability Advisory Committee）が2025年5月に公開した文書「SAC127 DNS Blocking Revisited」をご紹介します。

SSACではこれまで、SAC050およびSAC056でブロッキングに関する技術的考察と勧告を行ってきました。発行から10年以上が経過したこれらの文書に対して、現在の状況を合わせて「再考」したのが今回のSAC127です。

本文書は全体で42ページあるため、本稿ではまず結論である勧告を示し、それに対する説明や背景を本文書から抜き出して示すことにします。

原則と前提

その前に、主に第3章で触れられている、DNSブロッキングの実施検討における原則と前提について解説します。

「primum non nocere (まず害を及ぼさない)」の原則を適用する

SAC050 が医療における “first, do no harm” をインターネット技術に適用すべきと提唱したように、DNS ブロッキングでも「害を最小化する」姿勢が不可欠です。ブロッキングは、対象外のユーザやサービスに二次的影響 (ユーザ混乱、オーバーブロッキングなど) を及ぼすおそれがあります。技術的評価、テスト環境での検証、影響範囲のシミュレーションなどを通じ、事前に「害を及ぼさない」設計・運用を徹底すべきです (第3.2節)。

ブロッキングはユーザを「無効化」に誘導するリスク

DNS ブロッキングでTLS名称不一致エラー等が発生すると、ユーザはブラウザの「続行」操作を学習し、将来的に正当な証明書エラーも無視する行動を助長します。これにより、本来警告を受けるべきマルウェア感染サイトへの誘導や、中間者攻撃への耐性低下が懸念されます (第3.3節)。

回避手段は可視性と監査機能を損なう

ユーザがVPN/DoHなど回避技術を使うと、ISPやネットワーク管理者はDNS解析情報を得られず、DDoSや感染ホストの検知・対処、サービス品質管理が困難になります。結果として、ネットワーク全体のセキュリティ運用が弱体化するおそれがあります (第3.4節)。

開示と透明性の重要性

DNSブロッキングを実施している事実やブロック対象リストを公開しないと、ユーザやトラブル対応担当者は事象を「サイトダウン」や「誤設定」と誤認し、原因追究に無駄な工数を費やします。必要に応じて「どのドメインを、なぜ、どの方式でブロックしているか」を明示し、問い合わせ・是正手続きを整備すると運用負荷を軽減できます (第3.5節)。

ブロッキング状況の検出と測定

Open Observatory of Network Interference (OONI) などのプローブで実測データを収集し、「どこで、どのドメインが、どの程度」遮断されているかを定量的に把握すべきです。測定結果はポリシー見直しや影響範囲の確認にも活用可能で、運用のエビデンス基盤として重要です (第3.6節)。

これらの前提にたって、勧告を見ていきます。

勧告

本文書では最終的に3件の勧告を行っています。

1. DNSブロッキングを実装または義務付けするすべての主体が、この技術の影響を理解することを推奨する。
2. すべての主体 (政府やポリシー・法律・ネットワーク上の運用管理を行う組織) によるDNSブロッキング実装は、以下のガイドラインに従うことを推奨する。
   1. 当該主体は、DNSブロッキングによりその目的を達成できるかどうかを判断する必要がある。
   2. 当該主体は、リスクを最小限に抑えるために、十分なレビューおよび意思決定プロセスを備え、ブロッキングする内容と方法について明確なポリシーを持つ必要がある。
   3. 当該主体は、オーバーブロッキングやユーザに与える巻き添え被害を最小限に抑える技術を使用して、ポリシーを実装する必要がある。
   4. 当該主体は、管轄外のネットワークまたはユーザに影響を与えてはならない。
3. リカーシブサーバの運営者は、EDE (Extended DNS Error) を使用してエンドユーザとトラブルシューティング担当者にDNSブロッキングが行われていると示すことを推奨する。

以下、それぞれの勧告について解説していきます。

勧告1

「DNSブロッキングを実装または義務付けするすべての主体が、この技術の影響を理解することを推奨する。」

ここでいう「すべての主体」とは、DNS ブロッキングを実装または義務付けるあらゆる組織を指します。具体的には、国家や行政機関・司法機関といった政府当局、法院の差止命令を執行する法執行機関、ドメイン登録を管理するレジストリ・レジストラ、教育機関や企業内ネットワークのポリシー管理者、ISP や公共リゾルバ運営者など、ネットワークやサービスに対してポリシー的・法的・運用的なコントロールを有するすべての主体が含まれます (第7章)。

具体的にどのように理解するべきかというと、実装や義務付けを行う主体は、DNS ブロッキングの技術的影響を多角的に把握しなければなりません。たとえば、オーバーブロッキングや管轄外ユーザへの影響、ユーザがセキュリティ警告を無視する行動を誘発するリスク、別リゾルバ利用やVPN/DoH/DoTによる回避手段、運用コストなどをそれぞれ評価し、政策決定や実装方針に反映させる必要があります(第1章)。

勧告2

「すべての主体 (政府やポリシー・法律・ネットワーク上の運用管理を行う組織) によるDNSブロッキング実装は、以下のガイドラインに従うことを推奨する。」

あらためて、どのような主体が対象となっているかを整理します。

• 政府: 国家の行政機関や立法・司法機関を含み、法令や裁判所命令に基づいてDNS ブロッキングを命じる組織。たとえば本文書内で触れられている過去の事例においては中国の「金盾(Great Firewall)」、スイス連邦最高裁のオンラインギャンブル遮断、ブラジル最高裁のXサービス遮断命令などが該当します (第2.3節)。
• ポリシーの運用管理を行う組織: レジストリ・レジストラや企業・学校のネットワーク管理者。組織内のアクセス制御ポリシーに基づき、教育機関の有害サイト遮断や企業のSNS制限などを実装します (第2.2節)。
• 法律の運用管理を行う組織: 裁判所・検察などの法執行機関。知財権侵害や違法コンテンツへの差止命令を根拠に、ISPやリゾルバに対しドメイン遮断を義務付ける主体です (第2.3節)。 
• ネットワーク上の運用管理を行う組織: ISP、いわゆるパブリックリゾルバ (Cloudflare, Quad9等)、リカーシブサーバ運営者など、DNSクエリのフィルタリングやブロックリスト運用を技術的に実装する組織です (第4.1節)。

この勧告ではAからDの4つのガイドラインを示しています。

勧告2A

「当該主体は、DNSブロッキングによりその目的を達成できるかどうかを判断する必要がある。」

ここでは、当該主体が達成したい目標 (例: マルウェア拡散防止、著作権侵害防止、未成年保護など) を明確化し、DNS ブロッキングがそれらの目的に対して技術的に機能するかを検証するプロセスを示しています(第7章)。

適切な手段である、というのは、目標をどれだけ阻止できるか (到達阻止率)、目標ドメインのみを選択的にブロックできるか、他のドメインやサービスに影響を与えずに実装できるか、ブロックによる利益と損失の相対評価、および絶対的に耐え難い被害の有無といった複数の評価軸で判断することを指します (第3.1節)。

勧告2B

「当該主体は、リスクを最小限に抑えるために、十分なレビューおよび意思決定プロセスを備え、ブロッキングする内容と方法について明確なポリシーを持つ必要がある。」

十分なレビューとは、過去の事例や影響範囲を含む技術的分析、誤検出 (false positive) やオーバーブロッキングのリスク評価を行い、ground truth リストとの突合やシミュレーションテストを通じて安全性を担保するプロセスを指します (第3.2節)。

十分な意思決定プロセスとは関係者による多層的な承認フロー、透明性のある文書化、意思決定基準と責任分担を定義し、変更時のレビューや異議申立手続きを含む統制されたワークフローを指します (第3.2節)。

明確なポリシーとはブロック対象ドメインの定義、使用技術 (NXDOMAIN, リダイレクト等)、更新頻度、誤検出時の是正手順、影響モニタリング方法を文書化したものを指します (第3.2節)。

ポリシーの中には「何をブロックするか」「どのようにブロックするか」が含まれている必要があります。ポリシーには定期レビューと誤検出対応フロー、および影響範囲の継続的モニタリングが実装されていなければなりません (第3.2節)。

勧告2C

「当該主体は、オーバーブロッキングやユーザに与える巻き添え被害を最小限に抑える技術を使用して、ポリシーを実装する必要がある。」

オーバーブロッキングとは、意図した対象以外のドメインやサブドメイン、サービスまで誤って遮断する現象を指します。たとえば、第三レベルのみ遮断すべき example.tld サブドメインを第二レベルでブロックし、合法的なサービスまで影響を及ぼすケースがあります (第3.2節)。

巻き添え被害とは、ブロック範囲外のユーザや他のサービス利用者が不利益を被ることを指します。たとえば、公共のリゾルバ利用者、オフショアのユーザ、あるいは他ネットワークのコンテンツ配信が阻害されるケースがあります (第3.2節)。

このような被害を抑えるため、精密なサブドメイン単位のフィルター適用、誤検出検証機構、および影響範囲モニタリングを併用する技術的対策が推奨されます (第3.2節)。　

勧告2D

「当該主体は、管轄外のネットワークまたはユーザに影響を与えてはならない。」

当たり前のように思えるかもしれませんが、過去にはブロッキングの目的を達成するために政府が管轄外のネットワークに影響を与えてしまった事例があります。イタリアの Piracy Shield では、音楽海賊版サイト遮断命令の誤動作により drive.usercontent.google.com が数時間ブロックされ、Google Drive や YouTube が利用不能になりました (第3.2.1節)。

インターネットは自律分散システムですから、自ら管理するネットワークにのみ影響を限定し、他者のトラフィックに不必要に介入しない設計が求められます (第3.1節)。

勧告3

「リカーシブサーバの運営者は、EDEを使用してエンドユーザとトラブルシューティング担当者にDNSブロッキングが行われていると示すことを推奨する。」

これまでの勧告は実装する主体を対象としていましたが、この勧告では実務的にDNSブロッキングを行うリカーシブサーバの運営者を対象としています。

EDE (Extended DNS Error) とは、本文書の第6.6節で解説されていますが、DNSのサーバがクライアントに対してエラーを返すときに、そのエラーが出た理由をEDNSのオプションとして送信できる仕様です。RFCで標準化されており、主要なパブリックリゾルバやオープンソース DNS ソフトウェアで実装されています。

この EDE コードの定義の中にはコード16「Censored」というものがあります。実際に Google Public DNS (8.8.8.8) では、REFUSED レスポンスに Extended DNS Error コード 16 (Censored) を付与して返す実装を行っています (第6.6節)。 

ブロッキングの回避技術

最後に、一般にDNSブロッキングの議論で行われる「DNSブロッキングを実施しても容易に回避されるため意味がない」といった主張について、どのような回避技術がありどのように評価されているのかについて簡単にまとめます。この内容は本文書の第5章にまとめられています。

リゾルバの切り替え

エンドユーザは通常、ISP等から指定されたリゾルバ (リカーシブサーバ) を使用しますが、自身で別のリゾルバを指定して使用することもできます。たとえば、いわゆるパブリックリゾルバと呼ばれる、Google/Cloudflare/Quad9等の事業者が提供する公開されたリゾルバが使用できるほか、知識があればリゾルバはユーザ自身で運用することも可能です。DNSブロッキングでは通常リゾルバで制御を行うため、制御の行われていない別のリゾルバを使用することでブロッキングを回避できます。この設定は多くのデバイスで、OSの設定画面からエンドユーザが容易に行うことができます。ただし、ネットワーク管理者がトラフィックをIPパケットやTLS SNIのレベルで監視している場合はこの方法では100%回避できません。

また、いわゆるDoXとよばれる、DNS over HTTPS、DNS over TLS、DNS over QUICなどで別のリゾルバにクエリすることで、DNSクエリ自体を暗号化することができます。この場合は、ネットワーク管理者はどのようなクエリを行っているか監視できなくなります。

VPN

VPNを使用することで、VPNの中もしくは先にある別のリゾルバを使用することができます。また、VPNでトラフィックを暗号化することで、手元のネットワーク管理者がトラフィックを検閲している場合でもIPパケットレベルでは中身を知られないようにすることができます。検閲側でVPNトラフィックをすべて遮断してしまうことで使用できなくなりますが、VPNは必ずしもブロッキング回避のためだけに使われる技術ではなく、オーバーブロッキングを引き起こす可能性があります。

匿名化・難読化ツール

TorやPsiphonなどの技術を使用しすべてのパケットを暗号化することで、よりネットワーク管理者による検閲を回避しやすくなります。

ただし、これらを使用すると遅延の増大などパフォーマンスの低下を引き起こす場合があります。Torの場合は特定のノードへの通信を検閲側ですべて遮断することは可能ですが、Psiphon等の場合は分散型プロキシであるため、100%通信を遮断することは難しくなります。

分散システム

IPFSなどのP2P分散型ホスティングシステムはDNSを使用せずコンテンツにアクセスできることから、DNSブロッキングの対象になりません。IPFSに限らず、分散システムとしての設計を強く持ったプロトコルではブロッキングが効果的に実施できないことがあります。実際に2017年にトルコ政府がWikipediaをブロッキングした際にはIPFSでミラーが公開されたケースがあります。

DNSSEC制御

DNSSEC署名が行われているドメイン名についてDNSブロッキングを行うと署名検証が失敗します。また、検閲側が偽の署名応答を行うことも容易ではありません。このため、偽の応答を返すことでDNSブロッキングする場合は署名検証に失敗し、名前解決が停止します。これはユーザやネットワーク運用者の観点では障害として見えることがあります。一方で、昨今ではDNSSECを前提に迂回・弱体化させるミドルボックスが存在していることも知られています。

本稿では、まずブロッキングの原則と前提について理解した後、勧告1の技術的影響理解を通じてDNSブロッキングの有効性と限界を把握し、次に勧告2A – 2D の目的妥当性検証、リスク最小化策、オーバーブロッキング緩和、管轄外影響回避という4つのガイドラインに沿った評価とポリシー策定を示し、最後に勧告3でEDEを用いた通知実装による透明性向上とトラブルシューティング支援を提案しているという構図で整理しました。これら3 件の勧告は、DNSブロッキングを運用・政策に組み込む際の羅針盤として、リスクを最小化しつつ機能を最大化するための実践的指針となることが期待されます。また、最後にまとめたブロッキングの回避技術については、さまざまなブロッキング議論を行う上で技術的困難性を理解するための一助となれば幸いです。