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.