Facebookと.clubドメインのDNS障害からレジストラとして学んだこと
本記事では、ドメイン管理者の観点から今回のFacebookと.clubドメインの障害を整理したいと思います。
10月5日に発生したFacebookの不具合は、世界中で6時間以上主要SNSの利用が不可能になるというこれまで経験のない規模の影響をもたらし、大きな注目を集めました。
またFacebookの件ほど話題となった訳ではありませんが、10月7日21時頃より、.clubドメインでも障害が発生しました。
この障害によりご迷惑をおかけしたお客様には、ドメインレジストラとして深くお詫び申し上げます。
参考URL
FACEBOOK Engineering:
https://engineering.fb.com/2021/10/04/networking-traffic/outage/
GoDaddy Registry ツイート:
https://twitter.com/GoDaddyRegistry/status/1446124321324220417
どちらの障害もValue-Domainが提供するサービスである「ドメイン」と、ドメインを運用するシステムである「DNS」が大きく関連しています。
そこで今回は、Value-Domainのドメイン管理者が、この障害によって何を学んだかをお伝えしたいと思います。
なお、Facebook障害についてはCloudFlare社が自社ネットワークの観測結果に基づく、技術的検証や影響度の分析を行っています。
The Cloudflare Blog：
https://blog.cloudflare.com/during-the-facebook-outage/
同じエンジニアとして非常に勉強になるものでした。上記のブログも一読されることをお勧めします。
Facebookと.clubの障害の概要
まずはFacebookと.clubの障害のおさらいから。
Facebookの障害の概要
・概要
Facebookのメインサイト「facebook.com」の名前解決（※）が不可能に。
それによってInstagram/WhatsApp/Oculus等Facebookアカウントを必要とするサービスが利用不可能となる。
・期間
日本時間10月5日午前0時40分頃から6時間以上利用不可が継続
この件についてFacebookの中の人は「メンテナンス対応の際予想外の問題が生じた」ためであると公表しています。
※名前解決とは？
ドメインを運用するシステム「DNS」においてそのドメインのIPアドレスを割り出すこと。
インターネット上で使用される全てのサービスは、この名前解決が可能であることが必要です。
ドメインについては「ドメインってそもそも何なん？をやさしく解説いたします」で詳しく解説していますので、そちらもあわせてご覧ください。
.clubドメインの障害の概要
・概要
全.clubドメインの名前解決が不可能に。
・期間
日本時間10月7日21頃から3時間程度
残念なことに、現在まで.clubドメインの管理組織からこの件に関する詳細は公表されていません。
彼ら（Godaddy Registry）のこの問題に対するアナウンスは冒頭に紹介したたったの1ツイートのみです。
「facebook.com」という1つのドメインか、それとも全.clubドメインかという対象の差はあってもどちらも「ドメインの名前解決が不可能」であったというのは、事象として共通しています。
Facebookと.clubの影響度の違いについて
同じ名前解決の障害であっても、Facebookの障害は様々なメディアに取り上げられるなど大きな反響を呼んだ一方、.clubドメインの障害は主要メディアに上がることはなく、国内ドメイン管理会社であってもアナウンスをしていない会社もあるほど、関心度の低い障害となっています。
この影響度の違いは、ドメインの技術的構造を知っていれば非常に興味深い事柄と言えます。
詳しくは、「ドメインの運営を支えるレジストリとレジストラの違い」をご参考いただければと思いますが、そもそもDNSはドメインの管理上位から順に階層化される分散型データベースによって構成されています。
WEBサービスに関する全ての処理は、このルート→TLD→ドメインの順にその住所（IPアドレス）を確認するというDNSの処理の後に行われるもので、今回の.clubドメインの障害はこの2番目、「TLD」DNSサーバー自体が動作しなくなった、というものでした。
個別のドメインを管理する権威DNS階層より一つ上の階層で障害が生じたことにより全ての.clubドメインのインターネット上の住所が世界中の誰もわからない状態、その影響範囲は2021年6月時点.club登録数約120万ドメインの全てという莫大なものです。
120万件の.clubドメインそれぞれにどれほどの利用者、関係者がいるかは想像もつきませんが、それでもFacebookの公表利用者数である30億人とはいかないまでも、非常に影響度の大きい障害であったことが理解できます。
何故.clubの障害は話題を呼ばなかったのか？その理由（.clubの利用者自体が比較的少数といえばお終いですが）の一つには、DNSの技術であるTTL（Time To Live）が存在すると考えます。
TTLについて
TTLとは、DNSのキャッシュ保持期間のこと。ドメインユーザーであってもあまりなじみのない単語かもしれません。
Value-Domainでも「通常は変更の必要はありません」と公開するほどです。なお、これは誤りではありません。
DNS情報・URL転送の設定：
https://www.value-domain.com/userguide/manual/moddns
例として「example.com」というWEBサイトを閲覧する場合、閲覧者がそのWEBサイトを訪問した時点で、閲覧者のPC（厳密にはリゾルバ）には「example.com」のDNS情報が、「example.com」に設定されたTTLの秒数保持されます。
この動作は、TTLが300なら300秒、3,600なら1時間、86,400なら1日の間、閲覧者のPCは後述した「ルート→TLD→ドメインの順にその住所」を確認するという処理を行わず、自分のPC内でのみ「example.com」の住所を発見し、そこにアクセスすることを可能にします。
ここで理解いただきたいのは、TTLの間、DNSキャッシュが維持されている間は、ルート、TLD、権威DNSといったDNSの上位階層でどんな障害が生じようとも、そのドメインの利用者への影響は生じないという技術的な仕様についてです。この観点からFacebookと.clubの障害を考えてみます。
TTLから考えるFacebookと.clubの障害
そもそもTTLの設定値は（というよりDNSはインターネット上で公開することを前提に設計されていますから）誰でも確認することが可能です。
dig @a.ns.facebook.com facebook.com a +norecurse +noall +answer
facebook.com. 300 IN A 31.13.82.36
ここで表示される「300」という数値がTTLです。ここから「facebook.com」のTTLは300秒、ということが分かります。
さて、facebookの障害は「facebook.com」が名前解決不可能となったことに端を発しました。この名前解決不可能という状態はあくまでDNSの視点で言えば「権威DNSサーバー」以下の階層の問題に相当します。
ここから、DNSの観点ではFacebookの障害発生後、「facebook.com」のTTLとして許されている僅か300秒間、世界中のユーザーはFacebookの利用が普段と何ら変わらず可能だった、しかしそれが一瞬で消化された後、他のユーザーと全く同様にFacebookが利用不可となった、という当時の状況が見えてきます。
仮にですが、facebookが自社ドメインのTTLをより長めに、例えば86,400（1日）に設定していたなら、facebookが障害を解決するまでの6時間、その間にもDNSキャッシュによる接続は利用者をfacebookに接続することに成功していたはずです。
現実的には、いつそのDNSキャッシュを保持したか等複雑な技術要素が絡むため影響を0にすることは不可能ではありますが、少なくとも利用者への影響を低減することが可能であったかもしれません。
一方、.clubの障害はより複雑です。TLDレベルのDNSサーバーの解決不可は極めて稀、というより本来発生してはならないものである、ということが前提になります。
そもそもルート→TLDの階層の名前解決がどのように行われるのか、以下は名前解決の流れを上から順に端的に示したものです。
dig example.club +trace
1.ルートDNSへの解決
. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS m.root-servers.net.
2.TLDDNSサーバーへの解決
club. 172800 IN NS ns1.dns.nic.club.
club. 172800 IN NS ns2.dns.nic.club.
club. 172800 IN NS ns3.dns.nic.club.
club. 172800 IN NS ns4.dns.nic.club.
club. 172800 IN NS ns5.dns.nic.club.
club. 172800 IN NS ns6.dns.nic.club.
3.権威DNSサーバーへの解決
example.club. 86400 IN NS ns1.value-domain.com.
example.club. 86400 IN NS ns2.value-domain.com.
4.住所（IPアドレス）の解決
example.club. 600 IN A 111.111.111.111
ルートDNSというのは「a～b.root-servers.net」の13個のDNSサーバーです。
対して上記の「ns1～ns6.dns.nic.club」というのが.clubのTLDDNSサーバーになります。
ルート→TLDDNSサーバーと解決した後、「example.club」の住所（IPアドレス）である「111.111.111.111」を見つけているという動作の流れがなんとなく掴めるかと思います。
.clubの障害発生当時、「ns1～ns6.dns.nic.club」の6つのDNSサーバーは全て名前解決が不可能な状態に陥りました。
上記で言えば②～③の処理において必要となる、「example.clubの権威DNSサーバーがどこにあるのか」（=NSレコード）という情報自体がわからなくなってしまったのです。
ここでFacebookとの差異が明確になります。「③権威DNSサーバーへの解決」をご覧いただきたいのですが、正常時に.clubTLDサーバーが解決していた「example.clubのNSレコード」のTTLは86,400秒、つまり1日です。
また、各.clubドメインのTTLの設定値はこの障害においても有効です。それぞれのドメインが障害発生から解決までの4時間以上のTTL値を持っていたなら、それらのドメインの利用者のほとんどはこの障害の発生に気づくことなく、これまで通りサービスの利用が可能な状態を維持したことでしょう。
これらのTTLの差異により、1ドメインの解決断がほぼ全利用者に影響を与えたFacebookと比べ、.clubドメイン全体で見た場合の影響度は割合として低いものであった、そのため話題性、注目度的にもほぼ度外視される結果となってしまった、という要素はある程度存在すると考えます。
なお、冒頭に述べましたがTLDDNSサーバーの障害発生はそれ自体が発生してはならないものです。
DNSの仕組み上、「権威DNSサーバーがどこにあるのか」という情報はTLDDNSサーバーのみが唯一もつものとなっています。
「権威DNSサーバー」は個別のドメインの住所情報を唯一もつサーバーであるため、「権威DNSサーバー」の所在がわからないという状況は個別のドメインの名前解決を行う仕組み自体が停止した状況であることを意味します。
これはTTL云々に関係なく、ドメインの構造と動作を保全する役目をもつTLD管理組織（レジストリと言います）にとっては緊急事態です。
TLD管理組織はそのTLDの管理を行うにあたり、ICANN（ドメイン最上位管理機関）との取り決めにより、「1週間のDNSダウンタイム合計が4時間」かつその10％に到達した状況を「緊急事態」と定義し、ICANNへの報告と対応を行うことを明記しています。
レジストリ契約：
https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-ja.pdf
また、ドメインの利用者にお支払いいただく新規/更新/移管などのドメイン料金にはこのTLDDNSサーバーの運用費を含めたICANN/レジストリ手数料が含まれています。
ドメインの管理上最も発生してはならない障害の一つであり、個人的にはGodaddy Registryがこれら定款に記される諸々の対応をどう行ったのか、それに対するICANNの対応も非常に気になるところですが、残念ながら明確な情報は一切公表されていません。
Facebookと.clubの障害の結論
Facebookと.clubのDNS障害、それに対するTTL視点での説明と、TTLが持つ耐障害性の面に触れました。
恐らくドメイン利用者のほとんどにとって、TTL自体、「名前は聞いたことはあるが意味は知らない」「なんとなく設定している、DNS提供者の設定に任せている」といったものであると思います。
国内ドメイン管理各社にTTLについてこの記事について書いた内容を質問すれば、恐らくほとんどの会社はValue-Domainと同じく「通常は変更の必要はありません」と回答することでしょう。
そしてそれは間違いではありません。共用DNSの管理会社が提供するTTLの初期値にはそれなりの理由があり、Facebookのようなメジャーサイトでもない限り、TTLに気を遣う必要はないと判断するのが技術的にも妥当であるからです。
TTLの設定を長めに設定することを推奨しているのでもありません。TTLを短く設定することは利用者にとっては設定変更の反映を迅速にするという明確なメリットがあります。
TTLという何気ない設定項目の重要性、ドメインの管理構造とその責務について、この記事を読んで関心を持つ方が一人でも増えるなら満足です。
今回の2件の障害は、DNS技術者ではなくドメイン管理者として、TTLを始めとするドメインの細部に対する市場全体の考え方（あくまで利用者に関係の深い部分についてのみサポートし、それ以外の内容について啓蒙すらしないという姿勢）に危機感を覚えるに十分だったというのが正直な感想です。
.clubの障害は特に、前例のないTLDレベルのDNS障害に対して、我々はその対応を議論することもなく、原因追及を積極的に行う姿勢もありません。
Godaddy Registryの責任とするのは容易で、.clubの影響度を考えた上での対応と言えばそれまでですが、それでも実際のドメイン利用者としての視点があまりに欠如してはいないか、という思いも沸き上がります。
私たちはドメインが持つリスクとそれに対する対応、サービス提供方法を再度根底から考え直す必要がある。
利用者がその意味を理解せずとも、利用者自身に設定を要求することもなく、結果として私たちの提供サービスを利用いただければ最良の結果が得られる。
1レジストラの立場として、そんなサービスを作り出さなければならない、というのがこの2件の障害から学んだことになります。
目次へ