Internet Infrastructure Review（IIR）Vol.59
2023年6月23日

4. フォーカス・リサーチ（3）

IIJとDNSの30年

4.1 はじめに

従来はもっぱら学術機関での利用に限られていたインターネットに、商用サービスとして日本で初めて接続できるようにしたのがIIJでした。1993年11月のことです。それから今年で30年になります。本稿では、この30年の歩みをDNSの視点で振り返ります。

4.2 1990年代：接続サービスと共に

DNSはなかった

IIJは、1992年12月にインターネットイニシアティブ企画として設立され、翌5月に現在の社名に改められました。7月には「UUCPサービス」が、そして11月、ついに国内初の商用インターネット接続サービスである「インターネット接続サービス」が開始されました。

DNSはホスト名からIPアドレスを調べるサービスであり、インターネットを利用するには必須のものです。そのため、接続サービスを契約するとキャッシュDNSサーバがセットで付属してくるものとして扱われるのが一般的です。その現在の常識からすれば、IIJにおけるDNSの歴史もこのときに始まったものと考えそうですが、実はそうではありませんでした。提供されたのはあくまで専用線による接続サービスだけであり、キャッシュDNSサーバは含まれていなかったのです。

国内初のサービスとはいえ、利用者は学術ネットワークとしてのインターネットを知っている人が主でした。インターネットとは中央集権ではなく分散システムである。参加者は平等であり、必要なものは自分で何とかするか、足りなければ参加者同士の相互扶助で補完する。IIJとユーザの双方がこのような認識を共有していたと思われます。IIJが提供するのはあくまでインターネットに接続するところまで、DNSやメールやネットニュースなど接続した後の利用に必要になるものは自分で用意してほしいというのがIIJの立場であり、ユーザもそれが当然と受け止めていたようです。

最初のDNSサーバ

ユーザが利用できるキャッシュDNSサーバが最初に提供されたのは、1994年5月の「ダイアルアップIPサービス」からでした。専用線を使った常時接続ではなく、電話回線を使って必要なときだけ接続するというもので、小規模な法人や個人でも利用できました。NTTの電話料金夜間定額サービスであるテレホーダイはまだ始まっておらず（1995年から）、接続したら必要な情報だけ収集してすぐ切断するという、当時主流だったパソコン通信と同じような使われ方でした。専用線接続と異なりユーザが必要なサーバを用意するにはそぐわない利用形態のため、キャッシュDNSだけはIIJ側で提供することになったようです。

キャッシュDNSサーバを提供するようになってからも、権威DNSサーバについてはユーザが用意してくださいという立場は変わりませんでした。とはいえ、DNSは教科書どおりであればプライマリ/セカンダリの2台構成にするものであり、当時はその両方をユーザで構築するのも簡単でなかったことから、セカンダリだけはIIJで引き受けるケースもありました。これは商売ではなく、インターネットの対等な参加者としての相互扶助の一環として行われていたようです。そのセカンダリDNSとしてゾーンを収容していたのは、なんとダイアルアップIPサービス用のキャッシュDNSサーバでした。現在の常識では考えられない構成ですが、当時は規模が小さく、相乗りさせることが合理的な判断だったようです。

相互扶助の精神で運用されていたセカンダリDNSとして重要なものに、JPドメインがあります。IIJに依頼されることになった経緯が分かる文書は今でもJPNIC上で公開されています（注1）。

IIJでは1994年からJPドメインのセカンダリを引き受けるようになり、以来現在に至るまで運用が続いています。その後は単なる扶助を越え、2001年にはいち早くIPv6に対応したり、2004年には海外拠点を設置してAnycastに対応するなど、先進的な機能も積極的に取り入れ、JPドメインの安定運用のお手伝いをさせていただいています。

インターネットの普及

1990年代半ばは、インターネットが個人の手に届くようになった時期です。1994年9月、インプレスよりINTERNET magazineが創刊され、1995年11月にはTCP/IPを標準搭載したWindows95が日本でも発売されました。IIJ以外にも多くのISPが次々と誕生したのもこの時期です。

1996年12月、個人向け接続サービスの需要に応えて始まったのが「IIJ4U」です。大規模な個人向けサービス専用に設備構成を設計しており、可用性確保のため2台のキャッシュDNSサーバを異なるネットワークセグメントに置くという、今となっては常識の構成もここで初めて採用されました。

