俺 Pedia

窓際エンジニア(仮)の日常

さくらのレンタルサーバで独自ドメインを利用している場合に発生する問題

この記事は「低予算でも闘う企画担当者の為の鎮魂歌 Advent Calendar 2015」の4日目の記事です。
 
今回は前回少しだけ触れましたさくらのレンタルサーバを利用する際に注意すべき独自ドメインの設定に関する問題について取り上げます。

一般的なコンテンツの公開(新規・サーバ移転)の流れ

まずはじめにコンテンツを公開する際に行う、ドメインの取得からコンテンツが公開されるまでの流れを説明します。 この流れは新たにドメインを取得し新しいコンテンツを公開するケース(以降、新規と表現)と、既に公開済みのコンテンツを公開に利用するレンタルサーバのみを変更するケース(サーバ移転)の二つが存在します。

① 新規のケース

新規のケースでは、ドメインの取得から始まりサーバの契約及びその設定、そして公開するコンテンツの配置やその設定を行い、その後DNSサーバにて公開時に利用するサーバの情報をDNSレコードとして登録し、その情報が伝播する事で順次ユーザーにコンテンツが閲覧する事ができる状態となります。
(便宜上、検索エンジンへの登録やURLの配布などの手順は省略します)
 
f:id:levelnine:20151203192527p:plain:w850  
新規の場合はそもそも公開済みのコンテンツがありませんので、今回問題とするケースは発生しません。

② サーバ移転のケース

一方でサーバ移転のケースでは新規の場合と異なり、既に掲載中のコンテンツがありますので公開中のコンテンツに影響を可能な限り与えずに移設を完了する必要があります。
想定される一般的な流れとしては、まずは移設先のレンタルサーバの契約を行い、契約した移設先のレンタルサーバ上でコンテンツを公開する為の設定を行います。その後、移設するコンテンツのアップロードやプログラムが正常に動作する事に確認を行い、最終的にDNSサーバにてレコードを書き換えその情報が伝播する事で順次ユーザーが移設後のサーバに訪れるようになります。
 
f:id:levelnine:20151203193911p:plain:w850  
移転先のサーバへのアクセスは移転作業担当者の端末上でhostsファイルの変更を行うなどして該当ドメインのアクセス先サーバを移転先サーバに行われるよう一時的に変更する事でレコードの書き換えを行わずに独自ドメインでのアクセスと同等のコンテンツの表示確認やプログラムやスクリプトの動作確認を行う事が可能です。
 
このように、サーバ移転を行う場合はあらかじめ移転先のサーバにて準備を行い移転先で正常に表示が行われることやプログラムが含まれる場合は仕様の変更などによりその影響が出ていないか等を確認し正常に動作する事が確認でき次第、DNSレコードの書き換えを行い移転先となるレンタルサーバにアクセスが行われるよう手続きを進める必要があります。

さくらのレンタルサーバに移転する場合の流れ

前述のようにサーバ移転のケースではDNSのレコードの書き換えはあくまでも最後に行う作業となるのですが、さくらのレンタルサーバで独自ドメインを行う場合に限りこの流れでは対応する事ができません。
 
さくらのレンタルサーバでは独自ドメインを利用する場合は、あらかじめレンタルサーバにその設定を行う必要があります。その際、利用するドメインのAレコードが対象となるさくらのレンタルサーバに設定されていないと手続きを進めることができません。
その為、さくらのレンタルサーバに移転する場合はサーバの準備を行う段階でDNSの書き換えを行い、その後サーバの設定、コンテンツのアップロードという流れになります。 なお、コンテンツのアップロードと表示確認そのものは、独自ドメイン経由のアクセスにこだわらない(プログラムやスクリプトが影響を受けない)のであれば標準で割り当てられるさくらのドメインにて行う事で最低限の確認は行う事が可能ですので、それを考慮した場合さくらのレンタルサーバへの移転は次にような流れになります。

f:id:levelnine:20151203200034p:plain:w850

