idnits 2.17.1 draft-levine-dbound-dns-05.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 (4 October 2020) is 1297 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 4 October 2020 5 Expires: 7 April 2021 7 Publishing Organization Boundaries in the DNS 8 draft-levine-dbound-dns-05 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 7 April 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 6.2. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 6.3. SSL Certificates . . . . . . . . . . . . . . . . . . . . 8 60 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 8. ABNF syntax of bound records . . . . . . . . . . . . . . . . 9 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 10. Variations . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 65 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 67 12.2. Informative References . . . . . . . . . . . . . . . . . 11 68 Appendix A. Implementations . . . . . . . . . . . . . . . . . . 12 69 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 12 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 Often, the organization that manages a subtree in the DNS is 75 different from the one that manages the tree above it. Many 76 applications use information about such boundaries to implement 77 security policies. For example, web browsers use them to limit the 78 names where HTTP cookies can be set, and Secure Socket Layer (SSL) 79 certificate services use them to determine the party responsible for 80 the domain in a signing request. Mail security applications such as 81 Domain-based Messaging Authentication, Reporting and Conformance 82 (DMARC) use them to locate an organization's policy records in the 83 DNS. This specification is intended to provide boundaries usable for 84 DMARC, and possibly for other applications. 86 [[Please direct discussion of this draft to the dbound working group 87 at dbound@ietf.org.]] 89 2. Design Issues 91 Organization boundaries can be assigned on what one could call an 92 opt-in or opt-out basis. "Opt-in" means that two names are only 93 managed by the same organization if both actively assert that they 94 are related. "Opt-out" means that if there is any boundary 95 information at all for a DNS subtree, each name is assumed to be 96 under the same management as its parent unless there is a boundary 97 assertion to the contrary. This design describes an opt-out model. 99 Within the opt-out model, this design can adapt to a variety of 100 scenarios: 102 * Policies can be published by the domains themselves, or by a third 103 party. In the former case, each domain might assert its own 104 boundary policies. In the latter case, the third party makes the 105 assertions, which may or may not agree with what the domains 106 themselves would want. 108 * Multiple levels of delegation may be implemented, which is 109 different from irregular boundaries. For example, "us", "ny.us", 110 and "k12.ny.us" are irregular boundaries, because they're all 111 handled by the US top-level domain registry operator. 112 CentralNIC's "uk.com" would be a second level of delegation below 113 Verisign's com. 115 * Different sets of boundary rules can be published for different 116 applications. For example, the boundaries for SSL certificates 117 might be different from the boundaries for e-mail policies, or for 118 HTTP cookie setting policies. 120 In the lookup process below, the boundary point data is stored in the 121 DNS tree in a TXT record. The boundary is considered to be directly 122 below the name that the process returns, similarly to the names in 123 the [PSL]. If the process returned "abc.example", then 124 "foo.abc.example" and "bar.abc.example" are separated by the 125 boundary, but "foo.abc.example" and "bar.foo.abc.example" are not. 127 Each domain can publish its own policies within its own domain name 128 space, or a separate authority can publish a global set of policies 129 in a separate name space. 131 3. TXT record format 133 *._bound.k12.ny.us IN TXT "bound=1" "." "." "k12.ny.us" 135 The bound TXT record contains at least four text strings: a tag, two 136 keyword strings and a domain name. Strings beyond the fourth are 137 ignored. 139 The "bound=1" tag is to prevent confusion when a domain publishes a 140 wildcard such as *.example.com that could match a _bound name. 141 Records that do not start with the correct tag or that have fewer 142 than four strings are ignored. 144 Each keyword string is a series of comma separated keywords. If the 145 string would otherwise be empty, it is a single dot. 147 The first keyword string expresses policy options. It can include 148 NOLOWER which means that no lower level boundaries can exist below 149 this one, and NOBOUND which means that this name is not a boundary 150 for this application. 152 The second keyword string identifies the application(s) to which this 153 boundary applies. The strings DMARC, COOKIE, and CERT mean that the 154 applications are DMARC, HTTP cookies, and SSL certificate signing 155 respectively; a dot means it is a default for any applications not 156 otherwise specified. 158 The domain name is an absolute domain name, without the final dot. 159 The first label in the name may be "*" to indicate that the boundary 160 is at any name one label deeper than the rest of the name. That is, 161 the asterisk matches a single label, not the usual DNS sense of 162 matching any string of labels. 164 4. Lookup Process 166 In general, the lookup process takes as input a domain name and 167 application. It returns the name of the boundary node in the DNS. 168 This may be the domain itself or a parent. If there is no policy for 169 the domain the lookup fails; there are no defaults, and the DNS root 170 is not within any organization boundary. (Applications may apply 171 defaults of their own, but that is beyond the scope of this 172 specification.) 174 Names of boundary information records use the tag "_bound" which is 175 intended to be unique. 177 For the first lookup, the client extracts the top level component 178 (i.e., the rightmost label, as "label" is defined in Section 3 of 179 [RFC1034]) of the domain name from the subcomponents, if any, and 180 inserts the prefix in front of that component, after other components 181 if any. For example, if the domain to be checked is "example.com" or 182 "www.example.com", the client issues a DNS query for 183 "example._bound.com" or "www.example._bound.com". If the domain is a 184 dotless one such as "example", the client looks up "_bound.example". 186 If the boundary information is published by a third party, the client 187 appends the base name of the third party's domain to the name to be 188 looked up. Then the client does a DNS lookup of TXT records at that 189 name, which will return zero or more TXT records. A failure such as 190 NXDOMAIN is considered to return zero records. A lookup can return 191 multiple records if different applications have different boundaries 192 or policy options. The lookup process discards any records that do 193 not start with "bound=1" or contain less than four strings. 195 If a relevant policy record is returned, and the record does not 196 contain the NOBOUND keyword, the domain name in the record is the 197 policy boundary. A policy record is relevant if it lists the desired 198 application, or it is a default policy and there is no record with 199 the application's keyword. For example, a check for a boundary above 200 "example.com" would be issued at "example._bound.com", and the 201 expected TXT record could be "bound=1 . . com". 203 If there are no boundaries at all in a TLD, the policy record 204 contains "bound=1" "." "." "." indicating the root. For example, if 205 all subdomains of the "example" top-level domain (TLD) are under the 206 same management as the TLD itself, checks for "_bound.example" or 207 "www._bound.example" would return "bound=1" "." "." ".". 209 If the relevant record has the NOLOWER keyword set, the process 210 stops. Otherwise, the client inserts the prefix tag into the name 211 just below (i.e., to the left of) the name at the largest matching 212 boundary indicated in the lookup result, and repeats the lookup. For 213 example: 215 * When evaluating "www.foo.example.com", the first query would be to 216 "www.foo.example._bound.com". If the reply to this is "bound=1 . 217 . com", then the second query would be to 218 "www.foo._bound.example.com". 220 * When evaluating "www.example.ny.us", the first query would be to 221 "www.example.ny._bound.us". If the reply to this is "bound=1" "." 222 "." "us", the next lookup would be to "www.example._bound.ny.us". 223 If it returned "bound=1 "." "." "ny.us", the third lookup would be 224 to "www._bound.foo.ny.us". 226 This process repeats until a DNS lookup returns a relevant record 227 with the NOLOWER keyword, or a lookup returns no relevant records, at 228 which point the boundary is the domain name in the last retrieved 229 relevant record. 231 If an otherwise relevant record has the NOBOUND keyword, the process 232 continues if the NOLOWER keyword is not present, but there is no 233 boundary at the name with the NOBOUND keyword. These NOBOUND keyword 234 enables a name in the hierarchy to be a boundary for some 235 applications but not for others. 237 If the domain name in a boundary record starts with a *, e.g., 238 "*.example", the client replaces the * with the corresponding element 239 of the domain being matched. If the domain were "www.test.example", 240 the boundary record domain would be treated as though it were 241 "test.example". 243 5. DNS Records 245 The publishing entity uses wildcards and prefixed names that parallel 246 the regular names under a TLD to cover the domain's name space. 248 If there is a boundary at a given name, an entry in the TLD record 249 covers the names below it. For example, if there is a boundary at 250 ".TEST", a suitable record would be: 252 *._bound.test IN TXT "bound= "." "." "test" 254 If the boundary is above the TEST domain, i.e., TEST is under the 255 same management as FOO.TEST, the record would indicate no boundaries, 256 and an additional non-wildcard record is needed to cover TEST itself: 258 *._bound.test IN TXT "bound=1 "." "." "." 259 _bound.test IN TXT "bound=1 "." "." "." 261 In domains with irregular policy boundaries, multiple records in the 262 record describe the boundary points. For example, in the US (United 263 States) TLD, there are legacy domains under XX.US where XX is a two- 264 letter state abbreviation, and there are some further points such as 265 "k12" for schools within a state, with a boundary such as such as 266 "k12.ny.us". A suitable set of of records can cover this structure. 267 The closest encloser rule in RFC 4592 [RFC4592] makes the wildcards 268 match the appropriate names. 270 *._bound.us IN TXT "bound=1 "." "." "us" 271 *._bound.ny.us IN TXT "bound=1 "." "." "ny.us" 272 *._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. Its syntax would be the same as a TXT record, a 422 series of text strings, but without the initial tag field. They 423 would still need to be in a separate subtree identified by _bound 424 labels so that the wildcard name coverage would work. 426 If third parties want to publish boundary information, they can do it 427 in their own subtree of the DNS. For example, if policy.example were 428 publishing boundary information about boundaries, the records for the 429 test domain described above would be: 431 *._bound.test.policy.exaple IN TXT "bound=1" "." "." "." 432 _bound.test.policy.example IN TXT "bound=1" "." "." "." 434 11. IANA considerations 436 IANA is requested to add this entry to the "Underscored and Globally 437 Scoped DNS Node Names" Registry. 439 +=========+============+=================+ 440 | RR Type | _NODE NAME | Reference | 441 +=========+============+=================+ 442 | TXT | _bound | (this document) | 443 +---------+------------+-----------------+ 445 Table 1 447 This document requests that IANA create a registry of dbound Flag 448 keywords. Its registration policy is IETF Review. Its initial 449 contents are as follows. [[NOTE: new flags are likely to change the 450 lookup algorithm]] 451 +=========+=================+==========================+ 452 | Keyword | Reference | Description | 453 +=========+=================+==========================+ 454 | NOLOWER | (this document) | No lower level policies | 455 +---------+-----------------+--------------------------+ 456 | NOBOUND | (this document) | No boundary at this name | 457 +---------+-----------------+--------------------------+ 459 Table 2: BOUND Flag Keywords Initial Values 461 This document requests that IANA create a registry of BOUND 462 Application keywords. Its registration policy is First Come First 463 Served. Its initial contents are as follows. [[Note: New 464 applications don't affect the lookup process, and shouldn't affect 465 existing applications.]] 467 +=========+=================+===========================+ 468 | Value | Reference | Description | 469 +=========+=================+===========================+ 470 | . (Any) | (this document) | Any application without a | 471 | | | specific boundary record | 472 +---------+-----------------+---------------------------+ 473 | DMARC | (this document) | DMARC organizational | 474 | | | domains | 475 +---------+-----------------+---------------------------+ 476 | COOKIE | (this document) | HTTP cookies | 477 +---------+-----------------+---------------------------+ 478 | CERT | (this document) | Owner of certificate | 479 | | | requests | 480 +---------+-----------------+---------------------------+ 482 Table 3: BOUND Applications Initial Values 484 12. References 486 12.1. Normative References 488 [RFC1034] Mockapetris, P.V., "Domain names - concepts and 489 facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, 490 November 1987, . 492 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 493 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 494 . 496 12.2. Informative References 498 [PSL] Mozilla Foundation, "Public Suffix List", November 2015. 500 Appendix A. Implementations 502 A sample python implementation is available at 503 https://github.com/jrlevine/bound. It includes a library routine to 504 find the boundaries for a domain name, and a script to translate the 505 Mozilla PSL [PSL] into the DNS format. For testing, a copy of the 506 translated PSL is online at bound.services.net. 508 Appendix B. Change Log 510 *NOTE TO RFC EDITOR: This section may be removed upon publication of 511 this document as an RFC.* 513 04 to -05 Editorial changes, add implmentation appendix 515 03 to -04 Make TXT fields separate strings, add shadow records, 516 update ABND 518 02 to -03 Add wildcard labels like in the PSL. 520 01 to -02 Make TXT record the proposal, new RR as alternative. 522 -00 to -01 Editorial changes to limit standard use to DMARC. 524 non-WG to -00 Add NOBOUND record to make wildcard matches do the 525 right thing 527 Rename to match WG name 529 Author's Address 531 John Levine 532 Taughannock Networks 534 Email: standards@taugh.com 535 URI: https://jl.ly