その頃には法人向け接続サービスでもキャッシュDNSサーバの提供が始まっていましたが、基本はお客様が自前で構築・運用するという点は変わらず、どうしてもそれができない場合にのみ使ってくださいという形態だったようです。これが標準提供になったのが、1997年11月に開始された「IIJエコノミー」からです。

SOHOという語は既に死語になった感はありますが、Small Office・Home Officeのことで、自宅や小規模な事務所などを仕事場にする働き方のことです。このSOHO向けの廉価版専用線サービスがIIJエコノミーで、従来の法人向け接続サービスとは異なり、ユーザが自分でサーバを設置、運用するような利用を前提としていませんでした。つまり、キャッシュDNSサーバもIIJが用意することになったのです。

このようにしてキャッシュDNSサービスの基礎が確立しました。この後ADSLや光回線、VPN、モバイルなど様々な形態での接続サービスがリリースされていきますが、回線側が変わっても、キャッシュDNSの方は設備の増強などをしつつも基本は変わりません。

4.3 2000年代：DNS単独のサービス開始

1999年、アメリカの株式市場はインターネット関連企業を中心に大きく値上がりしました。インターネットとはまったく無関係の企業でも、「ドットコム」をつけた社名に変更するだけで株価が2倍になったと言われています（注2）。この異常な高値は2001年の暴落で幕を閉じ、今では「ドットコム・バブル」として知られています。このドットコムとは、もちろんgoogle.comやyahoo.comなど、ドメイン名末尾の".com"のことです。

日本では1991年のバブル崩壊以降、平成不況、就職氷河期が依然と続いており、アメリカほどのバブルは起きませんでした。しかし、ソフトバンクの株式時価総額がトヨタ自動車に次いで2位になるなど、この時期に大きく成長した企業の多くがIT関連でした。

株価の上昇は一時的なバブルでしたが、自社専用ドメインを持つ習慣は完全に定着しました。大手企業やインターネット関連企業だけでなく、それ以外の企業も取得するのが当然になりました。ドメインを取得しても権威DNSに登録しなければ使えません。IIJはそれまで権威DNSが必要ならば自前で運用してくださいというスタンスでしたが、それには相応の専門知識が必要です。インターネットが一部の「分かっている人」向けだった時代はこのとき既に過去のものになっており、サーバ運用のノウハウを持たない人でも権威DNSに情報を載せたいという需要は大きくなっていました。

これに応えるため、2000年3月、ついにDNS単独のサービスを開始します。それが権威DNSの運用全般とWebからのゾーン情報の編集を可能にする「DNSアウトソースサービス」、セカンダリサーバだけを引き受ける「DNSセカンダリサービス」、そしてドメインの登録維持管理を行う「ドメイン管理サービス」です。

それまでJPドメインにはco.jp（企業）やac.jp（学術機関）などといった属性に基づく分類がありました。ドメインとは組織を表すものであり、だからこそ1組織につき1ドメインしか登録できませんでした。しかし2001年になって、組織に紐づかず、登録ドメイン数にも制限のない汎用JPドメインの制度が開始されました。これにより組織ごとのドメインだけでなく、商品やブランドごとに専用ドメインを登録する事例も増え、ドメイン登録数、そしてDNSアウトソースサービス/セカンダリサービスの利用は年々拡大していきました。

また、組織に属さない個人でもドメインを持つことは珍しくなくなりました。そのため、2002年3月、独自ドメインによるメールとWebそしてDNSのホスティングを個人向けに機能を抑えるかわりに低廉な料金で利用できる「IIJmioパーソナルドメインサービス」を、更に2003年3月にはDNSホスティングのみの「IIJmioシンプルDNSサービス」の提供を開始しました。

DNSアウトソースサービス、DNSセカンダリサービス、ドメイン管理サービスの3サービスはその後も機能追加や設備増強を繰り返しながら20年以上も継続する長寿サービスになりました。このうち特に大きかったのがDNSSEC対応と、オプションサービスである「サイトフェイルオーバーオプション」でしょう。

DNSはインターネットの利用に欠かせない要素技術の1つですが、1980年代に設計されたプロトコルであるため、当初想定されていなかった、あるいは無視して問題ないと思われていた欠点も含んでいます。その1つが、キャッシュポイズニング攻撃や中間者攻撃などにより応答パケットが偽造されたとしてもそれを検知するのが難しいという点です。詳細については長くなるのでここでは割愛しますが（注3）、DNSの登録情報に電子署名を付与し、応答を受け取った側はその署名を検証して情報の真正性を確認できるようにしたのがDNSSECです。

