分享
 
 
 

RFC3008 - Domain Name System Security (DNSSEC) Signing Authority

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group B. Wellington

Request for Comments: 3008 Nominum

Updates: 2535 November 2000

Category: Standards Track

Domain Name System Security (DNSSEC) Signing Authority

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

This document proposes a revised model of Domain Name System Security

(DNSSEC) Signing Authority. The revised model is designed to clarify

earlier documents and add additional restrictions to simplify the

secure resolution process. Specifically, this affects the

authorization of keys to sign sets of records.

The key Words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in RFC2119 [RFC2119].

1 - IntrodUCtion

This document defines additional restrictions on DNSSEC signatures

(SIG) records relating to their authority to sign associated data.

The intent is to establish a standard policy followed by a secure

resolver; this policy can be augmented by local rules. This builds

upon [RFC2535], updating section 2.3.6 of that document.

The most significant change is that in a secure zone, zone data is

required to be signed by the zone key.

Familiarity with the DNS system [RFC1034, RFC1035] and the DNS

security extensions [RFC2535] is assumed.

2 - The SIG Record

A SIG record is normally associated with an RRset, and "covers" (that

is, demonstrates the authenticity and integrity of) the RRset. This

is referred to as a "data SIG". Note that there can be multiple SIG

records covering an RRset, and the same validation process should be

repeated for each of them. Some data SIGs are considered "material",

that is, relevant to a DNSSEC capable resolver, and some are

"immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC

validation. Immaterial SIGs may have application defined roles. SIG

records may exist which are not bound to any RRset; these are also

considered immaterial. The validation process determines which SIGs

are material; once a SIG is shown to be immaterial, no other

validation is necessary.

SIGs may also be used for transaction security. In this case, a SIG

record with a type covered field of 0 is attached to a message, and

is used to protect message integrity. This is referred to as a

SIG(0) [RFC2535, RFC2931].

The following sections define requirements for all of the fields of a

SIG record. These requirements MUST be met in order for a DNSSEC

capable resolver to process this signature. If any of these

requirements are not met, the SIG cannot be further processed.

Additionally, once a KEY has been identified as having generated this

SIG, there are requirements that it MUST meet.

2.1 - Type Covered

For a data SIG, the type covered MUST be the same as the type of data

in the associated RRset. For a SIG(0), the type covered MUST be 0.

2.2 - Algorithm Number

The algorithm specified in a SIG MUST be recognized by the client,

and it MUST be an algorithm that has a defined SIG rdata format.

2.3 - Labels

The labels count MUST be less than or equal to the number of labels

in the SIG owner name, as specified in [RFC2535, section 4.1.3].

2.4 - Original TTL

The original TTL MUST be greater than or equal to the TTL of the SIG

record itself, since the TTL cannot be increased by intermediate

servers. This field can be ignored for SIG(0) records.

2.5 - Signature EXPiration and Inception

The current time at the time of validation MUST lie within the

validity period bounded by the inception and expiration times.

2.6 - Key Tag

There are no restrictions on the Key Tag field, although it is

possible that future algorithms will impose constraints.

2.7 - Signer's Name

The signer's name field of a data SIG MUST contain the name of the

zone to which the data and signature belong. The combination of

signer's name, key tag, and algorithm MUST identify a zone key if the

SIG is to be considered material. The only exception that the

signer's name field in a SIG KEY at a zone apex SHOULD contain the

parent zone's name, unless the KEY set is self-signed. This document

defines a standard policy for DNSSEC validation; local policy may

override the standard policy.

There are no restrictions on the signer field of a SIG(0) record.

The combination of signer's name, key tag, and algorithm MUST

identify a key if this SIG(0) is to be processed.

2.8 - Signature

There are no restrictions on the signature field. The signature will

be verified at some point, but does not need to be examined prior to

verification unless a future algorithm imposes constraints.

3 - The Signing KEY Record

Once a signature has been examined and its fields validated (but

before the signature has been verified), the resolver attempts to

locate a KEY that matches the signer name, key tag, and algorithm

fields in the SIG. If one is not found, the SIG cannot be verified

and is considered immaterial. If KEYs are found, several fields of

the KEY record MUST have specific values if the SIG is to be

considered material and authorized. If there are multiple KEYs, the

following checks are performed on all of them, as there is no way to

determine which one generated the signature until the verification is

performed.

3.1 - Type Flags

