#1414: Cloudflare と Quad9 の DNS、MacBook Pro バッテリー交換、TidBITS を Apple News で読む
Apple が、Touch Bar 非搭載の一部の 13 インチ Macbook Pro を対象にバッテリー交換プログラムを開始した。Adam Engst が詳細を伝える。Adam はまた TidBITS の Apple News Format での出版も開始したことを発表し、iOS 上の News アプリで表示の最適化を図ったことを説明する。Glenn Fleishman が寄稿記事で、Cloudflare と Quad9 による新しい DNS サービスを解説し、これらを使うことでパフォーマンス、セキュリティ、プライバシーの向上が期待できる理由を説明する。それから、今週号の拡大版 ExtraBITS をお見逃しなく。先週はたくさんの興味深い出来事があったからだ。今週注目すべきソフトウェアリリースは iMovie 10.1.9、Things 3.5、Typinator 7.5、BusyContacts 1.2.11、Default Folder X 5.2.4、それに ChronoSync 4.8.6 だ。
Apple、一部の Non-Touch Bar 13-Inch Macbook Pro の電池を交換
Apple は Touch Bar 非搭載モデルの 13-inch MacBook Pro の一部に対して電池交換プログラムを立ち上げた。これらの電池は部品故障が原因で膨張することがある。
この問題は、オンライン報告から推測出来る範囲で言うと、そう広範囲に広がっている様には見えないが、MacRumors フォーラム上の wwwebtech の写真から判断すれば、結構深刻な事態になり得る。
あなたの MacBook Pro が対象なのかどうか調べるには、この交換プログラム上のフィールドに自分のシリアル番号を入力する。該当する場合、Apple Authorized Service Provider か Apple Retail Store で、或いは Apple Repair Center に送ることで電池を交換して貰える。
関連する損傷について Apple は次の様に言っている:
注:バッテリーの交換に支障をきたす損傷がある場合は、そちらを先に修理する必要があります。場合によっては別途修理料金がかかることがありますので、あらかじめご了承ください。
しかしながら、上記の写真の MacBook Pro の持ち主は、最初 Apple は別途修理料金がかかるかもしれないと言っていたが、後になって全ての料金を取り下げたと報告している。もし今現在この膨張問題を経験しているのであれば、修理は無償でなされるであろうと私には思える (そして、そうでない場合は、抵抗すべきである)。もう既に有料で電池交換した人や、この問題に起因することで MacBook Pro を修理せざるを得なかった人は、Apple に連絡して返金を求めるべきである。
TidBITS を Apple News で読むには
iOS 9 で、Apple は Apple News とそれに関連する News アプリを Newsstand に置き換わるものとして導入した ("iOS 9 の News についてのニュース" 30 September 2015 参照)。News はどちらかといえば伝統的な RSS リーダーであったが、時を経て Apple は独自の Apple News Format を使って出版者に彼らの記事をどう見せるかについてより多くの制御を与えるようになった。同社は News アプリを未だ Mac には導入していないが、Apple の Texture の買収によりニュースサービスが形を変えるのに伴って姿を現わすことになるのかもしれない ("Apple、デジタル雑誌サービス Texture を買収" 12 March 2018 参照)。
どの様にしたら TidBITS を Apple News で読めるかを説明する前に、簡単なアンケートに答えて欲しい - 皆さんはどのぐらいの頻度で News アプリをお使いですか? もう既に数百の回答は得ているので、結果については次週に報告したい。
もう既に News アプリを利用されている皆さんに対しては、TidBITS が今や Apple News Format 経由で Apple News で見られることをお知らせしたい。と言うことで、我々の記事は iPhone や iPad の両方の上で、次のスクリーンショットで見られる様に、これまでになく良く見える様になった。[訳者注:現時点では News アプリは残念ながら日本では使えるようになっていない。]
私は Apple News Format で我々の記事を提供することが TidBITS を Apple 技術に興味を持つより多くの人に拡大することを願うものだが、そうなる可能性があるのか、或いはそれを検証出来るのかすらも分からない。
でも、もし皆さんが News アプリを利用されているのであれば、TidBITS をあなたの Following リストに追加するのは簡単である。そうしておけば、TidBITS に直接アクセス出来、そして TidBITS の記事も他の物と一緒に For You に含まれる様になる。
これをやる一番簡単な方法は iPhone か iPad で読んでいる最中に、このリンクをクリックすることである。それは Safari の中で tidbits.com に行き、そして Get TidBITS > Apple News をタップするのと同じである。(iPhone 上では、ロゴの右側にある省略記号をタップ、メニューを下方にスクロールして行き、Apple News をタップする。) どちらのやり方でも、News アプリの中の TidBITS チャネルに導かれる。TidBITS をフォローするには右上にあるハードマークをタップする。
他のやり方には、News アプリの中で以下の手順を踏む方法がある:
- News アプリの一番下にあるツールバーの中の Following をタップし、Following 画面を呼び出す。
- 検索フィールドに "TidBITS" とタイプし、それが現れたらハートボタンをタップする。
- そこから先は、TidBITS があなたの Following リストに現れるので、それをタップすれば、最新の話題にアクセス出来る。
我々の Apple News との統合に関するメモ:
- 我々は記事用と Watchlist 項目用に別々のセクションを作った - 切り替えるには上部にあるリンクをタップする (Drafts は私専用)。Watchlist 項目は未だ我々が期待している様には動いていない。News は我々が Watchlist 項目用に使っているアイコンを時々切り捨ててしまう;これに関して我々が出来ることは何もなさそうである。そして iPad 上では、このアイコンは馬鹿げた程大きい。
- 現時点では、我々の記事のコメントに対するリンクは無い。これを追加する術があるのかどうかは調査中である。
- iPhone では、スクリーンショットは極めて小さくなる。もし中のテキストを読みたいとか、細かい所を見てみたいと言うのであれば、iPhone を回転させて横位置にするとか、タップそしてピンチしてズームインすることもやってみて欲しい。
- 友人や同僚と、我々の記事の一つへのリンクを共有するために標準の iOS シェアシートを使うのであれば (是非やって欲しい!)、一つの https://apple.news リンクを共有することになる。これは尋常でない様に見えるかもしれないが、iOS 上の News で間違いなく開くし、他の全ての機器上の Web ブラウザーでも正常に働く。
我々が Apple News を使って物事を設定しているやり方について、質問やコメントをお持ちであれば、知らせて欲しい。全ては Alley Interactive の WordPress 用 Publish To Apple News プラグイン経由でなされるので、我々のやれることは限られていることは理解して欲しい。
Cloudflare と Quad9、DNS の改善を目指す
インターネット上でのほとんどあらゆることには、電子メールをブラウズすることから、ゲーミング、さらには音声通話に至るまで、あなたの目には決して見えないがセキュアでない、そういう一面をほとんど常時持っているドメイン名検索 (domain-name lookup) というものが伴う。あなたの活動が暗号化されていたとしても、https で保護されたウェブサイトを使っていても、あるいはまた VPN を使っていても、ドメイン名検索が情報を漏らすことは常にあり得る。それはつまり、あなたのインターネットサービスプロバイダや、Wi-Fi ルータを (例えばコーヒーショップの中で) 共有している見知らぬ人や、データセンターや、国の政府、またはあなたと袖摺り合う他の誰かが、あなたの挙動を覗き見できる可能性があるということだ。あなたが何を読んでいるか、あなたが誰とやり取りしているかといったことも、すべてそこに含まれる。
セキュリティを改善し、あなたのことが暴露される危険を減らそうと、これまで膨大な努力が注ぎ込まれたにもかかわらず、大した成果は達成されてこなかった。けれどもここに、二つの公開 DNS サービスがあって、あなたもご自分の ISP が提供する DNS サービスの代わりにこちらを使えば大きな違いが生まれるかもしれない。ただしその際にも、そちらのサービスの方を信用することから生ずる難点を意識することを忘れてはならない。これらのサービスは従来の公開 DNS サービス、とりわけ有名な Google Public DNS が提供してきたものを、さらにもっと拡張している。
それが、Cloudflare と Quad9 だ。両者とも、検証と、プライバシーに集中したプロトコル、DNS の漏洩や欠陥を緩和するための暗号化などを組み合わせて提供する、公開 DNS サーバを備えている。
では早速要点に入ることにして、あなたのデバイスがこれらのサービスを利用できるようにするための設定方法を説明しよう。それが済んだら、DNS の動作方法の核心に迫って、セキュアでもなく簡単に壊されてしまうこのような DNS のデザインを、これらのサービスがどのように改善しているのかを見て行こう。
Cloudflare または Quad9 を使うようにデバイスを設定する
あなたの Mac 上で、特定のネットワークアダプタ (Ethernet, Wi-Fi) ごとに DNS サーバを設定して、あなたがどのネットワークに接続してもその DNS サーバを使うようにできる。
- System Preferences > Network > Advanced > DNS を開く。
- DNS Servers ボックスの下にある + ボタンをクリックして、最初の DNS サーバの IP アドレスを入力する。
- 第二のサーバ (もしあれば) についても手順 2 を繰り返す。これは、最初のサーバが利用できなくなったり、あるいは反応が非常に遅くなったりした場合に備えてのことだ。(サーバ項目をドラッグして順序を入れ替えることもできる。)
- OK をクリックし、それから Apply をクリックする。
それぞれのサービスごとに入力すべき IP アドレスは次の通り:
- Cloudflare: 1.1.1.1 と 1.0.0.1 (下の注意を参照)
- Google Public 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 ファイバー接続で経験した。その場合は、Cloudflare のバックアップ用の 1.0.0.1 アドレスを使ってウェブページにアクセスしたり DNS を利用したりし、DNS のセットアップで 1.1.1.1 アドレスを省くことができるはずだ。
もう一つ、上記の Quad9 のアドレスには DNS ブロックリストが含まれていて、この組織が識別した悪意ある何百万ものアドレスにあなたのデバイスが接続しないようになっている。このブロックリストを回避したい場合のために、代替用の DNS サーバも用意されている: 9.9.9.10 と 149.112.112.10 だ。
iOS における DNS サーバ設定は、多くの人たちが望むような形では動作しない傾向がある。macOS においては、いったん詳細設定を決めておけば、あなたが接続するすべてのネットワークでその設定が使われる。けれども iOS においては、個々のネットワークごと別々に設定をしなければならない。さらに悪いことに、私たちのテストの結果では、DNS の値を変更すると、その後は設定が勝手に Automatic に戻ってしまい、私たちが入力しておいたサーバの IP アドレスが消えてしまった。また、セルラー接続用に DNS サーバを設定する方法は見つからなかった。
あなたの自前のネットワークでは、DNS サーバ設定をルーター上で変更しておくことをお勧めしたい。メーカーによって細かい所は異なるが、DHCP あるいは Network という設定領域を探せば、ローカルネットワーク上に割り当てられたアドレスの領域と、アドレス割り当てと共に渡される DNS サーバとを指定できるはずだ。
それ以外のオペレーティングシステムについては、Cloudflare、Google Public DNS、Quad9 それぞれのサービスのガイドを参照して頂きたい。
さて、ここから先は、まず DNS がどのように働くのかについて説明してから、Cloudflare、Google Public DNS、Quad9 のそれぞれがどのような種類の問題に対処すると約束しているのかについて順々に説明して行くので、興味のある方はどうぞ読み進んで頂ければと思う。
再帰的かつ分散型、DNS はインターネット・リスクの時代以前から存在
ドメイン名システム (domain name system) の歴史は、インターネットの最も初期の時代に遡り、その事実はしばしばそれと見て取れる。DNS は長年かけて数多くの機能を組み込んできたけれども、その核心は今も変わらない。これは、人間が読めるドメイン名 (例えば www.tidbits.com) を照合する辞書であって、それに応じて接続のために必要なデータ、例えばそのドメインの IP アドレス (例えば 64.62.135.130) などを返すものだ。
ほとんどあらゆる種類のインターネット接続、例えばウェブページを訪問するというような活動に際して、あなたのルーターで、あるいはあなたのデバイスのネットワーク設定で指定された DNS サーバに向けて、ドメイン名検索つまり DNS lookup が静かに送信される。多くの場合、あなたが使っているソフトウェアは一つのアクションについて複数個のドメインを検索する。例えば、ウェブページを開こうとする場合には、そのページとは別のサーバ上にホストされた画像やスタイルシートも呼び出さねばならないからだ。
この lookup 通信は DNS サーバから DNS サーバへと、非集中、分散型の階層を飛び移りつつ、そのドメインの正当なエンドポイントである DNS サーバを見つけるまで送信され続ける。そして最後には、その DNS サーバから必要な回答を添えた返信が送られるか、またはその lookup に何の回答もなかったというエラーが返される。
インターネットにアクセスをするすべてのデバイスやオペレーティングシステムは "stub resolver" と呼ばれるものを備えていて、これがあなたの問い合わせを一つの DNS サーバ (これも "resolver" と呼ばれる) へ送るために必要なことだけを知っている。通常、その DNS サーバはあなたの ISP (インターネットサービスプロバイダ) が運営している。場合によっては汎用に開放されている DNS サーバ、例えば Google Public DNS を使うこともある。(あなたがマゾヒストならば、自分独自の DNS サーバを運営することも可能だ。)
実際にはどのように動作するのか? 例えばウェブブラウザが www.tidbits.com を問い合わせ (クエリー) したとしよう。すると、あなたの Mac か iPhone の stub resolver が、"fully qualified domain name" と呼ばれるフルのクエリーをあなたが指定した DNS サーバに送る。その DNS サーバは、そのクエリーをバラバラに分解する。これは後ろから解釈され、末尾に (あなたの目にはまず見えないが) 暗黙のうちにドット "." が付加されて "www.tidbits.com." となる。この末尾のドットが DNS の root レベルを意味し、世界中にある数多くのサーバであらゆるトップレベルドメイン (.com、.uk、.aero など) の情報を持つことが認められているところがこれを処理する。あなたの DNS サーバはこれらの root サーバすべてに到達する方法を知っており、この例の場合には、.com サーバのどれかに問い合わせを送る。そうして .com を処理するサーバにそれが渡されれば、tidbits.com についての情報を求めたあなたのリクエストが TidBITS の DNS ホストに送られるが、このホストがネームサーバも運営していて、www.tidbits.com についての返信を提供する。そうして最後に、その 64.62.135.130 という IP アドレスがあなたの DNS サーバに送られ、それが stub resolver に伝えられる。
DNS は分散型だ。それはつまり、世界中の "fully qualified domain name" をすべて網羅した権威あるリストなどどこにも存在しないということだ。だから、root サーバが知っているのはトップレベルのドメインのみ、トップレベルドメインのサーバが知っているのはそれぞれの権限が及ぶ範囲内のドメインのみ、それ以下の階層を辿ってもずっと同じことが言える。また、DNS は非集中でもある。つまり、たった一つの権威ある場所などどこにもなくて、より低いレベルのドメインに対する責任が、枝分かれを伝い階層的に委託されている。
以上の説明を踏まえて、どのような問題点を解決すべきなのか見て行こう。
DNS の弱点を右から左へ
DNS と同様、初期のウェブは全くセキュアでなかった。けれども初期のサーバや Netscape など初期のブラウザを構築した人々はすぐに、e-コマースやバンキング、その他商用の利用のためにはセキュアな道筋が必須であることに気付いた。こうして SSL が生まれた。二つのポイントの間で、取り決めに基づく暗号化を提供するためのものだ。その後ほぼ 20 年近くもかかってようやく、当初の SSL が今は TLS に替わり、金銭取引その他の機密情報を扱わない一般のサイトでさえも、ウェブ暗号化が標準となるようになった。
それでもなお、DNS は未だにウェブよりも大きく立ち遅れている。DNS をより良いものにしようという努力は数多くなされ、いくつかの努力が競合したこともしばしばあったのだが、どれも定着するには至らなかった。公式に採用されたものさえいくつかあったけれども、ただ、フルに行き渡ることはなかった。要するに、DNS はざるのごとくにだだ漏れで、傍受の可能性がいたる所にあるというのが現状だ。
大多数の DNS lookup は、そのままの状態で送信される。なので、たとえあなたが他のすべてのものを暗号化しセキュアにしていたとしても、あなたが訪れたり、電子メールを送信したり、ファイルをアップロードしようとしたりしている先のドメインの名前は、すべてあなたのローカルネットワークや、中間に介在するすべてのネットワークの上を、そのままの形で通過している。だから、その途中のどこででもトラフィックを傍受する者は誰でも、トラフィックのコンテンツを知ることはできないとしても、あなたのトラフィックの行く先は、そのまま見ることができる。
あなたが VPN 接続を使っている場合、あなたの DNS lookup は VPN を通るのでローカルに傍受される心配はないが、それでも情報が漏れ出る可能性は残る。DNS Leak Test などのサイトを使えば、あなたの VPN が情報を漏らしているかどうかのテストができ、問題点の修正のためのヒントももらえる。
たとえ誰もあなたのローカルネットワークや途中に介在するポイントを傍受していなかったとしても、DNS サーバは常に、解決の連鎖を構成する個々のポイントにおいてクエリーの内容を丸ごと送信している。だから、root のところから個々のドメインの DNS ホストに至るまで、すべてのポイントがあなたがリクエストしたドメイン名を丸ごと知っている。つまり、DNS サーバ自体が、あなたの活動に関する情報限となり得る可能性を常に秘めている。
また、一時は DNS 応答が簡単に「毒を盛られる」ことができた。つまり、正しい応答結果が、アタッカーの使いたい偽物の応答結果に置き換えられてしまうことがあった。DNS サーバも stub resolver も、その応答が実際に最も信頼のおける情報源から来たものであるかどうかを識別できる効果的な方法がなかったからだ。この「毒盛り」の一つの形の結果としてインターネット最悪のセキュリティ欠陥が生まれ、2008 年にその欠陥が広く知られるようになる前に、あらゆるオペレーティングシステムのメーカーとあらゆる DNS サーバの開発者がパッチを施し終えた。
この特定の脆弱性はパッチされたけれども、誰かが公共の Wi-Fi ネットワークにアクセスしさまざまの単純なテクニックとすぐに利用可能なソフトウェアを用いることで DNS lookup に対する偽物の応答を提供することは今も可能だ。ただし、https 接続のために使われる暗号化が、大体においてこの攻撃の有効性を阻止している。例えばあなたのブラウザが、証明書が無効だというエラーを出して、誰かがあなたの接続を傍受しようとしているという警告を出すかもしれない。でも、だからと言って攻撃の可能性が消えた訳ではない。
もしも DNS サービスを提供している世界中のあらゆる組織が一致協力して、それぞれのシステムを改良し、ユーザーを教育し、今はまだフルには採用されていない新しい構想に同意したならば、すべてが変わるだろう。でも、そんなことは起こり得ないよと思われたあなたは、間違っていない。
それはそれとして、あなたが新しい DNS サーバに切り替えることで、パフォーマンスを改善し、プライバシーを増すことができるかもしれない。Cloudflare と Quad9 がそれぞれに打ち出した新しい公開 DNS サービスが、これらの問題点のいくつかに対処しているからだ。Google Public DNS を使っている人は既にその恩恵のいくつかを得ているのだが、この新しい二者が提供する利点をすべて享受できてはいない。そのことを次に説明しよう。
DNS のプライバシーと整合性のリークを防ぐ
Cloudflare と Quad9 はいずれも無料の公開 DNS を提供し、さまざまのテクニックや機能を備えているが、その中のいくつかはまだ広くサポートされていない。ここではまず両者が何を提供するかを列挙してから、その後で両者について具体的に、またプライバシーやデータ収集に関する問題点について、議論して行きたい。Google Public DNS もそれらの機能のいくつかを提供するが、全部ではない。
ここからは少々技術的な話になるが、弱点がどこにあるかを理解するためには読んでおく価値があると思う。いろいろな DNS サービスの主たる機能とは、次のようなものだ:
- 正当性: 暗号化された署名を使って、今は DNS サーバが応答の正当性を DNS サーバの全階層にわたり確認することが可能となっている。DNSSEC と呼ばれるこのテクノロジーは、偽物の応答で DNS に毒を盛ろうとする試みを阻止する。一部の DNS サーバが、この機能をサポートしていて、特に Cloudflare、Google Public DNS、Quad9 はこれを明確に提供している。
- 情報漏洩を減らす: 毎回 fully qualified domain name を root や中間のサーバすべてに送信する代わりに、"query name minimization" と呼ばれるプロトコルがドメインをその構成要素に分割する。すると、その DNS サーバは最小限必要なだけの情報を連鎖の中の個々のポイントに送るようになる。これにより中間のサーバによるあなたのクエリーに関する情報収集が防がれ、クエリーが通過するネットワークにアクセスを得た傍受者の意図を挫くことができる。Google Public DNS は、この機能を提供していない。
- DNS クエリーを end-to-end で暗号化: DNS を stub resolver と DNS サーバの間で暗号化する方法はいろいろある。DNS-over-TLS (DoT) と DNS-over-HTTPS (DoH) は互いに非互換であり、それぞれまだ初期の段階にあるが、いずれも DNS クエリーを stub resolver と DNS サーバの間で暗号化する。こうして暗号化された接続が外部の第三者に何かを漏らすことはない。言わば DNS クエリー用の VPN のようなもので、VPN と同じ種類の利点を持つ。Cloudflare は両方ともを、Google Public DNS は DoH を、Quad9 は DoT を提供する。
これらの機能の多くは、あなたが使うアプリやオペレーティングシステムの中にも、個別に独立して存在する。DNSSEC は、階層の個々のレベルにも、またそのドメインの DNS ホストにもそれぞれ証明書を必要とするが、それを実現するためにあなたが出来ることはない。
また、query name minimization もあなたの行動を何も要求しない。Cloudflare はこれと合わせて、存在しないドメイン情報について繰り返しクエリーが出される状況を減らすためのテクニック ("aggressive negative answers" と呼ばれるもの) を使って、グローバルな基盤構造の役に立とうとしている。
DoT と DoH は、最大限の利点を提供できるためにオペレーティングシステムに新しい stub resolver があることを必要とする。あなたも、ソフトウェアをインストールしてそれがシステムの stub resolver のプロキシとして働くようにすることでその利点が得られる。macOS を含むデスクトップのプラットフォームでは、"stubby" というソフトウェアをインストールすれば DoT をテストできる。Cloudflare もいくつかのプラットフォームで DoH 対応を提供する DNS プロキシを提供しているが、かなり複雑なのでインストールは経験を積んだユーザーに任せる方が良い。(私はインストールするつもりなどない!) DoH はいずれ個別のアプリケーションに埋め込むこともできるようになるかもしれないが、もしそうなればオペレーティングシステムが追い付く前に DNS セキュリティの改善が実現されるだろう。Mozilla Foundation が、Firefox の中で直接 DoT を使うテストを実施中だ。
DNS のパフォーマンスを改善する
これら関係するさまざまの段階から想像できる通り、DNS の解決処理は往々にして低速になる。たとえ個々の lookup が高速で処理されたとしても、これらはゲーティング項目だ。一部の lookup は順次処理されるので、一つのリソースがロードされる度にさらなる lookup が必要になって行けば、いくら数ミリ秒のものでも何十個と積み重なれば丸々1秒もかかってしまう。
十年以上も前、OpenDNS が公開 DNS サービスの先駆者として超高速の lookup を提供し、個々のユーザーに向けてウェブはもっと速くなると示してみせた。(OpenDNS は現在 Cisco が所有しており、他の分野に力を注いでいるので、この記事で紹介しないことにした。)
Cloudflare は、パフォーマンスをサービスの利点として主張する。 DNSPerf による調査報告もそれを裏付ける。Cloudflare は 10-12 ミリ秒でクエリーを処理するが、Google Public DNS も Quad9 も、DNS lookup への応答に 30 ミリ秒以上かかっているとのことだ。
以上、利点を述べてきたが、それと引き換えに失うものも議論しておく必要がある。
DNS lookup では、誰を信用するか
好ましくない第三者の目からあなたの DNS クエリーを保護するセキュリティ改善が得られるのは良いけれども、接続の向こう側にある DNS サーバに到着したクエリーは丸ごと暗号解読されて利用できる状態にある。言い替えれば、あなたはその DNS サーバを運営している団体を信用する必要があるということだ。なぜなら、その団体からはあなたの DNS lookup もそれに付随する情報もすべて見えているからだ。例えば stub resolver がクエリーを送信している相手の IP アドレスや、その他の情報もそうだ。それでは、Cloudflare や Quad9 とは何者なのか?
Cloudflare は、分散サービス妨害 (DDoS) 攻撃に対する商用および無料の保護を提供する会社だ。この種の攻撃は、全世界的に頻度もスケールもますます大きな悩みの種となりつつある。この会社は APNIC (Asia-Pacific Network Information Center) と提携関係にあって、この APNIC が 1.1.1.1 および 1.0.0.1 の IP アドレスを所有する。Cloudflare は自らのサービスに広範なプライバシー方針を公表しており、収集する情報も、何を破棄するかも、詳しく規定している。この会社は一部のデータを APNIC と共有するが、APNIC はそれを分析してから題材データを破棄している。
Cloudflare を気に入らないという人たちもいる。反 DDoS キャッシュと再ルートサービスを配備している人たちをいかなる意味でも差別扱いしないという同社の方針を、それらがヘイトスピーチやその他の過激な言論の中で利用されているにもかかわらず長年続けているからだ。また、Cloudflare の CEO がいくつかの過激なサイトを何の警告もなく方針の変更発表もなしに突然、ただ気持ちが変わったというだけの理由で排除したことを問題視する人たちもいる。
Cloudflare はマーケティングの手法としてかなり広範な無料サービスをいくつか提供する。これらは、小規模のビジネスに同社が声を届けて、後になって高額な契約を得るための、効果的かつ圧力なしの手法となっている。(TidBITS は現在、メインサーバのロードを減らすために Cloudflare の無料サービスを利用している。) Cloudflare はまた、自社が処理する DNS クエリーの分析を通じて DNS の誤用 (とりわけ Internet of Things デバイスによる誤用) に関する貴重な情報を集積しているところだ。
これとは対照的に、Quad9 は非営利団体であって、その設立提携会社には IBM、Packet Clearing House、Global Cyber Alliance といった名前が並ぶ。ここが運営するサービスはすべて、情報の暴露とリスクを最小限にしようという使命の一環として無料で提供されるが、Cloudflare と同様に情報の集積も実行しており、それが提携会社にとっては脅威の意識と軽減のために役立っている。Quad9 のプライバシー方針も同様に詳細なものだ。Adam Engst は Quad9 における重要人物の一人と長年の付き合いがあり、その方針が順守されることについては全幅の信頼を置いている。
最後にもう一つ、誰もが Google について知っており、Google が個人のデータを利用して自らの広告ビジネスを運営していることについて誰もがそれぞれの考えを持っている。Google Public DNS のプライバシー方針によれば、ここを通る情報が他の Google サービスのために利用されることはないという。私は数多くの Google サービスやウェブアプリを使っているが、Gmail は使っていないし、この会社が発表する方針が実際の行動とどの程度マッチしているのか、またこの会社が広報活動や政府関係の成り行きについてどの程度関心を持っているのかについて、年々ますます懸念を持つようになっている。
しかしながら、これらの団体のいずれについても、あなたのクエリーがそこに届いた時にプライベートのまま保たれないかもしれないという事実は常に残る。ハッカーが彼らのシステムに侵入することもあり得るし、政府機関が情報を要求したり支配権を握ったりすることもあり得る。公平を期して言えば、どのような DNS プロバイダであっても同じことが言える。あなたの ISP についても同じで、むしろ技術的な攻撃や法律的な攻撃に対しては立ち向かえる力が弱いとさえ言えるだろう。
もちろん、どこかの会社がプライバシー方針や公的声明で約束した内容に拡大解釈を施して、あなたについての情報を他者に販売したり、製品やサービスをあなたに売りつけるための手段としたりするのではないかと心配するのも、決して不合理なことではない。多くの会社がさまざまの方法で私たちの個人的メタデータを乱用してきたことを考えれば、もはや誰かを盲目的に信用することなど、私たちにできるはずがない。
より良い DNS に向けた小さな一歩
Princeton 大学の研究者たちのチームが、Oblivious DNS を提言した。誰かのクエリーが返送結果に再接続される可能性を劇的に軽減できるものだという。残念ながら、そのためには新たな DNS 基盤構造が必要となる。それが可能となるためには、大量の新しい DNS サーバを人々が喜んで試したいと思うことと、Apple、Google、Microsoft などオペレーティングシステムのメーカー各社が自社の顧客にとって十分に利益が大きいと判断することが必要だ。果たしてそれは実現するだろうか? おそらく無理だろう。なぜなら、DNS はあまりにも広く普及し浸透しているので、すべての人のために包括的に修正することは不可能だからだ。
それでもなお、より良いセキュリティとプライバシーに向けたどのような一歩であっても、それは建設的な一歩だ。あなたのデータがどこへ辿り着くのかと考えるのは重要なことであって、あなたのクエリーが Cloudflare、Google、あるいは Quad9 へ行くように切り替えることで、この記事で説明してきたような軽減策を施していない可能性が高いあなたの ISP に任せたままにするより状況が改善されるか否か、それを決断できるのはあなた自身に他ならない。
私はまた、これらの有名どころの公開 DNS サービスがインターネット基盤構造のプロバイダ各社にもっと圧力をかけて、あらゆる DNS resolver にこれらの改善を施して展開するよう促して欲しいものだとも思う。