DNSSEC.jp プロトコル理解
プロトコル理解SWG
RFC 4035

DNSSEC.jp

1

■ RFC 4035の構成
1. Introduction
2. Zone Signing
3. Serving
4. Resolving
5. Authenticating DNS Responses
6. IANA Considerations
7. Security Considerations
8. Acknowledgements
9. References21. Introduction• 本文書はDNSSECプロトコル処理を定義• 関連文書RFC4033/4034
RFC1034/1035
RFC2181/2308

3

2. Zone Signing• 2.1. Including DNSKEY RRs in a Zone
• 2.2. Including RRSIG RRs in a Zone
• 2.3. Including NSEC RRs in a Zone
• 2.4. Including DS RRs in a Zone
• 2.5. Changes to the CNAME Resource Record• 2.6. DNSSEC RR Types Appearing at Zone Cuts
• 2.7. Example of a Secure Zone

4

2. Zone Signing• 署名付きZONE－DNSKEY(DNS Public Key)－RRSIG(Resource Record Signature )－NSEC(Next Secure)－DS(Delegation Signer)
上記レコードを持たないものは署名なしZONEです＊CNAME RRの定義変更されます。

5

2.1 Including DNSKEY RRs in a Zone
• 1つ以上の公開/秘密鍵ペアがある• RRSIG RR生成に使用した秘密鍵に対する公開鍵を保存したDNSKEY RRを持つべき－RFC4034で規定したキー鍵フラグを設定－他の公開鍵を規定以外のキー鍵フラグを設定し
DNSKEY RRに保存してもよいが、RRSIG検証に使用してはいけない• zone apexに最低1つのDNSKEY RRと親側のDS
RRによりsecure entry pointと判断できる

6

2.1 Including DNSKEY RRs in a Zonejp

jp
example.jp

子DNSKEYに対応するDS RR例）example.jp DS

ハッシュ一致する？
→安全な委任先？

example.jp

DNSKEY例）example.jp DNSKEY

7

2.2 Including RRSIG RRs in a Zone
① RRSIG owner nameがRRset owner nameと等しい② RRSIG classがRRset classと等しい③ RRSIG typeがRRset typeと等しい④ RRSIG Original TTL値がRRsetのTTL値と等しい⑤ RRSIG RR’s TTL値がRRsetのTTL値と等しい⑥ RRSIG Labelsがowner nameのLabels数と等しい－null root labelまたは最も左側のlabelがワイルドカードであった場合は、countしない

8

2.2 Including RRSIG RRs in a Zone
⑦ RRSIG Signer’s NameがRRsetを持つZONE名と等しい⑧ Algorithm & Signer’s Name & Key Tagの内容により、zone内のDNSKEYが一つに特定できる
以上、８つの条件を満たしているRRSIGが1つ以上存在している
１つのRRsetが複数のRRSIG RRを持ってもよい

9

2.2 Including RRSIG RRs in a Zone

注意点
• RRSIG RR自身は署名されない－無限ループ処理になる• zone apexのNS RRsetは署名付きである• 親ZONEの子に委任するためのNS RRsetは署名されない（delegation points）－同様に、グルーアドレスRRsetは署名されない
jpdelegationjp
example.jp

point
10

2.2 Including RRSIG RRs in a Zone
① RRSIG owner nameがRRset owner nameと等しい
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
3600 RRSIG NS 5 1 3600
20040509183619 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg=
3600 DNSKEY 256 3 5 AQOy1bZV・・・ ;key id = 38519

112.2 Including RRSIG RRs in a Zone
② RRSIG classがRRset classと等しい
example. 3600 NS ns1.example.
※class=IN
example. 3600 NS ns2.example.
3600 RRSIG NS 5 1 3600
20040509183619 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg=
3600 DNSKEY 256 3 5 AQOy1bZV・・・ ;key id = 38519

122.2 Including RRSIG RRs in a Zone
③ RRSIG typeがRRset typeと等しい
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
3600 RRSIG NS 5 1 3600
20040509183619 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg=
3600 DNSKEY 256 3 5 AQOy1bZV・・・ ;key id = 38519

132.2 Including RRSIG RRs in a Zone
④ RRSIG Original TTL値がRRsetのTTL値と等しい
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
3600 RRSIG NS 5 1 3600
20040509183619 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg=
3600 DNSKEY 256 3 5 AQOy1bZV・・・ ;key id = 38519

142.2 Including RRSIG RRs in a Zone
⑤ RRSIG RR’s TTL値がRRsetのTTL値と等しい
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
3600 RRSIG NS 5 1 3600
20040509183619 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg=
3600 DNSKEY 256 3 5 AQOy1bZV・・・ ;key id = 38519

15

2.2 Including RRSIG RRs in a Zone
⑥ RRSIG Labelsがowner nameのLabels数と等しい
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
3600 RRSIG NS 5 1 3600
20040509183619 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg=
3600 DNSKEY 256 3 5 AQOy1bZV・・・ ;key id = 38519

16

2.2 Including RRSIG RRs in a Zone
⑦ RRSIG Signer’s NameがRRsetを持つZONE名と等しい
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
3600 RRSIG NS 5 1 3600
20040509183619 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg=
3600 DNSKEY 256 3 5 AQOy1bZV・・・ ;key id = 38519

172.2 Including RRSIG RRs in a Zone
⑧ Algorithm & Signer’s Name & Key Tagの内容により、zone内のDNSKEYが一つに特定できる
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
3600 RRSIG NS 5 1 3600
20040509183619 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg=
3600 DNSKEY 256 3 5 AQOy1bZV・・・ ;key id = 38519

18

2.3 Including NSEC RRs in a Zone
• 署名付きZONEが権限を持つ全てのowner names
または、子ZONEへ委譲するNS RRsetのownernamesに対して存在する－親ZONEのグルーアドレスRRsetにはNSEC RRとRRSIG RRも存在しない• NSEC RRのTTL値は、ZONE SOA RRの最小値と同じであるべき

19

2.3 Including NSEC RRs in a Zone

注意点
• 特定のowner namesに対してNSEC RR（対応する
RRSIG RR）だけしか存在しない状態があってはならない• 親側のNSEC RRのビットマップに注意－親ZONEが権限を持たないNS RRset以外のbitsは、クリアされなければならない
グルーアドレスRRset等のこと

20

2.4 Including DS RRs in a Zone
• 子ZONEが署名付きの場合、親ZONEにDS RRset
が存在すべき(認証連鎖を構築)－ZONE内のDS RRsetは、すべて署名されるべき－DS RRsetは、zone‘s apexに存在できない－DS RRsetは、複数設定可能
対応する子ZONEのZSKを使用し、子ZONE内のRRSIGが検証できること

21

2.4 Including DS RRs in a Zone
親ZONE

子ZONE

DNSKEYDNSKEY(公開鍵)NSDS

private keyで
署名すべき

権限委譲

確認すべき

DS

※権限委譲NSのTTL値とDSのTTL値は一致すべき22

2.4 Including DS RRs in a Zone
• 運用上の問題点－子ZONEにある対応するDNSKEY RRの識別が必要

親ZONEと子ZONEのやり取りに関しては、対象範囲外です。

23

2.5 Changes to the CNAME Resource Record• 署名付きZONEにCNAME RRsetが存在する場合、適切なRRSIGとNSEC RRsetが必要－動的な更新を行うKEY RRset使用可能※ダイナミックDNS• CNAME RRの定義－CNAME－NSEC（新規追加）－RRSIG（新規追加）

242.6 DNSSEC RR Types Appearing at Zone Cuts
• zone cutに存在可能なRR－NS RRset－NSEC RR（新規追加）－DS RR（新規追加）• NSEC RRとDS RRは親が権限を持つ－RFC4033のAuthoritative RRset項目参照

25

2.7 Example of a Secure Zone

付録Aに署名付きのZONE一式の例があります26

3. Serving• 3.1 Authoritative Name Server-3.1.1 including RRSIG RRs in a Response-3.1.2 including DNSKEY RRs in a Response-3.1.3 including NSEC RRs in a Response-3.1.4 including DS RRs in a Response-3.1.5 Responding to Queries for Type AXFR or IXFR
-3.1.6 The AD and CD Bits in an Authoritative Response• 3.2 Recursive Name Servers-3.2.1 The DO Bit-3.2.2 The CD Bit-3.2.3 The AD Bit• 3.3 Example DNSSEC Response27

