DNS is many things to many people --- perhaps too many thins to too many people.
Paul VixieDOMAIN NAME SYSTEM (DNS) は、階層的な、分散化された、自律的で、信頼性のあるデータベースだ。類を見ないリアルタイムな性能を世界中の人々に提供してくれる。Web ページを含むすべての TCP/IP 通信 は、最低一つの DNS 問い合わせから始まる。DNS は偉業だと言えるだろう。
DNS が何である かという理解をはっきりさせるためには、DNS が何でない かということと対比させなくてはいけない。インターネットのマーケットは、人類の活動の換金化に無限の創造性を与えてくれ、それはしばしばある種の仲介ビジネスの形をとる。DNS にとって、その拝金的な仲介ビジネスは、欺瞞を意味する。私たちに拝金的な仲介ビジネスをもたらした先駆者たちは、自分たちが売っているものは欺瞞なのだとは言わないが、(諺にあるように）ある鳥が鴨のように見え、鴨のように泳ぎ、鴨のように鳴くならば、それはたぶん鴨なのだ。
DNS のすべての誤用が欺瞞の源だというつもりはない。だが、頻繁にみられる DNS の濫用として、DNS はディレクトリシステムではないにも関わらず、その目的で用いることが挙げられる。ディレクトリシステムでは、人は大まかな問い合わせを行い、それに近い応答を得ることになる。 なんなら、冊子としての個人別電話帳を調べることを考えてみればいい。ユーザは、探す対象がどのようにリストされているのかを正確に知っていて見つけるのではなく、推測か誰もが考える思いつきから探し始めることで見つけ出すというのがしばしばだろう。DNSにはそのような仕組みはない。すべての問い合わせと、すべての応答は厳密なのだ。しかし、DNSには、近似的な照合という誤用を可能にしてしまい、そのために他のすべての人々が相当なコストを払う必要が生じるような少なくとも2つの機構があり、この誤用は広く利用されてしまっている。
最初に広がったDNSの欺瞞の手口は、DNS問い合わせを地域分散に用いることだった。Akamaiのようなコンテンツ配信ネットワーク(CDN)や、Cisco Distributed Dirctor は、受け取るDNS問い合わせを分析して、ウェブブラウザの誘導を行う。これらのサービスや製品は、DNS問い合わせの送信元IPアドレスを見て、それらが多くの複製された配信サーバのどれに近い場所からのものかを推定する。各配信サーバのシステムやネットワークの負荷測定や、問い合わせ元との距離に基づいて、要求されたURIのドメインに最も近くまたは最も良い状態にあるサーバにその要求が向くように、DNS応答が生成される。
この手法からはたくさんの問題が発生するが、いずれもCDN運用者のビジネスには影響しない。まず最重要なこととして、このポリシーベースのデータ (DNSのウソ応答)をキャッシュしたり再利用することを止めるか厳しく制限することが必要だ。 かつてDNSのパフォーマンスとスケーラビリティに不可欠だと考えられていたキャッシュや再利用は、利用者Aを意図したポリシーベースの応答が利用者Bからも見えてしまう場合、 (例えば負荷が変わって新しい調整がなされたりしても）利用者Bは利用者A向けの回答を参照してしまう。 かといって、キャッシュを止めてしまうとDNS参照の頻度が上がり (おそらくトランザクション単位で料金設定しているCDNの収益増大に貢献する）、アクセスする側のネットワーク負荷を上昇させ、平均トランザクション時間を少し高めることになってしまう。
さらにいうと、このおかげで、DNS問い合わせ元のIPアドレスが、エンド側ブラウザのネットワーク位置のヒントを与えるという想定が賢明とはいえなくなってきている。なぜなら、CDNが受けているDNS問い合わせは、エンドシステムから来るものではなく、キャッシュにヒットしなかったDNS再帰サーバからくるからだ。 また、CDNが性能をあげるための評価をルール化できるように、再帰検索サーバを地域分散しているISPさえある。しかしながら、多くの再帰検索サーバは国単位、大陸単位、あるいは半球単位にあり、CDNにとっては、うまく連携したスーパーノード群を配置し、多くの地域外からの問い合わせをいつも受けられるようにしておく必要がある。
CDNを使う主な利点は、小細工のないアウトソーシングを利用することと全くかわらない。もし、うまく機能しない場合は元コンテンツを所有している誰かが訴えられるだけだからだ。そうした責任の盾としてDNSシステムの性能と安定性にコストをかけなければいけない、というのがせいぜい不運なだけだ。地域外からの多くの問い合わせを受けるスーパノードをいまだに必要とするCDNがあるなら、必要な素直な手法は、正直にDNS応答すること、そして従前の擬似ランダム応答による分散メカニズムを機能させることだ。従前の擬似ランダム化技術には特許はなく、これまでのCDNの買収において誰も首を切られていないことに気づけば、そうしたやり方で、さらなるコンテンツ配信が今後10年間は続いていくことを期待できるだろう。
かなり頻繁(毎秒数百万回くらい)に世界の誰かがDNSに存在しないドメイン名の検索を行っている。たぶんこれはウェブブラウザを使っているユーザーのタイプミスによるものか、ウェブ上の間違ったリンクか、ハードやソフトのエラーが間違ったDNS問い合わせを送り出しているものだろう。いずれにしろ、応答は一般に NXDOMAIN (時にRCODE=3と記述される)であるべきで、これらの否定応答は、他の種のDNS情報と同様にキャッシュ可能だ。DNSはポリシーではなく事実を表現するようにデザインされているからだ。 こうした否定応答を受け取ったネットワークアプリケーション (ウェブブラウザとかメールサーバとかTCP/IPを用いるおよそすべてのもの）は、その応答をエラーとして扱い、その問い合わせの要因となった自身の作業を拒絶するべきである。ウェブブラウザだと、拒絶はエラーページという形をとる。メールサーバであれば、拒絶は「不達メール」という形になる。大きいものでも小さなものでも、新しいものでも古いものでも、全てのTCP/IPアプリケーションは NXDOMAIN への対処の仕方を知っている。
ウェブはルールを変えた。ウェブは若く、インターネットはウェブ以前からあったし、ウェブ以降も存在し続け、ウェブよりずっと大きいのだとしても、エンドユーザが見ているのはウェブだという事実は残る。 広告屋は、エンドユーザこそが収益の源泉だと説明するために、あらゆる言葉を使う。たとえば、「インプレッション」、「クリックスルー」、「アイボール」といった単語がそれだ。広告主たちは、「インプレッション」が可能であるのに、いったい全体、なんで NXDOMAIN なんか返すんだと問うだろう。それゆえ、君が存在しないドメイン名を尋ねると、扱いを知っているはずの NXDOMAIN に変わって、徐々に、 (あてにならない、誤った、欺瞞の）肯定応答を返されることになっていくだろう。
例えば、私が私の再帰検索サーバに存在しない名前を問い合わせると、NXDOMAIN だと教えてくれるだろう。一方、もし私が OpenDNS の再帰検索サーバに存在しない名前を問い合わせると、広告サーバを指し示す NOERROR 応答を送ってくるだろう。私が都合のよい例として OpenDNS を挙げているだけであることに注意して欲しい。OpenDNS がこの仕組みを発明したわけではないのだ。実際、Nominum 社や他の DNS ベンダーたちは、今やこうした仕掛けを付加した再帰検索サーバ製品を売って、世界のいくつかの ISP がこれをサービスし、また、そうした ISP の数は増えつづけている。なぜそんなに多く？ 答えは簡単で、NXDOMAIN 応答をすり替えないやつは、「インプレッション」による収益を得られないからだ。
いくつかの ISP が OpenDNS やその他の外部 DNS サーバへのアクセスをブロックして、顧客が ISP 自身のサーバを使うよう強制しているとの未確認の苦情がある。未確認ではあるが、私には苦情は確かなのだとわかる。ISP たちが踏みとどまるべき一線は非常に薄いものであり、金づるがドアから出て行こうとするのを、黙って見ていることはできないのだ。
そうした儲けを掻き込む極端な願望を実演した実話がある。何年か前、ICANN (Internet Corporation for Assigned Names and Numbers) との契約により .COM の運用をしている VeriSign 社が、.COM のトップレベルのゾーンに、その権威サーバが NXDOMAIN を応答を返さないようにワイルドカード (*.COM) を加えた。NXDOMAIN の代わりに、彼らは広告サーバである SiteFinder のウェブサイトのアドレスを含む応答を生成するようにしたのだ。これに対しコミュニティからの叫び声は高まり長く続き、ICANN がこのナンセンスを止めるための訴訟の用意をするより早く、多くの人々が .COM からの委譲の形 (例えば Google.com の権威サーバを教えてくれるような形）をとっていない応答を NXDOMAIN に書き戻すパッチを彼らの再帰検索DNSサーバに当てた。また、いくつかのISPたちは、SiteFinder の応答を ISP 自身の広告サーバを指すものにすり替えるようなロジックを彼らのポリシーベースのルータに組み込みもした。
NXDOMAIN は、DNSからの正確なエラー信号に依存する多くのアプリケーションに、利益をあげるための仕掛けを仕込むべく設計されたのではない。例えばウェブのクッキーで用いられている「同一起源信頼モデル(same origin trust model)」を考えてみよう。もし君が Google.com のクッキーを持っていて、KJHSDFKJHSKJHMJHER.GOOGLE.COM へのリンクへ誘導され、その結果の NXDOMAIN 応答がある広告サーバの肯定応答にすり替えられたら、HTTP GET 要求を送信する際に、Google.com のクッキーをその広告サーバに送信してしまうことになるだろう。Google.com のクッキーであればそう悪いことにはならないかもしれないが、BANKOFAMERICA.COM のクッキーだと現実に問題が生ずるだろう。 (「同一起源信頼モデル」問題について 教えてくれた Dan Kaminsky に感謝）
電子メールでも MX 問い合わせの際に応答のすり替えが起きる。多くの NXDOMAIN すり替え機構は、A レコードの問い合わせのみを引き金とすることでこれを避けようとするが、問題が生じないようにするためにはキャッシュを off にしなくてはいけない。NXDOMAIN は問い合わせタイプに依存しないし、SMTP の開始手続きではレコードタイプ = MX が得られないとレコードタイプ = A にフォールバック動作するからだ。それに近い防御 (訴訟を避けつつ利益を呼び込む設計）は、問い合わせのドメイン名が WWW. から始まっている場合にのみすり替えロジックを発動するというアイデアを含んでいる。…しかし、私の知る限り、WW .で始まったり、.CM で終わったりするようなタイプミスはたくさんあるし、それゆえ、長い目で見て望みは持てない。すでに過度のお金がつぎ込まれており、誰もそれが続くことを望んではいない。
本稿を書いている今ここに IETF ドラフト (proto-RFCと考えてよい）がある。これは、サービスプロバイダに求められる推奨設定と DNS リダイレクトの使用法に関するものだ。 (http://tools.ietf.org/html/draft-livin-good-dns-redirect-00) ...訳注：http://tools.ietf.org/html/draft-livingood-dns-redirect-00 のTYPO
この文書のゴールは、サービスの共通の枠組みを提供するためには DNS の欺瞞がどのように配信されるべきかについてのいくつかのルールを、この成長マーケットにいるすべてのベンダーと運用者に贈ることだ。一部のラッダイトたちは、この領域の「標準のベストプラクティス」は単純に何もしないことだと思っているかもしれないが、それは非現実的であり、私たちは標準化のアクションに直面している。 DNS 技術の標準仕様として、すべての DNS サービスがこの(新しい)方法で配信され、私たちの子供らが(今日の)エンドトゥーエンドなDNSの手法を(古風な)8トラックテープのように思うようになる未来が目に見えるようだ。
この文書は、この機能に関する議論に対して潜在的な貢献をするものだ。というのは、この機能を排除したければ、このサービスはネットワーク層 (言い換えれば MAC アドレスか装置のポート番号と結びつくべき）にあるべきで、トランスポート層の属性ではないと示唆しているからだ。他の種類のどの情報とも同様にはみえない spam を排除することはそれを受け入れることと比べて不経済であり、したがって本 IETF ドラフトの著者が Web クッキーは不十分であると指摘したことは議論にとって価値がある。 他の点では合意がないかもしれないが、少なくともこの点は議論のテーブルにある。この文書はまた、「法的に命じられた」DNS リダイレクション〜それはまさに正真正銘の悪夢であり私たちができるだけ速やかに歴史的興味の対象となってほしいと望むもの〜についても述べている。
この IETF ドラフトで超最高な部分は、以下に示すセクション 10 - DNSSEC Consideration - です。「DNS セキュリティ拡張が DNS リダイレクトに対して問題を生ずる唯一のケースは、検証用スタブリゾルバで起こる。このケースは今のところ普及が広がっておらず、適用可能な ISP や DNS プロバイダが、リダイレクトされた応答に署名できるように設定したトラストアンカーを利用することで緩和できるだろう。セクション 9.7 の前半で注意書きされているように、正規の応答の不正なリダイレクトも、DNSSEC の信用検証問題を引き起こすかもしれない。」
15年前、たくさんの象牙の塔の理論家たちが IETF に集まって言った。「DNS を安全にしよう」と。脅威モデルは時をこえて進化し、このプロトコル拡張 (DNSSEC) はほぼ普及の準備ができ、DNS での詐称を捕まえ無視できる可能性がおよそ見えてきている。 DNSSEC の標準化ほど時間がかかったものはなく、無粋さと複雑さで委員にとってのホラーとなったものはないが、ようやくDNSSEC はこう動くだろう、現在の市場で DNS の詐称を抑制できる助けになるだろうという見通しが立ったところだ。
DNS において、データを生成するのは権威サーバであり、それらは1つ以上のゾーンの権威を移譲されている。今日的には、DNS ゾーンというのはある名前の下すべてであると考えられる。例えば、www.google.com は Google.com ゾーンにある。DNSSEC はこれらのゾーンを公開鍵暗号を用いて署名し検証できるようにする。署名用秘密鍵はゾーンの管理者によって実際の個々のレコードのための署名レコードを生成するのに使われる。公開鍵は再帰検索サーバが受け取ったデータが、その公開鍵に対応する秘密鍵の持ち主によって署名されているかを検証するために用いられる。(検証用の)公開鍵は、Google.com ゾーンの公開鍵は .COM ゾーンで公開されるといったように、ゾーンの鍵を親ゾーンに置く形でDNSによって公開される。.COM の公開鍵がどう公開されたらいいかという長くて面白くない話は、本稿と密接な関係がないので、あえて省略する。
理論的には、詐称されたくない末端のシステムの所有者は、詐称されたくないと思っているゾーンの管理者と、彼らが共に DNSSEC を導入するならば手を組むことができる。NXDOMAIN を受信したいのに、今日、広告サーバへのポインターを受け取ってしまうアプリケーションは DNSSEC 世界においては「署名がありません」というエラーを受け取る。DNSSEC は署名が存在するはずであることを検証サーバに伝える仕組みを持っているのでエラーになるのだ。大多数のケースにおいて、ゾーン管理者は彼らのゾーンが詐称被害に遭っていることを気遣わない点に注意して欲しい。それゆえに DNSSEC はほとんどいつも静かなままなのだ。また、これは原型の DNSSEC の脅威モデルではなかったことを考慮してほしい。私たちは、2008年に Dan Kaminsky が発見したようなオンラインでの改竄を止めなくてはいけないと本当に思った。そこへ、NXDOMAIN によるすり替えのような中間者攻撃を止めるアイデアが、ちょうど花開いてきたのだ。
DNSSEC は「愚かな DNS トリック」を用いている CDN プロバイダたちの生き残りを面倒にするだろうが、彼らは、問い合わせ元の素性に基づいてそれぞれのための異なったポリシーベースの応答を生成し、それら異なった応答すべてに対してあらかじめそれぞれに対応して用意した鍵を用いて、完璧に正しい署名をつけて送り返すということが可能なので、戦いは終わらないだろう。
DNSSEC はまた、システム管理者やアプリケーション開発者の日常をも面倒なものにするだろう。私たち (ISC = BIND な人々）は、改善可能なことを BIND 9.7 に施しているし、他の多くのサービスや技術の提供者が同じように存在している。DNSSEC のキラーアプリケーションは、X.509 を使うことなく相互認証できるウェブサーバとウェブブラウザだ。 (ボランティアは集結し奮ってこれを実現させよう）
Microsoft や Mozilla などのブラウザの実装者たちは、素敵な「自動補完」をしてくれるグラフィカルなフロントエンドから URI を受け取りつつ DNS 検索を行うことをやりはじめた。これは http://www.cnn.com/ という URI を打ち込んでいる間に、ブラウザが W, WW, WWW, WWW.C, WWW.CN, WWW.CN, WWW.CNN というような問い合わせを生成するということだ。ここではトップレベルドメインが何であるかがブラウザにあらかじめ内蔵されていて分かっているので、まだ救いがある。例えば、ブラウザは WWW.C という問い合わせは実際には発しないだろう。しかし、中国のドメインである、WWW.CN や、コロンビアのドメインである WWW.CNN.CO は問い合わせてしまう。
Microsoft や Firefox にとって一つの単純に思える解決策は、中国やコロンビアの DNS サーバのハードと回線 (そして間違いなくたくさんの関係するトップレベルドメインの運用者たち) を買収することだが、残りのネットワークから生ずる愚かで無駄なトラフィックや情報の漏出を止めることはできないだろう。本当にベストな解決策は、こういう愚かな機能は、普段は止めていればそういうことは起きないのだからオプションにしておいて、私たちは (オプトインかオプトアウトかの）デフォルトがどうあるべきかの議論をすればいいのだ。自動補完機能のようなものを提供することを目的として、打ち込まれた文字列が正規のドメイン名か否かを判定するために予見的に DNS を用いたというのは、DNS の歴史の上で初めてのことなのだ。それは他の多くの新しいDNSの利用法でも同じことが言えるが、DNS はそれらのために設計されてはいない。
仮定の話として DNS の設計においてひとつ言えるのは、ドメイン名が上位から下位へ向かって (COM.CNN.WWW のように) 書かていたらよかったかもしれないということだ。そうなっていたら、グラフィカルなファイルシステムブラウザにおいてそうなっているように、部分的な名前補完ができただろう。でもこれは広く普及してしまった既存の実装の便宜を考えると、私たちが生きているうちは変えることはできないだろう。ブラウザの実装者たちに、よりスマートに、私たちのネットワークの DNS トラフィックにもっと考慮してくださいよとお願いすることが、私たちができることのすべてだ。
DNS は何でないか、それは、すり替えサービスでもなければ、ポリシーベースの情報の配信メカニズムでもない、ということだ。 DNS は、ポリシーではなく事実を表すように設計されていた。しかし、それが大変うまく動いてユビキタスとなっているので、企業家がそれを機会に満ちた未開の地だと期待するのはあまりに当然のことだ。そうした革新者たちが多少そこから食いぶちを持っていったとしても、DNS を実装し、拡張し、普及させ、世界規模のDNSサーバの運用を維持することに携わっている私たちは、全てが動きつづける方法を見い出し続けることだろう。
DNS のインストールベースは途方もないほど巨大なため、本稿で述べたことは不幸な所見であり手の届く範囲では解決の手段はないように見える。DNS が不十分でありながら、それでもあえて人々が利用可能でありたいと願うときの任務は、現在の設計を基礎としていくことしか考えられない。現在行われていることは、未成熟な市場でシェアを存分に奪い取ろうとする革新者が割り込もうとする状況に対し人々を守ろうとする情報戦争だ。嘘つきDNS対DNSセキュリティはそのわずかひとつの例にすぎないのだ。
著者 Paul Vixie (雑誌 Wired に『DNS のゴッドファーザー』と記された) は DNS の誤りと謎を解くことに20年間以上を費やしている
CACM のサイトを探すとき、うっかり cacm.org ではなく cacm.com を参照してしまうと、その結果、このように広告画面にリダイレクトされてしまう。これは NXDOMAIN のすりかえによって実現されている。
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.