Edited at

出来る!DNSのお引っ越し!

More than 3 years have passed since last update.


出来る!DNSのお引っ越し!

image

この記事はDrecom Advent Calendarの11日目です。

前日は、@tkeoさんによる EmacsでUnity開発をするです。

空気を読まずにインフラっぽい話をします。

DNSです。

Drecomでは、ずっと、DNS権威サーバーを自社のサーバーで運用してきました。

しかし、DNSが障害を起こした時の影響範囲はとても大きく、障害発生時には自社のすべてのサービスに影響します。

なので、DNSはきちんと冗長化する必要があるのですが、自社で行うとなるとコストが高くなりがちです。

そこで、権威DNSサーバーに、外部のサービスを利用することにしました。

「Amazon Route53」や「Google Cloud DNS」、「Akamai Fast DNS」などですね。

さて、これらの外部のサービスを利用するには、そこへDrecomで運用していたDNS権威サーバーをお引越しする必要があります。

ここで得られた知見について、まとめていこうと思います。

この文章さえ読めば、明日、権威DNSサーバーをお引っ越しすることになってもだいじょうぶ!たぶん。


お引越しについて

では、お引っ越しのの手順について説明していきます、が、その前に、簡単にDNSについておさらいしましょう。


DNSのおさらい

DNSには2種類のサーバーがあります。

権威DNSサーバーとキャッシュDNSサーバーです。


権威DNSサーバー

名前(Domain Name)とコンテンツ(IPアドレス等)の対応を保持しているサーバーのことです。

このサーバーは世界中に複数あり、データを分散して管理しています。

DNSは、自分が管理するドメイン名空間(ゾーン)の一部を、別の複数のサーバーへ管理を任せる(委任する)事を繰り返すことで、

ツリー構造のカタチでデーターを分散して、管理しています。

image

図を見てください。

rootゾーンは、jpゾーン、comゾーン、netゾーンを、それぞれ委任しています。

更に、jpゾーンはdrecomゾーンの管理を、委任しています。

この、jpゾーンから委任されたdrecomゾーンを、我々が管理しています。


DNSキャッシュサーバー

通常、クライアントPCが名前解決を、直接行うことはありません。

クライアントPCはDNSキャッシュサーバーという子に、名前解決を依頼します。

DNSキャッシュサーバーは、ルートサーバーから、再帰的に名前解決を行っていきます。

「www.drecom.jp」の場合で、見てみましょう。

下記のような流れで、名前解決が行われます。


  1. DNSキャッシュサーバーは、ルートサーバーに名前解決を依頼します

  2. ルートサーバーは、DNSキャッシュサーバーへ.jpのDNS権威サーバーを教えます

  3. DNSキャッシュサーバーは、.jpのDNS権威サーバーへ名前解決を依頼します

  4. .jpのDNS権威サーバーは、DNSキャッシュサーバーへdrecomのDNS権威サーバーを教えます

  5. DNSキャッシュサーバーはdrecomのDNS権威サーバーへ名前解決を依頼します

  6. drecomのDNS権威サーバーは、DNSキャッシュサーバーへwww.drecom.jpの名前を教えます


お引っ越し

では、「お引っ越し」について、書いていきます。

簡単な手順は下記のようになります。


  1. 引っ越し元と引越し先を同じ状態にしておく

  2. 引っ越し元で、引っ越しするゾーンのNSレコードを引越し先へ向けておく

  3. 親の権威DNSサーバーで引越し先を指し示す

  4. TTLが切れるまで並行運用

ここでのポイントは、2です。

2の手順を経ることで、いわゆる浸透問題を発生させること無く、お引越しを完了させられます。


お引っ越しのポイント

引っ越し元で、引っ越しするゾーンのNSレコードを引越し先へ向けておく、とはどういうことなのでしょうか?。

また、何で、この手順が必要なんでしょうか?。

説明していきます。

まず、「引越し元で、引っ越しするゾーンのNSレコードへ向けておく」ということについて、drecom.co.jpを例にとって説明します。

image

引っ越しを行う前、drecom.co.jpのDNS権威サーバーは「ns1.drecom.co.jp」と「ns2.drecom.co.jp」であり、

jpゾーンのDNS権威サーバー(a.dns.jp. ~ g.dns.jp.)から指し示されています。

digで名前解決すると、下記のような結果になります。

;; QUESTION SECTION:

; drecom.co.jp. IN A

