JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPRS トピックス＆コラム No.015
DNSSECの円滑導入と安定運用を実現するために考慮しなければならない点について、
レジストラ・DNS運用者における注意事項を中心に、具体的に解説します。
レジストリ・レジストラモデルによる管理レジストリ・レジストラモデルの登場人物レジストリ・レジストラにおける情報の流れレジストリにおける対応の次に必要なことレジストラにおける対応―情報の取り次ぎDNS 運用者における注意事項DNS 運用者間でのドメイン名移転の取り扱いレジストリ・レジストラモデルによる管理
現在のJPドメイン名や、.com/.netを始めとする主なgTLDでは、レジストリ・レジストラモデルと呼ばれる手法でドメイン名を管理運用しています。そのため、それらのTLDをDNSSECに対応させる場合、レジストリ・レジストラモデルに合致した形でDNSSECに関する情報を取り扱えるようにする必要があります。
レジストリ・レジストラモデルの登場人物
レジストリ・レジストラモデルにおける代表的な登場人物と、その役割を以下に示します。
① 登録者
そのドメイン名を登録している本人です。リセラーや
レジストラにドメイン名の登録を依頼します。
② リセラー
登録者からドメイン名の管理に必要な情報を受け取りますが、自らはレジストリへの登録を行わず、レジストラへの依頼により登録を行います。
③ レジストラ（*1）
登録者やリセラーからドメイン名の管理に必要な情報を受け取り、レジストリに登録を依頼します。
④ レジストリ
レジストラからドメイン名の管理運用に必要な情報を受け取り、自らのシステムに登録・管理します。登録した情報はTLDの権威DNSサーバーで公開されます。
レジストリ・レジストラにおける情報の流れ
現在のインターネットでは登録者のドメイン名の権威DNSサーバーは、登録者自身（*2）、リセラー、レジストラのいずれか（*3）により運用されることが一般的です。
いずれの場合も権威DNSサーバーに関する登録情報は、図 1に示した形でおのおののDNS運用者からレジストラに渡され、レジストリに登録されます。
▼すべての情報はレジストラ経由で登録
このようにレジストリ・レジストラモデルでは、すべての情報の登録は、レジストラによる取り次ぎによって実施されることになります。
レジストリにおける対応の次に必要なこと
現在、レジストリにおけるDNSSECへの対応作業が積極的に進められています。レジストリによるDNSSEC対応が完了することにより、そのTLDにおけるDNSSECの導入・運用のための基礎が整うことになります。
しかし、レジストリ・レジストラモデルにおいてDNSSECの導入を円滑に進めるためにはこれに加え、登録したドメイン名の権威DNSサーバーにおけるDNSSEC対応、及びレジストリに権威DNSサーバーに関する登録情報を取り次ぐレジストラやリセラーにおけるDNSSEC対応が必須となります。
以降ではレジストラ及びDNS運用者においてDNSSEC対応を実施する場合に必要となる対応事項・注意事項について、具体的に解説していきます。
レジストラにおける対応―情報の取り次ぎ
前述の通りレジストリ・レジストラモデルでは、レジストリへの情報の登録はレジストラを介して実施されます。そのためレジストラやリセラーでは、DNSSEC対応の際にレジストリへの登録が必要となるDSレコード（*4）の受け付けと、レジストリやレジストラへの取り次ぎに対応する必要があります。レジストリに取り次がれたDSレコードは、レジストリの権威DNSサーバーで公開されます。
DNS運用者における注意事項
ここでは、権威DNS サーバーの運用時に鍵と署名の取り扱いにおいて特に注意が必要となる事項について、具体的に解説します。
▼DSレコードはレジストリにのみ登録DSレコードはレジストリにのみ登録
DSレコードはNSレコードと異なり自らのゾーンデータには登録されず、レジストリの権威DNSサーバーのみに登録される情報であることに注意が必要です。
▼DNSSECでは定期的な鍵の更新が必要
DNSSECではセキュリティ上の理由により定期的な鍵の更新（ロールオーバー）が推奨されており、鍵（鍵署名鍵（KSK）及びゾーン署名鍵（ZSK）の双方）の定期的な更新が必要になります。
鍵の更新方法には二重署名法（Double Signature）と事前公開法（Pre-Publish）の2種類があります。
▼KSKの更新における注意
KSKの更新には通常、二重署名法を使用します（表1）。信頼の連鎖を維持するため単なる置き換えではなく、新鍵追加→二重署名→登録→旧鍵削除→再署名という手順を踏む必要があることに注意が必要です。
▼ZSKの更新手順
ZSK の更新には通常、事前公開法を使用します（図 2）。事前公開法では更新後に使用する新しい鍵（鍵B）を運用開始時にゾーンデータに事前登録し、公開しておくという方法が用いられます。
▼ゾーンデータへの定期的な再署名が必要
DNSSECではセキュリティ上の理由により、署名に有効期間が設定されています（*5）。そのため、ゾーンデータへの定期的な再署名が必要になります。このため、DNSSECでは登録情報に変化がない場合でもゾーンデータへの定期的な再署名（*6）が必要になることに注意が必要です。
DNS運用者間でのドメイン名移転の取り扱い
DNSSECではドメイン名の移転など、DNS運用者の変更の際に従来のNSレコードと同様の手法でDSレコードを更新した場合、DNSSEC検証エラーが発生する可能性があります（*7）。
検証エラーを避ける方法として、①移転元・移転先の共同作業により信頼の連鎖を維持したまま移転する、②いったんDNSSECを解除してから通常の方法で移転する（*8）、③移転元・移転先間において必要なデータのやりとりをレジストリが仲介する（*9）などの方法が検討・実施されています。
JPドメイン名では指定事業者がレジストラの役割を担当しています。【↑】
登録者が依頼する第三者が運用する場合もあります。【↑】
登録者がプライマリDNSサーバーを、リセラーやレジストラがセカンダリDNSサーバーをそれぞれ運用するなどの形態も見られます。【↑】
レジストリが提供するDNSSECサービス仕様により、DSレコードに対応する鍵署名鍵（KSK）そのものの登録が必要になる場合があります。【↑】
BIND9における有効期限のデフォルト設定値は30日となっています。
RRSIGレコードが更新されるため、再署名に先立ってSOAのシリアル値を増やしておく必要があります。
技術的詳細が以下の発表資料で紹介されています。
https://www.dns-oarc.net/files/workshop-200905/gudmundsson.pdf
DNSSEC ジャパン「レジストラ移転ガイドライン」p.12
http://dnssec.jp/wp-content/uploads/2010/11/20101122-techwg-regi
strar-transfer-guideline.pdf
Changing DNS Operators for DNSSEC signed Zones
http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change
掲載内容は2015年1月のものです。
Copyright©2001-2024 Japan Registry Services Co., Ltd.