このようにさくらのレンタルサーバでは独自ドメインを利用する為にはあらかじめDNS側でレコードの設定を変更しておく必要がありますので、短縮する事はできるものの、他社で行うような移転先サーバ上であらかじめコンテンツの表示確認やプログラムやスクリプトの動作確認を行った上で移転の実施を行う事ができず、どうしても多少のトラブルが発生する事を想定しなければなりません。
 
確かに単純な会社サイトや影響の限定的なコンテンツであればあらかじめ移転のお知らせを掲載し、利用者に影響がある事を告知すれば良いのかもしれませんが、そういったことを行う事は当然としても、やはり移転作業はより安全に行いたいと思うのが担当者の本音であると思います。
 

なぜさくらインターネットではこういうことになったのか

そもそもこの問題が発生したのは、2012年にさくらインターネットで起きたサブドメインハイジャック問題のタイミングであったと認識しています。
 
もともとさくらのレンタルサーバはさくら自身で運用しているDNSサーバと密接な連携が行われており、何れかのさくらの提供するサービスとドメインの結びつける事で他のサービスにもその設定の影響が及ぶ問題がありました。
この関係だけでなく、DNSサービスの問題も重なって結果的には第三者によりサブドメインをハイジャック可能となる脆弱性が生じることとなりました。
 
www.sakura.ad.jp
 
この問題を解消する過程で仕様の変更が行われたのですが、その際に予めDNSサーバへの操作権限がある(つまりドメインの所有権を有する)事を確認する為の措置として、事前にDNS上でレコードの設定を行った場合のみ独自ドメインに関する設定ができるような仕様に変更されました。
 
個人的な意見を述べるのであれば、そもそもレンタルサーバを含むマネジメントシステムの機能側の仕様を変更する話が本来の対応のあるべき姿であったと思うのですが、おそらくはその部分の変更を行うとなると提供しているサービスに大きな影響を及ぼす事が想定された為、結果、利便性を損なう事が想定されても現状のような対応とする事を選択したものと思われます。

少しでも影響を軽減する為に

独自ドメインの利用に関する問題点について説明しましたが、それだけですと何ら解決になりませんので、可能な限り影響を最小限にする為のテクニックを共有したいと思います。

① DNSのレコードを書き換える前にTTLの値は最少の値に変更する

そもそもさくらのレンタルサーバの利用に係らず、レコードの変更を伴う作業の場合はあらかじめ一時的にTTLの値を最小の値に変更しておきましょう。
キャッシュDNSでは原則としてTTLで指定された期限を経過し有効期限切れとなったキャッシュに対する参照が行われた場合、その応答を行う為に権威DNSへ紹介を行う事になります。その結果、該当ドメインの権威DNSで設定された内容がキャッシュDNSにも反映される事となり結果的に反映の時間を短縮できる可能性が高まります。
なお、残念ながら設定された値で必ずしも伝播が行われるわけではなく、一部のキャッシュDNSではTTLの値に従わないものがあったり、またそもそもTTLの値を変更してもその値の変更を参照し反映する為には既に設定されているTTLで指定された期限が経過している必要がありますので、少なくとも短縮を行う事ができる、程度の理解でいる方がよいでしょう。

② 独自ドメインの追加及び設定を行った後は一端レコードを移転前のサーバに戻す

前述したようにさくらのレンタルサーバに独自ドメインに関する設定の際に行われているのはドメインの所有権の確認です。
その為、一端設定を終えてしまえば特にその後DNSに設定した内容に影響されることはありません。
ですので、例えば移転を予定するサイトのログからユーザーが訪れない時間を予め確認しておき、①のように事前にTTLを最少の値にした状態で一端レコードを移設先のサーバ(つまり、さくらのレンタルサーバ)に変更します。
その状態で概ねTTLの時間が経過した頃にレンタルサーバの設定画面から独自ドメインの追加とそれに関連する設定を行います。
そして設定が完了したら速やかにレコードの設定内容を移設元のサーバに戻すことで他社のレンタルサーバと同様にhostsファイルを変更するなどの設定により移設先のサーバに担当者のみが接続できるようにできます。

