久々に（技術的にも実務的にも）良い意味で考えさせられる対応報告書を読んだ。
コインチェックの対応報告書がそれ。
読み解いてみたけど、存外に大変なことに（主にオレが書いた文の分量が）…。
コインチェックからリリースされたたインシデント対応報告
読んでいて、真面目な意味で面白く、かつ自分で考えようと思えばいろいろと考えられる報告書は、久しぶりに出会った。オレもこういう報告書を書けるようになりたい…。
真面目な意味で「どこが」面白いのか？（あくまで私見）
あくまで私見ではあるが、「監視業務にてレスポンスの遅延を検知し関連システムの調査を開始」という1行が、ものすごく興味をそそられた。
その次に「第三者によりドメイン登録情報が変更されていたことを確認」という結果につながるのが面白い。
この間の経過時間は、おおよそ7時間ちょっと。
その7時間にどんな調査／確認が行われたのか？は、いろいろと考える価値があるのだが、「レスポンス遅延」から「ドメイン登録情報が変更されていた」という経緯が、「風が吹けば桶屋が儲かる」を連想するレベルで「？」となり、その後に「レスポンスの内容を考える」ことにつながった。
その結果、自分の知見の総動員とまではいかないまでも、結構な勢いで自身の知見から仮説の再構成をするに至った。正直相当疲れたけど、ものすごく面白かった。
調査開始から事案確認までに実施したことを想定する
以降は、調査開始から事案確認までに、コインチェックで実施したのではないか？という調査の内容を考えていたりする。
レスポンスの遅延を検知
こういう話が出てくると、レスポンスの遅延が何に起因して発生するのか？が気になってくる。
オレとかは、Webサーバ／Webアプリケーションサーバへのアクセス時に発生する処理を並べて、遅延が発生するとしたらどこ？というのを考える。例えば以下のような処理がざっと並びますが、それぞれでどうなったら遅延が発生するのか？を考えてみることに。例えば、遅延という話だと、以下のような話が考えられる。
- Webサーバ／アプリケーションサーバの性能不足
- Webアプリケーションの処理遅延
- 名前解決の処理遅延
次に、遅くなる傾向（一斉に遅くなる／偏って遅くなる／遅くなることもある）などから、例えば以下のような話が考えられる。実際の対応現場では、もしかしたらもっと多岐にわたった検討を実施したかもしれないが、オレが考えられるのはさしあたり以下のような感じ。
- 一斉にまんべんなく遅くなる場合
単純にリソース不足。
ロードバランサ等に異常はなく、均等に処理を割り振って、サーバ側の負荷が均等に上昇・処理量が増えている
回線の帯域が逼迫している
DNSの処理が遅延している - 特定のサーバに偏って遅くなる場合
リソースが少ない特定のサーバが遅くなっていたり、ロードバランサのバランシングポリシーが誤っている（Webサーバ／アプリケーションサーバのリソース搭載状態によって、バランシングポリシーを均等ではなく30%:70%に振り分けるなどはありえる、もしくは同じリソースを持っているWebサーバ／アプリケーションサーバに、アクセスを均等に割り振らなければいけないはずが、なぜかバランシングポリシーがそうなっていないか）
特定のサーバに至る回線が逼迫している
特定のDNSレコードのみ名前解決が遅くなることがある - 特定の処理に偏って遅くなる場合
特定処理（例えばDBMSトランザクションが入る処理）で処理遅延が発生する
排他処理でリソース解放を待って遅くなる
その他、希少リソースを取り合うなどの理由で遅くなることも - ばらついて遅くなる場合
サーバ側に上記のような問題がある
ユーザからサーバまでの通信経路に（局所的に）問題が出ている
DNSの応答が時々遅くなる
上記の項目を全部一人で～となるとさすがに死ぬし、解決までの時間がかかりかねないので、それぞれに詳しいメンバが調査にあたったはず。とはいえ、Webサーバ／アプリケーションサーバ、DBサーバ、DNS、ネットワークの負荷がどんだけかかってるか？というレベルのチェックであれば、きちんとした運用をやっているところであれば、（時間はともかく）確実に状況を把握できるはず。
この時点で、DNSはあくまで疑義があるパーツの1つであり、ましてやレジストラの登録情報が改ざんされているなんて普通は考えない*1。
Webサーバ／アプリケーションサーバのリソースも処理負荷も回線帯域も問題ない場合に見るところ～例えばNWの遅延
次に見るべきところは、NW上の（TCP/UDPレベルの）レスポンス遅延がどれだけあるか？という（わりかし）ミクロなところかなと思う。TCPはOSのプロトコルスタックが、UDPはアプリケーションが返すものだが、負荷に問題がない以上、おおよそのレスポンスを見積もるのはそんなに難しい話ではない。特に、国内のデータセンタ等に情報を置いているサービスであれば、海をまたぐレベルでの遅延はほぼ起こり得ない（除く沖縄）。
おそらくだが、ここで遅延をミクロに見ていたエンジニアが「おかしい」と気付いたのが、DNSのレスポンス遅延なのではないか。
原因はともかく、DNSのレスポンス遅延（フルリゾルバがキャッシュする前の、権威DNSからのレスポンスが遅い）は、遅くともこの段階で見つかる可能性が高い。ただ、DNSの負荷や経路に異常がない（DNS側から見たら、インターネット上の通信経路に異常がない）可能性は非常に高いので、システム側からではこういう話は気づきづらい。
権威DNSからのレスポンスが何故遅れる？～ここでDNSの配置が問題に？
権威DNSからのレスポンスが遅れる、でも権威DNSの負荷は問題なく、経路も問題ない、となると、レスポンスの内容を確認する動きになる。知らないDNSがいる、という話は、この段階でわかる可能性が高い。
権威サーバは、リクエストに応じてレスポンスを返すが、このレスポンスは通常は、途中に存在するフルリゾルバ（DNSキャッシュサーバ）に一定時間留め置かれる。フルリゾルバがDNSからのレスポンスをキャッシュしている場合には、遅延が発生せず、そうでない場合には遅延が発生するのではないか？と考えるに至る。
DNSの配置がなぜ問題に？
ここで、DNSの配置がなぜ問題になるのか？を述べておく。
DNS自体は、クエリをさばいてレスポンスを返す単純なしくみであり、不明な内容があると、（権威DNSであっても）それを知っていると思われるDNSにリクエストを送る。例えばだが、あるドメインにおいて、サブドメインまるごと委任した場合なぞは、委任された先にもDNSが設置され、あるドメインの権威DNSが情報を持っていないサブドメインに対するリクエストと判断された場合には、サブドメインの情報を持つDNSに問い合わせを送り、応答をクエリ元に返す。
当然この場合、単独のDNSのみで処理を完結するよりも時間を要する。さらに、国外にあるDNSが、国内にあるDNSにリクエストを転送するような処理を考えると、
国内→国外→国内という感じで、一度国内にある（委任先の）DNSにリクエストを送る。
なお面白いことに、ここで何気に「距離」が効いてくる*2。
物理的な距離が1000kmほど離れているところだとどの程度の時間がかかるか？だが、単純に委任先のDNSにリクエストが到達するだけでも、「国内→1000km→国外→1000km→国内」というように、2000km程度の時間がかかる。そして、光速度は30万km/秒と言われているが、光ファイバ内だとおおよそ6～70%程度まで低下するため、20万km/秒となる。この光速度で2000kmを移動するためには、0.01秒（＝10m秒）を要する。光速度不変の法則とかいわずにもっと根性出せや、と思うかもしれないが、これが物理法則から導き出される限界の1つである。
そういう目でDNSのレスポンスを見て、レジストラへの登録情報に目が行く
システムを運用してる側からしたら、システムが順風満帆に動作していることのほうが稀で、実際には小さいトラブルや不具合が発生しながらも問題ないレベルに局所化していることのほうが（多分）圧倒的に多い。
となると、まず「自分とこの不具合」を疑って、徹底的に調査を行い、不具合がないところでやっと外に目が行き始める。
そこで「外部要因の1つ」であるレジストラの登録情報に注目し、そこで改ざんに気がついた、というオチになったのではないか。
レジストラの登録情報が改ざんされていると発生する懸念
レジストラの登録情報～今回の場合はDNSの情報～が改ざんされていたわけだが、これはかなり重大で、ドメインを乗っ取られるのに等しい。
Webサーバが乗っ取られるのは、それはそれで困るが、ドメインが乗っ取られることは、リクエストそのものの最初の行き先を操られるというさらに困った事態に陥る。
レジストラの登録情報が改ざんされる＝DNSの情報が改ざんされる、と考えると、メールの行き先も改ざん者が自由に変えられる。改ざんされて登録されたDNS上のMXレコードを攻撃者が持つホストにすれば、coincheck.com宛のメールを受け取り放題になる。ここで報告書の「問い合わせメール～」につながる。
別にコインチェックを擁護するわけではないが、この件は事象から原因にたどり着くまでが難しい…
後からはどうとも言えるかもしれないが、オレはこの机上検証を行うことで、「レスポンス遅延」から「レジストラの登録情報改ざん」を突き止めた方々の努力に敬意を表したい・そして、多岐にわたるレスポンス遅延の要因を1つ1つ潰し、レジストラの登録情報改ざんに至るまでの（想定）プロセスが、相当大変だという結論に至ったのは、1つの知見を得たとか考えている。
それこそここまでのことを10秒でトレースできる人がいれば～という話なのかもしれないが、そんな人はそうそういるわけではないし、オレもスタートとゴール（そしてその後）を見るまでは、そんなこと思いもしなかった。
結び～適切な仮説設定と、仮説に基づいた地道な調査が一番重要
ここまでにいろんなことを書いたが、最も重要なのは「適切な仮説設定」と「地道な調査」ということ。仮説設定が間違っていると、調査はあさっての方向に行きがちだし、地道な調査を行わないと、積み重ねる事実が瓦解しかねない。
自分も気をつけないとなぁ…と感じた瞬間である。