3. Serving（サーバ側処理
サーバ側処理）側処理）の概要■ネームサーバの要件• EDNS0メッセージサイズ拡張をサポートすること⇒推奨4000オクテット（最低でも1220オクテット）• IPv6で転送されるUDPデータグラムをMTUに応じてフラグメント化
すること• クエリが『EDNSのOPTレコードを持たない』 or 『DOビットがクリアされていた』場合、RRSIG、DNSKEY、NSEC RRは、通常のRRsetと同様の応答を行うこと。
※DS RRについては3.1.4.1で規定する特別な処理が必要

28

3. Serving（サーバ側処理
サーバ側処理）側処理）の概要• クエリに明示的なDNSSEC RRが含まれていて、クエリ内容とネー
ムサーバ自身が管理する複数のゾーン内容とが一致する場合、応答に以下の1つを返しても良いこと。
– 委任点の上に存在するRRset– 委任点の下に存在するRRset– 委任点の上、下に存在するRRset両方– Answer sectionを空（レコードなし）にして返す– それ以外の応答
– エラー

29

3. Serving（サーバ側処理
サーバ側処理）側処理）の概要• DNSSECはDNSメッセージヘッダ内に2つの新しいビットを割当– CD(Checking Disabled)ビット– AD(Authentic Data)ビット※CDビット
CDビットとビットとADビット
ADビットにビットに関する詳細
する詳細は
詳細は、Section 3.1.6、
3.1.6、3.2.2、
3.2.2、3.2.3、
3.2.3、4、4.9を
4.9を参照• CDビットはリゾルバ側で制御する。
– ネームサーバはクエリのCDビットを対応する応答にコピーしなければならない。

• ADビットはネームサーバ側で制御する。
– クエリに含まれるADビットを無視しなければならない。

30

3. Serving（サーバ側処理
サーバ側処理）側処理）の概要• ネームサーバの規定（[RFC2672]）に従い、DNAMEからCNAME
RRを合成した場合、合成したCNAME RRに対し署名を生成すべき
ではない

31

3.1 Authoritative Name Servers• クエリが『EDNSのOPT RRを持っている』 or 『DOビットが設定されていた』場合、RRSIG、NSEC、DS RRを後述の規則に従って応答に付加しなければならない• DNSSECはDNSのZONE転送プロトコルを変更しない(詳細はSection3.1.5)

32

3.1.1 including RRSIG RRs in Response• ネームサーバがDOビットが設定されたクエリに応答する場合、応答へのRRSIG RR付加は以下の規則に従う※TC（
TC（Trancation）：
Trancation）： 1ビットでビットで回答データ
回答データがデータが不完全であることを不完全であることを示であることを示し
改めてTCP
めてTCPでTCPで問い合せることが求せることが求められる。
められる。

規則内容

要求レベル
要求レベル

Answer sectionにsectionに署名付き
署名付きRRsetを
RRsetを付加する
付加する場合する場合①・その署名付
その署名付き
署名付きRRsetの
RRsetのRRSIG RRもRRもAnswer sectionにsectionに付加しなければならない
付加しなければならない。
しなければならない。
・他に付加されなければならない
RRの方が優先度が優先度が高い。
付加されなければならないRRset
されなければならないRRsetよりも
RRsetよりもRRSIG
よりもRRSIG RRの

MUST

②容量的に
TCビットをビットを設定しなければならない
設定しなければならない。
しなければならない。
容量的にRRSIG RRを
RRを付加できない
付加できない場合できない場合、場合、TCビット

MUST

Authority sectionにsectionに署名付き
署名付きRRsetを
RRsetを付加する
付加する場合する場合③・その署名付
その署名付き
署名付きRRsetの
RRsetのRRSIG RRもRRもAuthority sectionにsectionに付加しなければならない
付加しなければならない。
しなければならない。
・他に付加されなければならない
RRの方が優先度が優先度が高い。
付加されなければならないRRset
されなければならないRRsetよりも
RRsetよりもRRSIG
よりもRRSIG RRの

MUST

④容量的に
容量的にRRSIG RRを
RRを付加できない
付加できない場合できない場合、場合、TCビット
TCビットをビットを設定しなければならない
設定しなければならない。
しなければならない。

MUST

Additional sectionにsectionに署名付き
署名付きRRsetを
RRsetを付加する
付加する場合する場合⑤その署名付
その署名付き
署名付きRRsetの
RRsetのRRSIG RRもRRもAdditonal sectionにsectionに付加しなければならない
付加しなければならない。
しなければならない。

MUST

⑥容量的に
RRsetだけを残だけを残してRRSIG
してRRSIG RRを
RRを除
容量的にRRsetとそのRRsetとそのRRsetとそのRRsetのRRsetのRRSIG RR両方
RR両方が両方が付加できない
付加できない場合できない場合、
場合、RRsetだけを外しても良しても良い。

MAY

⑦この場合
この場合、
場合、RRSIG RRがRRが入らなかったとういうだけの理由らなかったとういうだけの理由で理由でTCビット
TCビットをビットを設定してはならない
設定してはならない。
してはならない。

33

MUST NOT3.1.2 including DNSKEY RRs in Response• ネームサーバがDOビットが設定されたクエリに応答する場合、応答へのDNSKEY付加は以下の規則に従う

内容

要求レベル
要求レベル

①DOビット
DOビットがビットが設定された設定された署名付された署名付き
署名付きゾーンのゾーンの頂点にある頂点にあるSOAにあるSOA or NS RRのRRのクエリにクエリに応答する
応答する場合する場合⇒ZONE頂点
RRsetをAdditional sectionにsectionに入れて返れて返しても良しても良い。
ZONE頂点にある頂点にあるDNSKEYにあるDNSKEY RRsetを

MAY

※この場合
この場合、
場合、DNSKEY RRsetとRRsetと対応の対応のRRSIG RRはRRはAdditional sectionにsectionに入れられるべき他れられるべき他の情報よりも情報よりも優先度
よりも優先度は
優先度は低くなる。
くなる。

②DNSKEY RRsetとRRsetとそのRRset
そのRRsetのRRsetのRRSIG RRのRRの付加に付加に十分な
十分な容量が容量が応答メッセージ
応答メッセージにメッセージに無い場合⇒ネームサーバはRRsetを応答に応答に付加すべきではない
付加すべきではない。
すべきではない。
ネームサーバはDNSKEY RRsetを

SHOULDNOT③DNSKEYとそのDNSKEYとそのDNSKEYとそのDNSKEYのDNSKEYのRRSIG RRのRRの付加に付加に十分な
十分な容量が容量が無い場合⇒ネームサーバはネームサーバは両RRを
RRを除外しなければならない
除外しなければならない。
しなければならない。

MUST④これらのRR
これらのRRがRRが入らなかったという理由らなかったという理由だけで理由だけでTC
だけでTCビット
TCビットをビットを設定してはならない
設定してはならない（
してはならない（Section3.1.1参照
Section3.1.1参照）。
参照）。

34

MUST NOT3.1.3 including NSEC RRs in Response• ネームサーバがDOビットが設定されたクエリに応答する場合、以下の応答毎の規則に従い、NSEC RR付加を行わなければならない。
– No Data※付録B.3参照– Name Error※付録B.2参照– Wildcard Answer ※付録B.6参照– Wildcard No Data ※付録B.7参照• 応答毎に異なった、NSEC RRを付加する理由※詳細は5.4.で説明– ネームサーバはZONE内に<SNAME,SCLASS,STYPE>に完全一致するものが存在しないことを証明するため– ネームサーバが返した応答がZONEデータが正しいことを証明するため

35

3.1.3.1 including NSEC RRs in Response “No Data”
No Data

ZONEは
ZONEは<SNAME, SCLASS>にSCLASS>に完全一致する
完全一致するRRset
するRRsetを
RRsetを持つが、つが、<SNAME,SCLASS, STYPE>に
STYPE>に完全一致する
完全一致するRRset
するRRsetがRRsetが存在しない
存在しない• ネームサーバがDOビットが設定されたクエリに応答する場合、且つ”No Data”応答へのNSEC RR付加は下記表の規則に従う– クエリ対象の名前は存在しているので、このクエリに対してWildcard展開は行われない– クエリのRRタイプが存在しないことを証明するには、単一の署名付きNSEC
RRがあれば充分
内容

要求レベル
要求レベル

①ネームサーバはsectionに<SNAME, SCLASS>にSCLASS>に関するNSECするNSEC RRとそのRRとそのRRとそのRRのRRのRRSIG RRを
RRを共ネームサーバはAuthority sectionにに付加しなければならない
付加しなければならない。
しなければならない。

MUST

②容量的に
容量的にNSEC RRまたはそのRRまたはそのRR
またはそのRRのRRのRRSIG RRがRRが付加できない
付加できない場合できない場合⇒ネームサーバはTCビットをビットを設定しなければならない
設定しなければならない。
しなければならない。
ネームサーバはTCビット