2010年7月、DNSのルートサーバでDNSSEC対応が開始され、同年12月にJPゾーンがDNSSEC署名されました。IIJのドメイン管理サービス、DNSアウトソースサービスでは2011年1月からDNSSECに対応しています。DNSSECは署名鍵の生成やゾーンへの署名など、これまでのDNS運用にはなかった煩雑な作業が必要で、そのため10年以上経った現在でも敬遠されがちな技術ですが、これらの作業をIIJのサーバ側が自動で行い、手間をかけずにDNSSECを利用できるようにしました。

DNSに登録された情報は静的なもので、応答を変更するには人間がそのたびに情報を書き換える必要がありました。2015年3月にDNSアウトソースサービスのオプションサービスとして提供開始された「サイトフェイルオーバーオプション」では、Webサーバなどの状態を外部から監視し、何らかの障害が発生したWebサーバをDNS応答からすみやかに取り除いたりスタンバイサーバに切り替えたり、またWebサーバが復旧したらDNSに自動で戻すことができるようになり、Webサーバの可用性向上を実現しました。

4.4 2010年代：攻撃との戦い

DDoS攻撃の拡大

2010年代はbotnetによるDDoS（分散型サービス拒否）攻撃が大規模化し、その対策に翻弄された時代になりました。

多数の端末から同時に多数のリクエストを送り付けることでサーバの処理能力を飽和させて可用性を失わせるのがDDoS攻撃です。コンピュータウイルスは2000年代に入ると不特定の端末に感染して広範囲に感染を広げるワームへと急速に進化し、更に組織化してbotnetとなりました。botnetを構成する多数のbotが攻撃者の指示を受け取ってDDoS攻撃する事件が各地で頻発するようになったのです。

その一方でインターネットのトラフィックは急速に増大を続けており、効率的なWebコンテンツ配信を目的とするCDN（Content Delivery Network）の利用も広がり、大規模配信を想定した構成のWebサーバであれば、ちょっとやそっとのDDoS攻撃でサービスが停止することはなくなりました。

ところで、DNSは1回の通信ではせいぜい数百バイトがやりとりされるに過ぎず、また効率的なキャッシュの仕組みも存在するため、CPUやメモリ、ネットワーク帯域といったリソースへの負荷はWebやメールといったプロトコルと比べると微々たるものです。そのため、Webサーバが高性能化、広帯域化される一方で、DNSサーバについては最低限のリソースしか確保されない状態が長く続いていました。

多くの場合、攻撃者の狙いはWebサイトを閲覧不能にすることです。その目的を果たせるのであれば、攻撃目標がWebサーバである必要はありません。WebにアクセスするためにはまずそのサイトのIPアドレスを知る必要があり、ならばIPアドレスを入手するための仕組み、すなわち権威DNSサーバを機能不全に陥れることでも目的は果たせるのです。CDNに守られて大量の攻撃リソースを費やしても屈しないWebサーバを狙うよりも、そこそこの負荷で容易に飽和してしまう権威DNSサーバを攻撃する方が攻撃者にとって効率的です。

この代表的な事例が、Dyn（後にOracleにより買収）が2016年10月に受けたDDoS攻撃です（注4）。Dynは権威DNSサービス提供事業者としては超大手で、TwitterやSpotifyなど世界中の名だたるWebサービスがDynにホスティングしていました。このDynが数十万台の端末から6時間にわたってDDoS攻撃を受けて応答を返せない状態になり、Dynを利用していた多数のドメインにアクセスできなくなりました。

このDynへの攻撃に先立つこと4年、2012年にIIJも権威DNSサーバに対する大規模なDDoS攻撃を受けています。攻撃対象はWebとDNSをIIJにホスティングしていたお客様ドメインです。最初はWebサーバが攻撃されましたが、性能には十分な余裕があり、落とせないと認識した攻撃者が権威DNSに目標変更したのです。IIJの権威DNSサーバは当時としては潤沢なリソースを確保していましたが、広帯域化するWebサーバを落とすつもりのリソースを費やしてくるDDoS攻撃にはまったく足りておらず、応答を返しづらい状態に陥ったのです。

