DNS · レッスン 5

DNS 設定

authoritative または recursive DNS サービスを選択し、安全に設定、検証、運用する方法を学びます。

DNS ソフトウェアは、普遍的な「最良のサーバー」ではなく、役割と運用要件に応じて選びます。authoritative service は zone を公開し、recursive service は名前を解決・キャッシュしてクライアントへ応答し、forwarding resolver は別の resolver へ問い合わせます。役割を組み合わせると攻撃対象領域が変わります。

役割と実装を選ぶ

BIND は、幅広い標準に対応した authoritative service と recursive service を提供できる。
Unbound は、検証を行う recursive resolver としてよく利用される。
dnsmasq は、規模の小さい管理済みネットワーク向けに、軽量の forwarding、caching、DHCP 機能を提供する。
PowerDNS は、複数のデータ backend に対応した別々の authoritative 製品と recursive 製品を提供する。

機能とパッケージは変化するため、インストール済みバージョンの公式文書を参照してください。必要な役割だけを配備し、意図しない recursion または zone service を無効にします。

自身が提供する zone の決定的なレコードを公開する役割はどれですか？

インストール前に設計する

zone、クライアント、問い合わせ量、更新方法、DNSSEC 要件、ログ、監視、バックアップ、復旧を定義します。authoritative zone には冗長サーバーと正しく登録された委任が必要です。recursive service には、明示的なクライアントアクセス制御、キャッシュポリシー、上流または反復問い合わせ先への到達性、不正利用対策が必要です。

制限のない recursion をインターネットへ公開してはいけません。open resolver は reflection attack に悪用され、ローカルリソースも消費します。

recursive 問い合わせを許可済みクライアントへ制限するのはなぜですか？

設定と Zone Data を検証する

reload 前に、実装固有の構文検査・zone 検査ツールを使います。BIND での一般的な例は次のとおりです。

$ named-checkconf
$ named-checkzone example.com /etc/bind/zones/db.example.com

ホストに適した権限とパスで実行してください。parser が成功しても、委任、serial の伝播、DNSSEC chain、ファイアウォール越しの到達性、正しい回答は証明されないため、制御された問い合わせを続けて行います。

zone の構文検査に成功しても証明できないものはどれですか？

安全に適用してテストする

現在の設定と復旧アクセスを保持して検証し、対応していれば restart ではなく reload します。各 authoritative server へ recursion を無効にして直接問い合わせ、SOA serial、NS 集合、正のレコード、存在しない名前、UDP と TCP の両方を比較します。

$ dig @192.0.2.53 example.com SOA +norecurse
$ dig @192.0.2.53 missing.example.com A +norecurse
$ dig @192.0.2.53 example.com SOA +norecurse +tcp

recursion については、許可済み・拒否対象のクライアントネットワーク、DNSSEC validation、cache behavior、上流依存先の障害をテストします。

authoritative server へ +norecurse で問い合わせるのはなぜですか？

サービスを運用する

問い合わせ失敗、遅延、キャッシュ動作、リソース使用量、zone transfer、serial の整合性、DNSSEC の期限、委任の健全性を監視します。元設定と署名用データを安全にバックアップしますが、新しいインスタンスが zone を読み込み、正しく応答できることも検証してください。対応中のバージョンへ patch を適用し、制御インターフェース、dynamic update、transfer access を制限します。

authoritative DNS の冗長性テストには何を含めるべきですか？