2020年10月24日(土) - 22:19 | カテゴリ:
Linux
DNSサーバと言えばBINDを思い浮かべる人が多いと思うが、
パケット1発で落ちるBINDコロリと呼ばれる様な脆弱性が出てきたりして、
昨今は脱BINDが囁かれる様になった。
そうは言っても、デファクトスタンダードとなっているBINDじゃないと出来ない事があったり、
権威DNS・キャッシュDNSを兼用させて、リソースをケチるにはBIND以外の選択肢が無かった。
筆者も例に漏れず業務含めメイン用途ではBINDを使い続けていたが、
ひょんな事からBIND以外の権威DNSサーバを運用する必要性が出てきたので情報収集を開始。
『コレは自鯖基盤の権威DNSにNSDを追加して運用チャンス (｀・ω・´)』
という事で、dnsdistを使う事でBIND・NSD間のフォールバックも実装しつつ、
権威DNSにBIND・NSDを併用した環境を構築してみた。
NSDのビルド方法などはコチラ
“ns-lab BB”のインターネット向け権威DNSは、gdnsdを使ってグローバルロードバランサも兼任している。
また、DNSクエリログを解析する事でFW自動遮断をしているので、クエリログ取得も必須要件となる。
この課題を解決する為に、フロントエンドにdnsdistを使ってクエリログを取得しつつ、
グローバルロードバランサ用のサブドメインクエリのみgdnsdに曲げる設計となっている。
NSDはソースを改造しないとDNSクエリログを取得出来ないのだが、
同様にクエリログを取れない、gdnsd・dnsdist構成を作ってあったので問題を解決出来そうだった。
という事で、今回の権威DNS構成変更によって最終的に上の構成になった。
“ns-lab BB”のインターネット向け権威DNSは、
IPv4/IPv6でデュアルスタックにしつつ合計4台で負荷分散をしているのだが、
内部では2台1セットで運用しており、セット毎に稼働OSとkernelチューニングを変えている。
今回は2台1セットを維持しつつ、1セット内でBINDメインとNSDメインを用意した。
さらにバックエンドにNSDとBINDをバックアップとして構えておき、dnsdistで転送先を切り替えられる様にした。
この構成にする事で、BINDやNSDが脆弱性で落ちたとしても1～3秒程度で互いのバックアップに切り替わり、
権威DNS停止から来る名前解決待ちや正常系への再問い合わせ遅延が発生しにくくなった。
また、フォールバックする様にしておく事により、サーバメンテナンス時に正常系のバックエンドに切り替え、
サービス停止無しでメンテナンスを行える様になった。
………
独自ドメインを持っている大半の人は、レジストラや代理店が用意している権威DNSを使うと思う。
というのも、権威DNSが落ちるとサービスに繋がらなくなる上、メンテナンスと脆弱性対応が面倒なので、
自鯖を趣味としている人でも、権威DNSを自前運用してインターネット公開している人は少ない筈。
企業レベルでドメインを運用するなら、IaaS付属の権威DNSや権威DNS専用サービスを別途契約してしまい、
自前運用している所は相当減ってきている様に感じる。
さらに、権威DNSサーバの脱自前運用も叫ばれ「餅は餅屋」ならぬ「ドメインは権威DNS屋」も浸透してきた。
だとしても、ローカルなど閉じた環境では自前運用が必須となる上、相応の経験が必要となるのが事実。
先の通り、DNSが止まるとサービスが全滅する事もあり、可用性確保に躍起している運用担当も多いと思う。
だからこそ、何でも出来る自鯖で今回の様なトリッキー構成を試してみるのは今後も必要になるだろう。
« 続きを隠す