さくらのレンタルサーバが参照するDNSは恐らく内部で準備しているキャッシュDNSであり、これは適切な値を権威DNSから取得し運用されていると考えられますので、TTLで指定した値に限りなく近い期限で設定した内容が伝播していることが想定されます。

以上の2つの手続きを行う事でさくらのレンタルサーバへの移転であってもサービスやコンテンツの公開にそれ程影響を及ぼすことなく移転作業を進める事が可能となります。

同一サーバに対しワイルドカードで設定されたドメインはどうなるの?

さて、さくらインターネットでサブドメインハイジャックの脆弱性が存在していた問題を取り上げましたが、レンタルサーバの仕組み上、例えばワイルドカードをあるサーバに対して設定した場合レンタルサーバ側ではどのアカウントが該当ドメインの所有者か判断して処理をおこなっているのでしょうか?
 
例えばコアサーバーではサーバを指定してアカウントを開設する事が可能ですので極論を言えば、同一サーバ上で運用されているドメインに対して悪意のある攻撃を仕掛ける事が可能となります。
 
Aさんは自分のアカウント上で「example.com」ドメインの「aaa」サブドメインと「bbb」サブドメインを運用する為にDNSのレコードの書き換えを行いました。その際ワイルドカードで設定したとします。
その設定を知った第三者であるBさんが同一サーバのアカウントを取得し「example.com」ドメインの「ccc」サブドメインに関する設定を自分のアカウント上で行ったとします。そうするとどのような挙動となるでしょうか。
 
答えは「ccc」サブドメインはAさんの意図しないまま、Bさんのアカウント上で設定された内容で表示されます。

これは仕組みを考えると止むを得ない事なのですが、そもそもレンタルサーバ上の各ドメインの受け入れはバーチャルホスト機能を利用して行われている事が一般的です。その為、仮に第三者のアカウント上であっても同一サーバに対して設定さえ行ってしまえば、仕組み上サーバとしてはアクセスがあった場合、該当のバーチャルホストに設定された内容で表示するしかありません。
 
但し、少なくともコアサーバーであればこの問題は事前に予防する事が可能です。
コアサーバーでは独自ドメインに対する設定が行われる場合、サブドメインのみの設定の場合はその他のアカウントの設定内容とのチェックが行われませんが、独自ドメインそのものが既に他のアカウントに設定されている場合、その独自ドメインに対するサブドメインをそのアカウント以外に設定する事はできません
その為、正当なドメインの所有者(前述の例であればAさん)が最初にドメイン設定を行う際に実際に使用するものがサブドメインであっても、ドメインそのものの設定を行っておけば第三者がそのドメインに対する設定を行う事を防止する事が可能となります。
 
もっともサブドメインのみでの運用というのはかなりレアなケースなのですが、例えばブログのみ運用しておりそれを「blog.example.com」のように設定している場合、もしかするとそれ以外のサブドメインを第三者が設定し自分の意図しないコンテンツを公開されてしまうおそれがあります。 またもっと深刻なケースでは、場合によってはクッキーの仕様を悪用し、クッキーを使い管理しているサービスのセッションを乗っ取るような行為が行われる可能性もあります。
 
レアなケースではありますが、そのような事も起きる事がありますのでワイルドカードの設定は行わない、そして、使用するかしないかに係らずサブドメイン以外についてもとりあえず設定しておくという癖をつけると万が一という事の予防になるかもしれません。

まとめ

さくらのレンタルサーバで独自ドメインを利用するケースで、他社のレンタルサーバから移転する場合は少し癖があります。
対策はありますので落ち着いて準備し、手順を踏めばサービスへの影響は最小限にすることが可能ですので是非参考にしてみてください。
 
また、レンタルサーバにはさくらのレンタルサーバにあるような癖がそれぞれのレンタルサーバに存在しています。
全てをここで上げる事は難しいのですが、ご紹介したようなコアサーバーの癖のようなものもありますので利用する場合の設定は最小限の設定で第三者に悪用されないよう適切な設定と確認を行うようにしていただければと思います。
 
明日からはPHPでの開発におけるライブラリやツールの紹介に入りたいと思います。