イベントレポート

Internet Week 2021

「DNSを使わなくなる未来」もあり得る? HOSTS.TXTから続く「DNS」本来の役割と進化の歴史、明日のカタチ

 「Internet Week 2021」において11月19日、恒例となっている「ランチのおともにDNS」が昨年に引き続きオンラインで開催された。今年のタイトルは「DNSの『明日のカタチ』について考える」。講演者である株式会社日本レジストリサービス(JPRS)の森下泰宏氏と芳野光氏がその全体概要を、誕生当時・今日・明日という3つに分けて解説した。

 DNSの誕生は、ARPANETがTCP/IPを標準プロトコルとして採用した年と同じ1983年であり、以来、インターネットにおける基盤サービスの1つとして、重要な位置を占め続けてきた。今回のランチタイムウェビナーでは、そのDNSに起きたさまざまな変化とその理由、今後起こるであろう変化に関する考察などが述べられた。今回の発表に合わせて作られた資料は盛り沢山なので詳細はそちらに譲り、本稿では、この内容のうち主立った部分についてレポートする。

[Internet Week 2021 イベントレポート目次]

  1. 「HTTPSリソースレコード」を使うと何がうれしいのか? 効果への期待と現実を解説 ~今年の「DNS DAY」の話題から(別記事)
  2. 「DNSを使わなくなる未来」もあり得る? HOSTS.TXTから続く「DNS」本来の役割と進化の歴史、明日のカタチ(この記事)

インターネットの急速な普及に対応したDNS

 冒頭、「誕生当時のDNSとその進化のカタチ」を担当した芳野氏は、インターネットが始まった当時、DNSは動かすことが優先であり、悪意の存在を想定していなかったことを述べた(図1)。

図1:誕生当時のDNSのカタチ(プロトコル)

 動かすことが優先、悪意の存在を想定しないという「カタチ」は、当時のインターネットは利用者や利用目的が制限されており、かつ匿名ではなかったこと、コンピューターの処理能力の低さや通信環境がさほどよくなかったという背景を考えると、やむを得なかったとも言える。当時のインターネットはとにかく相手とつながることが最優先であり、通信プロトコルはシンプルで動作が軽く、実装・運用が容易であることが求められていた。

 図1で示される内容は、現在もDNSの解説書でよく見かける内容である。UDPを使用し、平文による問い合わせと応答が1セット、UDPメッセージサイズの最大値が512バイトといった内容は、古くからDNSに関わっておられる方にはおなじみのものであろう(この図はあとで意味を持つので、覚えておいていただきたい)。

 DNSの本来の役割は「名前解決」であり、ドメイン名とIPアドレスを紐付けることで、アクセスしたい相手と名前で通信できるようにすることである。すなわち、分かりにくく覚えにくいIPアドレスに替え、人間にとって分かりやすく使いやすい「名前」を使えるようにするというのが、HOSTS.TXTから続くそもそもの役割である。

 しかしながら、DNSでは当初からドメイン名に対応するIPアドレスだけでなく、より一般的な情報を扱うことも想定していた。それを活用した代表例がMXレコードであり、「そのドメイン名宛ての電子メールを送信すべきサーバー」を情報として登録できるようになっていた。この機能は従来のHOSTS.TXTでは実現が難しく、電子メールの普及がDNSの普及を促進する原動力の1つとなった(図2)。

図2:誕生当時のDNSのカタチ(運用)

 その後、インターネットが広く普及していく中で、DNSにおいても足りない機能の追加や新たなニーズへの対応、信頼性や利便性の向上が図られていった(図3)。機能追加の例としてIPv6アドレスや国際化ドメイン名が挙げられるが、資料では他に、DNS NOTIFYによる権威DNSサーバー間のゾーンデータ同期の迅速化やネガティブキャッシュによる名前解決の効率向上、BIND以外のDNSソフトウェア実装の登場などについても述べられている(図4)。

図3:DNSの進化のカタチ
図4:まとめ:誕生当時のDNSとその進化のカタチ

インターネットの変化に合わせた変化

 続いて森下氏が、「今日のDNSのカタチ」として、DNSが今日を迎えるまでに起こった変化の内容と、それらの理由について解説した。図5において赤字で示された部分は、前出の図1と比して変更があった部分である。これを見ると、プロトコルの基本的な部分にも変更が加えられていることが分かる。特に、悪意の存在を想定し、その対策を行う方向に舵を切ったことが大きいと言える。

