サーバーの信頼性に関する考慮事項
サーバーを動作させるプラットフォームの信頼性
- H/WやOS
- 信頼性を保つには
- アップデートして最新の状態に保つことは当然のこと
-
多様性をもたせることも肝要
- 一つのシステムに依存していると、そのシステムに問題が見つかったとき全てのサーバーが影響を受けてしまう
- 運用コストとの兼ね合いでもある
DNSソフトウェアの選択
-
選定基準
- 運用実績
- 運用ノウハウ
- サポート体制
- 多様性の確保
主なDNSソフトウェア
提供元 | 権威サーバー | フルリゾルバー | |
---|---|---|---|
BIND | ISC | o | o |
NSD | NLnet Labs | o | |
Unbound | NLnet Labs | o | |
PowerDNS Authoritative Server | PowerDNS COM BV | o | |
PowerDNS Recursor | PowerDNS COM BV | o | |
Knot DNS | CZ.NIC | o | |
Knot Resolver | CZ.NIC | o |
-
BIND
- 長らくオープンソースのDNSソフトウェアといえばこれだった
- namedが権威サーバーとフルリゾルバーとを兼任、機能が豊富
-
脆弱性がしばしば報告される
- 内部処理が複雑
- 設計上の問題
-
NSD
- シンプル、はやい
-
Unbound
- BINDの代替を謳う
-
PowerDNS Authoritative Server
- ゾーンデータをMySQLやPostgreSQL等に格納できるのが特徴
-
PowerDNS Recursor
- Luaスクリプトによるフィルタリング、名前解決処理の拡張が可能
-
Knot DNS
- 権威サーバーに特化、はやい
-
Knot Resolver
- あたらしい
サーバーを設置するネットワークの選定
- 安定した外部接続を持ち、帯域を十分に備えていること
- 複数の権威サーバー(プライマリ、セカンダリ)は異なるネットワークに置くこと推奨
- フルリゾルバーは利用者からのアクセスもしやすいこと
DNSの設定と運用にまつわる潜在的なリスク
権威サーバー間のゾーンデータの不整合
- ゾーン転送に失敗によるプライマリ/セカンダリの不整合
親子間のNSリソースレコードの不整合
- 自分のゾーンの権威サーバー(子)に変更を加え、レジストリ(親)の委任情報の変更を怠った場合など
lame delegation (不完全な委任)
- 委任先(子)が権威サーバーとして動作していない状態
-
例
- 委任先の設定ミス
-
委任元の設定ミス
- 権威サーバーが動いていないサーバに委任してしまっているなど
-
ゾーン情報の期限切れ
- プライマリ-セカンダリ間で通信できなくなった場合など
外部名の設定
example.com.
のNSがns1.example.net.
にある、みたいなやつ- 外部名の管理権限が奪取されると自分のゾーンの管理権限も奪われる
DNSSECとDNSクッキーの概要
- キャッシュポイズニング耐性を高める
DNSSECの概要
- DNSSEC: DNS Security Extensions
- DNSの応答に電子署名を追加する
- 受け取った応答の出自と完全制を問い合わせ側で検証できる
DNSクッキーの概要
-
HTTPのクッキー
- 元来ステートレスなHTTPでステートを実現する
- 同じことをDNSでやる
- 問い合わせ側と応答側がそれぞれのクッキー(クライアントクッキー/サーバークッキー)を使って相手を相互に確認する