DNS委任: コンセプトとベストプラクティス

DNS委任の秘訣: インターネットの背骨を効率的かつ安全に管理する

2023年10月18日
翻訳: 竹洞 陽一郎

この記事は米Catchpoint Systems社のチュートリアル記事 "DNS Delegation: Concepts and Best Practices"の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。

DNS委任は、大規模で複雑なDNSインフラを管理する上で非常に重要な側面です。
これにより、組織はDNSゾーンをより小さく、より管理しやすい部分に分割し、異なるグループや個人に権限を委任することができます。
実際、委任は全体のDNSシステムの基盤の一つであり、ドメインの異なる部分の責任を分割することができるため、柔軟性やその他の利点を提供します。

この記事では、DNS委任のベストプラクティスを探求し、一般的な困難を避ける方法や、最適なパフォーマンスとセキュリティを確保する方法について詳しく説明します。
大規模なDNSインフラを管理するIT専門家であれば、DNSの仕組みについて興味があるだけであれば、この記事はDNS委任とその利点に関する貴重な洞察を提供します。
始めましょう！

DNS委任のキーコンセプトのまとめ

この記事で取り上げる内容を簡単にまとめました。

DNS委任の定義

「委任」という言葉は、一つまたはそれ以上のタスクの一部の責任を別の人または組織に移転することを意味すると、おそらく皆さんは知っているでしょう。
この用語はDNSの世界でも使用されており、そのプロセスはDNSゾーン委任（または単にDNS委任とも呼ばれることがあります）と呼ばれています。

DNS委任は、親DNSゾーンがDNSリゾルバに対して、DNSサブゾーン（または子ゾーン）の権限を異なるセットのDNSサーバに委任したことを示すプロセスです。
これにより、DNSリゾルバはサブゾーンのDNSレコードのための委任されたDNSサーバを見つけて問い合わせることができます。

DNS委任の利点

DNS委任を使用することで、DNS管理者や組織全体に多くの利点がもたらされます。

性能の向上

DNS名前空間の一部を異なるセットのDNSサーバに委任することで、主要なDNSサーバの負荷を減少させることにより性能を向上させることができます。

DNS管理の簡素化

DNS委任により、異なるチームや場所がそれぞれのDNS設定を管理することを可能にすることで、DNS管理を簡素化することができます。

サードパーティサービスとの統合

DNS委任を使用することで、コンテンツ配信ネットワーク（CDN）、クラウドベースのメールサービス、または追跡サービスなど、自らのDNSサーバにあなたのDNS名前空間の一部のDNS管理を委任することを要求するサードパーティサービスと統合することができます。

DNS委任の応用

上述したDNS委任のさまざまな利点は、DNSの多くの使用に適用されます。
しかし、それらはDNS委任が特に有用である多くの状況を示しています。

一般的なDNS委任の応用例としては、以下のような状況が挙げられます。

責任の分散

複数の部門や子会社があり、DNS管理の責任を異なるチームや場所に委任する必要がある場合。

サブドメインの特化

Webサイトやウェブアプリケーションのサブドメインを作成し、別々のDNS管理が必要、またはそれにメリットがある場合。

性能の強化

負荷分散と地理的分散を活用して、DNS問い合わせの応答を最適化したい場合。
サブゾーンを異なるDNSサーバに委任することで、組織は効率的に問い合わせの負荷を分散することができます。
さらに、戦略的に異なる地理的位置にあるDNSサーバに委任することで、ユーザは最も近いサーバに接続することでより速いDNS応答を受け取ることができます。
これらの技術を組み込むことで、組織は性能を強化し、リソースの利用を最適化し、ユーザに対してより速く効率的なDNS解決の体験を提供することができます。

サブドメインの外部委託

外部管理が関与する特定の目的のためにサブドメインを使用する必要があるかもしれません。
例えば、多くの組織は、メール認証や送信者の評価といった技術的な側面を取り扱う専門のメールサービス企業に委任するために、メールマーケティングの目的のために別のサブドメインを特別に作成します。

ゾーンとサブゾーンの理解

DNSは、ゾーンと呼ばれる単位に権威ある情報を組織化します。
ゾーンは基本的に、特定のDNSサーバが権威を持っているDNS名前空間の一部です。
各ゾーンには、そのゾーンのDNS情報を定義するリソースレコードのセットが含まれています。

