DNSの可用性をさまざまな方法で高める：IIJ DNSプラットフォームサービスのスゴいところ(第2回)

2020年04月23日木曜日

【この記事を書いた人】
やまぐち

アプリケーションサービス部所属。そのへんのおっさん。

「DNSの可用性をさまざまな方法で高める：IIJ DNSプラットフォームサービスのスゴいところ(第2回)」のイメージ

CONTENTS

はじめに

IIJ DNSプラットフォームサービスのスゴいところを紹介するシリーズの第2回です。第1回はこちら。

今回のテーマは「可用性」。つまり、何があってもサービスを止めないようにするための取り組みです。
Webコンテンツの大規模配信にCDN (content delivery network)サービスを利用することは、いまや特別なことではなくなりました。CDNはトラフィックを大容量の回線で受け止めるため、DDoS攻撃への対策にも使われることがあります。

では、CDNを使えばDDoS対策は十分なのでしょうか。答はNoです。CDNを使えば、たしかに大量のトラフィックでWebサーバが飽和することはまずなくなるでしょう。しかし、攻撃をしかける側の目的の多くはWebを閲覧不能にすることです。Webが閲覧できなくなるのであれば、その手段はWebサーバへの攻撃である必要はありません。Webサーバにアクセスするための情報を得られないようにする、すなわちDNSサーバの応答不能によっても目的を達せられるのです。

図1: WebとDNS、どっちを攻撃しても閲覧不能になる

単純にコンテンツの大規模配信だけが目的なのであればCDNの利用だけでも十分でしょう。しかし、CDNにDDoS対策としての側面も期待するのであれば、ユーザからのアクセスをCDNへ誘導する役割を担うDNSもそれと同等に強化しなければ片手落ちです。DDoS攻撃でCDNが落ちなければ攻撃者はターゲットをDNSに切り替えることが想定され、実際にそのような事例も発生しています。DNSはそれに耐えられる構成になっていなければなりません。

敵を作らなければ、攻撃される可能性は小さいでしょう。しかし、何がきっかけで「敵」認定されるかはわかりません。最近、ネットで炎上した事件にも、攻撃対象になった人が実は人違いだったものがいくつかあるのはみなさんご存知のとおりです。SNSで炎上してるだけならいいのですが(よくないですが)、SNSにとどまらず、見当違いのサイトへの攻撃にエスカレートする可能性もあります。どんなサイトでも攻撃される可能性はあるという認識が必要です。

「ぼくのかんがえたさいきょうのDNS」を越える

IIJでは、旧サービスであるDNSアウトソース/セカンダリサービスの時代から、継続的にDNSへの攻撃対策を強化してきました。その取り組みについては3年ほど前に「ぼくのかんがえたさいきょうのDNS」という記事で触れています。この記事にあるとおり、旧サービスでは主に以下の3つの対策を実施していました。

Anycastの導入
DDoS対策装置の導入
実装ダイバーシティ

それぞれの詳細については該当記事をご覧ください。これは新サービスのIIJ DNSプラットフォームサービスでもすべて実施しています。しかし旧サービスと同じわけではなく、それぞれについて強化もされています。

国内の権威DNSサービス事業者では残念ながらまだほどんど採用されていないAnycastですが、海外の事業者では、もはや常識といえるぐらいまで一般的になっています。アメリカは国土が広いため、純粋に国内向けのサイトでもAnycastしないと名前解決にかかる往復遅延が大きくなってしまうという事情もあるのでしょうが、「Anycastしてる」というだけでは宣伝文句にならず、Anycastの拠点数で優位性を競うようになっています。IIJ DNSプラットフォームサービスでは、ベーシックプランでも海外事業者の「常識」レベルの Anycast 拠点を国内外に設置し、プレミアムプランでは一気に3桁までAnycast拠点が増えます。

