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]