MUST

36

3.1.3.2 including NSEC RRs in Response “Name Error”
ZONEには<SNAME,には<SNAME, SCLASS>にSCLASS>に完全一致する
完全一致するRRset
するRRsetもRRsetも、Wildcard展開
Wildcard展開
Name Error ZONEにはにより一致により一致する
一致するRRset
するRRsetがRRsetが存在しない
存在しない• ネームサーバがDOビットが設定されたクエリに応答する場合、且つ”Name Error”応答へのNSEC RR付加は下記表の規則に従う
内容

要求レベル
要求レベル

①ネームサーバはネームサーバは下記の下記のNSEC RRとそのRRとそのRRとそのRRのRRのRRSIG RRをRRをAuthority sectionにsectionに付加しなければならない
付加しなければならない。
しなければならない。

MUST※owner名
owner名はWildcard展開
Wildcard展開されない
展開されない‐ <SNAME、<SNAME、SCLASS>にSCLASS>に完全一致する
完全一致するRRset
存在しないことを証明
するRRsetがRRsetが存在しないことをしないことを証明する
証明するNSECするNSEC RR‐ Wildcard展開
Wildcard展開により
SCLASS>に一致する
一致するRRset
存在しないことを証明
展開により<SNAME
により<SNAME、<SNAME、SCLASS>にするRRsetがRRsetが存在しないことをしないことを証明する
証明するNSECするNSEC RR②単一の単一のNSEC RRが
RRが上記2
上記2つのNSEC
つのNSEC RRを
RRを証明する
証明する場合する場合
RRとそのRR
RRをそれぞれ1
sectionに付加すべき
付加すべき⇒ネームサーバはネームサーバはNSEC RRとそのとそのRRのRRのRRSIG RRをそれぞれをそれぞれ1つだけ Authority sectionに

SHOULD③容量的に容量的にNSEC RRとRRとRRSIG RRがRRが付加できない
付加できない場合できない場合TCビットを設定しなければならない 。
⇒ネームサーバはネームサーバはTCビット
ビットを設定しなければならない

MUST

37

3.1.3.3 including NSEC RRs in Response “Wildcard Anser”
Wildcard
Answer

ZONEに
ZONEに<SNAME, SCLASS>にSCLASS>に完全一致する
完全一致するRRset
するRRsetはRRsetは存在しないが存在しないが、しないが、Wildcard
展開により展開により<SNAME,SCLASS,STYPE>
により<SNAME,SCLASS,STYPE>に<SNAME,SCLASS,STYPE>に一致する
一致するRRset
するRRsetがRRsetが存在する
存在する• ネームサーバがDOビットが設定されたクエリに応答する場合、且つ”Wildcard Answer”応答へのNSEC RR付加は下記表の規則
に従う
内容

要求レベル
要求レベル

①ネームサーバはsectionにワイルドカード展開後
ワイルドカード展開後の展開後の回答と回答とRRSIG RRを
RRを付加しなければならない
付加しなければならない。
しなければならない。
ネームサーバはAnswer sectionに

MUST②Authority sectionにはより良く一致する
一致するRRset
するRRsetがRRsetが無いことを証明
いことを証明する
証明する
sectionにはゾーンにはゾーン内ゾーン内に<SNAME, SCLASS>にSCLASS>に より良NSRC RRとそのRRとそのRRとそのRRのRRのRRSIG RRを
RRを付加しなければならない
付加しなければならない。
しなければならない。

MUST

③容量的に
容量的にNSEC RRとそのRRとそのRRとそのRRのRRのRRSIG RRがRRが 付加できない
付加できない場合できない場合⇒ネームサーバはTCビットをビットを設定しなければならない
設定しなければならない （3.1.3参照
3.1.3参照）。
参照）。
ネームサーバはTCビット

MUST

38

3.1.3.4 including NSEC RRs in Response “Wildcard No Data”
Wildcard
No Data

・ZONEには
ZONEには<SNAME,には<SNAME, SCLASS>にSCLASS>に完全一致する
完全一致するRRset
するRRsetはRRsetは存在しない
存在しない。
しない。
・Wildcard展開
Wildcard展開により展開により<SNAME,SCLASS>
により<SNAME,SCLASS>に<SNAME,SCLASS>に一致する
一致する1する1つ以上の以上のRRsetがRRsetが存在するが、するが、<SNAME,SCLASS,STYPE>に<SNAME,SCLASS,STYPE>に一致する
一致するRRset
存在しない。
するRRsetはRRsetは存在しない
しない。

• ネームサーバがDOビットが設定されたクエリに応答する場合、且つ”Wildcard No Data”応答へのNSEC RR付加は下記表の規
則に従う
内容

要求レベル
要求レベル

①Wildcard展開
Wildcard展開しても展開してもSTYPE
してもSTYPEにSTYPEに一致する
一致するRRset
するRRsetはRRsetは存在しないという存在しないという場合しないという場合⇒ネームサーバはネームサーバはAuthority sectionにsectionに以下の以下の条件を条件を満たすNSEC
たすNSEC RRとそのRRとそのRRとそのRRのRRのRRSIG RRをRRを 共に付加しなければならない

MUST※owner名
owner名はWildcard展開
Wildcard展開されない
展開されない‐ WildcardによりWildcardにより<SNAME,
により<SNAME, SCLASS>にSCLASS>に一致する
一致するWildcard
するWildcardのWildcardのowner名
owner名を持つRRsetの
RRsetの中でSTYPEに
STYPEに一致するものは無するものは無いことを証明
いことを証明する
証明するNSECするNSEC RR 。
- ZONE内
ZONE内に<SNAME, SCLASS>により
SCLASS>により良により良く一致する
一致するRRset
するRRsetはRRsetは存在しないことを存在しないことを 証明する
証明するNSECするNSEC RR。
RR。
②単一の単一のNSEC RRが
RRが上記2
上記2つの内容
つの内容を
内容を証明する
証明する場合する場合⇒ネームサーバは
RRとRRSIG RRをそれぞれ
RRをそれぞれ1をそれぞれ1つだけAuthority
つだけAuthority sectionにsectionに 含めるべきである
めるべきである
ネームサーバはNSECC RRと

SOULD

③容量的に
容量的にNSEC RRとRRとRRSIG RRがRRが付加できない
付加できない場合できない場合⇒ネームサーバはTCビットをビットを設定しなければならない
設定しなければならない（
しなければならない（Section 3.1.1参照
3.1.1参照）
参照）
ネームサーバはTCビット

MUST

39

3.1.3.5 Finding the Right NSEC RRs

※詳細は
を参照
詳細は5.4を• 特定のSNAMEに一致するRRsetが存在しないことを証明する
NSEC RRをネームサーバが付加しなければならない状況が存在する• 権威を持つゾーン内でそのようなNSEC RRを発見する処理は概念上は容易である• 以下のアルゴリズムで適切なNSEC RRが発見できる– 名前N に一致するRRsetがZONEZ に存在しないことを発見する– Z 内の全RRsetのowner名から重複する名前を除外– owner名のリストS を構築し、S を正規順序（[RFC4034]）に並べる– S の中にN が存在していたらその直前に順序づけられていたであろう名
前M を発見する– M がowner名N を持つRRsetが存在しないことを証明するNSEC RRのowner名になる40

3.1.4 including DS RRs in Response• ネームサーバがDOビットが設定されたクエリに応答する場合、応答へのDS RR付加は以下の規則に従う– DS、NSEC、RRSIG RRを付加することにより、参照メッセージサイズが大きくなるため、幾つか、または全てのglue RRが省略されてしまう場合がある
内容

要求レベル
要求レベル

①委任点に
委任点にDS RRsetがRRsetが存在する
存在する場合する場合⇒ネームサーバはRRsetに加えて、えて、DS RRsetとそのRRsetとそのRRsetとそのRRsetのRRsetのRRSIG RRを
RRを共にAuthority sectionにsectionに付
ネームサーバはNS RRsetに加しなければならない

MUST

②委任点に
委任点にDS RRsetがRRsetが存在しない
存在しない場合
しない場合⇒ネームサーバはRRsetに加えて、えて、DS RRsetがRRsetが存在しないことを存在しないことを証明しないことを証明する
証明するNSECするNSEC RRとそのRRとそのRRとそのRRのRRのネームサーバはNS RRsetに
RRSIG RRを
RRを共に 返さなければならない

