idnits 2.17.00 (12 Aug 2021) /tmp/idnits59486/draft-hunt-note-rr-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([I-D.krecicki-dns-covert]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC6195, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2019) is 1050 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group E. Hunt 3 Internet-Draft D. Mahoney 4 Updates: 6195 (if approved) ISC 5 Intended status: Standards Track July 6, 2019 6 Expires: January 7, 2020 8 A DNS Resource Record for Confidential Comments (NOTE RR) 9 draft-hunt-note-rr-02 11 Abstract 13 While the DNS zone master file format has always allowed comments, 14 there is no existing mechanism to preserve comments once the zone has 15 been loaded into memory or converted to a binary representation. 16 This note proposes a new RR type "NOTE", to be allocated from the 17 Covert-RR type range proposed in [I-D.krecicki-dns-covert], so that 18 confidential comments can be stored alongside zone data, and included 19 in zone transfers when Covert semantics are supported by the 20 secondary. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 7, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. The NOTE RR Type . . . . . . . . . . . . . . . . . . . . . . 3 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 60 4. Security and Privacy Considerations . . . . . . . . . . . . . 3 61 5. Normative References . . . . . . . . . . . . . . . . . . . . 3 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 64 1. Introduction 66 DNS zone master files may include comments: any text on a line 67 following an unquoted semicolon is ignored when parsing the file 68 [RFC1034]. These comments are often used by administrators to keep 69 notes about the zone data; for example, the purpose of a particular 70 host, or the person responsible for maintaining it. 72 When the zone is loaded, however, comments may be lost. Servers 73 which dump backup copies of dynamically updated or automatically 74 signed zones may obliterate comments that were in the original zone 75 files. Secondary servers do not receive comment text when 76 transferring zones from primary servers. 78 Comments could be stored in the zone itself as TXT RRs; these would 79 be preserved after zone updates and across zone transfers. However, 80 TXT records are available to any DNS query. Because zone file 81 comments commonly include information about internal networks and/or 82 personnel that could be of use to potential attackers, it is better 83 for distribution of comment data to be restricted. 85 A Covert Resource Record, as described in [I-D.krecicki-dns-covert], 86 could be used for the storage of private text information within zone 87 data itself. This data could be transferred from primary to 88 secondary servers when Covert semantics are supported, and but would 89 be concealed from normal DNS queries (except from specific trusted 90 DNS clients) and from secondary servers that do not signal their 91 support of Covert data transfer. 93 This document proposes the allocation of a new RR type NOTE from the 94 Covert-RR type range for this purpose. Comments that the operator 95 wishes to be stored and transferred with zone data can be encoded as 96 NOTE records. Traditional zone file comments, indicated by 97 semicolons, would still be ignored. 99 1.1. Definitions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 2. The NOTE RR Type 109 The NOTE RR is defined for all classes, with mnemonic NOTE and type 110 code (TBD). The RDATA and presentation formats are identical to 111 those of the TXT RR defined in [RFC1035], e.g: 113 $ORIGIN example.com. 114 joesbox 7200 IN A 192.0.2.42 115 7200 IN AAAA 2001:DB8:3F:B019::17 116 0 IN NOTE "Desktop system for Joe Smith, x7889" 118 The RR type code MUST be allocated from the Covert-RR type range, and 119 NOTE record data MUST be treated as Covert [I-D.krecicki-dns-covert]. 121 3. IANA Considerations 123 IANA is requested to allocate a DNS RR type number from the Covert-RR 124 type range for the NOTE RR type. 126 4. Security and Privacy Considerations 128 NOTE data should only be accessible via Covert DNS queries, because 129 zone file comments commonly include information that could be of use 130 to potential attackers. Failure to implement the restrictions 131 outlined in [I-D.krecicki-dns-covert] could allow leakage of 132 sensitive information. 134 5. Normative References 136 [I-D.krecicki-dns-covert] 137 Krecicki, W., Hunt, E., and D. Mahoney, "Domain Name 138 System (DNS) Resource Record types for transferring covert 139 information from primary to secondaries", draft-krecicki- 140 dns-covert-00 (work in progress), July 2019. 142 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 143 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 144 . 146 [RFC1035] Mockapetris, P., "Domain names - implementation and 147 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 148 November 1987, . 150 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 151 Requirement Levels", BCP 14, RFC 2119, 152 DOI 10.17487/RFC2119, March 1997, 153 . 155 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 156 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 157 May 2017, . 159 Authors' Addresses 161 Evan Hunt 162 ISC 163 950 Charter St 164 Redwood City, CA 94063 165 US 167 Email: each@isc.org 169 Dan Mahoney 170 ISC 171 950 Charter St 172 Redwood City, CA 94063 173 US 175 Email: dmahoney@isc.org