The signing KEY record MUST have a flags value of 00 or 01

(authentication allowed, confidentiality optional) [RFC2535, 3.1.2].

A DNSSEC resolver MUST only trust signatures generated by keys that

are permitted to authenticate data.

3.2 - Name Flags

The interpretation of this field is considerably different for data

SIGs and SIG(0) records.

3.2.1 - Data SIG

If the SIG record covers an RRset, the name type of the associated

KEY MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC2535,

section 2.3.6. The DNSSEC validation process performed by a resolver

MUST ignore all keys that are not zone keys unless local policy

dictates otherwise.

The primary reason that RFC2535 allows host and user keys to

generate material DNSSEC signatures is to allow dynamic update

without online zone keys; that is, avoid storing private keys in an

online server. The desire to avoid online signing keys cannot be

achieved, though, because they are necessary to sign NXT and SOA sets

[RFC3007]. These online zone keys can sign any incoming data.

Removing the goal of having no online keys removes the reason to

allow host and user keys to generate material signatures.

Limiting material signatures to zone keys simplifies the validation

process. The length of the verification chain is bounded by the

name's label depth. The authority of a key is clearly defined; a

resolver does not need to make a potentially complicated decision to

determine whether a key has the proper authority to sign data.

Finally, there is no additional flexibility granted by allowing

host/user key generated material signatures. As long as users and

hosts have the ability to authenticate update requests to the primary

zone server, signatures by zone keys are sufficient to protect the

integrity of the data to the world at large.

3.2.2 - SIG(0)

If the SIG record is a SIG(0) protecting a message, the name type of

the associated KEY SHOULD be 00 (user) or 10 (host/entity).

Transactions are initiated by a host or user, not a zone, so zone

keys SHOULD not generate SIG(0) records.

A client is either explicitly executed by a user or on behalf of a

host, therefore the name type of a SIG(0) generated by a client

SHOULD be either user or host. A nameserver is associated with a

host, and its use of SIG(0) is not associated with a particular zone,

so the name type of a SIG(0) generated by a nameserver SHOULD be

host.

3.3 - Signatory Flags

This document does not assign any values to the signatory field, nor

require any values to be present.

3.4 - Protocol

The signing KEY record MUST have a protocol value of 3 (DNSSEC) or

255 (ALL). If a key is not specified for use with DNSSEC, a DNSSEC

resolver MUST NOT trust any signature that it generates.

3.5 - Algorithm Number

The algorithm field MUST be identical to that of the generated SIG

record, and MUST meet all requirements for an algorithm value in a

SIG record.

4 - Security Considerations

This document defines a standard baseline for a DNSSEC capable

resolver. This is necessary for a thorough security analysis of

DNSSEC, if one is to be done.

Specifically, this document places additional restrictions on SIG

records that a resolver must validate before the signature can be

considered worthy of DNSSEC trust. This simplifies the protocol,

making it more robust and able to withstand scrutiny by the security

community.

5 - Acknowledgements

The author would like to thank the following people for review and

informative comments (in alphabetical order):

Olafur Gudmundsson

Ed Lewis

6 - References

[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",

STD 13, RFC1034, November 1987.

[RFC1035] Mockapetris, P., "Domain Names - Implementation and

Specification", STD 13, RFC1035, November 1987.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

Requirement Levels", BCP 14, RFC2119, March 1997.

[RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,

"Dynamic Updates in the Domain Name System", RFC2136,

April 1997.

[RFC2535] Eastlake, D., "Domain Name System Security Extensions",

RFC2535, March 1999.

[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures

(SIG(0)s )", RFC2931, September 2000.

[RFC3007] Wellington, B., "Simple Secure Domain Name System

(DNS) Dynamic Update", RFC3007, November 2000.

7 - Author's Address

Brian Wellington

Nominum, Inc.

950 Charter Street

Redwood City, CA 94063

Phone: +1 650 381 6022

EMail:

Brian.Wellington@nominum.com

8 Full Copyright Statement

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to

others, and derivative works that comment on or otherwise explain it

or assist in its implementation may be prepared, copied, published

and distributed, in whole or in part, without restriction of any

kind, provided that the above copyright notice and this paragraph are

included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing

the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of

developing Internet standards in which case the procedures for

copyrights defined in the Internet Standards process must be

followed, or as required to translate it into languages other than

English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFCEditor function is currently provided by the

Internet Society.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有