ゾーンは、プライマリ（メイン）およびセカンダリ（バックアップ）ネームサーバの両方に分散され、それらのゾーンに対する権威ある回答を提供します。
複数のサーバにゾーンを分散する目的は、1つ以上のサーバが利用できなくなった場合に冗長性と可用性を確保するためです。

ゾーンにはフォワードマッピングとリバースマッピング、2つのタイプがあります。
フォワードマッピングゾーンはホスト名をIPアドレスにマッピングするために使用され、リバースマッピングゾーンはIPアドレスをホスト名にマッピングするために使用されます。
両方のタイプのゾーンには、同じ基本的な情報セットが含まれています：

• ゾーン名
• SOA（Start Of Authority）レコード
• NS（NameServer）レコード
• その他のリソースレコード（オプション）

以下の画像は、BINDフォーマットのフォワードマッピングゾーンの例を示しています。

サブゾーン、または子ゾーンとも呼ばれるものは、ドメイン名の後半部分を親と共有するゾーンの分割です。
以下に示されているように、例えば、親のドメイン名がcompany.comの場合、サブゾーンはsales.company.comとなる可能性があります。

ゾーンと同様に、サブゾーンは管理上の利便性のためにまとめて管理されるDNSレコードのグループです。
通常、サブゾーンは特定の組織的要件を満たすために作成されます。
例えば、企業内の異なる部門や地域を分離するためなどです。

「サブゾーン」と「委任ゾーン」という用語が混同を招くかもしれませんが、委任ゾーンは基本的にサブゾーンであることを注意することが重要です。
ただし、サブゾーンとは異なり、委任ゾーンは親ゾーンとは異なるDNSサーバで管理されているという点が異なります。
この記事の後半で、これら二つの概念を比較するセクションがあります。

DNS委任の仕組み

DNSは30年以上前に設計されました。
インターネットの規模が劇的に拡大し、それに伴いDNSの管理要件が増加しても、委任が基本的に管理を分散化するため、DNSはうまくスケールしてきました。
上記の例を使用して、委任が具体的にどのように動作するか詳しく見てみましょう。

前述のサブゾーンの例では、company.comのDNS管理者は依然としてサブゾーンを管理しています。
しかし、例えば販売部門が特定のニーズを持ち、もはやcompany.comのDNS管理者のルールに従いたくないとしましょう。
独自のDNSサーバを設定し、独自のパラメータでsales.company.comを管理したいと考えています。

その場合、販売部門は委任を設定するためにcompany.comのDNS管理者と連携する必要があります。
そのため、sales.company.comの権威は、販売部門が管理する新しいDNSサーバセットに委任されます。

効果的な委任には、親ゾーンと子ゾーンの間の密接な協力が必要です。
具体的には、親ゾーンは、他の再帰リゾルバを参照するための、子の新しい権威サーバ（プライマリおよびセカンダリ）のNSレコードを含む必要があります。
これらはグルーレコードと呼ばれ、以下でさらに説明されています。

実際、DNS委任は常に行われていて、それは根本であるルートドメインから始まるからです。
DNSでの委任は、ルートドメインから問い合わせ先のドメイン名まで、階層的に行われます。
以下は、www.example.comというドメイン名を例として問い合わせる際に委任がどのように行われるかの概要です。

DNSリゾルバ（通常はあなたのISPにあります）がクライアントからDNS問い合わせを受信すると、キャッシュを確認します。
キャッシュ内に必要なIPアドレスが存在せず、かつフォワーディングの設定もされていない場合、デフォルトでは問い合わせは反復してルートネームサーバへと送られます。
ルートネームサーバのIPアドレス（IPv4とIPv6の両方）は、「root hints」として知られるファイルに保存されており、これは任意の再帰リゾルバの一部です。

ルートサーバは、このケースでは名前の最後の部分、要求された完全修飾ドメイン名（FQDN）の一部、つまり.comの部分のみに対して権威を持っており、この参照に応答します。
ここには、委任されたドメインのNSレコードが含まれます。
例えば、要求されたドメインがwww.example.comの場合、ルートサーバは、それが最上位であるため、以下に示すように.comのネームサーバのリストを提供します。

com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.

トップレベルドメイン「.com」のネームサーバ

ルートサーバから.comのネームサーバのリストを含む参照メッセージを受け取った後、再帰的リゾルバはその情報をキャッシュします。
そして、リストからネームサーバを一つ選び、反復的な問い合わせを送信します。

