ブラウジングからメール、ゲーム、音声通話まで、インターネット上のほぼすべてのタスクには、目に見えないドメイン名の参照が伴います。そして、その参照はほとんどの場合、安全ではありません。たとえアクティビティが暗号化されていても（httpsで保護されたウェブサイトを閲覧している場合でも、VPNを使用している場合でも）、これらのドメイン名の参照によって情報が漏洩する可能性があります。つまり、インターネットサービスプロバイダー、Wi-Fiルーターを共有している人（カフェなど）、データセンター、政府機関、その他関係者が、あなたの行動、例えばあなたが何を読んでいるか、誰とやり取りしているかなどを把握できる可能性があるのです。
セキュリティを強化し、リスクを軽減するための提案は、多大な努力が費やされているにもかかわらず、あまり浸透していません。しかし、ISPが提供するDNSサービスの代わりに利用できる2つの新しいパブリックDNSサービスは、大きな変化をもたらす可能性があります。これらのサービスは、既存のパブリックDNSサービス、特によく知られているGoogle Public DNSの機能を拡張したものです。
Cloudflare と Quad9 は、DNS の情報漏洩を軽減するために、検証、プライバシー重視のプロトコル、暗号化を組み合わせたパブリック DNS サーバーを提供しています。
DNS の仕組みや、これらのサービスが安全でない、破損しやすい設計をどのように改善するのかという詳細に入る前に、これらのサービスを使用するためにデバイスを構成する方法について簡単に説明します。
CloudflareまたはQuad9を使用するようにデバイスを設定する
Mac では、接続するネットワークに関係なく固定される特定のネットワーク アダプタ (イーサネット、Wi-Fi) の DNS サーバーを設定できます。
- システム環境設定 > ネットワーク > 詳細 > DNS を開く
- 「DNSサーバー」ボックスの下の「+」ボタンをクリックします。最初のDNSサーバーのIPアドレスを入力します。
- 最初のサーバーが利用できない場合や応答が非常に遅い場合に備えて、2 番目のサーバーがある場合は、手順 2 を繰り返します。(サーバーのエントリをドラッグして順序を変更できます。)
- [OK]をクリックし、[適用]をクリックします。
さまざまなサービスごとに、入力する IP アドレスは次のとおりです。
- Cloudflare: 1.1.1.1 および 1.0.0.1 (下記の注記を参照)
- Google パブリック DNS: 8.8.8.8 および 8.8.4.4
- Quad9: 9.9.9.9 および 149.112.112.112
複数のサービスの DNS サーバーを入力し、並べ替えてどれが好みに合うかを確認しても問題はありません。
一部のオペレーティングシステム、ネットワークハードウェア、およびソフトウェアでは、Cloudflareの1.1.1.1アドレスが汎用アドレス、ゴミアドレス、または内部アドレスとして扱われることに注意してください。その結果、そのアドレスでCloudflareのウェブサイトにアクセスしたり、そこにあるDNSサーバーを使用できない可能性があります。私はシアトルのCenturyLinkの光ファイバー接続でこの問題を経験しています。WebページとDNSへのアクセスにはバックアップの1.0.0.1アドレスを使用し、DNS設定で1.1.1.1アドレスを省略できるはずです。
また、上記のQuad9のアドレスにはDNSブラックリストが含まれているため、デバイスは組織が特定した数百万もの悪意のあるアドレスに接続できなくなります。このブラックリストを回避する代替DNSサーバーセット（9.9.9.10と149.112.112.10）をご利用ください。
iOSでは、DNSサーバー設定がmacOSと同様に、ほとんどの人が期待する通りに動作しない傾向があります。つまり、一度設定すれば、接続するすべてのネットワークで同じ設定が適用されるということです。設定はネットワークごとに必要です。さらに悪いことに、テストでは、DNS値を変更すると設定が「自動」に戻り、入力したサーバーのIPアドレスが破棄されることが分かりました。また、携帯電話接続用のDNSサーバーを設定する方法もありません。
ご自身のネットワークでは、ルーターのDNSサーバー設定を変更することをお勧めします。設定方法はメーカーによって大きく異なりますが、DHCPまたはネットワーク設定の項目で、ローカルネットワークに割り当てられているアドレスの範囲と、アドレス割り当て時に渡されるDNSサーバーの両方を指定できる項目を探してください。
他のオペレーティング システムについては、Cloudflare、Google Public DNS、Quad9 などのサービスのガイドを参照してください。
DNS がどのように機能するか、また Cloudflare と Quad9 がどのような問題に対処すると約束しているかに興味がある方は、ぜひ読み進めてください。
再帰的かつ分散的なDNSはインターネットリスクよりも前から存在していた
ドメインネームシステムの歴史はインターネットの黎明期にまで遡り、その歴史は今も色濃く残っています。DNSは長年にわたり多くの機能を獲得してきましたが、その本質は、人間が読めるドメイン名（www.tidbits.com など）と、接続に必要なIPアドレス（64.62.135.130）を対応付けるディレクトリです。
ウェブページの閲覧など、ほぼすべてのインターネット接続では、デバイスのネットワーク設定で指定されたDNSサーバーへのDNSルックアップが、暗黙的に実行されます。多くの場合、ソフトウェアは単一のアクションに対して複数のドメインを参照します。例えば、画像やスタイルシートが異なるサーバーにホストされているウェブページの場合などです。
その後、検索は分散階層構造のDNSサーバーからDNSサーバーへと巡回し、そのドメインの権威エンドポイントであるDNSサーバーを見つけます。最終的に、そのDNSサーバーは、必要な回答、または検索に対する回答がないことを示すエラーを含む応答を返します。
インターネット対応のデバイスやオペレーティングシステムには、「スタブリゾルバ」と呼ばれるものが搭載されています。これは、クエリをDNSサーバー（別名「リゾルバ」）に渡すのに必要な情報だけを格納します。このDNSサーバーは通常、ISPによって運営されています。あるいは、Google Public DNSのように、誰でもアクセスできるサーバーである場合もあります。（マゾヒストなら、自分で運営することもできます。）
これはどのように動作するのでしょうか? 例えば、Web ブラウザで www.tidbits.com を検索すると、Mac や iPhone のスタブリゾルバがその完全なクエリ (「完全修飾ドメイン名」と呼ばれる) を DNS サーバに渡し、DNS サーバはそれを断片に分解します。クエリは末尾から始まり、末尾には暗黙的に「.」(www.tidbits.com.) が含まれますが、最後のドット (.) を目にすることはめったにありません。このドットは DNS のルートレベルを示します。ルートレベルは、.com、.uk、.aero など、すべてのトップレベルドメインの権威情報を持つ世界中の多数のサーバによって処理されています。DNS サーバはすべてのルートサーバに到達する方法を知っており、この例では、そのうちの 1 つに .com サーバを要求します。.com を扱うサーバに渡されると、tidbits.com に関する詳細情報の要求は TidBITS の DNS ホストに渡され、そこでは特に www.tidbits.com に応答するネームサーバが稼働しています。最後に、IP アドレス 64.62.135.130 が DNS サーバーに送り返され、スタブリゾルバに渡されます。
DNSは分散型であり、世界中のすべての完全修飾ドメイン名（FQDN）に対する権威あるリストは存在しません。ルートサーバーはトップレベルドメインのみを認識し、トップレベルドメインサーバーはそれぞれの管轄下にあるドメインのみを認識し、といった具合に階層構造が続きます。また、DNSは分散型であり、単一の権限を持つサーバーは存在せず、下位レベルのドメインの責任はツリー構造を通じて委任されます。
それを説明したので、どのような問題を解決する必要があるかを見てみましょう。
右から左へのDNSの脆弱性
DNSと同様に、初期のWebは全く安全ではありませんでしたが、Netscapeなどの初期のサーバーやブラウザの開発者は、電子商取引、銀行業務、その他の商用利用には安全な経路が必要であることをすぐに理解しました。こうして、二点間でネゴシエートされた暗号化を提供するSSLが誕生しました。SSLはTLSに取って代わられましたが、金融情報などの機密情報を扱わないサイトでもWeb暗号化が標準となるまでには、ほぼ20年かかりました。
DNSは、Webの改善に向けて様々な、そしてしばしば競合する取り組みが提案されているにもかかわらず、依然としてWebから大きく遅れをとっています。中には正式に承認されたものさえありますが、まだ完全には導入されていません。つまり、DNSは漏洩しやすいものであり、傍受される可能性のあるポイントが数多く存在するのです。
ほとんどのDNSルックアップは平文で送信されるため、他のすべての操作が暗号化されていても、アクセス、メール送信、ファイルアップロードなどのドメインはすべて、ローカルネットワークとすべての中間ネットワークを通過します。経路上のどこかでトラフィックをスニッフィングしている人は、トラフィックの内容はともかく、トラフィックの行き先を見ることができます。
VPN接続を使用している場合、DNSルックアップはVPNを経由するためローカルでは公開されませんが、それでも一部の情報が漏洩する可能性があります。DNS Leak Testなどのサイトは、VPNで漏洩が発生していないかを確認し、問題の解決方法に関するアドバイスを提供するのに役立ちます。
たとえあなたのローカルネットワークやその中間のポイントを誰もスニフィングしていなくても、DNSサーバーは常にクエリ全体を解決チェーンの各ポイントに送信します。そのため、ルートから個々のドメインのDNSホストに至るまで、すべてがあなたが望むドメイン名全体を認識しています。そのため、DNSサーバー自体があなたの活動に関する情報源となる可能性があります。
また、DNS応答はかつては簡単に「ポイズニング」される可能性があり、正しい応答を攻撃者が利用したい応答に置き換えることができました。DNSサーバーやスタブリゾルバには、応答が実際の正確な送信元からのものかどうかを効果的に識別する方法がありませんでした。ポイズニングの一種は、インターネット史上最悪のセキュリティ欠陥の一つにつながり、2008年に広く知られるようになる前に、すべてのオペレーティングシステムメーカーとDNSサーバー開発者によって修正されました。
この脆弱性は修正されましたが、公衆Wi-Fiネットワークにアクセスし、様々な単純な手法と容易に入手可能なソフトウェアを用いてDNSルックアップに偽の応答を返すことは依然として可能です。https接続で使用される暗号化により、この攻撃はほぼ阻止されます。例えば、ブラウザは証明書が無効であることを示すエラーを表示し、誰かが接続を傍受しようとしていることを警告します。しかし、依然として可能性は残っています。
DNSサービスを提供する世界中のすべての機関がシステムを改善し、ユーザーを教育し、まだ完全には採用されていない新しい取り組みに合意すれば、これらすべてが変わる可能性があります。もしそれが実現しそうにないと思われるなら、それは間違いではありません。
その間、新しいDNSサーバーに切り替えることでパフォーマンスを向上させ、プライバシーも向上させることができます。CloudflareとQuad9の新しいパブリックDNSサービスは、これらの問題の一部に対処しています。これまでGoogle Public DNSをご利用だった方は、これらのメリットの一部は享受できているかもしれませんが、すべてではありません。
DNSのプライバシーと整合性の漏洩を阻止する
CloudflareとQuad9はどちらも、様々な技術と機能を備えた無料のパブリックDNSを提供していますが、その中にはまだ広くサポートされていないものもあります。まずは両社が提供するサービス内容について説明した後、両社について、そしてプライバシーとデータ収集の問題についてお話しします。Google Public DNSもこれらの機能の一部を提供しています。
少し技術的な話になりますが、弱点がどこにあるのかを理解するために読んでみる価値はあります。各DNSサービスの主な特徴は以下のとおりです。
- 有効性： DNSサーバーは、暗号署名を使用することで、DNSサーバー階層全体にわたって応答が有効であることを判断できるようになりました。DNSSECと呼ばれるこの技術は、偽の応答やDNSポイズニングの試みをブロックします。一部のISPのDNSサーバーもこの機能をサポートしていますが、特にCloudflare、Google Public DNS、Quad9が提供しています。
- 情報漏洩の削減： ルートサーバーとその中間にあるすべてのサーバーに完全修飾ドメイン名を送信する代わりに、「クエリ名最小化」と呼ばれるプロトコルがドメインを構成要素に分割します。DNSサーバーは、チェーンの各ポイントに必要な最小限の情報を送信します。これにより、中間サーバーがクエリに関する情報を収集するのを防ぎ、クエリが通過するネットワークへのアクセスを盗聴する攻撃者を阻止します。CloudflareとQuad9はクエリ名最小化をサポートしていますが、Google Public DNSはサポートしていません。
- DNSクエリのエンドツーエンド暗号化： DNSトラフィックを暗号化してスニッフィングを防ぐ方法はいくつかあります。DNS-over-TLS（DoT）とDNS-over-HTTPS（DoH）は互換性がなく、まだ初期段階ですが、どちらもスタブリゾルバとDNSサーバー間のDNSクエリを暗号化します。この暗号化された接続は、外部に情報を漏らしません。これはDNSクエリ用のVPNのようなもので、同様の利点があります。Cloudflareは両方を提供しており、Google Public DNSはDoH、Quad9はDoTを提供しています。
これらの機能のほとんどは、アプリやオペレーティングシステムとは独立して存在します。DNSSEC では、階層の各レベルとドメインの DNS ホストに証明書が必要ですが、その実現にユーザーが関与する必要はありません。
同様に、クエリ名の最小化もお客様側の手間はかかりません。Cloudflareは、グローバルインフラストラクチャの強化を目的として、存在しないドメイン情報に対する繰り返しのクエリ（「アグレッシブネガティブアンサー」と呼ばれる）を削減する手法も採用しています。
DoTとDoHのメリットを最大限に享受するには、オペレーティングシステムに新しいスタブリゾルバが必要です。システムのスタブリゾルバのプロキシとして機能するソフトウェアをインストールすることで、このメリットを今すぐ享受できます。macOSを含むデスクトッププラットフォームに「stubby」というソフトウェアをインストールしてDoTをテストしてください。Cloudflareも複数のプラットフォームでDoHをサポートするDNSプロキシを提供していますが、非常に複雑なため、インストールは上級ユーザーに任せるのが賢明です（私はインストールしませんが）。DoHは個々のアプリケーションに組み込まれる可能性もあり、オペレーティングシステムが追いつく前にDNSセキュリティを向上させることができます。Mozilla Foundationは、Firefox内で直接DoHを使用するテストを実施しています。
DNSパフォーマンスの向上
関係するすべてのステップから想像できると思いますが、DNS解決は遅くなることがあります。個々のルックアップは高速であっても、それがゲート要因となります。あるリソースが別のリソースを読み込む際に、より多くのルックアップが必要となるため、ルックアップは連続して行われるため、数十ミリ秒の時間が積み重なって数秒にも達してしまいます。
10年以上前、OpenDNSは超高速ルックアップを実現するパブリックDNSサービスの先駆者となり、DNSの改善によってより優れたユーザーエクスペリエンスを提供できることを実証しました。（OpenDNSは現在Ciscoの傘下にあり、他の分野に重点を置いているため、ここでは取り上げていません。）
パフォーマンスは、Cloudflareのサービスにおける主張の一つです。DNSPerfのレポートもそれを裏付けています。Cloudflareは10～12ミリ秒でクエリを処理しますが、Google Public DNSとQuad9はDNSルックアップへの応答に30ミリ秒以上かかります。
これらは利点ですが、トレードオフについても話し合う必要があります。
DNS ルックアップでは、誰を信頼しますか?
DNSクエリのセキュリティを不正アクセスから保護するための上記のすべての改善にもかかわらず、クエリは完全に暗号化されず、接続の反対側にあるDNSサーバーで閲覧可能です。つまり、DNSサーバーを運営する組織を信頼する必要があるのです。なぜなら、その組織はすべてのDNSルックアップと関連情報（IPアドレスやクエリを発行したスタブリゾルバの詳細など）を見ることができるからです。では、CloudflareとQuad9とは一体何者なのでしょうか？
Cloudflareは、世界中で頻度と規模が拡大し続ける分散型サービス拒否（DDoS）攻撃に対する、商用および無料の保護を提供しています。Cloudflareは、1.1.1.1および1.0.0.1のIPアドレスを所有するAPNIC（アジア太平洋ネットワーク情報センター）と提携しています。Cloudflareは、サービスに関して包括的なプライバシーポリシーを策定し、収集する情報と破棄する情報を詳細に規定しています。Cloudflareは一部のデータをAPNICと共有し、APNICはそれを分析し、元のデータを破棄します。
Cloudflareは長年、DDoS対策のキャッシュ・リダイレクトサービスを利用する顧客に対し、ヘイトスピーチなどの過激な言論に利用されている場合でも、いかなる差別も行わないというポリシーを掲げてきたため、同社に不快感を抱く人もいます。また、CloudflareのCEOが、方針変更や警告もなく、単に考えを変えたというだけの理由で、過激なサイトを突然削除したことに不満を抱く人もいます。
Cloudflare はマーケティングツールとしてかなり広範囲な無料サービスをいくつか提供している。これは同社にとって、後でプレミアムサービスを購入する可能性のある中小企業にアプローチするための効率的でプレッシャーのない手段だ。(TidBITS は現在、メインサーバーの負荷を軽減するために Cloudflare の無料サービスを利用している。) また、Cloudflare は処理する DNS クエリを通じて、DNS がどのように悪用されているか (特に IoT デバイスによるもの) に関する貴重な集約的情報も得ている。
対照的に、Quad9はIBM、Packet Clearing House、Global Cyber Allianceを創設パートナーとする非営利団体です。Quad9は、リスクと露出を最小限に抑えるという使命の一環として、すべてのサービスを無料で提供していますが、Cloudflareと同様に、パートナーの脅威認識と緩和に役立つ集約的な情報も収集しています。Quad9のプライバシーポリシーも同様に詳細です。Adam Engst氏は、Quad9の主要人物の一人と長年接してきた経験から、Quad9のポリシー遵守に大きな信頼を置いています。
最後に、Googleについては誰もが知っていますが、Googleが個人情報をどのように利用して広告事業を推進しているかについては、人によって意見が分かれています。Google Public DNSのプライバシーポリシーには、Google Public DNSに送信される情報は他のGoogleサービスには使用されないと記載されています。私は多くのGoogleサービスやウェブアプリを利用しています。しかし、Gmailは使っていません。Googleの声明と実際の行動がどの程度一致しているのか、そしてGoogleが広報活動や政府への影響をどれほど懸念しているのかについて、時とともに懸念が高まっています。
しかし、クエリがこれらの組織に到達した時点でプライバシーが確保されない可能性もあることは事実です。ハッカーがシステムに侵入したり、政府機関が詳細情報を要求したり、制御を奪ったりする可能性があります。公平を期すために言うと、これはISPを含むあらゆるDNSプロバイダに当てはまります。ISPは、技術的または法的攻撃への対抗能力がさらに低い可能性があります。
企業がプライバシーポリシーや公式声明で約束した範囲を超えて、個人情報を販売したり、製品やサービスのマーケティングに利用したりするのではないかと懸念するのは、決して無理なことではありません。企業が私たちの個人情報を様々な方法で悪用してきたことを考えると、もはや盲目的に信頼することはできません。
より良いDNSへの小さな一歩
プリンストン大学の研究チームがOblivious DNSを提案しました。これは、クエリと結果の関連性を劇的に低減するものです。残念ながら、この技術には新たなDNSインフラが必要になります。これは、人々が新しいDNSサーバーを大量に試用し、Apple、Google、MicrosoftなどのOSメーカーが顧客にとって十分なメリットがあると判断した場合に限り実現可能です。果たして実現するでしょうか？おそらく無理でしょう。DNSはあまりにも広く普及し、根付いているため、すべてのユーザーにとって包括的な解決策を提供することは不可能に思えます。
それでも、セキュリティとプライバシーの向上に向けて踏み出す一歩一歩は、必ずプラスになります。データがどこに行き着くのかを考えることは重要です。そして、Cloudflare、Google、Quad9にクエリを公開することが、ISPへの既存の露出よりも良い結果をもたらすかどうかは、ご自身で判断できるのです。ISPは、前述のDNS保護を一切採用していない可能性があります。
また、これらの注目度の高いパブリック DNS サービスにより、インターネット インフラストラクチャ プロバイダーに対して、あらゆる場所の DNS リゾルバーにこれらの改善を展開するよう、より大きな圧力がかかることを期待しています。