MUST③ネームサーバはネームサーバはまずNS
まずNS RRsetを
RRsetを付加し付加し、 その後その後にNSEC RRsetとそのRRsetとそのRRsetとそのRRsetのRRsetのRRSIG RRを
RRを付加しなけ
付加しなけ
ればならないMUST④容量的に
容量的にDS RRまたは
RRまたはNSECまたはNSEC RRとそのRRとそのRRとそのRRのRRのRRSIG RRがRRが付加できない
付加できない場合できない場合⇒ネーム サーバは
サーバはTCビット
TCビットをビットを設定しなければならない
設定しなければならない（
しなければならない（Section3.1.1参照
Section3.1.1参照）。
参照）。

MUST

41

3.1.4.1 including DS RRs in Response ※詳細はを参照
詳細は付録B.8を
付録• DS RRはZONE Cutの親ZONE側にしか存在しない点で特殊– 例）”foo.example”
foo.example”の委任に委任に関するDSするDS RRsetは
RRsetは、”foo.example”
foo.example”ZONEではな
ZONEではなく、”example”
example”ZONEにZONEに保存される
保存される• ネームサーバとリゾルバ双方がDS RRを処理する際で、以下の条件（４つ）を全て満たす場合のみ特別な処理を必要とする– ネームサーバがネームサーバがZONE Cutにある
CutにあるDSにあるDS RRsetの
RRsetの問い合わせを受信
わせを受信した受信した– ネームサーバは
ネームサーバは子ZONEにZONEに対して権威
して権威を
権威を持つ
– ネームサーバは
ネームサーバは親ZONEにZONEに対して権威して権威を権威を持たない– ネームサーバは
ネームサーバは再帰検索を
再帰検索を行わない
内容

要求レベル
要求レベル

・ネームサーバはネームサーバはSNAMEに
SNAMEに対して権威して権威をつが、問い合わされたRRset
わされたRRsetを提供することができないため、権威を持つが、RRsetを提供することができないためすることができないため、
ネームサーバはネームサーバは子ZONEのZONEの頂点に頂点にDS RRsetがRRsetが存在しないことを存在しないことを示しないことを示す権威を権威を持つ”No Data”
Data”応答を
応答を返さな
ければならない。
ければならない。

MUST

特別の特別の処理規則に処理規則に従った応答
った応答をする応答をする場合をする場合

42

3.1.4.1 including DS RRs in Response• 特別の処理規則に従った応答を除いた全ての場合は、以下のいずれかのケースになり、ネームサーバはDS RRsetを通常の処理処理規則に従ったエラー応答を返すことができる– ネームサーバが別の手段でDS RRsetを得られる– DNSSEC処理規則以前の段階でDS RRsetが得られないことがわかっている43

3.1.5 Responding to Queries for Type AXFR or IXFR• DNSSECはDNSのZONE転送処理を変更しない。
• 署名付きZONEはRRSIG、DNSKEY、 NSEC、DS RRsを持つが、これらのレコードはZONE転送処理の中では、特別な意味を持たない。
– 権威ネームサーバは、ZONE転送送信前またはZONE転送受信後に、ZONEが適切に署名されているかを検証しなくてもよい。

全般

要求レベル
要求レベル

①Section2でSection2で規定した
規定した署名
した署名の署名の要件を
要件をZONEがZONEが満たさない場合
たさない場合⇒権威ネームサーバ
ゾーン転送処理全てを
転送処理全てを 拒否してもよい
拒否してもよい 。
権威ネームサーバは
ネームサーバはゾーン転送処理全②
・ZONE転送
ZONE転送の転送の主要な
主要な目的は
目的は、全ての権威ての権威ネームサーバ
権威ネームサーバがネームサーバが 同一の同一のZONEコピー
ZONEコピーをコピーを持つことを保証
つことを保証すること保証することである。
である。
・ZONE検証
ZONE検証の検証の実行を
実行を 選択した
選択した権威した権威ネームサーバ
権威ネームサーバは
ネームサーバは、RRへのRRへの問合への問合わせを問合わせを選択的わせを選択的に選択的に拒否したり拒否したり受容したり受容したり受容したりしてはならない 。

44

MAY
MUST NOT3.1.5 Responding to Queries for Type AXFR or IXFR• DS Rrsetsが権威を持つZONE転送– DS RRsetsを付加しなければならない。

• NSEC RRsが権威を持つZONE転送– NSEC RRsを付加しなければならない。
– ZONE Cutの親側に存在するNSEC RRsは親ZONEの転送時に必ず付加されなければならない。
– 子ZONEの頂点に存在するNSECは子ZONEの転送時に付加されなければならない。

• RRSIG RRsが権威を持つZONE転送– RRSIG RRsを付加しなければならない。

45

3.1.6 The AD and CD Bits in an Authoritative Response• CDビットとADビットは、リゾルバと再帰ネームサーバ間のやりとりで使用するよう設計された。
• CDビットとADビットは ほとんどの場合、権威ネームサーバが行う問合わせ処理とは関係がない。

内容

要求レベル
要求レベル

①ネームサーバはネームサーバは権威を権威を持つ応答を
応答を生成する
生成する際する際にCDビット
CDビットを
ビットをクリアすべき
クリアすべきである
すべきである。
である。

SHOULD②応答の応答のAnswer section及section及びAuthority sectionにsectionに入れられたRRset
れられたRRsetがRRsetが全て信頼できない
信頼できない限
できない限り、 ネームサーバはーバは応答に応答にADビット
ADビットをビットを設定してはならない
設定してはならない。
してはならない。

