JAPAN REGISTRY SERVICES
No. 018

ＪＰＲＳ トピックス＆コラム■運用者から見たＤＮＳＳＥＣと従来のＤＮＳの違い～運用上特に注意が必要なポイント～
ＤＮＳＳＥＣの運用には、従来のＤＮＳにはなかった手順や注意点が存在しています。
従来のＤＮＳと比較して特に注意が必要なポイントについて、具体的に解説します。
■相対時間と絶対時刻

署名の有効期間を2011年1月8日17時45分4秒から2011年2月7日17時45分4秒までに設定

従来の DNS プロトコルでは、ある事象が発生した時点からの相対時間（タイムインターバル）で時間を管理しており、「○年○月○日○時○分○秒」といった、絶対的な時刻情報は使用していません 1 。各リソースレコ
ードの TTL や SOA レコード内の各設定値などは相対

jp. 86400 IN RRSIG SOA 8 1 86400 20110207174504 (20110108174504 60969 jp.
cXIsCBEbdIlER4bmx/7B4NdeFVlG/PypYxzyTb91OhtC
5OrDjXEKAH7XvuEZ5RGXHRShsnuUZoaty/oifRnfsceE
KEQkeI2dCCAg2UvhmN66SLjLcUkNadrPCBmm87ve94aa
33cC4tHGDuUHC7+ez0usc3Dxm5t0D5ljUWyJAFY= )jp. 86400 IN RRSIG …

jp. 86400 IN RRSIG …

時間による秒数であり、例えば TTL の場合、キャッシュ
DNS サーバーが受け取った TTL の値が初期値となり、1 秒ごとに減算されていきます（図 1）。
このように、従来の DNS プロトコルでは絶対時刻を使用していないため、DNS サーバーにおける正確な時刻

現在の時刻は2011年1月13日22時29分40秒
つまり、今受け取った署名は有効期間内
キャッシュDNSサーバー

権威DNSサーバー

図 2: 正確な時刻の維持が必要な理由■データの有効期間に注意の維持は、必須ではありません。

このように DNSSEC では、従来の DNS では発生しな
www 86400 IN A 192.0.2.1
www 86400 IN A 192.0.2.1
あと86399秒
mail 86400 IN A 192.0.2.2
あと86398秒
ftp 86400 IN A 192.0.2.3
あと86397秒::
受け取ったTTLの値を初期値に設定して1秒ごとに値を減らし、0になった時点でそのレコードを削除
キャッシュDNSサーバー

権威DNSサーバー

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

かった「データは存在しているが、そのデータはもう（まだ）有効ではない」という状況が発生します。そのため、
DNS サーバーに対するヘルスチェックを外部から実施
する場合、単にデータの存在のみのチェックだけでは不十分で、データの内容の有効性のチェックについても併せて実施する必要があります（図 3）。
DNS関連のチェックを全体に対して実施
各レコードが存在するか？
$ORIGIN example.jp.
各レコードが外部から検索できるか？
$TTL 3600…などを、DNSSEC関連情報も含めて実施する@IN SOA …
IN NS …
DNSSEC関連のチェックを関連レコードに対して実施
IN A …
DNSSECIN DNSKEY …
関連レコード IN RRSIG …
鍵は正しいか？
IN NSEC …
署名は正しいか？
www
IN A …
署名は有効期間内か？
IN AAAA …
…など、中身についてもチェックする
DNSSECIN RRSIG …
関連レコード IN NSEC …
…
時刻が正しいかの確認も忘れずにるすべての DNS サーバーでは、正確な時刻の維持が必要になります（図 2）。

図 3: ヘルスチェックの際のポイント
なお、ヘルスチェックを実施するシステムにおいても

1

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

Copyright © 2011 株式会社日本レジストリサービス

正確な時刻の維持が必要になります。

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

1

JAPAN REGISTRY SERVICES■NS レコードと DS レコードは「似て非なるもの」■データの登録・更新・削除のタイミングと順番