図5 今日のDNSのカタチ(プロトコル)

 特に大きな変化は、DNSの問い合わせ手順の変更とEDNS0の登場だろう(図6、図7)。それまでは、UDPで問い合わせを始めなければいけなかったクライアントやフルサービスリゾルバーが、最初からTCPで問い合わせを送れるようになった。また、DNSに汎用的な機能拡張の仕組みを提供するEDNS0の導入は、その後のDNSにとって極めて重要な変化となった。

図6:DNSに起こった変化(基本プロトコルの変更)
図7:変化の理由(基本プロトコルの変更)

 DNS応答の偽装を防止するための仕組みであるDNSSEC(図8)や、ユーザーのプライバシー(誰がいつどこにアクセスしようとしているかという情報)保護のためのDNS通信の暗号化機能が追加されたこと(図9)も、大きな変化の1つである。森下氏が示した「(DNSの仕様を書いた)RFC 1034・1035には『security』『privacy』という単語はない」という言葉は、誕生当時のDNSにはそれらが存在していなかったことを象徴している(図10)。

図8:DNSに起こった変化(セキュリティ機能の追加(1/2))
図9:DNSに起こった変化(プライバシー機能の追加)
図10:変化の理由(セキュリティ/プライバシー)

 また、近年のCDNサービスの普及に伴い、DNSとCDNサービスをより円滑に連携させるための仕組み作りも、積極的に進められるようになってきた。図11で示されているEDNS Client Subnetの役割は、問い合わせ先の権威DNSサーバーに対して問い合わせ元の情報(フルサービスリゾルバーに問い合わせてきたユーザーが接続しているIPアドレスブロック)を伝達することで、DNSを用いた広域ロードバランシングを円滑に動作させることにある。

 CDN側は、広域に分散させたコンテンツサーバーのうち、ネットワーク的に近いコンテンツサーバーにユーザーのアクセスを誘導したい。そのためには、ユーザーがどのネットワークに接続しているかを知りたいわけである。以前は、ほとんどのユーザーがネットワーク接続を提供している事業者のフルサービスリゾルバーを使っていたため、ユーザーとそのユーザーが使うフルサービスリゾルバーは同じネットワークに接続されていると見なしても問題は無かった。

 しかし、Google Public DNSやCisco OpenDNSのようなグローバルなパブリックDNSサービスが出現し、ユーザーがそれらを使うようになると、ユーザーとそのユーザーが使うフルサービスリゾルバーのネットワークは同じであるという前提が崩れ、アクセス元のフルサービスリゾルバーのIPアドレスをもとにした広域ロードバランシングが適切に動作しなくなってしまう。この問題に対応するため、DNS側で工夫をしてアクセス元の情報が含まれるようにしているのである。

図11:DNSに起こった変化(DNS以外のサービスとの連携)
図12:変化の理由(DNS以外のサービスとの連携)

 森下氏からはここまでのまとめとして、インターネットの変化を受けてDNSも変化し、「大人として振る舞う」ことが求められるようになってきたことが述べられた(図13)。ランディ・ブッシュ氏が2000年のIETFで発表した「The DNS Today - Are we Overloading the Saddlebags on an Old Horse?(参考訳:今日のDNS ? われわれは古馬にサドルバッグ(注:鞍に取り付けるかばん)を載せ過ぎているのか?)」を引用しつつ、DNSはもう限界だと言われながらも20年以上が経過したこととあわせ、DNSにかかる期待と負担はますます大きく重くなってきていることが説明された。

図13:まとめ 今日のDNSのカタチ

明日のDNSは、まだDNS

 未来の予測は難しく、分からないことも多い。そこで、「明日のDNSのカタチとは」では、今起こりつつある変化から今後起こりうる変化の兆しを捉え、サービス形態や利用形態がどう変わっていくかを予測したということである。

 今起こりつつある変化として挙げられたのは、HTTPSレコードとOblivious DoHの2つである(図14、図15)。

 HTTPSレコードは、ゾーン頂点の別名、ウェブサーバーの優先度設定、HTTPS接続情報の提供といったHTTPSサービスの利用・提供に関するさまざまなニーズを一度に実現する「野心的な内容」(森下氏)を持った、新しいDNSリソースレコードである。

 Oblivious DoHは、ユーザーのDNS問い合わせ・応答を中継するプロキシを導入し、HTTPSで暗号化した通信路にエンドツーエンドで暗号化したDNSデータを流すようにすることでユーザーのIPアドレスとDNS問い合わせの内容を同時に入手できないようにし、プライバシーを保護するための仕組みである。Oblivious DoHは、AppleがiCloud Private Relayで採用している。