MUST NOT③ネームサーバ（
権威を持つZONEから
ZONEから得から得たデータを
データを検証無しで検証無しで信頼
しで信頼してもよい
信頼してもよい 。
ネームサーバ（セカンダリ）
セカンダリ）は、権威をMAY④但し、ネームサーバ（
ネームサーバ（セカンダリ）
セカンダリ）が権威を権威を持つZONEを
ZONEを安全な安全な手段(
手段(安全な
安全なZONE転送
ZONE転送の転送の仕組み仕組み等)で入手できない限できない限り、検証無しの
検証無しの信頼しの信頼をしてはならない
信頼をしてはならない。
をしてはならない。

MUST NOT⑤明示的に明示的に設定されていない設定されていない限
されていない限り、このような 振る舞いをしてはならない

MUST NOT⑥再帰ネームサーバ
で規定する
再帰ネームサーバは
ネームサーバは、再帰検索で
再帰検索で得たデータを
データを含む応答を
応答を生成する
生成する際する際に、Section3.2で規定するCDする
ビットとビットとADビット
ビットに
する規則に
わなければならない。
ビットに関する規則
規則に従わなければならない。

46

MUST

3.2 Recursive Name Servers• 再帰ネームサーバとは、ネームサーバとリゾルバの両方の役割を担うものである。([RFC4033]規定)• このページ以降、説明を行う上での用語の定義– ネームサーバ機能実装部分 ： ネームサーバサイド– リゾルバ機能実装部分 ： リゾルバサイド• リゾルバサイドは、通常のキャッシュ処理、ネガティブキャッシュ処理に関する規定に従う

47

3.2.1 The DO Bit

内容

要求レベル
要求レベル

①再帰ネームサーバ
再帰ネームサーバのネームサーバのネームサーバサイドでネームサーバサイドで受信した
受信した検索要求
した検索要求に
検索要求にDOビット
DOビットがビットが設定されているかにかか設定されているかにかかわらず、わらず、リゾルバサイドはリゾルバサイドは、問い合わせ送信時
わせ送信時に
送信時にDOビット
DOビットをビットを設定しなければならない
設定しなければならない。
しなければならない。

MUST②DOビット
DOビットをビットを設定していない
設定していない問していない問い合わせを受
わせを受けた場合
けた場合、場合、再帰ネームサーバ
再帰ネームサーバのネームサーバのネームサーバサイドは
ネームサーバサイドは、応答内に答内に含まれる全
まれる全てのDNSSECてのDNSSEC RRをRRを取り除かなくてはならない。
かなくてはならない。

MUST③問い合わせの中
わせの中に明示的（
明示的（DOビット
DOビット設定有
ビット設定有り
設定有り）に要求された
要求されたDNSSEC
されたDNSSEC RRタイプ
RRタイプをタイプを取り除いてはいけない。
→要求された
要求されたDNSSEC
されたDNSSEC RRを
RRを返す

MUST NOT

48

3.2.1 The DO Bit
①

DOビット
ビット

DOビット
ビット

ネームサーバサイド リゾルバサイド②

ネームサーバ応答内の全てのDNSSEC RRを取り除く

DOビット
ビット

ネームサーバサイド

リゾルバ等

③

応答内の全てのDNSSEC RRを取り除く

DOビット
ビット

ネームサーバサイド

リゾルバ等
要求された
要求された
DNSSEC RR

49

3.2.2 The CD Bit• リゾルバは、CDビットを設定してネームサーバに照会すると、署名検証を無効にすることができる。
内容

要求レベル
要求レベル

①CDビット
CDビットがビットが設定されている設定されているクエリされているクエリにクエリに対し、ネームサーバサイドは
ネームサーバサイドは、応答に応答にCDビット
CDビットのビットの設定を設定をコピーしなけ
コピーしなければならない。
ればならない。

MUST②ネームサーバサイドは
ネームサーバサイドは、クエリとクエリと共にCDビット
CDビットのビットの状態を状態をリゾルバサイドにリゾルバサイドに渡さなければいけない。
さなければいけない。

MUST

③クエリに
クエリにCDビット
CDビットがビットが設定されている設定されている場合されている場合→問い合わせの要求元
わせの要求元である
要求元であるリゾルバ
であるリゾルバがリゾルバが自身で自身で認証を
認証を実行する
実行する責任する責任を責任を負うため、
うため、再帰ネームサーバ
再帰ネームサーバがネームサーバが干渉すべき
干渉すべき事柄
すべき事柄でないことを事柄でないことを示
でないことを示している。
している。

SHOULD④不良キャッシュ
不良キャッシュ（キャッシュ（Section4.7参照
Section4.7参照）
参照）に対応する対応するクエリするクエリをクエリを受信し受信し、CDビット
CDビットがビットが設定されたいた設定されたいた場合されたいた場合→ネームサーバはネームサーバは、不良キャッシュ
不良キャッシュから
キャッシュからデータ
からデータを
データを返すべきである。
すべきである。

SHOULD⑤不良キャッシュ
不良キャッシュにキャッシュに対応する対応するクエリするクエリをクエリを受信し受信し、 CDビット
CDビットがビットが設定されていない設定されていない場合
されていない場合→ネームサーバはネームサーバは、RCODE 2（
2（Server Fail）
Fail）を返さなければならない。
さなければならない。

MUST

50

3.2.2 The CD Bit④
ネームサーバサイド
CDビット
ビット

有

不良キャッシュ
データを返す不良キャッシュから
キャッシュからデータ
からデータを

リゾルバ等
リゾルバ等

無

⑤
不良キャッシュ
不良キャッシュにキャッシュに対応する問する問い合わせを受信
わせを受信

RCODE 2（（Server Fail））を返す

51

3.2.3 The AD Bit

内容

要求レベル
要求レベル

①応答内の
応答内のAnswer section及section及びAuthority sectionのsectionの全RRsetがRRsetが信頼できない
信頼できない場合できない場合⇒ネームサーバサイドは
ネームサーバサイドは、ADビット
ADビットをビットを設定してはならない
設定してはならない。
してはならない。

MUST NOT②応答内の応答内のAnswer sectionのsectionの全RRset、
RRset、及びAuthority sectionのsectionの任意の任意のNegative RRsがRRsが信頼できる
信頼できる場合できる場合⇒ネームサーバサイドはADビットをビットを設定すべき
設定すべきである
すべきである。
である。
ネームサーバサイドは、ADビットSHOULD③リゾルバサイドはリゾルバサイドは、RRがRRが信頼できるかの信頼できるかの判断できるかの判断をする
判断をする際をする際にSection5のSection5の規定に規定に従わなければならない。
わなければならない。

MUST

④応答に
応答に含まれる署名無
まれる署名無し
署名無しCNAME RRsがRRsが信頼できる
信頼できるDNAME
できるDNAME RRから
RRから生成から生成されたのが生成されたのが明されたのが明らかな場合
らかな場合
且つ、そのDNAME
そのDNAME RRが
RRが[RFC2672]で[RFC2672]で規定された
規定された合意規則
された合意規則に合意規則に従い応答に応答に含まれていた場合まれていた場合⇒ネームサーバはADビットをビットを設定しても設定しても良しても良い。
ネームサーバは、ADビット

MAY

52

3.3 Example DNSSEC Response

付録Bに応答パケットの例があります53

4. Resolving• 4.1 EDNS Support• 4.2 Signature Verification Support• 4.3 Determining Security Status of Data
• 4.4 configured Trust Anchors• 4.5 Response Caching• 4.6 Handing of the CD and AD Bits
• 4.7 Caching bad Data
• 4.8 Synthesized CNAMES• 4.9 Stub Resolvers- 4.9.1 Handing of the DO Bit- 4.9.2 Handing of the CD Bit- 4.9.3 Handing of the AD Bit
54

4. Resolving
本セクションではセキュリティ対応リゾルバ機能を持つものの振る舞いを 規定する。
多くの場合、この機能はセキュリティ対応再帰ネームサーバの 一部であるが、単独で動作する(stand-alone)セキュリティ
対応リゾルバも 多くの同じ要件を持つ。
セキュリティ対応再帰ネームサーバ固有の機能に ついてはセクション3.2で規定する。

＊本セクションで記載する要求レベルはRFC2119に記述されている通りに解釈される

55

4.1 EDNS Support
要求レベル
の事項
要求レベルMUSTのレベル
・問い合わせ時にEDNS OPT pseudo-RR にDOビットを付加しなければならない。
・EDNS OPT pseudo-RR内の『sender’s UDP payload size』フィールドを使用して受信出来るメッセージサイズを広報しなければならない。

• サポートするオクテットサイズ
サイズ
1220

要求レベル
要求レベル
MUST

4000

SHOULD

56

4.2 Signature Verification Support• 求められているサポート内容
セクション5で規定する署名検証の仕組みをサポート

要求レベル
要求レベル
MUST

受信した応答全てに対してその仕組みを適用

SHOULD

ワイルドカード所有者名の検証

MUST

• 例外
リゾルバがキャッシュサーバ（再帰ネームサーバ）である時、問い合わせにCDビットが設定されていた場合。
何らかのアプリケーションにてセキュリティ検証を行わないように設定されている場
合。
ローカルポリシーにより、問い合わせに対する検証が無効にされている場合

57

4.2 Signature Verification Support• ワイルドカード所有者の検証を行う場合
内容
不足しているセキュリティRRの問い合わせを行ってもよい※１
委任されたZONEの親側でNSEC RRが不足している場合、反復型リゾルバは親側のネームサーバに問い合わせる

要求レベル
要求レベル
MAY

委任されたZONEの親側でDSが不足している場合、反復型
リゾルバは親側のネームサーバに問い合わせる ※2

MUST

MUST

※１
問い合わせで得られる情報は時間差がある為、検証を行うには不十分な場合がある。
例）オリジナルの問い合わせ後にゾーンの更新が行われた場合※2
左から順番にラベルを取り除き問い合わせを行う。これをNS RRsetが見つかるか,
ラベルが無くなるまで繰り返す。

58

4.3 Determining Security Stauts of Data
• リゾルバは以下の4つの状態を判断出来る必要がある。
Secure（（安全）安全）指定したアンカーからそのRRsetまで署名付きDNSKEY
RR及びDS RRの連鎖を構築出来る。

Insecure（（安全でない安全でない）でない）

指定したアンカーからそのRRsetまで署名付きDNSKEY※1
RR及びDS RRの連鎖を構築出来ない。

Bogus（（不適正）
不適正）

RRsetまで信頼の連鎖を構築出来ると想定したが、署名検証に失敗した場合。もしくは存在すべき適切なDNSSECRRが無いために信頼の連鎖が構築出来ない※2

Indeterminate(不確定
不確定)
不確定

必要なDNSSEC RRを得られなかったため、そのRRsetが署名付きであるかを判断出来ない。 ※3※1 特定のRRsetが署名無しゾーンに存在する場合や、署名無しゾーンの下位にRRsetが存在する場合等。
※2 攻撃の可能性がある。もしくは設定エラーか何らかのデータ改変を示す場合もある。
※3 適切なゾーンを持つネームサーバにアクセス出来ない場合に生じ得る

59

4.4 Configured Trust Anchors• 求められている設定
内容
少なくとも一つの信頼出来る公開鍵またはDS RRを設定み組み込める機能
複数の信頼出来る公開鍵またはDS RRを設定に組み
込める機能

要求レベル
要求レベル
MUST

リゾルバの起動時に鍵を組み込める適度に強固な仕組みを幾つかもつべき ※１

SHOULDSHOULD※1 ハードディスクやNAS等
またtrust anchorsは安全な方法で更新される鍵を扱う為注意が必要である。
安全な方法としては物理メディアを介するものや、鍵交換プロトコル、他の帯域外（out of band）等の手段が考えられる。

60

4.5 Response Caching• 求められている機能
内容
最小単位のエントリーとして各応答をキャッシュする
エントリーが持つRRの中で、1つでも有効期限がきた
時点で、関連するエントリーのキャッシュを破棄する

61

要求レベル
要求レベル
SHOULDSHOULD4.5 Response Caching• 最小単位のエントリー構成
通常

QNAME QTYPE QCLASSセクション3.1.3.2で規定した応答 ※1

QNAME QCLASS※1 最初の問い合わせからデータをキャッシュし破棄するまでの間に、権威を持つデータが動的更新等によって変更される可能性があるため。

1．RRSIGレコードを使用する事で、回答がワイルドカードから合成された事を推測出来る。
再帰ネームサーバは、最初に受信したオリジナル回答による名前以外
名前以外の問い合わせに対して
名前以外応答を生成するために、このワイルドカードデータを保存し使用する。

2．名前の不在を証明するNSEC RRを受信した場合、セキュリティ対応リゾルバは
その名前の範囲内にある名前全てが存在しないことを証明するために、その NSEC RRをを再利用することができる。
再利用62

4.6 Handing of the CD and AD Bits
• 求められている機能
内容
応答内のRRsetに対してローカルポリシーが要求する
何らかの認証処理を実行する為に、CDビットを付加する事が出来る

要求レベル
要求レベル
MAY

自分が理解できないヘッダービットを問合わせメッセー
ジから応答メッセージに 無分別にコピーしてしまうような不適当な動作をするネームサーバからの影響を 避けるために、セキュリティ対応リゾルバは問合わせメッセージ生成時に ADビットをクリアしなければならない

MUST

応答メッセージが安全なチャネルから得られたか、安全なチャネルから応答を 得られなくてもメッセージヘッダ
ーに注意するような設定が特にされていない 限り、リゾ
ルバは応答に含まれるCDおよびADビットを無視しなけ
ればならない

MUST63

4.7 Caching BAD Data
概念的にはネガティブキャッシュと同様。違いは有効な否定応答をキャッシュするのではなく、特定の特定の回答の回答の検証に検証に失敗したという
失敗したという事実したという事実をキャッシュすること
事実• 求められている機能
内容

要求レベル
要求レベル

不要なDNSトラフィックを抑制する為に、署名が無効なデータを制限付きでキャッシュして
もよい

MAY

不良キャッシュを実装している場合は、そのキャッシュを利用したサービス不能攻撃を抑制する為に、幾つかの処理を行わなければならない

MUST

検証に失敗したRRsetは信頼出来るTTLを持たないので、TTLを自分で割り当てる必要が
ある

MUST

割り当てたTTLは攻撃の結果をキャッシュした影響を軽減する為に小さくすべきである

SHOULD

一時的な認証失敗をキャッシュしてしまわないように、認証が失敗した問い合わせを追跡記録すべきである

SHOULD

一定の閾値を超えて認証に失敗した場合は<QNAME,QTYPE,QCLASS>への問い合わせに対してのみ、
不良キャッシュを使用して応答すべきである

SHOULD

4.2で規定する規則に従った特定のRRsetの署名検証が求められない限り、RRsetへの問
い合わせに対して不良キャッシュを使用してはならない

MUST NOT64

4.8 Synthesized CNAMEs• 求められている機能
内容
有効な署名付きDNAME RRから署名無しCNAME RRが生成された場合、DNAME RRの署名がCNAME
RRも対象としている

要求レベル
要求レベル
MUST

署名が無いCNAME RRが存在するという理由で応答
メッセージを拒否してはならない。また、リゾルバはこのようなCNAME RRをキャッシュに保存しても良い。

MAY

65

4.9 Stub Resolvers• 求められている機能
内容
スタブリゾルバはDNSSEC RRをサポートしなければな
らない

要求レベル
要求レベル
MUST

※少なくともDNSSEC RRが含まれているだけの理由で誤った処理をしてはいけない

66

4.9.1 Handing of the DO Bits
4.9.1 DOビットの処理
内容
検証機能無しセキュリティ対応スタブリゾルバはアプリ
ケーションへの応答に再帰ネームサーバからのDNSSEC RRを含めてもよい
検証機能付きセキュリティ対応スタブリゾルバはDOビットを設定しなければならない

要求レベル
要求レベル
MAY

MUST

アプリケーションにDNSSEC RRを含めた応答を返そうとする検証機能無しスタブリゾルバは、再帰ネームサーバからDNSSEC RRを受信するためにDOビットを設定する必要がある。

67

4.9.2 Handing of the CD Bits
4.9.2 CDビットの処理
内容
検証機能無しセキュリティ対応スタブリゾルバはアプリ
ケーション層から要求されない限り、送信時にCDビットを設定すべきではない ※1
検証機能付きセキュリティ対応スタブリゾルバはCDビットを設定すべきである ※2

要求レベル
要求レベル
SHOULD NOTSHOULD※1
こっちでは検証出来ないから検証宜しく

スタブリゾルバ

ネームサーバ
検証結果 OK / NG だったよ

ユーザ

結果
※2

自分で検証するから結果だけちょうだい

スタブリゾルバ

CDビット

ネームサーバ
署名の情報送りますよ検証68

4.9.3 Handing of the AD Bits
4.9.3 ADビットの処理
内容
スタブリゾルバは再帰ネームサーバからの応答にADビットが設定されている事を調査しても良い。
(ADビットは暗号技術で検証された際に応答メッセージの回答部及び権威部付加される。)

要求レベル
要求レベル
MAY

セキュリティ対応スタブリゾルバが信頼出来るセキュリ
ティ対応再帰ネームサーバから安全チャネルを通してデータを得た場合を除き、如何なる場合でも自分の代わりに行ったとされる署名検証を信頼してはならない
検証機能付きスタブリゾルバはADビットの有無に関わらず署名検証を行う為、応答メッセージにADビットが設定されているかを検査すべきではない

MUST NOT69

SHOULD NOT

5. Authenticating DNS Responses• 5.1 Special Consideratons for islands of Security• 5.2 Authenticating Referrals• 5.3 Authenticating an RRset with an RRSIG RR-5.3.1 Checking the RRSIG RR Validity-5.3.2 Reconstructing the Signed Data
-5.3.3 Checking the Signature-5.3.4 Authenticating a Wildcard Expended RRset Positive Response• 5.4 Authenticated Denial of Existence• 5.5 Resolver Behavior When Signature Do Not Validate• 5.6 Authentication Example
70

5. Authenticating DNS Responses• DNSSEC RRsetを認証するために少なくとも一つの認証された『DNSKEY』or『DS RR』が必要。

• 『trust anchor』を使用してゾーンの頂点にある
DNSKEY RRが存在するか認証可能。

71

5. Authenticating DNS Responses
Resolver
DNSKEY⇒『Trust Anchor』
』
※事前に
事前に登録

DNS Root構造
事前に
事前に取得

•

DNSSEC RRsetを認証するために少なくとも一つの認証された『DNSKEY』or『DSRR』が必要。
『trust anchor』を使用してゾーンの頂点にあるDNSKEY
RRが存在するか認証可能。

DNSKEY RRset
DNSKEY（（KSK））
DNSKEY（
（ZSK）
）

子ゾーン
•

親ゾーン

RRSIG（（DNSKEY ）DS

DNSKEY RRset
DNSKEY（（KSK））
DNSKEY（（ZSK））
RRSIG（（DNSKEY ）72

RRSIG（（DS ）子ゾーンのDNSKEY(KSK)のダイジェスト値含む

5. Authenticating DNS Responses＜DNSKEY RR setを認証するためのResolverの処理＞①ゾーン頂点にあるDNSKEY RRset内に起点となるDNSKEY RRが存在するか検証②そのDNSKEY RRのゾーン鍵フラグが設定されているか検証
1111111111222222222233
01234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
Flags| Protocol| Algorithm |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+///
Public Key///+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-③ゾーン頂点にあるDNSKEY RRsetの署名を持つRRSIG RRが存在するか
検証④そのRRSIG RRと起点となるDNSKEY RRの組み合わせによってDNSKEY
RRsetを認証できるか検証（セクション5.3）
73

5. Authenticating DNS Responses
Resolver
DNSKEY⇒『Trust Anchor』
』
※事前に
事前に登録

•

親ゾーンのDNSKEY
RRsetの認証を実施

DNS Root構造
①、②
事前に
事前に取得
③、④
子ゾーン

親ゾーン
DNSKEY RRset
DNSKEY（（KSK））
DNSKEY（（ZSK））
RRSIG（（DNSKEY ）DS

DNSKEY RRset
DNSKEY（（KSK））
DNSKEY（（ZSK））
RRSIG（（DNSKEY ）74

RRSIG（（DS ）子ゾーンのDNSKEY(KSK)のダイジェスト値含む

5. Authenticating DNS Responses• リゾルバが起点となるDNSKEY RRを使用して、ゾーン頂
点のDNSKEY RRsetを一度認証すれば、DS RRsetを使用してそのゾーンからの委任を認証をすることができる。

• リゾルバは起点となる鍵から認証を開始し、他のゾーン頂点にあるDNSKEY RRsetの取得とDS RRset の使用により、下方に向けて再帰的な認証を可能にする。

75

5. Authenticating DNS Responses
Resolver

DNS Root構造
構造

DNSKEY⇒『Trust Anchor』
』
※事前に
事前に登録
•

事前に
事前に取得

DNSKEY RRset
DNSKEY（（KSK））
DNSKEY（（ZSK））
RRSIG（（DNSKEY ）DNSKEY RRset
DNSKEY（（KSK））
DNSKEY（
（ZSK）
）

子ゾーン

親ゾーンのDNSKEY
RRsetの認証を実施
孫ゾーン

親ゾーン

RRSIG（（DNSKEY ）DS

DNSKEY RRset
DNSKEY（（KSK））
DNSKEY（（ZSK））
RRSIG（（DNSKEY ）RRSIG（（DS ）子ゾーンのDNSKEY(KSK)のダイジェスト値含む

DS
RRSIG（（DS ） 孫ゾーンのDNSKEY(KSK)のダイジェスト値含む

76

5.1 Special Considerations for Islands of Security• Islands of Securityは親ゾーンからの認証の連鎖を構築できないため、基点となるゾーン鍵を取得する必要がある。⇒『Trust Anchor』• もし検証者がゾーン鍵を取得できない場合は署名なしみなした運用に切り替える。
DNS Root構造
root『test.com』』のDNSKEYDNSSECのの基点『jp』』のDNSKEYcom

jp

DNSSECの
の基点

事前に
事前に取得

example

ac

inter

test

Resolver
www

77

tell

bye

get

cp

5.2 Authenticating Referrais① 署名付きゾーンの頂点にあるDNSKEY RRsetが一度認証された場
合、DS RRsetを使用して署名付き子ゾーンの認証をすることができる。

② DS RRは、子ゾーンの頂点にあるDNSKEY RRset内のDNSKEYを特定し、子ゾーンのDNSKEY RRの暗号ダイジェストを含む③ リゾルバは子ゾーンのDNSKEY RRを使用して、子ゾーンの頂点にあるDNSKEY RRset全てを認証することができる。

78

5.2 Authenticating Referrais
Resolver
DNSKEY⇒『Trust Anchor』
』
※事前に
事前に登録

DNS Root構造
事前に
事前に取得
親ゾーンDNSKEY
RRs認証
認証
ゾーン

親ゾーン
DNSKEY RRset
DNSKEY（（KSK））
DNSKEY（（ZSK））

親ゾーンからゾーンからDSレコード
から レコード取得
レコード取得DSRRSIG（（DNSKEY ）子ゾーン

子ゾーンのDNSKEY（KSK）特定子ゾーンDNSKEY
RRs認証
認証
ゾーン

DNSKEY RRset
DNSKEY（（KSK））
DNSKEY（（ZSK））
RRSIG（（DNSKEY ）※子ゾーンの（KSK使用使用）
ゾーンのDNSKEY（
使用）

79

DS
RRSIG（（DS ）子ゾーンのDNSKEY(KSK)のダイジェスト値含む

5.2 Authenticating Referrais
DS RRが与えられた際、以下の条件が全て満たされれば子ゾーンの頂点にある
DNSKEY RRsetを認証することができる。

① DS RRは、親ゾーンの頂点にあるDNSKEY RRsetに含まれるDNSKEY RRによって認証済みである。
② DS RR内のアルゴリズムおよび鍵タグは、子ゾーンの頂点にあるDNSKEY RRset内のDNSKEY RRのアルゴリズムフィールドと鍵タグに一致。
③ DNSKEY RRの所有者名とRDATAがDS RRのダイジェストタイプフィールドで指定されるダイジェストフィールドでハッシュされている場合、得られたダイジェスト値はDS
RRのダイジェストフィールドと一致④ 子ゾーンにある、ダイジェストが一致したDNSKEY RRは、ゾーンフラグビットが設定されており、対応する秘密鍵によって子ゾーンの頂点にあるDNSKEY RRsetに署名し
ている。

80

5.2 Authenticating Referrais＜補足＞① 親ゾーンから得られた参照がDS RRsetを含まない場合、委任された名前に関する
DS RRsetが存在しないことを証明する署名付きNSEC RRsetを含めること。
② DNSSEC対応リゾルバは参照にDS RRsetもDS RRsetの不在証明をするNSEC
RRsetも含まれない場合、その親のネームサーバに対してDS RRsetも関する問合
せをしなければならない。
③ ゾーンにDS RRsetが存在しないことを証明するNSEC RRset を検証者が認証した場合、親から子に至る経路は存在しない。
④ リゾルバが子ゾーン内、又は、子ゾーンの下位ゾーンにある起点となるDNSKEY又は、DS RRを持っている場合、認証経路を再構築してもよい。

81

5.3 Authenticating an RRset with RRSIG RR① 検証者は初めにRRSIG RRを精査する。
-RRset の署名を持っているか-有効期限は過ぎていないか等② RRSIG RDATA（署名フィールドを除く）を署名対象のRRsetの正規形式に付け加え、正規形式の署名付き
データを形成③ 公開鍵と署名を使用して署名付きデータを認証する。

82

5.3.1 Checking the RRSIG RR validity① 検証者は初めにRRSIG RRを精査する。
規則内容

要求レベル
要求レベル

①RRSIG RRととRRsetはは同じ所有者を
所有者を持ち、同じクラスでクラスで なければならない。
なければならない。

MUST②RRSIG RRのの署名者名フィールドを含むゾーン の名前でなければならない
署名者名フィールドはフィールドはRRsetを
名前でなければならない

MUST③RRSIG RRのの署名対象フィールドのタイプと署名対象フィールドはフィールドはRRsetのタイプと同じでなければならない

MUST④ RRsetのの所有者名ののラベルフィールドの所有者名のラベル数
ラベル数は、RRSIG RRのラベルフィールドの値と同じかそれよりも大りも大きくなければならない

MUST

⑤検証者の
の有効期間終了フィールド
検証者の現在時刻を
現在時刻を表現する
表現する値
する値は、RRSIG RRの有効期間終了フィールドにフィールドに記載され
記載され
た時間と
さくなければならない。
なければならない。
時間と同じかそれよりも小じかそれよりも小さくなければならない

MUST

⑥検証者の
の有効期間開始フィールド
検証者の現在時刻を
現在時刻を表現する
表現する値
する値は、RRSIG RRの有効期間開始フィールドにフィールドに記載され
記載され
た時間と
きくければならない。
ければならない。
時間と同じかそれよりも大じかそれよりも大きくければならない

MUST⑦RRSIG RRのの署名者、署名者、アルゴリズム及アルゴリズム及び鍵タグフィールドはタグフィールドは、ゾーン頂点
ゾーン頂点にある頂点にあるの所有者名、
DNSKEY RRsetにに含まれるDNSKEYの所有者名、アルゴリズム及アルゴリズム及び鍵タグフィールドにタグフィールドにまれる
一致しなければならない
一致しなければならない

MUST⑧ DNSKEY RRsetははゾーン頂点RRsetにに含まれていなければならず、ゾーン頂点にある頂点にあるDNSKEYにある
まれていなければならず、
また、のフラグビット7）
フラグが設定されて設定されてまた、ゾーンビットフラグビット（
ゾーンビットフラグビット（DNSKEY RDATAのフラグビット ）のフラグがMUST

いなくてはならない。
いなくてはならない。

83

5.3.1 Checking the RRSIG RR validity① RRSIG RRとRRsetは同じ所有者を持ち、同じクラスでなければならない。
※class=IN
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
3600 RRSIG NS 5 1 3600
20040509183619 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg=

84

5.3.1 Checking the RRSIG RR validity② RRSIG RRの署名者名フィールドはRRsetを含むゾーンの名前でなければならない
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
3600 RRSIG NS 5 1 3600
20040509183619 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg=

85

5.3.1 Checking the RRSIG RR validity③ RRSIG RRの署名対象フィールドはRRsetのタイプと同じでなければならない
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
3600 RRSIG NS 5 1 3600
20040509183619 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg=

86

5.3.1 Checking the RRSIG RR validity④ RRsetの所有者名のラベル数は、RRSIG RRのラベル
フィールドの値と同じかそれよりも大きくなければならない
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
3600 RRSIG NS 5 1 3600
20040509183619 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg=

87

5.3.1 Checking the RRSIG RR validity⑤ 検証者の現在時刻を表現する値は、RRSIG RRの有効期間終了フィールドに記載された時間と同じかそれよ
りも小さくなければならない。
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
3600 RRSIG NS 5 1 3600
20040509183619 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg=

88

5.3.1 Checking the RRSIG RR validity⑥ 検証者の現在時刻を表現する値は、RRSIG RRの有効期間開始フィールドに記載された時間と同じかそれよりも大きくければならない。
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
3600 RRSIG NS 5 1 3600
20040509183619 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg=

89

5.3.1 Checking the RRSIG RR validity⑦ RRSIG RRの署名者、アルゴリズム及び鍵タグフィールドは、ゾーン頂点にあるDNSKEY RRsetに含まれるDNSKEYの所有者名、ア
ルゴリズム及び鍵タグフィールドに一致しなければならない
3600 DNSKEY 256 3 5 AQOy1bZV・・・ ;key id = 38519
3600 RRSIG NS 5 1 3600
20040509183619 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg=

90

5.3.1 Checking the RRSIG RR validity⑧DNSKEY RRsetはゾーン頂点にあるDNSKEY RRsetに含まれていなければならず、また、ゾーンビットフラグビット（DNSKEY
RDATAのフラグビット7）のフラグが設定されていなくてはならない。
1111111111222222222233
01234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
Flags| Protocol| Algorithm |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+///
Public Key///+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

91

5.3.2 Reconstructing the Signed Data
② オリジナルの署名付きデータの再構成
署名データ
署名データ
RRSIG RDATA＊署名フィールド
署名フィールド除フィールド除く

RR（
（1）
）

RR（
（2）
）

name|｜｜Type｜｜class｜｜
OrigTTL ｜RDATA length
RDATA

name|｜｜Type｜｜class｜｜・・・・
OrigTTL ｜RDATA length
RDATA①『class』はRRsetのクラスである②『Type』はRRsetのタイプである。
③『OrigTTL』はRRSIGオリジナルTTLフィールドから得られた値④『RDATA』フィールド内の名前はすべて正規形式（RFC4034参照）

92

5.3.3 Cheaking The Signature③ 公開鍵と署名を使用して署名付きデータを認証する
example. 3600 NS ns1.example.
署名生成に
署名生成に使用した
使用したアルゴリズムしたアルゴリズム
example. 3600 NS ns2.example.
＊『5』』⇒RSA/SHA-1
3600 RRSIG NS 5 1 3600
20040509183619( 20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
鍵ID
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg= )・・3600 DNSKEY 256 3 5 (AQOy1bZV・・・) ;key id = 38519① RRSIG RRのアルゴリズムフィールドは署名生成に使用したアルゴリズムを特定する②署名そのものはRRSIG RDATAの署名フィールドに保存③署名の検証に使用する公開鍵は対応するDNSKEY RRの公開鍵フィールドに保存される。

93

5.3.3 Cheaking The Signature★DNSKEY RRがが２つ以上になる
以上になる場合になる場合
条件に一致した公開鍵を１つずつ試していき、署名検証に成功するか、試すべき鍵が無くなるまで繰り返すことによってのみ、正式なDNSKEY RRを決定することができる。

★RRSIG RRののラベルフィールドがの完全修飾所有者名のラベルフィールドがRRsetの
完全修飾所有者名のラベル数
ラベル数と一致しない
一致しない場合
しない場合
RRsetが無効。もしくは、ワイルドカード展開によって得られたものかのどちらか。
リゾルバはRRsetを信頼できるとみなす前に、ワイルドカード展開が適切に行われたかを検証しなければならない。（MUST）

94

5.3.3 Cheaking The Signature★リゾルバがリゾルバがRRsetをを信頼できると信頼できると判断できると判断した
判断した場合した場合
検証者はRRSIG RRと認証されたRRsetに含まれる各RRのTTLを下記に示す値の最小値を超えないように設定しなければならない。
（MUST）・ 応答を受信した際のRRsetのTTL・ 応答を受信した際のRRSIG RRのTTL・ RRSIG RRのオリジナルTTLフィールドに含まれる値
・ RRSIG RRの署名有効期間終了時刻と現在時刻との差

95

5.3.4 Authenticating a Wildcard Expanded RRset Positive Response★ RRsetのの所有者ののラベル
所有者のラベル数
ラベル数が、署名を署名を持つRRSIG RRのフィールドのフィールドの値より大より大きい場合
きい場合⇒RRsetとその署名をもつRRSIG RRはワイルドカード展開の結果生成されたもの★ リゾルバが
リゾルバが受信した
受信した応答
した応答は
応答は、応答を応答を認証するために認証するために必要するために必要な
必要なNSEC
RRをすべてをすべて含）をすべて含むべきであること。（＊
むべきであること。（＊参照。（＊参照 section 3.1.3）

96

5.4 Authenticated Denial of Existence
RulesⅠ）queried RR nameとNSEC RRのowner nameが同じ場合
NSEC RRのType bit mapを検証し判断する
example.
NSEC
a.example.
NSEC
ai.example.
NSEC
b.example.
NSEC
ns1.example. NSEC
ns2.example. NSEC*.w.example. NSEC
x.w.example. NSEC
x.y.w.example. NSEC
xx.example.
NSEC例) ai.example. MXの不在証明

