DNSの移行方法について

お仕事の話ですが、最近、DNSを自社で保持しているBINDから、Amazon Web Services の Route53 にゾーン情報を移行しました。DNSに関する知識がほとんど無いところからやったので色々調べまくったりして大変でした。
その上で分かったDNSサーバの移行（ゾーン情報の移行）の方法について、今後の自分のためにメモを残しておきたいと思います。

覚えておきたい基礎知識

下記のようなサイトを見て学習しました。まずは「○○レコードってなんぞや？」というところを理解する必要があります。その次に、「じゃあ、具体的にどういう流れで移行すればいいんだ？」というところを調べていきます。


1．移行元ゾーンの様々なTTLを怒られない程度に短くする（移行2日前など）

まずは自社のBIND内のゾーンの色んなTTLを可能な限り短くします。
AレコードやNSレコードはもちろんのこと、SOAレコードのTTLも短くしてください。
目安としては、AレコードやNSレコードは300秒程度まで減らしてください。
SOAレコードは複数種類のTTLがありますが、それぞれ10分の1程度まで減らします。
個体差はあると思いますが、1日もあれば短くなったTTLで各DNSサーバの情報が書き換わっている（更新した情報が浸透できている）と思いますので、変更作業実施予定日の2日前ぐらいにはやっておきたいところです。

変更値の目安（これくらいまで短くしてください）

Aレコード … 300秒
NSレコード … 300秒
MXレコード … 300秒
TXTレコード … 300秒
SOAレコードのRefresh … 600
SOAレコードのRetry … 300
SOAレコードのExpire … 6000
SOAレコードのNegative cache TTL … 300
SOAレコードは特に’‘Negative cache TTL’‘を短くすることが大切です。これが短くなってると、もしなんかのミスで「そんなサーバ存在しねーよ」状態になってもNegative CacheのTTLの間隔で更新することが可能になります。


2．移行元を停止せずに移行先にゾーン情報をコピーする（移行2日前）

コピー方法はいろいろありますが、移行先サーバを作成して、そこに移管したいゾーンと全く同じ情報を登録します。
すみません、すべての情報のうち、移行元のDNSサーバー自身に関する情報は不要です。
すなわち、DNSサーバーを指し示すAレコードや、CNAME、NSレコードなどです。
BINDからAWS Route53への移行方法としては、Perlのスクリプトを使う方法が有名みたいです。しかし、この記事執筆時の移行元BINDサーバは、なぜかそれが使えなかったため、手動でコピーしました。ゾーンが数十など行くようであれば、どうにかしてツールでコピーすることをお勧めします。


3．移行先ゾーンの様々なTTLを怒られない程度に短くする（移行2日前）

移行先のゾーンのTTLも短くしてください。短さの程度は移行元と同じ程度で構いません。
理由は、移行の際に移行先ゾーンのTTLも短いと、設定漏れ内容の再設定を行うカバー作業の時間が短縮されるためです。
移行が完了したら、世の中のためにデフォルト値に戻しておきましょう。


4．移行元のゾーン情報に移管先のDNSサーバをNSレコードで登録する（移行2日前）

移行元のBINDサーバのゾーンに、移行先のDNSサーバをNSレコードとして登録します。
それにより、一時的に「DNSサーバの仲間が増えたから紹介するぜ！」状態になります。
つまり、レジストラの管理画面からWhois情報変更後に、古い情報を元に移行元サーバへ
問い合わせを行ってきたエンドユーザーに対して、応答可能なDNSサーバな1つとして、
移行先のサーバを紹介することができ、アクセスが途切れるのを防ぎます。
これをやっておかないと、さまざまなキャッシュが消えるまで全く接続できない状態になります。


5．移行先のサーバが世に出たことを確認する（移行1日前）

