Browse Prior Art Database

DNS Security Extension Clarification on Zone Status (RFC3090)

IP.com Disclosure Number: IPCOM000005285D
Original Publication Date: 2001-Mar-01
Included in the Prior Art Database: 2001-Aug-21
Document File: 12 page(s) / 24K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E. Lewis: AUTHOR

Abstract

The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated.

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

Network Working Group E. Lewis Request for Comments: 3090 NAI Labs Category: Standards Track March 2001

DNS Security Extension Clarification on Zone Status

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 (2001). All Rights Reserved.

Abstract

The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated.

1 Introduction

Whether a DNS zone is "secured" or not is a question asked in at least four contexts. A zone administrator asks the question when configuring a zone to use DNSSEC. A dynamic update server asks the question when an update request arrives, which may require DNSSEC processing. A delegating zone asks the question of a child zone when the parent enters data indicating the status the child. A resolver asks the question upon receipt of data belonging to the zone.

1.1 When a Zone's Status is Important

A zone administrator needs to be able to determine what steps are needed to make the zone as secure as it can be. Realizing that due to the distributed nature of DNS and its administration, any single zone is at the mercy of other zones when it comes to the appearance of security. This document will define what makes a zone qualify as secure.

Lewis Standards Track [Page 1]

RFC 3090 DNS Security Extension on Zone Status March 2001

A name server performing dynamic updates needs to know whether a zone being updated is to have signatures added to the updated data, NXT records applied, and other required processing. In this case, it is conceivable that the name server is configured with the knowledge, but being able to determine the status of a zone by examining the data is a desirable alternative to configuration parameters.

A delegating zone is required to indicate whether a child zone is secured. The reason for this requirement lies in the way in which a resolver makes its own determination about a zone (next paragraph). To shorten a long story, a parent needs to know whether a child should be considered secured. This is a two part question. Under what circumstances does a parent consider a child zone to be secure, and how does a parent know if the child conforms?

A resolver needs to know if a zone is secured when the resolver is processing data from the zone. Ultimately, a resolver needs to know whether or not t...