耐DDoS帯域も大幅に強化されています。ベーシックプランでも旧DNSアウトソース/セカンダリサービスの10倍以上の1Tbps超、プレミアムプランではベーシックプランからさらに一桁上の30Tbps超の帯域を確保しています。2016年に起きた特大規模のDDoS攻撃事件が1.2Tbpsと言われており、ベーシックプランではそれとほぼ同程度の攻撃まで、プレミアムプランではそれを余裕で受け止められる構成になっています。ちなみに海外事業者では、DDoS攻撃についても対策するのは当然とした上で、どの程度の規模まで耐えられるかでサービス競争する時代になっているようです。

BINDの脆弱性は相変わらず年に何度も見つかっています。そこで、IIJ DNSプラットフォームサービスでは外部からのクエリを受けるサーバ(NSレコードに記載するサーバ)としてはBIND先生にご隠居してもらうことになりました。新たにKnotを採用して、旧サービスから続投するNSDと実装ダイバーシティをはかっています。BIND先生は完全に引退したわけではなく、あまり目の触れないところで引き続きお仕事を続けてもらっていますが、限定的な利用でしかないので、もし新たな脆弱性が発見されたとしても影響を受けにくくなっています。ちなみに実装ダイバーシティを公式に謳ってるサービスは海外でも(もしかしたらあるのかもしれませんが、こちらの観測範囲では)見たことがありません。公にしてないけどやってるところはあるようですが。

DDoS対策って必要なの？

通常のサイトであれば、DDoS攻撃のターゲットになることなんて、そうめったにあるものではありません。多大なコストをかけて充実した設備を備えても、その設備の耐用年数のうちにまったく攻撃を受けない可能性の方がむしろ高く、ほどんどの場合、コストは無駄に終わります。だからといって備えをしていなかったところにいざ発生してしまうと甚大な被害を受けます。こういうHILF (High-Impact, Low-Frequency)なイベントをどの程度のリスクととらえ、どれだけコストをかけるのかは難しいところです。

第1回で述べたとおり、この記事は「DNSプラットフォームサービスすげーぜ」というアピールだけでなく、「真似できるところがあればどんどん真似してね」という趣旨でもあります。しかし、ここまで説明した内容をオンプレ運用で真似して構築するのは、いくらHigh Impactだからといっても現実的ではありません。1Tbpsの回線、いくらかかると思いますか。それだけ費用をかけても本サービスの下位プラン(月額2000円)の帯域にしかなりません。自前でやるのはあきらめてください。HILFなリスクへの対策はコストがかかるからこそ、サービスを買うべきです。

しかし、権威DNSサービスを提供する同業他社さんにはぜひ追随していただきたいと思っています。前述のとおり、海外では日本でも知られているような大手事業者だけでなく、中堅規模の事業者でもAnycastやDDoS mitigationは当たり前にやっています。それらと比較すると、我々の新サービスが飛び抜けて高スペックだとは思っていません。残念ながら、日本の事業者はサービススペックが低いと言わざるを得ない現状があります。ユーザさんからAnycastの要望はないかもしれません。しかし、それはAnycastという概念が日本ではあまり馴染みがないからであって、提供しない理由にはなりません。

設備障害への備え

ここまで、外部からの攻撃に対する備えを説明してきました。しかし、可用性を検討しなければならないのは攻撃だけに限りません。設備故障や自然災害もあります。予兆があって故障が起きる前に対処できるケースもなくはないですが、稀です。たいていはある日突然壊れます。その突然の故障でサービスが止まらないような備えも必要です。

IIJ DNSプラットフォームサービスでは、データセンター内部の設備をすべて多重化しています。ネットワーク障害や電源障害などで1系統が全滅しても止まりません。さらに、複数のデータセンターに同じ設備を置いてactive/active構成で稼動しているので、1拠点がビルごと爆破されても止まりません。拠点内のサービス設備全部の電源を一気に落としてもサービスが継続できることはテスト済みです(さすがに爆破のテストはできなかった)。なお、拠点は日本国内だけでなく海外にも設置していますが、海外拠点はDNSのクエリを受けるサーバだけであり、公開が前提のゾーン情報だけしか置かれません。ゾーン編集やユーザ認証などの機能を担当するサーバはすべて日本国内に設置されており、センシティブな情報が海外拠点に複製されることはありません。