図14:起こりつつある変化(HTTPSレコード)
図15:起こりつつある変化(Oblivious DoH)

 どちらもインターネットのサービス形態・利用形態の変化への対応であり、今後起こるであろう変化も同様に、インターネットのサービス形態・利用形態の変化が鍵となるであろうことが説明された(図16)。

図16:変化の理由

 では、今後起こるであろうインターネットの変化とは何であろうか。森下氏は、現状で見られる変化の兆しとして、通信形態の変化と移動体通信の強化を挙げた(図17)。

図17:今後起こり得る変化の兆し

 インターネットは、ユニキャストと呼ばれる単一の相手に対してデータを送信するという形(一対一)をベースに、IPアドレスを使用したエンドツーエンドの通信を行うことで発展してきた。しかし、現在では、端末は利用者とともに自由に移動するし、CDNサービスやIoTデバイス間の通信で見られるような、一対多や多対多のコミュニケーションをより効率よく実現したいというニーズも出てくるようになった。加えて、動画配信をはじめとする大容量のデータ通信が頻繁に行われるようになったことで、通信帯域が常に圧迫されるようにもなってきている。

 そのような状況下で出てきたものが「情報指向ネットワーク(Information/Content-Centric Networking:ICN)」と呼ばれる考え方である。この考え方では、欲しいコンテンツを示す「名前」を指定して要求すると、ルーターが自分のところに要求元が求めるコンテンツがあるかを確認し、持っていればそれを案内する。持っていなければ、隣接するルーターに要求を転送するという動作になる。これにより、自然にネットワーク的に近いところからコンテンツが得られることになる。

 DNSではドメイン名を指定して対応するIPアドレスを得るが、ICNではコンテンツの名前を指定してコンテンツを得る、これまでとは異なる方向性を持った新しいネーミングサービスである。これが広まるかどうかは、使いやすさや実効性の面などの要考慮点や課題も多く、流動的な部分が多い。しかし、将来、DNSに替わる何かしらの強力なネーミングサービスが出現し、ユーザーは主にそれを使うようになることも、可能性としてあり得ると考えておくべきであろう(図18)。

図18:利用者が直接にはDNSを使わなくなる未来

 森下氏は、もし新しいネーミングサービスが開発されるとしたらという前提で、「最低限、この3つの問題を解決して欲しい」ということを述べている(図19)。確かに「データの更新に冷たい」「運用ミスに冷たい」「切り替えがルーズ」という、DNSが「生まれながらに持ってしまった」特性に起因するトラブル事例や障害事例は、枚挙にいとまがない。

図19:未来のDNSに望むこと

 現実を見ると、DNSに替わるネーミングサービスは当分出てきそうもない。加えて、DNSはさまざまなサービスから出されるさまざまな要求を飲み込んでいく柔軟性を兼ね備えている。そうした状況を考えると、森下氏の「明日のDNSは、まだDNSであろう」という言葉には同意しかない(図20)。

図20:おわりに:明日のDNSのカタチとは

 今後、インターネットのサービス形態・利用形態が大きく変化し、それに適合する強力なネーミングサービスが開発され普及しても、DNSという仕組みが一気に置き換えられるということはないだろう。利用者がDNSを直接使わなくなっても、インターネットに接続されたホスト同士を結び付ける基盤技術として、重要な位置を占めていくことに変わりはないはずだ。

 森下氏は、最後に「明日の、そして未来のインターネットを支えるため、一緒に頑張っていきましょう」という言葉で締めくくった。今回の資料は、すでにJPRSのサイトで公開されている。時代に伴うDNSの変化がよくまとまっているので参照されたい。

図21:参加者に届けられたプレゼント

[Internet Week 2021 イベントレポート目次]

  1. 「HTTPSリソースレコード」を使うと何がうれしいのか? 効果への期待と現実を解説 ~今年の「DNS DAY」の話題から(別記事)
  2. 「DNSを使わなくなる未来」もあり得る? HOSTS.TXTから続く「DNS」本来の役割と進化の歴史、明日のカタチ(この記事)