委任されたドメインのネームサーバは、要求されたドメインの一部に対して権威を持っているため、参照で応答します。
参照メッセージの中で、委任されたドメインのNSレコードを送信します。
要求されたFQDNがwww.example.comの場合、.comのサーバはexample.comのネームサーバのリストで応答します。

example.com.		172800	IN	NS	a.iana-servers.net.
example.com.		172800	IN	NS	b.iana-servers.net.

「example.com」のネームサーバ

前のステップの回答をキャッシュした後、再帰的リゾルバはプロセスを続け、選択されたネームサーバ（例：a.iana-servers.net）にFQDNの反復的な問い合わせを送信します。
一度example.comのネームサーバに到達すると、権威あるネームサーバは、リゾルバに対してAuthoritative Answer (AA) フィールドセットの回答を送り返します。
この回答には、NXDOMAINなどの有効なレスポンス、またこの例の場合はAレコードが含まれます。

www.example.com.		86400 	IN	A	93.184.216.34

「www.example.com」のIPアドレスを示すAレコード

以下の画像は、ルートDNSサーバからexample.comドメインの権威までのDNS解決のトレースを示している上記のプロセスを示しています。
このツールはこちらで見ることができます。

グルーレコード

グルーレコードは、親ドメインと子ドメインを接続する情報をAレコードとAAAAレコードの形で提供するため、委任には不可欠です。
これらは、ドメイン名とそれに対応するネームサーバ間の循環依存関係を解決するのに役立ちます。

再び委任の例を見てみましょう。
親ゾーンcompany.comは、ns1.sales.company.comおよびns2.sales.company.comネームサーバにsales.company.comを委任しています。
この場合、適用されるゾーンの子としてのネームサーバを使用しているので（例：ns1.sales.company.comはsales.company.comの子です）、これらのネームサーバがどこにあるか（対応するIPアドレスによって）を知るためにグルーレコードを使用する必要があります。

そうしないと、解決ループにはまってしまいます。
したがって、親ゾーン（company.com）は、委任（NSレコード）だけでなく、ネームサーバの名前をそのIPアドレスにマップ（またはグルー）するAレコード（必要に応じてAAAAレコード）も含んでいます。

sales.company.com. IN NS ns1.sales.company.com.
sales.company.com. IN NS ns2.sales.company.com.
ns1.sales.company.com. IN A 2.2.2.2
ns2.sales.company.com. IN A 3.3.3.3

グルーレコード記載例

サブゾーンと委任の比較

親ゾーンの管理者として、サブゾーンと委任の適切な使用を考慮することが重要です。
子ゾーンのコントロールを維持し、そのデータを親ゾーンと同じサーバに保存する場合は、サブゾーンが適しています。
しかし、子ゾーンに独自の管理権限を持たせ、データを別のサーバに保存したい場合は、委任がより良い選択となります。

内部専用のドメイン設定では、委任はほとんど必要ない一方で、サブゾーンははるかに一般的に使用されます。

「Lame delegation」とは

「Lame delegation」とは、親ドメインが子ドメインを特定のネームサーバセットに委任しようとするが、そのネームサーバがゾーンの権威を持っていないか、あるいはDNSサービスで操作できない状況を指します。
以下で、lame delegationの一般的なシナリオを詳しく見ていきましょう。
また、RFC 8499とRFC 1912で技術的な定義も見ることができます。

下の画像は、親ゾーン（company.com）が誤ったグルーレコードを含む参照で応答し、再帰的リゾルバを誤った、または到達不可能なIPアドレスに指示するシナリオを示しています。
再帰的DNSがこの参照を追跡すると、IPアドレスが到達不可能（サーバダウン）であるか、利用可能であるがDNSサービスが実行されていない（タイムアウト）ため、ドメイン名を解決できないことがわかります。
クライアントはおそらく遅延を経験し、最終的に再帰的DNSリゾルバから「SERVFAIL」応答コードを受け取るでしょう。

下の画像の内容で考えてみましょう。

再帰的リゾルバが親ゾーンからの参照を受け取ると、ネームサーバのうちの1つだけが正しいものとして参照されます。
サーバ2.6.6.6はsales.company.comの権威を持っていません。
そのため、リゾルバが権威ある答えを求めてネームサーバ2.6.6.6に問い合わせを送信するたびに、どんな応答も得られず、ルートサーバから再度開始します。

