\こんにちは、m//t です。
豪雨が続きますね。線状降水帯ですか、なかなか厄介です……
今回は DNS 関連のトラブルに関する事例をご紹介します。
なお、本稿には前職でDNS関連サポートを担当していた経験や個人的にもDNS関連サーバを運用している中での経験も多く含んでいます。また、DNS関連セミナーやイベント等で紹介されていた事例を含む場合もありますのでご了承ください。
※書き進めていてボリュームが大きくなったので、小分けにします。
目次
お客様オフィス回線上位
【背景】
- お客様はオフィスのインターネット回線、およびメール/WEB等のレンタルサーバについて事業者Aを利用。
- お客様はメール/WEB等のレンタルサーバを他事業者Bに移転する意向。
【動き】
1 お客様は権威DNS/メール/WEBを事業者Bに移転すべく手配
2 事業者Bは各サーバ及びDNSゾーンを設定して待機
3 お客様が whois nameserver 変更 (事業者Bが対応)
4 事業者BのDNSサーバが参照されることにより外部からメール/WEB接続がはじまる。
【問題点】
- お客様は新しいメールサーバ、WEBサーバへアクセスできず、旧サーバに繋がる状況が続いた。
【原因】
- 事業者Aが提供するDNSサーバは権威、キャッシュ(フルリゾルバ)兼用で、お客様が移転後も権威DNSがゾーンを持ち続けていて、お客様からのアクセスに不具合が発生した。
- 事業者Aの権威DNS解約処理は毎月月末対応で、変更できないと言われた。
【結果】
- お客様は事業者Bへの移転を諦め、元通り事業者Aの提供する環境へ戻った。
【教訓】
- 移転元の情報を把握してきれいに切り替えよう。
出て行くのなら……
【背景】
- お客様はメール/WEB等のレンタルサーバについて事業者Aを利用。
- お客様はメール/WEB等のレンタルサーバを他事業者Bに移転する意向。
【動き】
1 お客様は権威DNS/メール/WEBを移転すべく事業者Bに相談
2 事業者Bは必要事項や懸念点についてお客様へ確認。お客様は事業者Aへ確認。
※ここで問題発生!! 事業者Aがこんなことを言い出した。
- ドメイン維持管理を他社移管した時点で DNSサーバからゾーンを消しますよ。
- ドメイン維持管理をうちのままでも、nameserverを他社のものに変更したら同様。
【問題点】
- 移転先DNSは準備できていても、これまで移転元を参照していた端末等は移転元DNSに問合せを続け、目的のレコードが得られず、メール送信やWEB閲覧に失敗する。
→ ということが移転実行前にわかった。
【原因】
- whoisが書き換わっても委任の連鎖途中にある nameserverの情報が変わるまで時間がかかり、その間正しいゾーン情報を持つDNSサーバに到達しなくなる。
【結果】
- 事業者Bは「移転元DNSのゾーン情報をうまく調整すれば最短に抑えられますよ」と提案したが、whois書き変え直後に移転元DNSからゾーン情報がなくなるのはしばらく牽けない状態となるため避けたい、と再検討されることになった。
【教訓】
- 最初に選んだ先が不幸の……
- 諦め(思い切り)も必要かと。
NSが……
【背景】
- お客様はメール/WEB等のレンタルサーバについて事業者Aを利用。
- お客様はメール/WEB等のレンタルサーバを他事業者Bに移転する意向。
【動き】
1 お客様は権威DNS/メール/WEBを事業者Bに移転すべく手配
2 事業者Bは各サーバ及びDNSゾーンを設定して待機
3 お客様が whois nameserver 変更 (事業者Bが対応)
4 事業者BのDNSサーバが参照されることにより外部からメール/WEB接続がはじまる。
【問題点】
- 移転前に一度移転元DNSを参照した端末等はwhois切替後も長時間移転元DNSを参照し続けた。
【原因】
- 移転元DNSにおいて、メールサーバやWEBサーバ等の各AレコードのTTLは短くしてあったが、NSレコードのTTLが非常に長く、そのキャッシュが接続元端末等が参照するリゾルバから消えるまで移転先DNSを参照してもらえなかった。
【結果】
- 事業者Bはお客様に対して、移転元DNSの内容を以下のように変更するよう提案。
1 ゾーン情報からSOAレコードとNSレコード以外の全てのレコードを移転先DNSと同じにする。
2 NSレコードで指す nameserver は 事業者Bが用意している nameserverに書換える。 - Aレコード等のTTLは短くしてあったため、事態を悪化させることなく移転完了。
【教訓】
- 移転元ゾーンのレコードは漏れなく全てTTLを確認しよう。
最後に
DNS移転、サーバ移転で問題を起こさないためには移転元DNSサーバでの適切な作業が重要です。
ただ、往々にして何らかの不満により移転されるケースが多く、移転元での作業対応が十分にできない状態で実施に踏み切られるのを時折り見かけます。移転元および移転先のDNSをうまく操作して、丁寧に作業されることをお勧めします。
[参考]
JPRS トピックス&コラム
「■DNSサーバーの引っ越し ~トラブル発生を未然に防ぐ手順とポイント~」
https://jprs.jp/related-info/guide/019.pdf
今回は「移転問題」をテーマにしていくつかのトラブル事例をご紹介しました。
今後のテーマとしては以下を予定しています。
「浸透問題」「設定ミス」「地雷原」……
以上、昔話担当? の m//t でした。
COBOL系SE,PG から NetNews(nntp)配送管理者(tnn.netnews.stats集計担当) を経て現職。
社内業務改善(「やりたくない」がモチベーション)でいろいろ社内ツールを作ってきました。
ネットワーク系の機器をいじることも多いので、それらの管理や制御に関するツールもちらほら。
perlで書くことが多いですね。(COBOLやFORTRAN、Pascal でもいいですけど……)
どれだけ読みやすく書けるか、10年後の自分に手紙でも書くような気持ちで。
最近はDNSを少しかじったりしてますが、いろいろ悩ましいことが多すぎます (>_<)
好きなポート番号は53、119、123です。
LINK
クラウドベリージャム:プロフィールページ