;; ANSWER SECTION:
drecom.co.jp. 300 IN A 210.148.6.25

;; AUTHORITY SECTION:
drecom.co.jp. 166513 IN NS ns1.drecom.co.jp.
drecom.co.jp. 166513 IN NS ns2.drecom.co.jp.

AUTHORITY SECTIONに、drecom.co.jpの権威を持つ(drecom.co.jpゾーンを管理している)DNSサーバーとして、ns1.drecom.co.jpとns2.drecom.co.jpが返されています。

引っ越しを行うにあたり、下の図のような状態に変更します。

image

digで名前解決すると、下記のような結果になります。

(引越し先の権威DNSサーバーを便宜的にns1new.drecom.co.jpとns2new.drecom.co.jpとします)

;; QUESTION SECTION:

; drecom.co.jp. IN A

;; ANSWER SECTION:
drecom.co.jp. 300 IN A 210.148.6.25

;; AUTHORITY SECTION:
drecom.co.jp. 166513 IN NS ns1new.drecom.co.jp.
drecom.co.jp. 166513 IN NS ns2new.drecom.co.jp.

この手順を踏まないと、どのような問題が起こるのか、「www.drecom.co.jp」を名前解決する場合を例にとって説明します。


  1. 「www.drecom.co.jp」を名前解決します

  2. すると、「www.drecom.co.jp」とns1.drecom.co.jpの両方がキャッシュされます


    • ns1.drecom.co.jpのTTLを3600秒、「www.drecom.co.jp」のTTLを300秒とします



  3. 「www.drecom.co.jp」のTTLが切れた時、ns1.drecom.co.jpのTTLがまだ残っているので、ns1.drecom.co.jpへ名前解決しに行きます

  4. その応答のAUTHORITY SECTIONには、ns1.drecom.jpとns2.drecom.jpが入っており、実装によってはキャッシュされているTTLの値がリセットされます

という流れで、いつまでも引っ越し元、今回はns1.drecom.co.jpとns2.drecom.co.jp、が利用されてしまいます。

この手順を踏むと、下記のような動作になります。


  1. 「www.drecom.co.jp」を名前解決します

  2. すると、「www.drecom.co.jp」とns1.drecom.co.jpの両方がキャッシュされます


    • ns1.drecom.co.jpのTTLを3600秒、「www.drecom.co.jp」のTTLを300秒とします



  3. 「www.drecom.co.jp」のTTLが切れた時、ns1.drecom.co.jpのTTLがまだ残っているので、ns1.drecom.co.jpへ名前解決しに行きます

  4. その応答のAUTHORITY SECTIONには、ns1new.drecom.co.jpとns2new.drecom.co.jpが入り、キャッシュが更新される

BIND 9.2.2以前では、このような挙動をします。

安全のため、この手順を踏んでお引越しをすることをおすすめします。


同期について

前項までで、お引越しに必要なDNS周りの知識を記述しました。

ここでは、DNS的な知識からはちょっと外れる、しかし、お引っ越しするにあたっては考えて置かなければならないことを、書きます。

それが何かというと、お引越し元とお引越し先の同期です。

ゾーン転送というDNSの仕組みが利用できれば、良いのでしょうが、そうは行かない場合もあります。

こんな時どうするかというと、APIを利用して同期をとるscriptを書きます。それしか方法ないですし。

また、このAPIを利用して同期をとるというのは、あとで述べるセカンダリの準備のところでも役に立ちます。


セカンダリについて

最近、DDoS攻撃でDNSが落とされる自体が何度か発生しています。

この事への、最も有効な対策は、別会社のDNSサービスを利用して、セカンダリを用意することです。

例えば、Google Cloud DNSとAmazon Route53などですね。

セカンダリが存在していれば、完全に引けなくなる事態は防げます。

しかし、ほとんどのDNSサービスでは、「自分がマスターになりセカンダリにゾーン転送をする」ということが出来ません(逆は可能です、お引越しに必要な場合があるので)。

なので、APIを利用して、変更を契機にして同期を走らせるなり、定期的に同期を走らせるscriptを書く必要があります。

ということで、ここで、先ほど書いた同期scriptが役に立ってきます。


まとめ

DNSについてのおさらいと、権威DNSサーバーを引っ越すときのポイントについて説明しました。

あることが当たり前で、普段意識することのないDNSというサービスですが、意識して調べてみると、色々と面白い気付きがあります。

みなさんもたまには調べてみると、楽しいですよ!。

次は、@motsatさんです。