今昔物語：DNS

こんにちは、元々満員電車が苦手で以前から早めに出社していましたが、 最近は時差出勤者が増えたせいかコロナ前より電車が混んでいて、どうしたものかと思案中の m//t です。

当社のDNS

さて、今回は当社DNSサービスの変遷について、トラブル事例も交えてご紹介します。
前回に続き、古い内容もあるため、不明瞭、不正確な点についてはご容赦ください。

黎明期

昔々、当社のDNSサーバは複数台で構成していましたが、権威DNSとキャッシュDNS(フルリゾルバ)を兼用していました。
構成を初めて見た時に感じたのは、

• オープンリゾルバなのは嫌だ！
• 権威DNSとキャッシュDNSを同居するのは嫌だ！

ということでした。
改善作業に取り組みたかったのですが、システム開発の手伝いに駆り出されたり、とあるお客様サーバ群の構成変更に伴うネットワーク変更設計等で忙殺されてしまいました。

DC移転

2006年6月、メインで利用していたデータセンタ(以降DC)が2008年3月閉鎖を発表します。
お客様サーバを含む全ての機器を移設する必要が出てきました。
DNSサーバもその一つです。
移転先は以前より利用している別事業者のDC。すぐ近くにあります。

仮想化へ

移転に際し、ハードウェア(自社サーバ群)の圧縮とIPアドレスの付け替えが命題となりました。
新しく購入したちょっといいサーバ上に仮想サーバとして移転元サーバの後継機を構築していきます。

お客様サーバからの参照先にもなっているため、新旧両DCで同じ名前のDNSサーバを稼働させ、お客様サーバの移転にあわせて新DCのDNSを参照するように変更していきます。

DNSサーバたちも搭載先物理サーバを分散しながら仮想サーバとして配置しました。

壁にぶつかる

しばらくして問題が2点あがりました。

1. 同一物理サーバに同居する別の仮想サーバが思いのほか負荷が高く、DNSサーバ群の応答にも影響し、そのせいで一部のお客様環境に影響が出始めていたこと。
2. 移転先DCに元々あったお客様サーバ で可能な限りのプロセスを再起動しても、まだ移転元DNSサーバを参照しに行く機器がいること(サーバ再起動にはお客様との調整に時間がかかる)。

です。
一つ目については従来通りの物理サーバでDNSを稼働させることで一旦回避しました。
もう一つについては厄介で、移転元閉鎖が間近なためお客様調整の時間が作れない状況でした。
移転元DCに相談し、離れたDCでしばらく同じIPアドレスのDNSサーバを稼働させて貰うことで時間を稼ぎました。
2008年春には移転元DCを完全撤収し、一時避難していた一部DNSサーバも2009年秋までには移転を完了、撤収しました。

権威キャッシュ兼用問題

そんな中、ドメイン管理を含む他社からのホスティング移転のご契約をいただきます。
当社での準備も済ませ、whoisのネームサーバ情報も変更。当社内や各種外部環境において新サーバへの接続が確認できましたが、お客様環境からは 待てど暮らせど古いサーバしか見えません。

原因は、 お客様オフィスのインターネット環境がホスティングと同じ事業者を利用していたこと、 その事業者が権威DNSとキャッシュDNSを兼用していたことでした。
そのせいでお客様オフィスからは新しいゾーン情報にアクセスできず、新サーバを利用できない状態が続きました。
残念ながらこのお客様は当社契約をキャンセルし、元の環境に戻られました。

そういう事件もあって、「当社DNS環境も権威DNSとキャッシュDNSを分離すべきだ」という空気感を醸成することができました。
加えて、当時権威DNSへのamp攻撃が流行し、RRL (Response Rate Limiting)を導入したいが、キャッシュDNSが同居してたら無理、というのもきっかけになりました。

分離計画

権威DNSとキャッシュDNSを分離して、より健全な環境を目指します。
以下の三段階で行うことにしました。

1. 役割りの明確化
2. 各DNSサーバにアクセス制限(ACL)を導入する。
3. 権威DNSサーバでリゾルバの機能を停止する。

役割りの明確化

以下を実施

• 各サーバで権威DNSとキャッシュDNSの役割りを明確にする。
• 運用する各ドメインの whois nameserver 情報を今回「権威DNS」と決めたもののみに変更。
• 権威DNSとして保持する各ドメインのゾーン情報内のNSレコードも同様に変更。

各DNSサーバにアクセス制限(ACL)を導入する。

社内利用のIP群、お客様に提供しているネットワークおよび、一部のお客様オフィス環境(ご利用回線事業者提供のリゾルバへの変更過程)についてリストアップし、各DNSサーバの許可リストとした。
この段階では権威DNS、キャッシュDNSともにリストに載っているアドレスからの問合せに対してリゾルバとして機能するようにした。
当社キャッシュDNSを参照しているお客様オフィス環境についてはそれぞれの回線事業者が提供するサーバを参照するように変更いただいた。

権威DNSサーバでリゾルバの機能を停止する。

全ての機器のDNS問合せ先(フルリゾルバ設定)を変更したのち、権威DNSサーバに再帰問い合わせが来なくなったのを確認して、リゾルバの機能を停止した。

さらに繰り返す……

仮想化

機能分離や実験環境等により関連サーバが増えてきたため、再びハードウェア圧縮を試みます。
複数のサーバでストレージを共有したうえで、KVMベースで仮想マシンを載せました。
これによりハードウェアの冗長化と負荷調整の容易化を図ることができました。

DC移転

2018年、環境老朽化(データセンタ事業者の統廃合?)により、再度DCの閉鎖が決まります。2020年初春がリミットです。
移転先については様々検討の結果、 同一事業者の別DCに移ることにしました。

最初に新旧DC間を回線で繋いでひとつの大きなネットワークにします。
その後、物理的に機器を移設したり、新環境を構築して新旧DC間で無停止マイグレーションしたりと、いろんな方法で移転を進めていきます。
DNSサーバ群についても新DCに新しく仮想環境を構築し、移せるものはそのままマイグレーション、必要に応じて新サーバを構築して同IPのまま新旧DCで切り替え等を行い移転を完了しました。

今後は……

DoHやDoT、さらには最近議論が再燃しているDNSSECへの対応等、セキュリティ面での検討も進めていく必要があります。
(結果どうするかはわかりませんが……)

最後に

トラブル事例についてはあまりご紹介できませんでしたが、別の機会にまとめてご紹介できればと思います。

ドメイン事業者やDNSサーバを変更する場合、移転元(変更元)での準備が重要になります。
「新DNSに新ゾーンを突っ込んで、whois切り替えればいいや」という考え方は高い確率でトラブルが起きます。
他社DNSへ移転される場合でも、新しく(移転等で)当社DNSをご利用いただく場合でもできるだけ不具合が発生しないようご協力できればと思います。
不明点はお気軽にご相談ください。

以上、昔話担当? の m//t でした。