idnits 2.17.1 draft-levine-dbound-dns-04.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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 307: '...y policy records MUST have records for...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 April 2020) is 1476 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. 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 J. Levine 3 Internet-Draft Taughannock Networks 4 Intended status: Informational 10 April 2020 5 Expires: 12 October 2020 7 Publishing Organization Boundaries in the DNS 8 draft-levine-dbound-dns-04 10 Abstract 12 The organization that manages a subtree in the DNS is often different 13 from the one that manages the tree above it. We describe an 14 architecture to publish in the DNS the boundaries between 15 organizations that can be adapted to various policy models and can be 16 queried with a small number of DNS lookups. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 12 October 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Design Issues . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. TXT record format . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Lookup Process . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. DNS Records . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 6. Application scenarios . . . . . . . . . . . . . . . . . . . . 7 57 6.1. DMARC . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 6.2. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 6.3. SSL Certificates . . . . . . . . . . . . . . . . . . . . 8 60 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 8. ABNF syntax of bound records . . . . . . . . . . . . . . . . 8 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 10. Variations . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 65 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 67 12.2. Informative References . . . . . . . . . . . . . . . . . 11 68 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 71 1. Introduction 73 Often, the organization that manages a subtree in the DNS is 74 different from the one that manages the tree above it. Many 75 applications use information about such boundaries to implement 76 security policies. For example, web browsers use them to limit the 77 names where HTTP cookies can be set, and Secure Socket Layer (SSL) 78 certificate services use them to determine the party responsible for 79 the domain in a signing request. Mail security applications such as 80 Domain-based Messaging Authentication, Reporting and Conformance 81 (DMARC) use them to locate an organization's policy records in the 82 DNS. This specification is intended to provide boundaries usable for 83 DMARC, and possibly for other applications. 85 [[Please direct discussion of this draft to the dbound working group 86 at dbound@ietf.org.]] 88 2. Design Issues 90 Organization boundaries can be assigned on what one could call an 91 opt-in or opt-out basis. "Opt-in" means that two names are only 92 managed by the same organization if both actively assert that they 93 are related. "Opt-out" means that if there is any boundary 94 information at all for a DNS subtree, each name is assumed to be 95 under the same management as its parent unless there is a boundary 96 assertion to the contrary. This design describes an opt-out model. 98 Within the opt-out model, this design can adapt to a variety of 99 scenarios: 101 * Policies can be published by the domains themselves, or by a third 102 party. In the former case, each domain might assert its own 103 boundary policies. In the latter case, the third party makes the 104 assertions, which may or may not agree with what the domains 105 themselves would want. 107 * Multiple levels of delegation may be implemented, which is 108 different from irregular boundaries. For example, "us", "ny.us", 109 and "k12.ny.us" are irregular boundaries, because they're all 110 handled by the US registry operator Neustar. CentralNIC's 111 "uk.com" would be a second level of delegation below Verisign's 112 com. 114 * Different sets of boundary rules can be published for different 115 applications. For example, the boundaries for SSL certificates 116 might be different from the boundaries for e-mail policies, or for 117 HTTP cookie setting policies. 119 In the lookup process below, the boundary point data is stored in the 120 DNS tree in a TXT record. The boundary is considered to be directly 121 below the name that the process returns, similarly to the names in 122 the [PSL]. If the process returned "abc.example", then 123 "foo.abc.example" and "bar.abc.example" are separated by the 124 boundary, but "foo.abc.example" and "bar.foo.abc.example" are not. 126 Each domain can publish its own policies within its own domain name 127 space, or a separate authority can publish a global set of policies 128 in a separate name space. 130 3. TXT record format 132 *._bound.k12.ny.us IN TXT "bound=1" "." "." "k12.ny.us" 134 The bound TXT record contains at least four text strings: a tag, two 135 keyword strings and a domain name. Strings beyond the fourth are 136 ignored. 138 The "bound=1" tag is to prevent confusion when a domain publishes a 139 wildcard such as *.example.com that could match a _bound name. 140 Records that do not start with the correct tag or that have fewer 141 than four strings are ignored. 143 Each keyword string is a series of comma separated keywords. If the 144 string would otherwise be empty, it is a single dot. 146 The first keyword string expresses policy options. It can include 147 NOLOWER which means that no lower level boundaries can exist below 148 this one, and NOBOUND which means that this name is not a boundary 149 for this application. 151 The second keyword string identifies the application(s) to which this 152 boundary applies. The strings DMARC, COOKIE, and CERT mean that the 153 applications re DMARC, HTTP cookies, and SSL certificate signing 154 respectively; a dot means it is a default for any applications not 155 otherwise specified. 157 The domain name is an absolute domain name, without the final dot. 158 The first label in the name may be "*" to indicate that the boundary 159 is at any name one label deeper than the rest of the name. That is, 160 the asterisk matches a single label, not the usual DNS sense of 161 matching any string of labels. 163 4. Lookup Process 165 In general, the lookup process takes as input a domain name and 166 application. It returns the name of the boundary node in the DNS. 167 This may be the domain itself or a parent. If there is no policy for 168 the domain the lookup fails; there are no defaults, and the DNS root 169 is not within any organization boundary. (Applications may apply 170 defaults of their own, but that is beyond the scope of this 171 specification.) 173 Names of boundary information records use the tag "_bound" which is 174 intended to be unique. 176 For the first lookup, the client extracts the top level component 177 (i.e., the rightmost label, as "label" is defined in Section 3 of 178 [RFC1034]) of the domain name from the subcomponents, if any, and 179 inserts the prefix in front of that component, after other components 180 if any. For example, if the domain to be checked is "example.com" or 181 "www.example.com", the client issues a DNS query for 182 "example._bound.com" or "www.example._bound.com". If the domain is a 183 dotless one such as "example", the client looks up "_bound.example". 185 If the boundary information is published by a third party, the client 186 appends the base name of the third party's domain to the name to be 187 looked up. Then the client does a DNS lookup of TXT records at that 188 name, which will return zero or more TXT records. A failure such as 189 NXDOMAIN is considered to return zero records. A lookup can return 190 multiple records if different applications have different boundaries 191 or policy options. The lookup process discards any records that do 192 not start with "bound=1" or contain less than four strings. 194 If a relevant policy record is returned, and the record does not 195 contain the NOBOUND keyword, the domain name in the record is the 196 policy boundary. A policy record is relevant if it lists the desired 197 application, or it is a default policy and there is no record with 198 the application's keyword. For example, a check for a boundary above 199 "example.com" would be issued at "example._bound.com", and the 200 expected TXT record could be "bound=1 . . com". 202 If there are no boundaries at all in a TLD, the policy record 203 contains "bound=1" "." "." "." indicating the root. For example, if 204 all subdomains of the "example" top-level domain (TLD) are under the 205 same management as the TLD itself, checks for "_bound.example" or 206 "www._bound.example" would return "bound=1" "." "." ".". 208 If the relevant record has the NOLOWER keyword set, the process 209 stops. Otherwise, the client inserts the prefix tag into the name 210 just below (i.e., to the left of) the name at the largest matching 211 boundary indicated in the lookup result, and repeats the lookup. For 212 example: 214 * When evaluating "www.foo.example.com", the first query would be to 215 "www.foo.example._bound.com". If the reply to this is "bound=1 . 216 . com", then the second query would be to 217 "www.foo._bound.example.com". 219 * When evaluating "www.example.ny.us", the first query would be to 220 "www.example.ny._bound.us". If the reply to this is "bound=1" "." 221 "." "us", the next lookup would be to "www.example._bound.ny.us". 222 If it returned "bound=1 "." "." "ny.us", the third lookup would be 223 to "www._bound.foo.ny.us". 225 This process repeats until a DNS lookup returns a relevant record 226 with the NOLOWER keyword, or a lookup returns no relevant records, at 227 which point the boundary is the domain name in the last retrieved 228 relevant record. 230 If an otherwise relevant record has the NOBOUND keyword, the process 231 continues if the NOLOWER keyword is not present, but there is no 232 boundary at the name with the NOBOUND keyword. These NOBOUND keyword 233 enables a name in the hierarchy to be a boundary for some 234 applications but not for others. 236 If the domain name in a boundary record starts with a *, e.g., 237 "*.example", the client replaces the * with the corresponding element 238 of the domain being matched. If the domain were "www.test.example", 239 the boundary record domain would be treated as though it were 240 "test.example". 242 5. DNS Records 244 The publishing entity uses wildcards and prefixed names that parallel 245 the regular names under a TLD to cover the domain's name space. 247 If there is a boundary at a given name, an entry in the TLD record 248 covers the names below it. For example, if there is a boundary at 249 ".TEST", a suitable record would be: 251 *._bound.test IN TXT "bound= "." "." "test" 253 If the boundary is above the TEST domain, i.e., TEST is under the 254 same management as FOO.TEST, the record would indicate no boundaries, 255 and an additional non-wildcard record is needed to cover TEST itself: 257 *._bound.test IN TXT "bound=1 "." "." "." 258 _bound.test IN TXT "bound=1 "." "." "." 260 In domains with irregular policy boundaries, multiple records in the 261 record describe the boundary points. For example, in the US (United 262 States) TLD, there are legacy domains under XX.US where XX is a two- 263 letter state abbreviation, and there are some further points such as 264 "k12" for schools within a state, with a boundary such as such as 265 "k12.ny.us". A suitable set of of records can cover this structure. 266 The closest encloser rule in RFC 4592 [RFC4592] makes the wildcards 267 match the appropriate names. 269 *._bound.us IN TXT "bound=1 "." "." "us" 270 *._bound.ny.us IN TXT "bound=1 "." "." "ny.us" 271 *._bound.k12.ny.us IN TXT "bound=1 "." "." "k12.ny.us" 273 In the usual case that only the boundary closest to the looked up 274 domain name is of interest, the publishing entity can publish 275 "shadow" wildcard records for lower level boundaries that are used 276 rather than the higher level records for names below those 277 boundaries: 279 *.ny._bound.us IN TXT "bound=1 "." "." "ny.us" 280 *.k12.ny._bound.us IN TXT "bound=1 "." "." "k12.ny.us" 282 [TBD: What if anything to put at the shadow point? Currently if you 283 look up "k12.ny._bound.us" you'll get nothing because it's an ENT. 284 Is that OK? If not should it point to ny.us or k12.ny.us? ] 286 In some cases, a domain may assert that every name below a given name 287 is a boundary, or that every name other than a specific set of 288 exceptions is a boundary. For example (adapted from the Mozilla PSL) 289 every name below kobe.jp is a boundary other than city.kobe.jp. This 290 could be expressed as: 292 *.kobe._bound.jp IN TXT "bound=1 . . *.kobe.jp" 293 city.kobe._bound.jp IN TXT "bound=1 NOBOUND . city.kobe.jp" 294 *.city.kobe._bound.jp IN TXT "bound=1 NOBOUND . city.kobe.jp" 296 For any set of policy boundaries in a tree of DNS names, a suitable 297 set of policy records can describe the boundaries, so a client can 298 find the boundary for any name in the tree with a single policy 299 lookup per level of delegation. 301 Since the delegation structure is unlikely to change frequently, long 302 time-to-live (TTL) values in the TXT records are appropriate. 304 If different applications have different boundaries or policy 305 options, the policy records for each application are put at the 306 appropriate names for the boundaries. Due to the way DNS wildcards 307 work, each name with any policy records MUST have records for all 308 policies, with the NOBOUND bit for policies for which the name is not 309 in fact a boundary. 311 6. Application scenarios 313 Here are some ways that DMARC and potentially other applications can 314 use BOUND data. 316 6.1. DMARC 318 If a DMARC lookup for the domain in a message's From: header fails, 319 the client would do a boundary check for the domain name using the 320 "DMARC" application. The organizational domain is the immediate 321 subdomain of the boundary domain. (Note that the boundary will 322 always be the one looked up or an ancestor.) 324 6.2. Cookies 326 If an http request attempts to set a cookie for a domain other than 327 the request's own domain, the client would do boundary check for a 328 "cookie" application for both the request's domain and the cookie 329 domain. If they are not separated by a boundary, the request is 330 allowed. 332 6.3. SSL Certificates 334 The client would do a boundary check for the domain name in a normal 335 certificate, or the name after the "*." in a wildcard certificate for 336 a "cert" application. If the boundary is above the name, the name is 337 allowed. 339 7. Discussion 341 The total number of DNS lookups is no more than the number of levels 342 of boundary delegation, plus one if the last boundary doesn't have 343 the NOLOWER keyword. That is unlikely to be more than 2 or 3 in 344 realistic scenarios, and depends on the number of boundaries, not the 345 number of components in the names that are looked up. With shadow 346 records, it will typically be one lookup that matches a shadow record 347 and a second to check below it that gets NXDOMAIN if the shadow 348 record doesn't contain NOLOWER. 350 Some domains have very irregular boundaries. This may require a 351 relatively large number of records to describe all the boundaries, 352 but it doesn't seem like a number that would challenge modern DNS 353 servers, or need unduly complex scripts to create them. A mechanical 354 translation of the boundary information the Mozilla PSL as of April 355 2020 creates about 16,000 records. 357 The wildcard lookup means that each time an application looks up the 358 boundaries for a hostname, the lookup results create DNS cache 359 entries that will not be reused other than for subsequent lookups for 360 the identical hostname. This might cause cache churn, but it seems 361 at worst no more than we already tolerate from DNSBL lookups. If the 362 boundary zone is signed, DNS caches should be able to syntheize some 363 answers from cached woldcards. 365 8. ABNF syntax of bound records 367 The syntax of bound records is something like this: 369 ; each token in BOUND is a separate string in the TXT record 371 BOUND = BTAG BFLAGS BKWDS DOMAIN 373 BTAG = %s"bound=1" 375 BFLAGS = ( BFLAG *("," BFLAG) ) / "." 377 BFLAG = s%"NOLOWER" / s%"NOBOUND" / MISCTOK 379 BKWDS = ( BKWD *("," BKWD) ) / "." 381 BKWD = s%"DMARC" / s%"COOKIE" / s%"CERT" / MISCTOK 383 ; miscellaneous tokens for future expansion 385 MISCTOK = `1*ALPHA 387 9. Security Considerations 389 The purpose of publishing organization boundaries is to provide 390 advice to third parties that wish to know whether two names are 391 managed by the same organization, allowing those names to be treated 392 "as the same" in some sense. Clients that rely on published 393 boundaries are outsourcing some part of their own security policy to 394 the publisher, so their own security depends on the publisher's 395 boundaries being accurate. 397 Although in some sense domains are always in control of their 398 subdomains, there are many situations in which parent domains are not 399 expected to influence subdomains. For example, second level domains 400 in global TLDs (gTLDs) operated by registries with contracts with the 401 Internet Corporation for Assigned Names and Numers (ICANN) Since 402 there is no technical bar to a parent publishing records that shadow 403 part or all of the boundary record namespace for delegated 404 subdomains, correct operation depends on the parent and subdomains 405 agreeing about who publishes what. 407 The DNS is subject to a variety of attacks. DBOUND records are 408 subject to the same ones as any other bit of the DNS, and the same 409 countermeasures, such as using DNSSEC, apply. 411 10. Variations 413 Some boundary schemes distinguish between public and private 414 subtrees. If that were useful, a PUBLIC flag keyword could indicate 415 that the subtrees below a boundary were public rather than the 416 default of private. 418 Since nothing but the boundary records should be published at names 419 with _bound components, one could get the same effect with a new 420 DBOUND RRTYPE, which would avoid the problem of confusion with other 421 TXT wildcards. 423 If third parties want to publish boundary information, they can do it 424 in their own subtree of the DNS. For example, if policy.example were 425 publishing boundary information about boundaries, the records for the 426 test domain described above would be: 428 *._bound.test.policy.exaple IN TXT "bound=1" "." "." "." 429 _bound.test.policy.example IN TXT "bound=1" "." "." "." 431 11. IANA considerations 433 IANA is requested to add this entry to the "Underscored and Globally 434 Scoped DNS Node Names" Registry. 436 +---------+------------+-----------------+ 437 | RR Type | _NODE NAME | Reference | 438 +=========+============+=================+ 439 | TXT | _bound | (this document) | 440 +---------+------------+-----------------+ 442 Table 1 444 This document requests that IANA create a registry of dbound Flag 445 keywords. Its registration policy is IETF Review. Its initial 446 contents are as follows. [[NOTE: new flags are likely to change the 447 lookup algorithm]] 449 +---------+-----------------+--------------------------+ 450 | Keyword | Reference | Description | 451 +=========+=================+==========================+ 452 | NOLOWER | (this document) | No lower level policies | 453 +---------+-----------------+--------------------------+ 454 | NOBOUND | (this document) | No boundary at this name | 455 +---------+-----------------+--------------------------+ 457 Table 2: BOUND Flag Keywords Initial Values 459 This document requests that IANA create a registry of BOUND 460 Application keywords. Its registration policy is First Come First 461 Served. Its initial contents are as follows. [[Note: New 462 applications don't affect the lookup process, and shouldn't affect 463 existing applications.]] 464 +---------+-----------------+---------------------------+ 465 | Value | Reference | Description | 466 +=========+=================+===========================+ 467 | . (Any) | (this document) | Any application without a | 468 | | | specific boundary record | 469 +---------+-----------------+---------------------------+ 470 | DMARC | (this document) | DMARC organizational | 471 | | | domains | 472 +---------+-----------------+---------------------------+ 473 | COOKIE | (this document) | HTTP cookies | 474 +---------+-----------------+---------------------------+ 475 | CERT | (this document) | Owner of certificate | 476 | | | requests | 477 +---------+-----------------+---------------------------+ 479 Table 3: BOUND Applications Initial Values 481 12. References 483 12.1. Normative References 485 [RFC1034] Mockapetris, P.V., "Domain names - concepts and 486 facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, 487 November 1987, . 489 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 490 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 491 . 493 12.2. Informative References 495 [PSL] Mozilla Foundation, "Public Suffix List", November 2015. 497 Appendix A. Change Log 499 *NOTE TO RFC EDITOR: This section may be removed upon publication of 500 this document as an RFC.* 502 03 to -04 Make TXT fields separate strings, add shadow records, 503 update ABND 505 02 to -03 Add wildcard labels like in the PSL. 507 01 to -02 Make TXT record the proposal, new RR as alternative. 509 -00 to -01 Editorial changes to limit standard use to DMARC. 511 non-WG to -00 Add NOBOUND record to make wildcard matches do the 512 right thing 514 Rename to match WG name 516 Author's Address 518 John Levine 519 Taughannock Networks 520 PO Box 727 521 Trumansburg 523 Email: standards@taugh.com 524 URI: http://jl.ly