KINDNS – DNS運用者への優しい手引

本「ICANN技術政策文書」シリーズの前回からしばらく時間が空いてしまいました。今回はICANNがはじめた「KINDNS: Knowledge-Sharing and Instantiating Norms for DNS and Naming Security」という取り組みについて紹介します。これはDNS運用者に対して、そのさまざまな状況に応じたベストプラクティスを取りまとめているプロジェクトです。ルーティングセキュリティにおけるMANRSをご存知の方は、それのDNS版だと思って差し支えないかと思います。

KINDNSとは

KIND(やさしい)とDNSをあわせてKINDNSと表記し、「カインドネス」(Kindness: 優しさと同じ)と発音します。KINDNSでは現在、三つのことに焦点をおいています。

• 運用者コミュニティにより積極的に取り入れられること
• KINDNSガイドラインへのフィードバックを収集整理し、現行のガイドラインに新たに加えるべきベストプラクティスを特定すること
• KINDNSガイドラインの自己評価ツールと監視プラットフォームを開発し、容易に運用とガイドラインとを比較できるようにすること

KINDNS ガイドライン

KINDNSでは、権威サーバ運用者、リカーシブサーバ運用者、プラットフォーム強化の三つにカテゴリ分けを行い、それぞれに対して運用ガイドラインを提供しています。また、それぞれの中でもTLD権威サーバやISPのリカーシブサーバのような重要なインフラを運用しているのか、それとも通常の組織ごとのゾーン権威サーバや社内のリカーシブサーバを運用しているのかなど、状況によって細かくチェックすべき項目が分かれています。

以降、典型的な例に従ってどのガイドラインが当てはまるのか、ガイドラインではどのようなことが求められているのかを見てみます。

権威サーバ運用者

権威サーバの場合、「TLDとクリティカルなゾーン」と「その他のゾーン」によって状況が2種類想定されています。ここでは一般的な「その他のゾーン」について簡単にご紹介します。

DNSセキュリティ

• 1. ゾーンはDNSSECで署名されなければならず(MUST)、鍵管理のベストプラクティスに従わなければならない(MUST)。
• 2. 権威サーバ間のゾーン転送にはアクセス制限を設けなければならない(MUST)。
• 3. 悪意的もしくは事故的で意図しない編集・改ざんを避けるため、ゾーンファイルの完全性を管理しなければならない(MUST)。

DNS可用性とレジリエンス

• 4. 同じサーバを権威サービスとリカーシブサービスで共用してはならない(MUST NOT)。つまり、権威サーバを運用する場合は、DNSソフトウェアのリカーシブ機能を無効化しなければならない(MUST)。
• 5. 運用的・地理的観点から、最低でも2つのサーバを使わなければならない(MUST)。
  • 1. あるゾーンのすべての権威サーバは、同一のサブネットに置いてはならない(MUST NOT)。
  • 2. あるゾーンのすべての権威サーバは、物理的に異なる場所に置かれなければならない(MUST)。
• 6. DNSインフラを構成するサービス・サーバ・ネットワーク機器の監視を実装しなければならない(MUST)。

リカーシブサーバ運用者

リカーシブサーバの場合、「プライベートリゾルバ」「共用プライベートリゾルバ」「パブリックリゾルバ」の3種類の状況が想定されています。ここでは社内用のリゾルバなどが該当する「プライベートリゾルバ」について簡単にご紹介します。

DNSセキュリティとプライバシ

• 1. DNSSEC検証を有効化しなければならない(MUST)。
• 2. クエリ送信元を制限するためにACL(アクセスコントロールリスト)を使用しなければならない(MUST)。
• 3. ドメイン名漏洩を低減するため、QNAME Minimizationを有効化しなければならない(MUST)。

DNS可用性とレジリエンス

• 4. 同じサーバを権威サービスとリカーシブサービスで共用してはならない(MUST NOT)。
• 5. 最低でも二つのサーバを使わなければならない(MUST)。
• 6. DNSインフラを構成するサービス・サーバ・ネットワーク機器の監視を実装しなければならない(MUST)。

プラットフォーム強化

これは権威サーバかリカーシブサーバか、どのような状況かに関係なく、すべての運用者が気にかけるべきベストプラクティスです。詳細はKINDNSのプラットフォーム強化のページをご覧ください。

ネットワークセキュリティ

• 1. DNSサーバへのネットワークトラフィックを制限するために、ACLを実装しなければならない(MUST)。
• 2. 顧客に割り当てられていないIPアドレスを送信元としたパケットを外部に送信しないために、BCP38/MANRSの外向きフィルタリングを実装しなければならない(MUST)。

ホストとサービスのセキュリティ

• 3. 各DNSサーバの設定はロックされなければならない(MUST)。
  • 1. DNSサービスの提供に不要なすべてのサービスやソフトウェアパッケージはアンインストールするか、削除されなければならない(MUST)。
  • 2. DNSサービスを提供するサーバではDNSサーバソフトウェアのみを動作させなければならない(MUST)。つまり、DNSサーバではWebやメールなど他のサービスを動作させてはならない(MUST NOT)。
  • 3. すべての関係するログやDNSサブシステムは有効化しなければならない(MUST)。ログはアーカイブ・調査・監査のため集中した場所に集約しなければならず(MUST)、集約されたログはポリシーに基づき一定期間保持されなければならない(MUST)。
• 4. システムリソースに対するユーザの権限やアプリケーションアクセスは制限しなければならない(MUST)。DNSサブシステムの管理に直接関係する者以外がDNSサービスの設定・データファイル・データベースを読み書きできないよう、ファイルの権限や所有者設定を制限しなければならない(MUST)。
• 5. システムとサービスの設定ファイルはバージョン管理しなければならない(MUST)。権威サーバの場合ゾーンファイル・ゾーンデータもバージョン管理しなければならない(MUST)。
• 6. SSHやWeb設定ツールなど、マネジメントサービスへのアクセスは制限されなければならない(MUST)。DNSサービスや管理に必要でないすべてのサービスは無効化するか、可能であればアンインストールしなければならない(MUST NOT)。もしくは、不要なサービスへのネットワークアクセスをブロックしなければならない(MUST)。
• 7. システムコンソールへのアクセスは、パスフレーズや2要素認証で保護された暗号鍵で保護されなければならない(MUST)。

今回はDNS運用のベストプラクティスをまとめたKINDNSをご紹介しました。一見すると当たり前のことが羅列されているように見えますが、自信を持って「これらにすべて準拠しています」と言える運用をするためには十分な準備が必要です。社内やサービスでDNS関連サービスを管理されている方は、運用要件の定義や日々のオペレーションの参考にしてみてはいかがでしょうか。