この例では、再帰的リゾルバは、親ゾーンによって提供される2つのNSレコードがあるため、IPアドレス2.2.2.2を持つ正しいネームサーバを選択する確率は（ラウンドロビンメカニズムを使用していると仮定して）50％です。
エンドユーザにとって、この問題は名前の解決が遅いとして現れるかもしれません。
再帰的リゾルバは、最終的な権威あるネームサーバ2.2.2.2に到達するか、タイムアウトが発生するまで、繰り返しループを続けます。

結論として、Lame delegationはDNS解決のエラーやドメイン名の解決プロセスの遅延の原因となることがあります。
これは、委譲されたサブドメインの問い合わせが繰り返しLame DNSサーバに参照されるためです。
Lame delegationは、DNS問い合わせのログを分析することで特定できます。Lame delegationは、DNSサーバの設定を修正して更新すること、または有効な応答を提供できる異なるDNSサーバにサブドメインを委譲することによって解決できます。

DNS委任のベストプラクティス

DNSゾーンの効果的な委任は、信頼性の高く利用可能なDNSインフラを維持するために不可欠です。
委任が適切に行われると、DNS問い合わせの効率的な解決が可能となり、問題のリスクが最小限になります。
このセクションでは、DNSインフラの最適なパフォーマンスとセキュリティを確保するためにDNSゾーンを委任する際に従うべきベストプラクティスについて説明します。

正確性の維持

委任されたゾーンのNSレコードが最新であり、現在の権威のあるネームサーバのセットを正確に反映していることを確認します。
これにより、Lame delegationの問題を回避できます。
これは、委任されたネームサーバの状態を定期的に監視し、それらが適切に設定され、正しく機能していることを確認することで実現できます。

少なくとも2つの権威ネームサーバを使用する

ドメインを1つのネームサーバだけに委任すると、単一障害点となり、ドメインのダウンタイムの原因となることがあります。
ドメインが利用可能であることを確保するために、異なる地理的地域に位置する少なくとも2つのネームサーバを使用することを推奨します。

コミュニケーションと文書化を優先する

すべての関係者間の明確なコミュニケーションは、効果的なDNS委任にとって不可欠です。
すべての人が彼らの役割と責任を理解していることを確認し、委任された内容とプロセスの各部分の責任者に関する記録を提供する徹底的な文書化を作成します。

DNSのヘルスと設定を定期的に監視する

DNSサーバとゾーンファイルを頻繁に監視し、最適に動作しておりエラーがないことを確認します。
DNS監視ツール（Catchpointなど）やアラートサービスを使用して、問題が深刻になってオンラインサービスに影響を与える前に検出します。

主要な概念の要約

DNS委任は、インターネットがその巨大なサイズと複雑さにもかかわらず効率的に維持されるための基本的な部分です。
組織がDNSの責任を異なるチームや場所に委任するとき、DNSの管理を簡素化し、パフォーマンスを向上させ、サードパーティのサービスを組み込むことができます。
しかし、DNSインフラの安全性と信頼性を確保するためには、この記事で概説されているようなベストプラクティスを使用することが重要です。

DNS委任を正しく実装することで、組織は効率的なDNS管理を保証し、潜在的なDNSインフラの問題を最小限に抑えることができます。

次は？

1. DNS委任

DNS委任のアプリケーションと利点について全て学びましょう。実装のベストプラクティスも含みます。

2. DNSフラッド攻撃

DNSサーバをターゲットにした分散型サービス拒否（DDoS）攻撃であるDNSフラッド攻撃のタイプと影響、そしてそれらからどのように保護するかについて学びましょう。

3. プライベートDNS

プライベートDNSについて全て学びましょう。利点、異なるアーキテクチャタイプ、およびベストプラクティスを含みます。

4. DNSのTTL値

この無料ガイドでは、DNS Time to Live（TTL）値、その重要性、およびさまざまなレコードタイプに対して適切な数字を選択するためのベストプラクティスについて全て学びましょう。

5. マネージドDNS

マネージドDNSの利点と欠点を探り、手動DNS管理と比較してみましょう。

6. DNS攻撃

DNS攻撃がどのように機能し、それらを特定し軽減する方法を学びましょう。これには、DNSポイズニング、トンネリング、フラッド、ハイジャックが含まれます。

7. 遅いDNS

DNSパフォーマンスに影響を与える要因を学び、遅いDNSの状態を診断する方法とDNS速度を最適化するためのベストプラクティスについて学びましょう。

8. DNSハイジャック

DNSハイジャックがどのように発生するかを一例を用いて学び、これらのサイバー攻撃を検出し、修復し、防ぐためのベストプラクティスについて学びましょう。