Internet DRAFT - draft-ogud-fake-nxdomain-type
draft-ogud-fake-nxdomain-type
DNSOP O. Gudmundsson
Internet-Draft F. Valsorda
Updates: 1035 (if approved) CloudFlare Inc.
Intended status: Standards Track May 7, 2015
Expires: November 8, 2015
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
Gudmundsson & Valsorda Expires November 8, 2015 [Page 1]
Internet-Draft NXDOMAIN via NSEC type map May 2015
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
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Changes . . . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 3
6. Implementation Experience . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 4
Appendix A. Document history . . . . . . . . . . . . . . . . . . 4
A.1. Abridged Revision History . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4
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".
Gudmundsson & Valsorda Expires November 8, 2015 [Page 2]
Internet-Draft NXDOMAIN via NSEC type map May 2015
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
Gudmundsson & Valsorda Expires November 8, 2015 [Page 3]
Internet-Draft NXDOMAIN via NSEC type map May 2015
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
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
7.2. Informative References
[RFC4471] Sisson, G. and B. Laurie, "Derivation of DNS Name
Predecessor and Successor", RFC 4471, September 2006.
Appendix A. Document history
This section (and sub-sections) should be removed before publication.
A.1. Abridged Revision History
00 Initial draft.
Authors' Addresses
Olafur Gudmundsson
CloudFlare Inc.
San Francisco, CA 94107
USA
Email: olafur@cloudflare.com
Gudmundsson & Valsorda Expires November 8, 2015 [Page 4]
Internet-Draft NXDOMAIN via NSEC type map May 2015
Filippo Valsorda
CloudFlare Inc.
London
UK
Email: filippo@cloudflare.com
Gudmundsson & Valsorda Expires November 8, 2015 [Page 5]
