Signaling NSEC record owner name nonexistence
draft-ogud-fake-nxdomain-type-00

Abstract

DNSSEC was to large extent designed for off-line signing. A number of new opportunities arise when on-line signing is used. In negative answers case there is no real need for the wildcard proof and the server can just state that the queried name and type do not exist in a single NSEC/NSEC3 record. But such a minimally covering NSEC record that shares the name with the query name can not set the NXDOMAIN RCODE. Still, some applications want to explicitly know if the name does exist. This document allocates a new DNS RRtype that can be used to signal nonexistence of the owner names of NSEC/NSEC3 records.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 8, 2015.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Requirements Notation
• 3. Protocol Changes
• 4. IANA Considerations
• 5. Security Considerations
• 6. Implementation Experience
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Appendix A. Document history
• A.1. Abridged Revision History
• Authors' Addresses

1. Introduction

The DNSSEC Specification [RFC4035] is largely designed for off-line signing [RFC4471] with minimal thought for as how on-line signing systems can give out smaller/better answers.

One way to give a validate-able negative answer for a question when the name does not exist is to state that the name exists but the type does not. This allows to generate one NSEC instead of two. This works great for resolvers as they see that what was asked for does not exist and thus tell the application that.

There is a sub-class of applications that care if the name exists rather than the type and the question is asked to check for the existence of the name and not the type. The above approach makes life hard for these applications.

To support both of the above expectations we propose to define a RRtype, that has no body and never exists (i.e. a meta-type). When the bit for this type is set in the NSEC/NSEC3 bitmap the application can take that to mean "the right RCODE for this answer would be NXDOMAIN".

2. Requirements Notation

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

3. Protocol Changes

This document specifies a special DNS RRType [RFC1035] that can only appear in NSEC/NSEC3 bitmaps [RFC4034] to signal that:

• this is an on-line signed answer
• none of the owner name nor the target name or any name in between them exist
• this name is not covered by any wildcard

The purpose of this is to signal that the "right answer" for this query was RCODE=3 and multiple NSEC/NSEC3 records in the authority section, but because the answer was signed on-the-fly it was pretended that the query name exists but the type does not, thus answering with RCODE=0 and one NSEC record in the authority section. We call this RRType FakeNXDOMAIN or FDOM, type code is TBD.

An authoritative DNS server SHOULD NOT be extended to load this type or any other meta type.

A resolver MAY translate the returned NSEC record in a RCODE=3 answer, if it so chooses, to clients that do not ask for DNSSEC answers.

4. IANA Considerations

We request an assignment in the "Domain Name System (DNS) Parameters" registry sub-registry "Resource Record (RR) TYPEs" for a type code FDOM (Fake DOMain name) suggesting using the lowest Meta-Type code available 128.

5. Security Considerations

While the content of the answer changes with this technique, its actual meaning is the same and such an answer can't be replayed by an attacker to mean anything else than its intended meaning.

An application sensible to the difference between a nonexistent name and a nonexistent type SHOULD support the RRType defined in this document, and can rely on it to retrieve the information they look for securely since the NSEC/NSEC3 bitmap is signed.

6. Implementation Experience

TBD

7. References

7.1. Normative References

7.2. Informative References

Appendix A. Document history

This section (and sub-sections) should be removed before publication.

A.1. Abridged Revision History

00 Initial draft.

Authors' Addresses