Browse Prior Art Database

Domain Name System Security (DNSSEC) Signing Authority (RFC3008)

IP.com Disclosure Number: IPCOM000005200D
Original Publication Date: 2000-Nov-01
Included in the Prior Art Database: 2001-Aug-17
Document File: 8 page(s) / 14K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

B. Wellington: AUTHOR

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 25% of the total text.

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 RFC 2119 [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.

Wellington Standards Track [Page 1]

RFC 3008 DNSSEC Signing Authority November 2000

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 f...