nslookup(dig)テスト【DNSサーバ接続確認】（[[http://www.cman.jp/network/support/nslookup.html]]）
などを使って、移行先のサーバが移行元サーバの新しいNSレコードとして追加されたかを確認する。
追加されていれば、前述の「DNSサーバの仲間が増えたから紹介するぜ！」状態になっていると言えます。

6．レジストラの管理画面からDNSサーバを移管先へ変更する（移行1日前）

お名前.comやムームードメインの管理画面へログインし、DNSサーバー（ネームサーバーと書かれていることも）の設定内容を変更します。 
自社でDNSサーバーを運用している場合は、そのDNSサーバーが設定画面に書かれていると思いますので、 その内容を移行先のDNSサーバーのものへ更新します。 
‘’これが実質的な「移行開始作業」’‘となり、ここから色んなキャッシュがクリアされるまで、いわゆる「長ければ数日、 サイトが見れなくなる」可能性があります。

7．旧サーバが参照されていないことを確認する （移行2、３日後）

TTLを確認して、切れたタイミングでDNSサーバー接続確認を再度行ってください。
SOAレコードおよびその他すべてのレコードの情報が移行先のDNSサーバーで設定したものとなっていれば、
移行は完了しています。それを確認した後、移行元DNSサーバからゾーン情報を削除するなり、
移行元DNSサーバーを停止するなりしてください。
もしものために、ゾーン情報を削除したり、サーバー自体を削除したりする前に、一度停止してみることをオススメします。


以上、これでいつかまた自分がDNSサーバの移行をやらなきゃいけなくなった時に、自分の記事を見てなんとかできることでしょう。未来の俺、検討を祈る。


コメント

コメントを投稿

このブログの人気の投稿

一部のユーザだけ NET::ERR_CERT_REVOKED でサイトにアクセスできない

イメージ
一部のユーザから、HTTPSのURLにアクセスできなくなったという連絡を受けました。 なんでも攻撃される恐れのあるサイトですとかなんとか…。 ブラウザのスクリーンショットをもらってみたら、こんな表示が。 Google Chromeでも同じ感じのエラーメッセージが表示されていました。（サイト名が出るので省略…） Chromeの方のエラーメッセージをよく見ると、 NET::ERR_CERT_REVOKED と書かれています。ファッ！？証明書が失効している…！？ そんな馬鹿なと思い手元でアクセスしてみたら普通に繋がる…HTTPSできてるよ？なんで？何が起こってるんだろう…。 結論を言うと、 SSL証明書業者が手違いで中間CA証明書を失効させてしまった ことにより、私たちが購入して使っている証明書が一時的に利用不可能になり、そのネガティブキャッシュをユーザが参照している 、というお話でした。 解消のための新しい中間CA証明書が公開されていたので、そちらを使って更新してみると、問題は解消されました。 ただ、自社が買っていたのはクイックSSL証明書だとばかり思っていたので、更新に失敗しまくって時間がかかりました。違うやつだった…。 SSL証明書とかドメインの周りのメンテナンスは多くても年に数回とかっていう頻度なので、いろいろ思い出すのに苦労しますね。 ていうか、そういうことあるんですね、中間証明書間違って消しちゃった！とか。 レジストラのDNSサーバダウンと合わせて、「 うちのせいじゃないんだけどご迷惑をおかけしてごめんなさい案件 」って感じで覚えておきたい…。
続きを読む

[AWS] WAF を自分で組み立てるなら SAM でテンプレート書いた方が楽だよ

タイトルの通りです。 あ、 この記事は AWS初心者 Advent Calendar 2018 の7日目 として書いております。 最近会社でWAFとかLambdaとかSAMとかちょっとEC2やRDSといった基本のプロダクトとは違った要素について検証・導入を行なっているのですが、Lambdaをデプロイするために使ってみたSAMでWAFをデプロイすると楽ちんでした。 たとえばここに、HTTPリクエストのメソッドの種別を確認し、HEAD、CONNECT、TRACEを利用したアクセスをブロックするようなWAFを作成するためのSAMテンプレートがあります。 これが存在するディレクトリで以下のようにパッケージングのためのコマンドを実行します。 あ、念の為に雑多なディレクトリではなく、このテンプレートだけが存在する新しいディレクトリを作成してください。 aws --profile [プロファイル名] cloudformation package --template-file template.yml --s3-bucket [あらかじめ用意したS3バケット名] --output-template-file packaged-template.yml これを実行することで、SAMでのデプロイのためにパッケージング化された各種ファイルが指定したS3バケットに送られ、そこからデプロイするために書き換えられた packaged-template.yml が生成されます。 Lambda Functionのためのソースコードがあればここで併せてパッケージング化されるのですが、今回は無いのでtemplate.ymlだけですね。 そして以下のコマンドを実行するとデプロイされます。 aws --profile [プロファイル名] cloudformation deploy --template-file packaged-template.yml --stack-name otameshi-http-method-restriction-for-cloudfront --capabilities CAPABILITY_IAM --parameter-overrides yourApplicationeName=[任意の文字列] コマンド名に
続きを読む

[#CentOS][#Apache] CentOS6 でApacheが起動できない

CentOS 6 で httpd を起動させようとした時のこと $ sudo /etc/init.d/httpd start httpd を起動中: httpd: bad user name apache    [ 失敗 ] なんじゃこりゃ。 ■問題 Apacheが起動できない。問題はapacheユーザ ■原因 httpd.confには ユーザ：apache グループ：apache　でhttpdを起動するようになっている。 ユーザとグループを確認してみよう… $ cat /etc/passwd | grep apache $ ユーザが居ない… $ cat /etc/group | grep apache apache:x:48: グループはある。なんでこうなってんだ？ ■対処 ユーザ「apache」を作ってグループ「apache」に入れてあげよう。 # useradd -g apache apache useradd: /etc/passwd をロックできません。後でもう一度試してください。 は？(#ﾟДﾟ) # ll /etc/*.lock -rw-------. 1 root root 5  2月 12 07:29 2013 /etc/passwd.lock -rw-------. 1 root root 5  2月 12 07:29 2013 /etc/shadow.lock これを消すか # rm /etc/passwd.lock rm: remove 通常ファイル `/etc/passwd.lock'? y # rm /etc/shadow.lock rm: remove 通常ファイル `/etc/shadow.lock'? y これでもう一度apacheをuseraddして…あれ、もしかしてロックファイルがApahceをインストール剃る前からあって、もしかしてyumのインストールシーケンスの中でユーザ作成だけ失敗してたりしてるのかな？ ということでApacheをインストールし直す方向で。 # yum remove httpd $ sudo yum install httpd httpd-devel mod_wsgi Pythonの勉強したいからmod_wsgiも入れてます。 で、yum入りました。 Transaction Summary
続きを読む