DNSがよくわかる教科書 ch10 よりよいDNS運用のために

DNS勉強メモ

出典: 


サーバーの信頼性に関する考慮事項

サーバーを動作させるプラットフォームの信頼性

  • 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でやる
  • 問い合わせ側と応答側がそれぞれのクッキー(クライアントクッキー/サーバークッキー)を使って相手を相互に確認する