サーバ内部で動いているプログラムは必要に応じて機能強化等を実施する予定ですが、そのアップデートのためのメンテナンス作業中にサービスが利用できないということがないよう、更新版への切り替えも瞬時におこなえるような設計になっています。

もしIIJのネットワークがインターネットから孤立すると、さすがに何もできなくなります。こうなるとベーシックプランは完全にサービス停止になります。あきらめてください。しかし、プレミアムプランで契約されたゾーンであれば、提携した外部事業者が提供するサーバで名前解決できます。ゾーンの編集などはできず、サービスレベルは大幅に低下しますが、それでも権威DNSサービスとして一番重要な名前解決だけは死守します。提携事業者が頑張ってくれている間に復旧を急ぎます。

技術的なことではなく、純粋に契約上の話になりますが、プレミアムプランではサービス品質保証(SLA)がつきました。名前解決が止まると返金請求できます。ベーシックプランにSLAはありませんが、サービス品質が低いわけではなくプレミアムプランと同等の運用をしています。なぜ上位プランだけなのかというと、ぶっちゃけプランの差別化という営業上の理由ですね。

ネームサーバのTLD分散

それから、ネームサーバ名を変えました。従来のDNSアウトソース/セカンダリサービスでは、以下のようなNSレコードが使われていました。

example.com.    IN    NS    dns-a.iij.ad.jp.    ; DNSセカンダリサービス
example.com.    IN    NS    dns-b.iij.ad.jp.    ; DNSアウトソースサービス
example.com.    IN    NS    dns-c.iij.ad.jp.    ; DNSアウトソースサービス

example.comというドメインですが、NSレコードがiij.ad.jpドメインです。はい、リスクですね。IIJに何の落ち度がなかったとしても、万が一、jpドメイン全体にかかわるような障害が発生した場合、example.comドメインの名前解決ができなくなります。example.comドメインなのに、jpドメインの障害の影響を受けるのです。
IIJ DNSプラットフォームサービスではお客様ゾーンにNSレコードを3つ割り当てますが、この3つのネームサーバはTLDのレベルで分散しています。たとえばこんな感じ。

example.com.    IN    NS    ns-xxxxx.x.d-53.jp.
example.com.    IN    NS    ns-xxxxx.x.d-53.net.
example.com.    IN    NS    ns-xxxxx.x.d-53.info.

もしjpやnetやinfoのいずれかがTLDごと全滅するような障害が発生したとしても、3つあるNSレコードのうちひとつが使えなくなるだけで、残り2つで名前解決ができるようになっています(ただしcomが全滅した場合はNSレコードをどうしようとexample.comは救えません)。
ほかに同じようなことをやっているところを思い出される方も多いかもしれません。そう、AWS Route53です。

example.jp.        IN    NS    ns-xxx.awsdns-xx.net.
example.jp.        IN    NS    ns-xxx.awsdns-xx.org.
example.jp.        IN    NS    ns-xxx.awsdns-xx.co.uk.
example.jp.        IN    NS    ns-xxx.awsdns-xx.com.

Route53のNSレコードが異なるTLDにまたがっているのには、こういう理由があったのです(AWSの中の人に聞いたわけじゃないので、ほんとにそういう意図なのかどうかは推測ですが)。ただ、Route53はcomとnetを併用していますが、IIJ DNSプラットフォームサービスではcomは使いません。これにも理由があります。comとnetはどちらもVeriSign Global Registry Servicesという同じレジストリが運用しているのです。同一事業者が運用しているため、もしcomが全滅するような障害が起きるなら、netもいっしょに全滅している可能性が高く、comとnetを両方使うのはリスク回避にならないと判断しました。d-53.comというドメインを取れなかったからじゃないんだよ(いや、それもあるけど)。

