---

運用者から見たDNSSECと従来のDNSの違い～運用上特に注意が必要なポイント～

---

DNSSECの運用には、従来のDNSにはなかった手順や注意点が存在しています。
従来のDNSと比較して特に注意が必要なポイントについて、具体的に解説します。

• 相対時間と絶対時刻
• データの有効期間に注意
• NSレコードとDSレコードは「似て非なるもの」
• データの登録・更新・削除のタイミングと順番
• NSEC3を用いる場合の注意点

相対時間と絶対時刻

 従来のDNS プロトコルでは、ある事象が発生した時点からの相対時間（タイムインターバル）で時間を管理しており、「○年○月○日○時○分○秒」といった、絶対的な時刻情報は使用していません（*1）。各リソースレコードのTTLやSOAレコード内の各設定値などは相対時間による秒数であり、例えばTTLの場合、キャッシュDNSサーバーが受け取ったTTL の値が初期値となり、1秒ごとに減算されていきます（図1）。
 このように、従来のDNS プロトコルでは絶対時刻を使用していないため、DNS サーバーにおける正確な時刻の維持は、必須ではありません。

▼DNSSEC では正確な時刻の維持が必要

 これに対し、DNSSECで導入された署名（RRSIGレコード）には、有効期間の開始（inception）と終了（expiration）の双方が、1970年1月1日からの絶対時刻で記述されています。
 そして、送信されてきた署名を受信側で検証する際には、その署名が有効期間内であるかを自身が管理する時計を参照して確認するため、DNSSECを構成するすべてのDNSサーバーでは、正確な時刻の維持が必要になります（図2）。

データの有効期間に注意

 このようにDNSSEC では、従来のDNS では発生しなかった「データは存在しているが、そのデータはもう（まだ）有効ではない」という状況が発生します。そのため、DNS サーバーに対するヘルスチェックを外部から実施する場合、単にデータの存在のみのチェックだけでは不十分で、データの内容の有効性のチェックについても併せて実施する必要があります（図3）。

 なお、ヘルスチェックを実施するシステムにおいても正確な時刻の維持が必要になります。

NSレコードとDSレコードは「似て非なるもの」

 DNSSECでは親子間の信頼の連鎖を構築するためにDSレコードの親への登録・公開が必要になります。DSレコードは従来のNSレコードに似た形で取り扱うことが可能ですが、その取り扱いにはNSレコードとは異なる点が存在しています。

▼NSは親子双方が持ち、子が権威を持つ

 NSレコードは親子双方に同じ内容が登録・公開され、子のNSレコードが権威を持ちます。親のNSレコードは権威を持たない委任情報として扱われます（図4）。

▼DS は親のみが持ち、親が権威を持つ

 これに対しDSレコードは子の鍵署名鍵（DNSKEY（KSK））から生成され、親にのみ登録・公開されます。そのため、DSレコードはNSレコードとは異なり、親のものが権威を持つことになります（図5）。

 そして、DNSSECでは親子間の信頼の連鎖を、親のDSレコードと子のKSKを照合することにより検証します。もし親のDSレコードに対応するKSKを子が一つも保持していなかった場合、即座にDNSSEC検証エラーとなり名前解決に失敗するため、特に注意が必要です。

データの登録・更新・削除のタイミングと順番

 DNSでは従来から、子のDNSサーバーでの準備完了後に親のデータを登録・更新することが必要でした。DNSSECの導入後はこれに加え、更新前の古いキャッシュデータが完全にクリアされた後に次の手順を実行するという手順を、これまで以上に遵守する必要があります。
 例として、二重署名法によるKSKのロールオーバー手順を表1に示します。

NSEC3を用いる場合の注意点

 ゾーンの列挙（詳細はトピックス＆コラムNo.16を参照）を防止するためにNSEC3を使用する場合、そのゾーンのすべての権威DNSサーバーがNSEC3に対応している必要があります。
 NSEC3では存在しない名前を問い合わされた際に権威DNSサーバーが必要なハッシュ値を動的に計算するため、権威DNSサーバーにNSEC3に非対応のものが含まれていた場合、正しく動作しません（図6）。

 セカンダリサーバーをDNSサービス事業者に委託する場合などに、特に注意が必要です。

---

SOAのシリアルに時刻を使用することがありますが、これはバージョン番号であり、DNSプロトコルでは時刻として管理されません。【↑】

---

掲載内容は2011年1月のものです。