DNSSEC では親子間の信頼の連鎖を構築するため

DNS では従来から、子の DNS サーバーでの準備完に DS レコードの親への登録・公開が必要になります。

了後に親のデータを登録・更新することが必要でした。

DS レコードは従来の NS レコードに似た形で取り扱うこDNSSEC の導入後はこれに加え、更新前の古いキャッとが可能ですが、その取り扱いには NS レコードとは異シュデータが完全にクリアされた後に次の手順を実行なる点が存在しています。

するという手順を、これまで以上に遵守する必要があり▼NS は親子双方が持ち、子が権威を持つます。

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

子（example.jp）

同じNSを登録

例として、二重署名法による KSK のロールオーバー手順を表 1 に示します。
①新しいKSKの生成と自分のゾーンデータへの追加②新旧双方のKSKによりDNSKEY（ZSK）を署名③自分のDNSKEYのTTL設定値の時間分待つ- DNSKEY（KSK）の古いキャッシュデータがクリアされる子のNSが権威を持つ$ORIGIN example.jp.
...
@IN NS ns1.example.jp.

④新しいKSKに対応するDSレコードを親に登録依頼⑤親のDSの登録更新を確認⑥親のDSのTTL設定値の時間分待つ- DSの古いキャッシュデータがクリアされる⑦古いKSKをゾーンデータから削除⑧新しいKSKのみでDNSKEY（ZSK）を署名

図 4: NS レコード
▼DS は親のみが持ち、親が権威を持つ
これに対し DS レコードは子の鍵署名鍵（DNSKEY

表 1: KSK のロールオーバー手順■NSEC3 を用いる場合の注意点（KSK））から生成され、親にのみ登録・公開されます。

ゾーンの列挙（詳細はトピックス＆コラム No.16 を参そのため、DS レコードは NS レコードとは異なり、親のも照）を防止するために NSEC3 を使用する場合、そのゾのが権威を持つことになります（図 5）。

ーンのすべての権威 DNS サーバーが NSEC3 に対応し親（jp）$ORIGIN jp.
...
example.jp. IN NS ns1.example.jp.
IN DS 26065 8 2 (40602F76F8F1181BBF4A61E52A5659E26948B747B8A3
AEABAE3B7FD8ED967A9C )親のDSと子のDNSKEY（KSK）の双方が権威を持つ

DS生成・登録子（example.jp）$ORIGIN example.jp.
...
@IN NS ns1.example.jp.
IN DNSKEY 257 3 8 (AwEAAcaKHUdaEkNlFDwXXZJYGA1SoIH3w6GVdHk7i2Vl
iI+Kz0Kn+kT9Ub2VIBjM7e4XmdS0Quakpj5VTLjnFofr(略)) ; key id = 26065ている必要があります。
NSEC3 では存在しない名前を問い合わされた際に権威 DNS サーバーが必要なハッシュ値を動的に計算するため、権威 DNS サーバーに NSEC3 に非対応のものが含まれていた場合、正しく動作しません（図 6）。
プライマリサーバー（NSEC3対応） セカンダリサーバー（NSEC3非対応）

DNSデータ
応答

ハッシュ値
計算

図 5: DS レコード
そして、DNSSEC では親子間の信頼の連鎖を、親のDS レコードと子の KSK を照合することにより検証します。

DNSデータ
応答

ハッシュ値
計算

同一内容
DNSデータ

DNSデータ

ハッシュ値計算機能によりNSEC3を生成・応答できるハッシュ値計算機能がないためNSEC3を生成・応答できないもし親の DS レコードに対応する KSK を子が一つも保持

図 6: NSEC3 を用いる場合の注意点

していなかった場合、即座に DNSSEC 検証エラーとなセカンダリサーバーを DNS サービス事業者に委託すり名前解決に失敗するため、特に注意が必要です。

Copyright © 2011 株式会社日本レジストリサービス

る場合などに、特に注意が必要です。

※全てのコラムは http://jpinfo.jp/topics-column/ でご覧いただけます。 2