この事件はIIJのDNSサーバの設計思想を大きく転換させるきっかけとなりました。これ以前と以後で、DNSサーバのネットワーク構成が大きく変わっています。飽和攻撃に耐えられる十分な帯域を確保すること、仮にそれに耐えられなくてもAnycastにより被害を局所化する仕組みを備えること、またDNS以外のサービスに影響を波及させないようDNSサーバ群を専用ネットワークに分離することなど、多重の防御策を講じました。これらの対策を取り入れた設備構成変更はDNSアウトソースサービスなどの権威DNSサーバ、接続サービスなどで利用されるキャッシュDNSサーバ双方で順次実施されました。

オープンリゾルバ問題

DDoSは被害を受けるばかりではありません。残念ながら、IIJのDNSサーバが踏み台にされDDoS攻撃の「砲台」として利用されることもありました。

DNSは下位層のプロトコルとして主にUDPを用いますが、UDPはTCPに比べてクライアントによるIPアドレスの詐称が容易です。また、DNSの応答のパケットサイズは問い合わせの数十倍〜数百倍に大きくすることができます。これを利用すると、悪意のある攻撃者は送信元IPアドレスを攻撃対象のものに詐称した問い合わせを踏み台となるDNSサーバに送り、そのIPアドレスにパケットサイズを増幅させた応答を返させるようにすることで、攻撃対象のネットワーク帯域を飽和させることができます。このような攻撃を「DNS amplification attack（DNS amp）」あるいは「DNS reflection attack」と呼びます（図-1）。

拡大する

図-1 DNS amp

DNS ampが成立するのは、DNSサーバが詐称されたIPアドレスに応答を返してしまうためなので、詐称されたIPアドレスからの問い合わせに応答を返さないようにすることで防ぐことができます。しかし、UDPを利用している都合上、詐称を見破るのは困難です。

本来キャッシュDNSサーバは組織ごとに用意するものであり、その組織内のユーザだけが利用できれば十分です。組織外からの問い合わせには応答しないようになっていれば、送信元IPアドレスが詐称されていたとしても、組織外に大きな応答を返すことがなくなり、DNS ampの踏み台として利用することができなくなります。しかし、インターネットが相互扶助の精神で動いていた時代から長い間キャッシュDNSサーバにはそういった制限をかける慣習は一般的ではありませんでした。IIJのキャッシュDNSサーバも例外ではなく、アクセス制限がないオープンリゾルバとなっていました。

盛んにDDoS攻撃が行われるようになったこの時期、悪意ある攻撃者はこれらオープンリゾルバに目を付け、踏み台として利用するようになりました。アクセス制限をすれば踏み台として利用できなくなるのは分かっているのですが、そうすると不正目的ではなく本来の用途でIIJのサーバを利用していただいているユーザも使えなくなってしまいます。長い間このジレンマに苦しんできましたが、ついに2013年12月、IIJのキャッシュDNSサーバに対してIIJ網外からのアクセスができなくなるよう設定を変更しました。

オープンリゾルバ対策はこれで終わりではありません。IIJが提供しているキャッシュDNSサーバの対策は完了しましたが、ユーザが自分で設置していたキャッシュDNSサーバやルータのDNS機能がオープンリゾルバになっていて攻撃の踏み台にされていたケースも多数あり、その該当ユーザに連絡して対処を要請するという活動が続きました。IIJだけでなく世界的に地道な対策が進んだことで、DNSを踏み台にしたDDoS攻撃は次第に下火になっていきました。

4.5 2020年代：更なる発展

暗号化DNS

DNSは公開情報です。そのため、当初は盗聴されないこと（機密性）よりも改ざんされないこと（完全性）が重視されていました。2010年から始まったDNSSECも完全性を保証するための仕組みです。しかし、米NSAが大量の個人情報を収集していたことが暴露された2013年のいわゆるスノーデン事件（注5）をきっかけに、インターネット技術の標準化を推進する任意団体IETF（Internet Engineering Task Force）は「広範な監視は攻撃である」と宣言し（注6）、今後策定されるインターネット上のプロトコルは広域監視に耐え得る仕組みを具備するよう求めました。スノーデン事件ではDNSも監視対象になっていたこともあり、公開情報とはいえどんな情報を欲しがっているのかは個人のプライバシーであり、DNSにも機密性は必要であるという結論に達しました。