a.example.
NS SOA MX RRSIG NSEC DNSKEY
ai.example.
NS DS RRSIG NSEC
b.example.
A HINFO AAAA RRSIG NSEC
ns1.example. NS RRSIG NSEC
ns2.example. A RRSIG NSEC*.w.example. A RRSIG NSEC
x.w.example. MX RRSIG NSEC
x.y.w.example. MX RRSIG NSEC
xx.example.
MX RRSIG NSEC
example.
A HINFO AAAA RRSIG NSEC
※最初に戻る97

5.4 Authenticated Denial of Existence
RulesⅡ）queried RR nameとNSEC RRのowner nameが違う場合①②を実施した結果で、判断をする
example.
NSEC
a.example.
NSEC
ai.example.
NSEC
b.example.
NSEC
ns1.example. NSEC
ns2.example. NSEC*.w.example. NSEC
x.w.example. NSEC
x.y.w.example. NSEC
xx.example.
NSEC例) az.example.の不在証明

a.example.
ai.example.
b.example.
ns1.example.
ns2.example.
*.w.example.
x.w.example.
x.y.w.example.
xx.example.
example.
※最初に戻る98①az.example.
を探しているんだけど・・・
ai.exampleの次は、b.example.
このZONEには存在しない
②ワイルド
カード展開
だ！！

