idnits 2.17.1 draft-dcrocker-dns-perimeter-01.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 too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 11, 2019) is 1778 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-levine-dbound-dns-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Crocker 3 Internet-Draft Brandenburg InternetWorking 4 Intended status: Informational T. Adams 5 Expires: December 13, 2019 Proofpoint 6 June 11, 2019 8 DNS Perimeter Overlay 9 draft-dcrocker-dns-perimeter-01 11 Abstract 13 The Domain Name System (DNS) naming syntax provides no meta-data for 14 indicating administrative transitions through the hierarchy. For 15 example, it does not distinguish the higher-level portions that 16 operate as public registries, versus those that operate as private 17 organizations. This specification creates a basic overlay mechanism 18 for defining a logical Perimeter between administrative entities 19 through the naming hierarchy. The mechanism can then be applied for 20 a variety of independent administrative indications. 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 December 13, 2019. 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 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Perimeter Overlay Overview . . . . . . . . . . . . . . . . . 5 59 4. DNS Perimeter Overlay Syntax . . . . . . . . . . . . . . . . 6 60 4.1. Perimeter Branch Indication . . . . . . . . . . . . . . . 6 61 4.2. Perimeter TXT RR . . . . . . . . . . . . . . . . . . . . 7 62 4.3. Syntax ExampleS . . . . . . . . . . . . . . . . . . . . . 8 63 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.1. End/Begin Interaction . . . . . . . . . . . . . . . . . . 9 65 5.2. Schema/Schema Interaction . . . . . . . . . . . . . . . . 9 66 6. Sample Overlay Templates . . . . . . . . . . . . . . . . . . 9 67 6.1. Default/Override 'Convenience' Overlay . . . . . . . . . 10 68 6.2. Master/Addition 'Control' Overlay . . . . . . . . . . . . 10 69 6.3. Vendor/Customer Overlay . . . . . . . . . . . . . . . . . 11 70 6.4. Organizational Alias . . . . . . . . . . . . . . . . . . 11 71 7. Propogating 'Begin' Location for Search Efficiency . . . . . 11 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 8.1. _perim Registration in DNS Underscore Global Scoped 74 Entry Registry . . . . . . . . . . . . . . . . . . . . . 13 75 8.2. DNS Perimeter Overlay Registry . . . . . . . . . . . . . 13 76 8.3. Suffix Entry in DNS Perimeter Overlay Registry . . . . . 14 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 10.1. References - Normative . . . . . . . . . . . . . . . . . 15 80 10.2. References - Informative . . . . . . . . . . . . . . . . 16 81 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 82 Appendix B. DNS Suffix Perimeter . . . . . . . . . . . . . . . . 17 83 B.1. IANA DNS Suffix Registration . . . . . . . . . . . . . . 18 84 B.2. Suffix Perimeter TXT Syntax . . . . . . . . . . . . . . . 18 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 Although some administrative structure can be inferred for the Domain 90 Name System (DNS), there is no formalized syntax that distinguishes 91 between the sequence of names in its referenced hierarchy. It does 92 not mark any differentiating characteristics, such as transitions 93 across administrative perimeters, as the sequence is followed. For 94 example, it does not mark a change in administrative authority for 95 subordinate names. A common example of needing such differentiation 96 is to indicate what part of a name belongs to a 'public' registry and 97 what part belongs to a private registrant within that registry. 99 This specification defines a mechanism for marking perimeters in 100 domain names, thereby permitting creation of logical overlays to the 101 DNS. Various types of administrative distinctions could be useful. 102 To facilitate creation of multiple, logical overlays, this 103 specification only defines a basic, extensible mechanism for marking 104 the presence of a Perimeter between administrations, and indicating 105 where the semantics of the Perimeter are defined. 107 As a detailed example and to satisfy a real-world need, an overlay 108 that emulates the established Public Suffix List ([PubSuff], 109 [PubSuff-SSAC]) is provided in Appendix B. 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in 114 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 2. History 119 A number of Internet functions seek to discern a 'base' portion in a 120 domain name, such as the basic organizational name like example.com, 121 from a longer name, like marketing.west.example.com. An approach to 122 accomplishing this is to distinguish the part that belongs to 123 "public" registries, and consider the next node name below that as 124 the base name. 126 The Public Suffix List has been used to satisfy this requirement. It 127 has two kinds of domain names. One is for these 'public' names that 128 operate through ICANN coordination. The other is 'private' which 129 serves as a naming base in some cases [PubSuff], [PubSuff-SSAC]. The 130 list is maintained as an independent effort producing a standalone 131 document, with all of the challenges involved in such an operation. 132 Entries are manually registered, which requires vetting of the source 133 and on-going validation. Entries can be for a single name or can use 134 a wildcard notation, to cover all names below the one that is 135 registered. It is also possible to enter a name declared to be an 136 exception to the wildcard cover. In keeping with the move towards 137 support of non-ASCII names, entries are in UTF-8. 139 For 2015-2016, IETF's DBOUND working group explored possible DNS 140 enhancements that would permit embedded information to support uses 141 such as the Public Suffix List. The effort ultimately was 142 unsuccessful. Several drafts were used as input to the working group 143 discussions [DBOUNDwg]. 145 NOTE: _The following summaries are intentionally terse and 146 simplified. Suggestions for superior language that 147 remains terse are eagerly sought. /dcrocker_ 149 Two were considerations of underlying issues: 151 DABprob: _"DBOUND: DNS Administrative Boundaries Problem Statement"_ 152 offers a "Problem Statement" and offered an extensive list of 153 possible uses [DABprob]. 155 DNRcon: _"Concepts for Domain Name Relationships"_ explores the 156 general topic of "relationships" between different domain 157 names. It considers structural choices, such as within the 158 same naming hierarchy, versus across separate branches. It 159 also considers types of relationships, such as public vs. 160 private. Some use cases are considered, as are some solution 161 considerations [DNRcon]. 163 The proffered specifications were: 165 ODuse: _"Organizational Domains and Use Policies for Domain Names"_ 166 proposes "an extensible system in which domain name policies 167 can be discovered at various levels in the DNS tree." A 168 policy record is stored under an underscored node name in a 169 TXT record. The record can indicate that the current node is 170 an organization name or that the name one level down is. 171 Wildcards are permitted, to cover sub-domains, indicating a 172 limit to the number of levels down. Usage policies are 173 marked as allowed or not allowed. Initial types of policies 174 were httpcookie and all (to indicate a default.) There is a 175 mechanism for using URIs to retrieve parameters.[ODuse] 177 OBD: _"Publishing Organization Boundaries in the DNS"_ offers a 178 specification "to publish in the DNS the boundaries between 179 organizations that can be adapted to various policy models". 180 Policies are expressed within a 16-bit bit-masked field. A 181 demarcation point is indicated by a published record above 182 the point, using a new DBOUND RR. The record can indicate 183 that there are no boundaries lower than this name. The 184 search algorithm is fully specified for all uses. It also 185 indicates that "[d]ifferent sets of boundary rules can be 186 published for different applications." The applicable 187 application of a boundary is indicated by a numeric value in 188 the record [OBD]. 190 ODUP: _"Resource Record for DNS Administrative Boundaries"_ 191 specifies a method for "judging domain name administrative 192 boundaries" and considers the records within a boundary to be 193 related and those across a boundary to be unrelated. The 194 specification defines a different DBOUND RR, from that of 195 [OBD]. If supports assorted flags plus an "Anchor Name/Name 196 Collection" field. The Anchor Name usage "build a connection 197 between the owner name and the anchor name which is a FQDN", 198 where"owner name" is defined as "some names' anchor name" in 199 a different DBOUND RR. The Name Collection usage lists 200 "names which are supposed to share the same DNS boundaries 201 under the same anchor name" [ODUP]. 203 SOPA: _"Asserting DNS Administrative Boundaries Within DNS Zones"_ 204 defines "...a way to assert that two domains lie in the same 205 policy realm..." or that they do not [SOPA]. 207 In general terms, it's important for any effort in this space to 208 carefully consider the guidance in both [RFC5507] and [RFC6950]. Of 209 particular concern to the current draft are the caveats highlighted 210 in Section 3.3.1 of [RFC6950], about synchronization, authorization 211 and delegation. 213 3. Perimeter Overlay Overview 215 A Domain Name Perimeter (DNS Perimeter) distinguishes a logical 216 separation, occurring between two adjacent nodes in the DNS 217 hierarchy. The name that is lower in the hierarchy marks the 218 beginning of its portion (identified by "BEGIN"), and the name higher 219 marks the end of its portion (identified by the term "END"). As 220 such, a Perimeter is the interface between segments along a domain 221 name branch, for which there can be different administrative 222 authorities and to which different policies can be applied. 224 Because the DNS does not permit associating information with the 225 graph connector 'between' names, information about a Perimeter needs 226 to be associated with one or both of the nodes adjacent to the 227 Perimeter. One possible advantage of this requirement is permitting 228 flexibility in the operational management of marking a Perimeter. 229 The organization 'above' the Perimeter might have more or less 230 incentive to mark the Perimeter than the organization 'below' it. In 231 this way, the Perimeter can be marked by the organization with the 232 greater incentive (or by both organizations, depending on the use 233 case.) 235 Definition of a DNS Perimeter: 237 A logical demarcation between two, adjacent DNS nodes, where one 238 node is the parent of the other, and the child is part of a branch 239 spanning one or more subdomains. 241 The metadata that is associated with such a node name needs to 242 indicate: 244 Position: Whether this node name is at the 'end' of am administrative 245 sub-hierarchy, before a Perimeter transition -- and 246 therefore the final node name 'above' the Perimeter; 247 whether it 'begin's a portion of administrative sub- 248 hierarchy, immediately after a Perimeter transition; or 249 whether it is a node name that is an internal 'part' of a 250 sub-hierarchy. 252 The 'part' construct might be useful for defining a place 253 to hold parametric detail specific to that node within the 254 hierarchy. It might also be useful to hold a pointer to 255 the 'begin' node name. 257 Schema: The registered name of the perimeter definition. The 258 Schema name identifies the semantic discipline for the 259 record containing the reference. This permits multiple 260 Schemas to share the same perimeter. 262 Parameters: Any schema-specific information required by the schema 263 definition. 265 Note: DNS Perimeter Overlay uses a TXT RRset to an _underscored node 266 name (_perim). This constrains queries for TXT records to only 267 Perimeter records. Still, a query to a Perimeter Overlay node 268 will return all of the TXT records stored there, and there might 269 be multiple 'users' (schemas) using the same DNS node name. So, 270 the client will need to do a simple search of the returned TXT 271 RRs, for the one that is desired. It is expected that there 272 will never be a large number of such records; so the burden of 273 distinguishing among multiple records is expected to be small. 275 4. DNS Perimeter Overlay Syntax 277 A node that is immediately above or below a DNS Perimeter indicates 278 itself with TXT DNS RR, in an _underscore-labeled sub-branch under 279 that node [RFC8552]. 281 4.1. Perimeter Branch Indication 283 The scoped use of the Perimeter TXT RR is indicated with a 284 subordinate, leaf node name of: 286 "_perim." 288 The IANA registration information for the _perim DNS scoped attribute 289 name is in Section 8.1. 291 4.2. Perimeter TXT RR 293 A TXT RR that is used to indicate a Perimeter is composed of an 294 initial identifier, followed by three fields, as described in 295 Section 3. 297 The ABNF [RFC5234] for the Perimeter TXT RR is: 299 Perim TXT: "perim" sp Pos sp Schema [sp Params] 300 ; ISSUE: the 'perim' string is arguably redundant, given that the 301 ; _underscored node naming approach already defines this as a 302 ; perimeter record. 303 ; I encourage keeping it, so interpretation of the record can stand 304 ; on its own. /dcrocker 306 Pos: "begin" / "end" / "part" 307 ; begin = first in the perimeter hierarchy sub-sequence 308 ; part = within the hierarchy sub-sequence 309 ; end = last in the hierarchy sub-sequence 311 Schema: { Entry from DNS Perimeter Registry } 313 Params: Param *("," Param) 315 Param: attr [eq val] 317 attr: 1*alpha 318 ; what is a better choice than ? /dcrocker 320 eq: "=" 322 val: 1*alpha 323 ; what is a better choice than ? /dcrocker 325 Perimeter TXT RR ABNF 327 Schema is the registered name for a specific use of the DNS Perimeter 328 Overlay mechanism. The IANA registration information for the _perim 329 DNS scoped attribute name is in Section 8.2. 331 That is, a TXT record under _perim has a series of space-separated 332 fields: 334 1. Identifies this as a _perim TXT record. 336 2. Indicates whether the record 'begins' an administrative area, by 337 appearing as the first node after a Perimeter, or whether it 338 'ends' an administrative area, by appearing as the last node 339 before a Perimeter. 341 3. Indicates the controlling Schema. 343 4. Optional to the syntactic mechanism, this is a series of one or 344 more comma-separated (with no white space) parameters, as defined 345 by the particular Schema specification, where a parameter can be 346 a simple string or an attribute/value pair. 348 4.3. Syntax ExampleS 350 Therefore, an organization might indicate the top of its naming 351 hierarchy with: 353 _perim.company.pubregistry.example 354 / 355 TXT "perim begin suffix private" 357 Suffix BEGIN Example 359 while the parent registry for this organization's name might also 360 indicate the name above it is the bottom of the delegating 361 organization's naming branch: 363 _perim.pubregistry.example 364 / 365 TXT "perim end suffix public" 367 Public Suffix END Example 369 and a node within a private organization's branch might point to its 370 'organizational domain' that begins this private suffix: 372 _perim.dept.company.pubregistry.example 373 / 374 TXT "perim part suffix private od=company.pubregistry.example" 376 Suffix PART Example 378 5. Discussion 379 5.1. End/Begin Interaction 381 The occurrence of either a 'begin' or an 'end' _perim TXT resource 382 record defines the Perimeter, in terms of basic Perimeter existence. 383 The presence of both _perim TXT records both above and below the 384 Perimeter is redundant. 386 For this core mechanism, a 'begin' _perim TXT record MAY occur in a 387 top-level domain, immediately under the DNS root. It would, of 388 course, have no corresponding 'end' parameter "above" the Perimeter. 389 Beyond specification of the technical details, actual usage of a 390 Perimeter record for a name administered through a "public" registry 391 is a matter of registry policy and is, therefore, outside the scope 392 of this specification. 394 A particular Schema might define specific requirements or constraints 395 on the occurrence of its Perimeter records. The Schema might mandate 396 only one type of record. Or it might permit policy parameters that 397 could conflict. Such issues are entirely within the purview of the 398 Schema specification and are invisible to this core DNS Perimeters 399 Overlay mechanism. 401 5.2. Schema/Schema Interaction 403 For simplicity and commonality, the core DNS Perimeter Overlay 404 mechanism defers policy and usage detail up to the Schema 405 specifications that rely on that detail. 407 The semantics and extended syntax of a Perimeter are defined by a 408 specific, registered Schema that is referenced in a _perim TXT RR. 409 In terms of the core Perimeter Overlay mechanism, a Perimeter that 410 is defined by one Schema is invisible to other Schemas by default, 411 even if they share the same node. 413 However a Schema specification MAY define its own rules regarding 414 the occurrence of different Perimeter Schemas and/or the 415 relationship of this Schema to another. For example, one Schema's 416 Perimeter Overlay might create dependencies and interactions with 417 another Schema Perimeter Overlay. 419 6. Sample Overlay Templates 421 Here are some notional use cases, for abstract usage models using DNS 422 Perimeter Overlays. They are provided as basic discussions, rather 423 than detailed specifications, to serve both as simple examples and as 424 guidance for possible adaption to specific needs. Other models are 425 certainly plausible. 427 NOTE: This section might be appropriate to move into an independent 428 document, as a larger repertoire of examples is developed and 429 specified. As this document develops, suggestions for additional 430 samples is encouraged. /dcrocker 432 A Schema specification needs to make clear what operational and 433 policy models it is using, to distinguish it from other Schemas that 434 might seem similar. 436 CAVEAT: There is a basic (but easily-forgotten) reality that the 437 registry for a parent domain has ultimate control over the 438 descendant domains. All sorts of anomalies are possible (and 439 likely) when a descendant is a different organization, but 440 ultimately, that's the type of issue that isn't directly 441 discernible via DNS. Concern for such issues is internal to the 442 administration of that DNS node hierarchy. responsible 444 6.1. Default/Override 'Convenience' Overlay 446 An organization might want to have a Perimeter early in the DNS 447 hierarchy that defines a basic set of parameters and policies, as 448 defaults for names within the Perimeter. It might then permit nodes 449 under this to override any of these defaults. The default record, 450 therefore, serves as a convenience, to reduce the amount of detail 451 that needs to be provided at lower levels in the DNS hierarchy. 453 Specifying the details that can be provided as defaults is 454 straightforward. 456 The basic operational model is for the client to start with the full 457 DNS name, down to the lower level and then look up to the higher- 458 level 'base' name. There needs to be a simple, efficient means for 459 the client to determine what that 'base' name is, so that it can 460 deterministically query it for the default information. 462 6.2. Master/Addition 'Control' Overlay 464 An organization might want to have a Perimeter early in the DNS 465 hierarchy that defines a rigorous set of mandatory parameters and 466 policies. Within its administrative purview, these would be global 467 details, enforced for all subordinate names. 469 As for the Convenience model, the overlay specification here needs to 470 make clear what operational model applies. The remaining technical 471 details are the same as for the Convenience model. What differs is 472 the semantics of using the superior/subordinate overlay records. 474 Note that most of the operational details of the 'Control" model are 475 the same as the 'Convenience' model, although their semantics have a 476 basic difference. 478 6.3. Vendor/Customer Overlay 480 A vendor that services customers via subdomains under their corporate 481 domain might opt to publish DNS Perimeter declarations as clear 482 demarcations between their "enterprise" and "customer" nodes. The 483 Schema might define semantics that enable third parties to support 484 the customers, potentially applying different rules per customer 485 node. In this case, each "begin" _perim TXT RR associated with a 486 node will define the policies that apply to that customer, while the 487 "end" _perim DNS TXT will act as the demarcation line between the 488 customer(s) and the vendor. 490 6.4. Organizational Alias 492 There are various relationships that might exist between two domain 493 names in different DNS branches. One example is complete 494 equivalence. That is, the two names are aliases for the same 495 organizational unit. A DNS Perimeter Overlay Schema could support 496 this construct by having a Schema parameter that specifies a the 497 domain name of organizational alias. Each name could point to the 498 other. (The 'part' example in Section 4.3 demonstrates the simpler 499 case of merely pointing to a name earlier in the branch, but a Scheme 500 could define a similar construct that instead points to names in 501 other branches.) Concerns for authorization and accuracy would be 502 internal to the Schema. 504 7. Propogating 'Begin' Location for Search Efficiency 506 NOTE: This section is currently offered as a discussion, to consider 507 the plausibility of an approach at efficiently finding a 'begin' 508 record, given a name farther down its branch. /dcrocker 510 One concern for the pragmatics of DNS operation is being able to 511 easily populate records into a large number of sub-domains. Another 512 is producing a useful response for names that are not registered, 513 such as for communicating policies related to an organization's sub- 514 domains. In both cases, the information can be stored in a higher- 515 level name. 517 However it is one thing to list data in the DNS -- somewhere up the 518 branch of the hierarchy -- and quite another to find it, when its 519 location is not already known. 521 _Given a longer domain name, what is the process of finding the 522 shorter portion containing a _perim TXT 'begin' declaration?_ 524 In the worst case, a tree-walk is required, querying each, next- 525 higher portion of the DNS, or starting at the root and querying each 526 node down. For a name with many components, this can be expensive 527 and slow, while essentially creating a vector for a denial of service 528 attack. 530 A feature embedded in the basic DNS specification is the wildcard, as 531 defined in Section 4.3.3 of [RFC1034]. This permits server-side 532 configuration into a higher-level domain name and delivers the 533 information for queries to subordinate names. Unfortunately, this 534 feature cannot be used for records that are stored under a 535 specialized naming branch such as those using underscored scoping, 536 since they are in an adjacent branch under the name and cannot 537 propagate. 539 _So how can a user process that has a fully qualified domain name, 540 find Perimeter information from some upper level in the hierarchy, 541 such as the base "organizational domain", when the classic DNS 542 wildcard feature cannot be used?_ 544 In some cases, the queried name will exist and might have a 'part' 545 record to provide the information, or it might exist and not have the 546 information, or it might not exist. The latter two cases requires 547 some additional means for obtaining information about the containing 548 Perimeter. 550 Absent additional mechanism, finding a DNS Perimeter requires some 551 sort of tree walk, which has the problems cited above. Use of a 552 purpose-built RR -- rather than underscore-scoped naming -- would 553 permit employing wildcards, but new RRs continue to suffer deployment 554 and use barriers. 556 Having a tree-walk done offline and publishing a list is a 557 possibility. That is, publish a table that shows the entries which 558 were found by a background searching process. When there are 559 relatively few entries and the search space is relatively small and 560 the rate of change is relatively slow, this approach can be useful. 561 However it requires consulting an external table and requires an 562 effort to maintain it. 564 Another approach is use of the DNS Additional section in the server 565 response: 567 Query for a Perimeter node; the server will return would include 568 the associated Perimeter BEGIN record from earlier in the 569 hierarchy, if the queried node is within that hierarchy -- that 570 is, is above the actual or virtual END record. (As for any 571 information supplied through the Additional section, the 572 responding server will need to be modified to provide this 573 enhanced information for specific kinds of queries.) 575 It might be reasonable to constrain this behavior only to a Perimeter 576 record that requests it, by adding a wildcard construct to the basic 577 Perimeter BEGIN syntax. 579 A Perimeter-aware client -- or recursive server -- could cache these 580 results, building an incremental portion of the overall table for 581 this type of Perimeter. 583 8. IANA Considerations 585 8.1. _perim Registration in DNS Underscore Global Scoped Entry Registry 587 The following entry is to be added to the DNS Underscore Global 588 Scoped Entry Registry: 590 +---------+-------------+----------------------------+ 591 | RR Type | _NODE NAME | REFERENCE | 592 +---------+-------------+----------------------------+ 593 | TXT | _perim | {this document}, Section 4 | 594 +---------+-------------+----------------------------+ 596 Table 1: _perim Registration in Global Scoped Entry Registry 598 8.2. DNS Perimeter Overlay Registry 600 The DNS Perimeter Overlay Registry lists specific uses of the DNS 601 Perimeter Overlay mechanism. 603 The registration table for the DNS Perimeter Overlay Registry will 604 contain two columns: 606 +--------+-----------+ 607 | SCHEMA | REFERENCE | 608 +--------+-----------+ 609 +--------+-----------+ 611 Table 2: DNS Perimeter Overlay Registry Table 613 o This registry is to operate under the IANA rules for "Expert 614 Review" registration; see Section 8.2.1. 616 o The detail to be provided by a DNS Perimeter Overlay entry's 617 referenced Schema specification is defined in Section 4.2. 619 o The specification referenced in a DNS Perimeter Overlay 620 registration MUST contain values for all of the fields specified 621 in Section 4.2. 623 o Within the registry, each Schema name must be unique. 625 o The table is to be maintained with entries sorted by the Schema 626 name. 628 o The required Reference for an entry MUST have a stable resolution 629 to the organization controlling that registry entry. 631 8.2.1. Guidance for Expert Review 633 This section provides guidance for expert review of registration 634 requests in the DNS Perimeter Overlay Registry. 636 This review is solely to determine adequacy of a requested entry 637 in this Registry, and does not include review of other aspects of 638 the document specifying that entry. For example such a document 639 might also contain a definition of the resource record type that 640 is referenced by the requested entry. Any required review of that 641 definition is separate from the expert review required here. 643 The review is for the purposes of ensuring that: 645 o The details for creating the registry entry are sufficiently 646 clear, precise and complete 648 o The Schema name is unique in the table 650 For the purposes of this Expert Review, other matters of the 651 specification's technical quality, adequacy or the like are outside 652 of scope. 654 8.3. Suffix Entry in DNS Perimeter Overlay Registry 656 NOTE: As a formality, this section is in the IANA section for this 657 document. However it is expected that the Public Suffix use of 658 DNS Perimeter Overlay will be moved to a separate specification 659 document, before this document is published. /dcrocker 660 +--------+-----------------------------+ 661 | SCHEMA | REFERENCE | 662 +--------+-----------------------------+ 663 | suffix | {this document}, Appendix B | 664 +--------+-----------------------------+ 666 Table 3: DNS Perimeter Overlay Registry Table 668 9. Security Considerations 670 This memo defines a mechanism for signaling information about 671 administrative perimeters. The mechanism itself introduces no 672 security issues. However specific uses of the mechanism might define 673 transitions in authority that offer new attack surfaces. 675 o A basic opportunity for concern is authorization to make a 676 particular assertion, using a DNS Perimeter Overlay. The basic 677 mechanism defined here offers no means for validating an 678 assertion. So any detailed specification for a particular use 679 needs to consider the potential of unauthorized assertions. 681 o Conflicting Perimeter entries for adjacent 'begin' and 'end' 682 assertions could be problematic. That is, information in the 683 _perim TXT RR for the parent name might conflict with information 684 in the _perim TXT RR for the child. Consideration of such a 685 conflict is left to the individual Schema specifications that use 686 the DNS Perimeter Overlay mechanism. 688 10. References 690 10.1. References - Normative 692 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 693 STD 13, RFC 1034, November 1987. 695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 696 Requirement Levels", BCP 14, RFC 2119, March 1997. 698 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 699 Specifications: ABNF", RFC 5234, January 2008. 701 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 702 2119 Key Words", RFC 8162, May 2017. 704 [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource 705 Records through "Underscored" Naming of Attribute Leaves", 706 RFC 8552, ISSN 2070-1721, March 2019. 708 10.2. References - Informative 710 [DABprob] Sullivan, A., Hodges, J., and J. Levine, "DBOUND: DNS 711 Administrative Boundaries Problem Statement", I-D draft- 712 sullivan-dbound-problem-statement-02, August 2016. 714 [DBOUNDwg] 715 IETF, "Domain Boundaries (dbound)", 2016. 717 [DNRcon] Deccio, C. and J. Levine, "Concepts for Domain Name 718 Relationships", I-D draft-deccio-dbound-name- 719 relationships-00, July 2015. 721 [OBD] Levine, J., "Publishing Organization Boundaries in the 722 DNS", I-D draft-levine-dbound-dns-01, September 2016. 724 [ODUP] Yao, J., Kong, N., and X. Li, "Resource Record for DNS 725 Administrative Boundaries", I-D C. Deccio, January 2016. 727 [ODuse] Deccio, C., "Organizational Domains and Use Policies for 728 Domain Names", I-D draft-deccio-dbound-organizational- 729 domain-policy-03, July 2016. 731 [PubSuff] Foundation, M., "Public Suffix List", 732 URL https://publicsuffix.org. 734 [PubSuff-SSAC] 735 Committee, I. S. A. S. A., "SAC070: SSAC Advisory on the 736 Use of Static TLD / Suffix Lists", URL 737 https://www.icann.org/en/system/files/files/sac- 738 070-en.pdf, May 2015. 740 [PubSuffSyn] 741 Foundation, M., "Public Suffix List Format", 742 URL https://publicsuffix.org/list/. 744 [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design 745 Choices When Expanding the DNS", RFC 5507, April 2009. 747 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 748 "Architectural Considerations on Application Features in 749 the DNS", RFC 6950, October 2013. 751 [SOPA] Sullivan, A. and J. Hodges, "Asserting DNS Administrative 752 Boundaries Within DNS Zones", I-D draft-sullivan-domain- 753 policy-authority-02, February 2016. 755 [SubTLD] Pettersen, Y., "The Public Suffix Structure file format 756 and its use for Cookie domain validation", I-D draft- 757 pettersen-subtld-structure-10, February 2014. 759 Appendix A. Acknowledgements 761 Appendix B. DNS Suffix Perimeter 763 ISSUE: _Specification of Perimeter use to replicate Public Suffix 764 List functionality. This section needs careful review and 765 revision by the PSL community. _ /dcrocker 767 _It appears that there are a number of adjunct uses of Domain 768 Names that get merged with the PSL. These probably are 769 candidates for other Perimeter Overlay encodings. /d_ 771 ISSUE: _The basic usage mode for PSL information is for an 772 application that has a fully qualified domain name to 'find' 773 the portion that is public, as distinct from the remaining 774 portion that is assigned by a private registry. The 775 'finding' process is not facilitated by the DNS, which only 776 queries for an exact name, rather than doing "searching". 777 Worse, this impedes building a table by brute-force testing 778 of the tree._ 780 _So an open issue is the method for either real-time or 781 background use of PSL information through DNS Perimeter 782 Overlay. /dcrocker_ 784 The Public Suffix List describes itself as [PubSuff]: 786 "A "public suffix" is one under which Internet users can (or 787 historically could) directly register names." 789 An advisory report by the ICANN Security and Stability Advisory 790 Committee uses a definition of PSL from [SubTLD]: 792 "A domain under which multiple parties that are unaffiliated with 793 the owner of the Public Suffix domain may register subdomains." 795 The basic semantics of the list are quite simple, only marking the 796 Perimeter between the portion of a domain name -- it's suffix -- 797 administered by a public registry and the remaining portion of the 798 name administered by a registrant. Some uses of the list have more 799 elaborate semantics, but these really are value-added features beyond 800 the basic mechanism -- even though some are encoded in the published 801 list. The details of the Public Suffix list are not amenable to 802 algorithmic derivation, because the criteria for determining whether 803 a suffix is 'public' varies significantly from one DNS naming branch 804 to another. 806 The goal in defining a Public Suffix Perimeter within the DNS itself 807 is to permit the owner of a name at a Public Suffix Perimeter to mark 808 its presence directly, rather than having to go through an 809 independent registration service. Anyone can then discern the 810 Perimeter directly, without needing access to a separate list. 811 Further much, or all of, the compiled list can be developed by a 812 rigorous DNS tree walk, rather than by relying on additions and 813 deletions each being submitted to the Public Suffix registration 814 service. 816 A particular efficiency and convenience in this direct publication 817 method is that the public registry can have a single entry for the 818 'end' name in the public suffix and implicitly thereby mark all of 819 the children names as the 'begin' of the private part of the name. 821 NOTE: The details provided here are a bare minimum to define 822 Public Suffix Perimeters. As this specification is 823 reviewed by subject matter experts, it is expected that 824 the details will be enhanced. /dcrocker 826 B.1. IANA DNS Suffix Registration 828 The IANA registration information for the Suffix Perimeter entry is 829 at Section 8.3. 831 B.2. Suffix Perimeter TXT Syntax 833 This specification for DNS Suffix information, stored in a _perim TXT 834 record, is meant to approximate what is specified in [PubSuffSyn]. 835 Each DNS Perimeter Overlay Suffix Schema TXT RR serves as a 'rule' in 836 the Public Suffix table. Some accommodations have been made, to the 837 constraints of fitting this within a TXT value segment. 839 Given the variety of uses of information called "Public Suffix List", 840 there could reasonably be different specifications offered. Two 841 possibilities are listed here: 843 B.2.1. Core PSL 845 This provides a simple capability for marking a Perimeter, without 846 labeling their 'type'. 848 Perim Params: extra SP comment 850 extra: ["!"] *("*.") 851 ; ! = exception 852 ; * = wildcard for node name field(s), 853 ; creating prefix to current name. 855 comment: "//" *CHAR 857 'Core' DNS Suffix Params ABNF 859 A simple entry will have no parameters; the existence of the TXT 860 record defines the DNS node containing it as an entry in the Public 861 Suffix List. If wildcard fields are specified, they are added as a 862 prefix to the current node's name. An 'exception' indicator marks 863 this name as overriding a higher-level rule. 865 B.2.2. PubPrivPSL 867 This permits distinguishing between portions of the namespace that 868 are public and those, below this, that are private. In order to 869 prevent a private entry from claiming that it is public, a private 870 registry can declare that it is the lowest-level (final) public 871 registry 873 Perim Params: pubpriv extra SP comment 875 pubpriv: "pub" [", fin"] / "priv" 876 ; distinguish between public vs. private registry 877 ; public registry can indicate it is the final (lowest) one 879 extra: ["!"] *("*.") 880 ; ! = exception 881 ; * = wildcard for node name field(s), 882 ; creating prefix to current name. 884 comment: "//" *CHAR 886 'Public/Private' DNS Suffix Params ABNF 888 There can be layers of public registries and layers of private 889 registries, for a single, fully qualified domain name. This version 890 of the specification permits multiple boundaries; an explicit 891 indication of the type of registry is required. A simple entry will 892 have no parameters; the existence of the TXT record defines 893 the DNS node containing it as an entry in the Public Suffix List. If 894 wildcard fields are specified, they are added as a prefix to the 895 current node's name. An 'exception' indicator marks this name as 896 overriding a higher-level rule. 898 Authors' Addresses 900 D. Crocker 901 Brandenburg InternetWorking 902 675 Spruce Dr. 903 Sunnyvale, CA 94086 904 USA 906 Phone: +1.408.246.8253 907 Email: dcrocker@bbiw.net 908 URI: http://bbiw.net/ 910 T. Adams 911 Proofpoint 913 Email: tadams@proofpoint.com