そこで標準化されたのがDNS over TLS（DoT）とDNS over HTTPS（DoH）です。従来のDNSはUDPまたはTCPの上に直接DNSメッセージを載せていましたが、DoT/DoHはそれぞれTLS、HTTPSのレイヤーの上にDNSメッセージを載せることで、第三者による盗聴を防ぎます。

2018年から2019年にかけて、Google Public DNS やCloudflare 1.1.1.1などのパブリックDNSサービスが相次いでDoT、DoHに対応し、またWebブラウザやOSなどクライアント側での対応も続きました。

現時点ではDoT/DoHで暗号化されるのはクライアントとキャッシュDNSサーバの間だけで、キャッシュDNSサーバと権威DNSサーバの間は暗号化の対象になっておらず、またDoT/DoHサーバの設定を自動化する仕組みが普及していないなど、現状の利用にはまだ課題が残る部分はありますが、将来的には重要な位置を占めるだろうと考えられています。

そのため、IIJでは技術検証のための実験サービスとして2019年5月より「IIJ Public DNSサービス」を開始しました。DoT、DoHはUDPを使わずDNS ampの踏み台に利用される恐れがないため、オープンリゾルバとしてIIJ以外のユーザにも開放しています。その後接続サービスで利用されるキャッシュDNSサービスにも順次DoT/DoHの対応が拡大しています。

新しい権威DNSサービス

インターネット黎明期から、権威DNSサーバは複数台構成にして可用性を向上させるべきものとされてきました。DNSを踏み台にしたDDoS攻撃は減りましたが、その後もDDoS攻撃自体はむしろ増えていることもあり、近年はゾーンを複数のDNS事業者に分散して設置することにより、特定の事業者が障害で応答できなくなった場合でも名前解決を継続できるようにするという考え方がとくに大規模なサイトでは一般的になりつつあります。

2000年にサービス開始されたDNSアウトソースサービス、DNSセカンダリサービスは機能強化を随時繰り返してきましたが、「DNSの問い合わせを受けてそれに答える」という基本機能に特化しており、複数の事業者で連携するには機能が足りませんでした。そのため、その他管理機能も強化するなどサービスを一新し、2019年11月、「IIJ DNSプラットフォームサービス」としてリリースしました。IIJをプライマリサーバにして他事業者をセカンダリにしたり、ユーザのプライマリサーバから転送されたゾーンにIIJサーバでDNSSEC署名するなど、従来のサービスではできなかった構成を自由にデザインできます。サイトフェイルオーバーオプションの後継サービスである「IIJ DNSトラフィックマネージメントサービス」も2022年3月に開始されました。

4.6 まとめ

IIJの30年の歴史をDNSの観点から駆け足で振り返りました。紹介しきれなかったエピソードなども多くありますが、誌面の都合上割愛せざるをえませんでした。

DNSは古くから存在するプロトコルですが、古いままではなく、常に進化を続けています。そして、インターネットの根幹を支える土台の1つであるということに関しては昔も今も変わりありません。IIJは今後も先進的な機能を積極的に取り入れつつ、堅牢かつ柔軟なDNSサービスを提供していく予定です。

1. （注1）JPNIC、「DNS管理グループ作業報告（一部、議題の元を含む）」（https://www.nic.ad.jp/ja/materials/committee/1994/0510/shiryou-2-4-1.html）。
2. （注2）バートン・マルキール『ウォール街のランダム・ウォーカー』第4章。
3. （注3）例えば「DNSSECとは」（https://jprs.jp/dnssec/doc/dnssec.pdf）などを参照してください。
4. （注4）Wikipedia、「DDoS attacks on Dyn」（https://en.wikipedia.org/wiki/DDoS_attacks_on_Dyn）。
5. （注5）Wikipedia、「エドワード・スノーデン」（https://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%89%E3%83%AF%E3%83%BC%E3%83%89%E3%83%BB%E3%82%B9%E3
   %83%8E%E3%83%BC%E3%83%87%E3%83%B3）。
6. （注6）RFC7258 Pervasive Monitoring is an Attack。

4. フォーカス・リサーチ（3） IIJとDNSの30年

• 4.1 はじめに
• 4.2 1990年代：接続サービスと共に
• 4.3 2000年代：DNS単独のサービス開始
• 4.4 2010年代：攻撃との戦い
• 4.5 2020年代：更なる発展
• 4.6 まとめ