Network Working Group E. Hunt Internet-Draft D. Mahoney Intended status: Standards Track ISC Expires: November 29, 2014 May 28, 2014 A DNS Resource Record for Confidential Comments (NOTE RR) draft-hunt-note-rr-01 Abstract While the DNS zone master file format has always allowed comments, there is no existing mechanism to preserve comments once the zone has been loaded into memory or converted to a binary representation. This note proposes a new "NOTE" RR type, which is stored alongside zone data and may be included in zone transfers, but is not returned in response to DNS queries. 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 29, 2014. Copyright Notice Copyright (c) 2014 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 Hunt & Mahoney Expires November 29, 2014 [Page 1] Internet-Draft note-rr May 2014 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 2. The NOTE RR Type . . . . . . . . . . . . . . . . . . . . . . . 3 3. The NOTE-OK Option . . . . . . . . . . . . . . . . . . . . . . 4 4. Authoritative Server Behavior . . . . . . . . . . . . . . . . . 4 5. Recursive Server Behavior . . . . . . . . . . . . . . . . . . . 5 6. DNSSEC Signing Behavior . . . . . . . . . . . . . . . . . . . . 5 7. UPDATE Behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9.1. NOTE RR Type Code . . . . . . . . . . . . . . . . . . . . . 6 9.2. NOTE-OK Option Code . . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Hunt & Mahoney Expires November 29, 2014 [Page 2] Internet-Draft note-rr May 2014 1. Introduction DNS zone master files, as specified in [RFC1035], can include comment text: any text on a line following an unquoted semicolon is ignored. Once the zone has been loaded, however, these comments can be lost. Servers which dump backup copies of dynamically updated or automatically signed zones may obliterate comments that were in the original zone files; slave servers do not receive comment text when transferring zones from master servers. Comments can be stored in the zone as TXT RRs, which are backed up and preserved across across zone transfers, but TXT records are available to any DNS query. Because zone file comments commonly include information about internal networks and/or personnel that could be of use to potential attackers, it is better for distribution of comment data to be restricted. This document proposes a mechanism to store confidential comments within zone data. The presence/absence and the content of comments are concealed from normal DNS queries (except from specific trusted DNS clients), as well as from slave servers that do not explicitly signal their ability to cooperate with these restrictions. A "NOTE" RR can be used to store a comment at a DNS node. It may be transferred to slaves or written to permanent storage, but it is not returned in response to normal DNS queries. A "NOTE-OK" EDNS [RFC6891] option signals that the sender understands NOTE records and will restrict their dissemination. If this option is not included in a zone transfer request, NOTE data will be omitted from the zone transfer. Traditional zone file comments, indicated by semicolons, are still ignored. 1.1. Reserved Words 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]. 2. The NOTE RR Type The NOTE RR is defined for all classes, with mnemonic NOTE and type code [TBD]. The RDATA and presentation formats are identical to those of the TXT RR defined in [RFC1035], e.g: Hunt & Mahoney Expires November 29, 2014 [Page 3] Internet-Draft note-rr May 2014 $ORIGIN example.com. joesbox 7200 IN A 198.51.100.42 7200 IN AAAA 2001:DB8:3F:B019::17 0 IN NOTE "Desktop system for Joe Smith, x7889" 3. The NOTE-OK Option A slave transferring a zone from a master server must explicitly signal its understanding of the NOTE RR. The mechanism for this is an EDNS option, with OPTION-CODE [TBD]. OPTION-LENGTH MUST be zero and OPTION-DATA MUST be empty. Including a NOTE-OK option in a query of type AXFR or type IXFR signals that the zone transfer client has implemented the NOTE RR and is able to restrict access to NOTE data as specified in Section 4. If the option is not included, the server MUST omit NOTE records from the zone transfer. Including a NOTE-OK option in a query of type NOTE or type ANY signals that the client is not a recursive or forwarding resolver and will not cache or further distribute the response. If and only if the client is explicitly authorized to receive NOTE data, the server MAY respond. If the option is not included, the server MUST respond as if NOTE data did not exist. 4. Authoritative Server Behavior Because zone file comments often contain information which may be security-sensitive or otherwise not for public consumption, authoritative servers implementing the NOTE RR type MUST implement the restrictions described below: o NOTE RRs MUST NOT be returned in response to any DNS query, including zone transfer requests, unless the query contains a NOTE-OK option. o The NOTE RRset TTL MUST be zero. Any configured TTL greater than zero is overridden. o NOTE RRs MUST be omitted from responses to queries of type ANY. (This MAY be relaxed if the client is explicitly trusted with NOTE data and the query contains a NOTE-OK option.) o When an explicit query for type NOTE is received, the server MUST return NXDOMAIN or NOERROR/NODATA, depending on the presence or absence of other data at the node. (This MAY be relaxed if the Hunt & Mahoney Expires November 29, 2014 [Page 4] Internet-Draft note-rr May 2014 client is explicitly trusted with NOTE data and the query contains a NOTE-OK option.) Where and as noted, these requirements MAY be relaxed, if and only if a separately-configurable access control mechanism is available so that NOTE records are visible only to a restricted set of explicitly trusted clients (i.e., queries originating from a particular IP address range or signed by a specific TSIG key, and including a NOTE-OK option), and hidden from all other clients. The default setting of such a mechanism, and the behavior of any server not implementing such a mechanism, MUST be to hide NOTE data from all clients. 5. Recursive Server Behavior Recursive resolvers MUST NOT send NOTE-OK when iterating to satisfy recursive client queries. In addition, resolvers SHOULD implement the following restrictions: o NOTE RRs MUST NOT be cached; a TTL greater than zero MUST be ignored. o Recursive queries for type NOTE MUST be answered as if the data did not exist. o Resolvers SHOULD NOT iterate for type NOTE except to determine whether the correct response code is NXDOMAIN or NOERROR. 6. DNSSEC Signing Behavior In order to preserve the fiction that NOTE RRs do not exist for untrusted clients, some changes are needed with respect to DNSSEC signing and query logic [RFC4035]: o NOTE RRsets MAY be left unsigned. o If NOTE RRsets are signed, then the covering RRSIG RRsets MUST be hidden from untrusted clients just as the NOTE RRsets are. If a NOTE RRset at an otherwise empty node is signed, the server MUST respond with NXDOMAIN to a query of type NOTE or type ANY, in spite of the presence of an RRSIG RRset at that node. RRSIG RRsets covering type NOTE MUST be omitted from zone transfers and query responses whenver NOTE RRsets would be. RRSIG RRsets covering type NOTE MUST have TTL zero. Hunt & Mahoney Expires November 29, 2014 [Page 5] Internet-Draft note-rr May 2014 o Nodes containing NOTE RRs but no other data SHOULD be omitted from NSEC [RFC4034] RR chains and MAY be omitted from NSEC3 [RFC5155] RR chains. o The NOTE RR type MUST NOT be included in the Type Bit Map field of an NSEC or NSEC3 RR. 7. UPDATE Behavior NOTE RRs MAY be submitted via UPDATE [RFC2136]. Servers SHOULD ignore prerequisites that specify type NOTE, in order to conceal from untrusted clients the presence or absence of NOTE RRs. 8. Security Considerations It is an explicit design goal that NOTE data should not be accessible via normal DNS queries, because zone file comments commonly include information that could be of use to potential attackers. Operators using NOTE RRs in their zones SHOULD disallow zone transfers except to trusted slave servers. Authoritative servers MAY refuse to load or serve NOTE data if zone transfers are not restricted. 9. IANA Considerations IANA is requested to take the actions in this section. 9.1. NOTE RR Type Code This document requests the allocation of a DNS RR type number for the NOTE RR type. 9.2. NOTE-OK Option Code This document requests the allocation of an EDNS(0) option code for the NOTE-OK option. 10. Acknowledgments Thanks to Paul Vixie, Stephen Morris, Chuck Aurora, Jeremy Reed and Nicholas Weaver, Doug Barton and Olafur Gudmundsson for suggestions and feedback. Hunt & Mahoney Expires November 29, 2014 [Page 6] Internet-Draft note-rr May 2014 11. References 11.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 11.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. Authors' Addresses Evan Hunt ISC 950 Charter St Redwood City, CA 94063 USA Email: each@isc.org Hunt & Mahoney Expires November 29, 2014 [Page 7] Internet-Draft note-rr May 2014 Dan Mahoney ISC 950 Charter St Redwood City, CA 94063 USA Email: dmahoney@isc.org Hunt & Mahoney Expires November 29, 2014 [Page 8]