idnits 2.17.1 draft-dickson-dnsop-glueless-00.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 abstract seems to contain references ([I-D.dickson-dnsop-ds-hack]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (16 September 2021) is 946 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-dickson-dnsop-ds-hack-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Dickson 3 Internet-Draft GoDaddy 4 Intended status: Informational 16 September 2021 5 Expires: 20 March 2022 7 Operating a Glueless DNS Authority Server 8 draft-dickson-dnsop-glueless-00 10 Abstract 12 This Internet Draft proposes a Best Current Practice for protecting 13 authority servers against MITM and poisoning attacks, using a domain 14 naming strategy to not require glue A/AAAA records and use of DNSSEC. 16 This BCP assumes the use of validating resolvers, which should 17 already be a BCP itself. 19 MITM and poisoning attacks should only be effective/possible against 20 unsigned domains. 22 However, until all domains are signed, this guidance is relevant, in 23 that it can limit the attack surface of unsigned domains. 25 This guidance should be combined with [I-D.dickson-dnsop-ds-hack] 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 20 March 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 62 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . 3 64 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 68 9. Informative References . . . . . . . . . . . . . . . . . . . 6 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 DNS Security extensions (DNSSEC) are additions to the DNS protocol 75 which provide data integrity and authenticity protections, but do not 76 provide privacy. 78 2. Conventions and Definitions 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 82 "OPTIONAL" in this document are to be interpreted as described in BCP 83 14 [RFC2119] [RFC8174] when, and only when, they appear in all 84 capitals, as shown here. 86 3. Background 88 Use of DNSSEC requires upgrades to software for authorative servers, 89 resolvers, and optionally clients, in order to benefit from these 90 protections. It also requires that DNS operators actually sign their 91 zones. 93 When a given zone is unsigned, those protections to the zone contents 94 are not available. 96 Any unsigned zone is trivially able to be altered by an on-path 97 attacker. 99 An off-path attacker is limited to use of cache poisoning attacks. 101 However, some class of cache poisoning attacks target unsigned 102 delegation data. These records consist of the necessary NS records, 103 and when necessary, "glue" records for IP address corresponding to 104 these NS records. 106 The impact to successful cache poisoning of delegation records is 107 that the attacker may substitute their own name servers for the 108 legitimate name server. In other words, the attacker is able to 109 promote itself to being effectively on-path, and trivially modify 110 unsigned domain results. 112 4. Proposed Solutions 114 There are two delegation record types that require protection against 115 off-path attackers, for unsigned domains. 117 For protecting NS records used in delegations, there is a new 118 proposal for use of a new DS record. See [I-D.dickson-dnsop-ds-hack] 119 for details. 121 The present draft addresses the "glue" records, by recommending 122 methods to make them unnecessary. If there is no delegation glue 123 data, an attacker cannot poison that data. The resolver cache would 124 contain only authoritative data, which cannot be pre-empted by such 125 poisoning attacks. 127 5. Recommendations 129 The following practice is RECOMMENDED for unsigned zones: 131 * Do not use in-bailiwick name server names for unsigned zones. 133 * Use out-of-zone names for the name servers for unsigned zones 135 Example: 137 Do NOT do the following (delegations requiring glue): 138 unsigned-zone.example NS ns1.unsigned-zone.example 139 unsigned-zone.example NS ns2.unsigned-zone.example 140 // glue 141 ns1.unsigned-zone.example A (IP address) 142 ns1.unsigned-zone.example AAAA (IP address) 143 ns2.unsigned-zone.example A (IP address) 144 ns2.unsigned-zone.example AAAA (IP address) 146 Instead, do the following (glueless delegations): 147 unsigned-zone.example NS ns1.nameserver-signed-zone.example 148 unsigned-zone.example NS ns2.nameserver-signed-zone.example 149 // 150 // Delegation to signed zone containing name server names 151 nameserver-signed-zone.example NS ns1.nameserver-signed-zone.example 152 nameserver-signed-zone.example NS ns2.nameserver-signed-zone.example 153 nameserver-signed-zone.example DS (DS record data) 154 // glue records for this delegation 155 ns1.nameserver-signed-zone.example A (IP address) 156 ns1.nameserver-signed-zone.example A (IP address) 157 ns2.nameserver-signed-zone.example AAAA (IP address) 158 ns2.nameserver-signed-zone.example AAAA (IP address) 160 The following practice is RECOMMENDED (for signed name server name 161 zones, i.e. large operators' zones): 163 * For name server name zones (zones containing data for name 164 servers), use dedicated name server names for the zone itself 166 * Consider use of another zone for the dedicated name server names, 167 to make the name server name zone itself fully glueless 169 * For this additional zone, also consider using a different name 170 server _name_ for its delegation's exclusive use 172 * Decoupling the respective NS names, ensures changes and updates to 173 the zone that uses glue, don't affect any other zones 175 * Depending on parent zone policy (e.g. TLD database policy), 176 renaming or renumbering name servers may affect delegations using 177 them (NS entries) 179 * A single zone with non-reused NS names guarantees side effects of 180 this sort are not possible 182 * Additional lookups are required on the initial reference to any NS 183 in the main glueless zone 185 * Subsequent (new) queries for the IP addresses of glueless name 186 servers only require single queries 188 Example: 190 Entries in the example TLD 191 // 192 // Same unsigned zone uses the same name servers 193 // However, the name server is in its own glueless zone 194 unsigned-zone.example NS ns1.nameserver-signed-zone.example 195 unsigned-zone.example NS ns2.nameserver-signed-zone.example 196 // 197 nameserver-signed-zone.example NS ns1.separate-zone.example 198 nameserver-signed-zone.example NS ns2.separate-zone.example 199 nameserver-signed-zone.example DS (DS record data) 200 // 201 separate-zone.example NS special-ns1.separate-zone.example 202 separate-zone.example NS special-ns2.separate-zone.example 203 separate-zone.example DS (DS record data) 204 // glue for special-ns1 and -2 205 // special-ns1 and -2 are used only for/by separate-zone 206 special-ns1.separate-zone.example A (IP address) 207 special-ns1.separate-zone.example AAAA (IP address) 208 special-ns2.separate-zone.example A (IP address) 209 special-ns2.separate-zone.example AAAA (IP address) 211 Zone file for nameserver-signed-zone: 212 nameserver-signed-zone.example SOA (soa record data) 213 // glueless NS are used 214 nameserver-signed-zone.example NS ns1.separate-zone.example 215 nameserver-signed-zone.example NS ns2.separate-zone.example 216 // actual glueless address records for "real" name server names 217 ns1.nameserver-signed-zone.example A (IP address) 218 ns1.nameserver-signed-zone.example AAAA (IP address) 219 ns2.nameserver-signed-zone.example A (IP address) 220 ns2.nameserver-signed-zone.example AAAA (IP address) 221 // etc etc etc 223 Zone file for separate-zone: 224 separate-zone.example SOA (soa record data) 225 // This is the only non-glueless NS in use 226 // NB: matches glue in parent 227 separate-zone.example NS special-ns1.separate-zone.example 228 separate-zone.example NS special-ns2.separate-zone.example 229 special-ns1.separate-zone.example A (IP address) 230 special-ns1.separate-zone.example AAAA (IP address) 231 special-ns2.separate-zone.example A (IP address) 232 special-ns2.separate-zone.example AAAA (IP address) 233 // actual address records for "real" name server name 234 // (only used by nameserver-signed-zone) 235 ns1.separate-zone.example A (IP address) 236 ns1.separate-zone.example AAAA (IP address) 237 ns2.separate-zone.example A (IP address) 238 ns2.separate-zone.example AAAA (IP address) 240 6. Security Considerations 242 This guidance is not a substitute for use of DNSSEC for DNS domains. 244 This guidance is useful in preventing off-path attackers from 245 poisoning DNS cache entries necessary for delegations. 247 However, an on-path attacker is still able to manipulate DNS 248 responses sent over UDP or unencrypted TCP. 250 Use of an encrypted transport is one potential method of preventing 251 MITM attacks (i.e. DNS over TLS from resolver to authoritative 252 server, aka ADoT), but this is still less secure than use of DNSSEC. 254 7. IANA Considerations 256 This document has no IANA actions. 258 8. Normative References 260 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 261 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 262 May 2017, . 264 9. Informative References 266 [I-D.dickson-dnsop-ds-hack] 267 Dickson, B., "DS Algorithms for Securing NS and Glue", 268 Work in Progress, Internet-Draft, draft-dickson-dnsop-ds- 269 hack-00, 11 August 2021, 270 . 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, 275 DOI 10.17487/RFC2119, March 1997, 276 . 278 Appendix A. Acknowledgments 280 Thanks to everyone who helped create the tools that let everyone use 281 Markdown to create Internet Drafts, and the RFC Editor for xml2rfc. 283 Thanks to Dan York for his Tutorial on using Markdown (specifically 284 mmark) for writing IETF drafts. 286 Thanks to YOUR NAME HERE for contributions, reviews, etc. 288 Author's Address 290 Brian Dickson 291 GoDaddy 293 Email: brian.peter.dickson@gmail.com