5.4 Authenticated Denial of Existence• Resolverは、署名済みNSEC RRを使用して、署名付きZONE内に特定のRRsetが存在しないことを証明する
参照： Rules Ⅰ• queried RRsetの不在検証に必要なNSEC RRを全て取得するための処理を行う－ワイルドカードRRsetの不在も証明する必要ある－しかし、特定の問い合わせへの回答だけに労力を注がないように抑制する
参照： Rules Ⅱ99

5.5 Resolver Behavior When Signatures Do Not Validate
root
DNSKEYDSRRSIG RRを検証できなかった！
DNSKEY

信頼できない？！
(まだ途中なのに・・)

DS• CD bit なし－回答は、ServFail－検証失敗のRRsetはキャッシュできる

DNSKEYDS
DNSKEYDS
trust
anchor• CD bit あり－回答は、data from BAD cache
参照：Sections 4.7

キャッシュ※ data from BAD cache : 認証に失敗した特定の〈QNAME,QTYPE,QCLASS〉

ユーザ

100

5.6 Authentication Example

付録Cに認証処理の例があります101

6. IANA Considerations• RFC2535－CDおよびADビットを予約• RFC3655－ADビットの意味を再定義• RFC2671－EDNS導入• RFC3225－DNSSEC OKビット定義

102

7. Security Considerations• 本文書はRRsetに署名/認証する方法を規定• security-aware recursive-mode resolverは、CD/ADビットを使用する場合、安全な
channelが必要になる＊参照：Sections 3.2.2 & Sections 4.9

security-aware
recursive-mode
resolverresolver攻撃者

security-oblivious
recursive-mode
resolvers103

7. Security Considerations• ローカルポリシーの策定－認証失敗後の動作はアプリに依存－アプリの振る舞いに注意しましょう－提供サービスに影響を与える可能性あり

104

8. Acknowledgements
9. References105