ちなみに、TLD分散ではなく内部名を使うという方法でも回避できます。サービスに頼らずオンプレで頑張るのであれば内部名にしてください。しかし、サービスとしての権威DNSでは内部名は扱いづらく、こちらの選択肢は取れませんでした。外部名/内部名とは何か、なぜDNSホスティングサービスでは外部名の方がいいのかについては、ここでは説明を割愛します。JANOG40での筆者らの発表資料をご覧ください。

親子ゾーン同居問題の解消

可用性を高める取り組みについては以上になります。可用性の話とは関係はありませんが、ネームサーバ名を変更した件に関連してもうひとつ。

example.comゾーンがすでに存在しているサーバ上に、子ゾーンとしてwww.example.comを追加するケースを考えます。
example.comゾーンとwww.example.comゾーンのそれぞれにwww.example.comというレコードを追加した場合、優先されるのはどちらのゾーンに追加したレコードでしょうか?

答は実装依存で、どちらを優先すべきというルールは存在しません。しかし、知るかぎりでは既存のDNS実装はすべて子ゾーン側を優先します。また、www.examle.comゾーンにwww.example.comのA/AAAAレコードが存在しない場合、example.comゾーンの方に存在していても、子ゾーンの方が優先されて名前解決に失敗します。この動作はexample.comゾーンからwww.example.comゾーンへの権威委譲の有無にかかわらず同じです。

図2: 親子同居

これはさまざまな人がゾーンをホスティングする共用DNSサービスでは極めて危険な動作です。たとえば、すでにexample.comゾーンが存在しているときに、example.comとは無関係の第三者がwww.example.comゾーンを作成してしまったらどうなるでしょうか。example.comゾーンからwww.example.comゾーンに権威を委譲しなくても、www.example.comゾーンを使えてしまうため、Webサイトを乗っ取れてしまいます。また、

example.com    IN    MX    10 mx.example.com.

というMXレコードが存在するとき、無関係の第三者がmx.example.comというゾーンを作成することで、example.comドメイン宛のメールを奪うことができるようになります。

ほかにも、_acme-challenge.example.comゾーンによりLet’s Encryptで*.example.comのTLSサーバ証明書を取得できたり、wpad.example.comゾーンによりexample.comドメインを利用しているユーザのHTTPプロクシ設定を変更できたりするなど、親子ゾーンが同居していると、さまざまなセキュリティ上の問題が発生します。

こういったドメインハイジャックについては、2012年にはJPRSから注意喚起のアナウンスも出ています。旧DNSアウトソース/セカンダリサービスでは親子ゾーンが同居しており、この問題を排除するために親ゾーンの契約者とは異なる人が子ゾーンを契約しようとする場合には親ゾーン契約者に確認するなどのフローを設けており^(※)、また、わざわざ列挙しませんがドメインハイジャック以外にも特別扱いが必要なケースがほかにもいくつかあり、サービス運用上の懸念になっていました。

※：親ゾーンはドメインの所有者が契約するが、その所有者の了承の上で子ゾーンをSIerが契約・運用する、などのパターンがあるので、一律に却下できない。

IIJ DNSプラットフォームサービスでは、この仕様を全面的に改め、親子ゾーン同居問題が根本的に発生しないようにしました。つまり、親子はかならず別居します。親子が同居する旧サービスでは親ゾーンから子ゾーンへの権威の委譲がなくても名前解決できてしまっていましたが、別居する新サービスでは委譲が必須になるので、親から委譲してもらえない悪意ある第三者の子ゾーンによりハイジャックされることはありません。

これ、旧DNSアウトソース/セカンダリサービスの時代からずっとやりたかったことなのです。しかし親子を別居させるにはNSレコードを変更する必要がありますが、こちらでは変更作業は実施できず、お客様がレジストラ(指定事業者)にネームサーバ変更を申請していただく必要があって実現できなかったのです。新サービスの仕様で真っ先に決定したのが同居問題の解消であり、むしろ別居を実現させるために新サービスを作ったといってもいいぐらいの最優先事項でした。前述のTLD分散は、別居させるときにどうせNSが変わるんだからついでにやっとくか、ぐらいのいわばオマケ的な位置づけでしかありません。