idnits 2.17.1 draft-ietf-dmarc-psd-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 27, 2019) is 1728 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kitterman 3 Internet-Draft fTLD Registry Services 4 Intended status: Experimental July 27, 2019 5 Expires: January 28, 2020 7 DMARC (Domain-based Message Authentication, Reporting, and Conformance) 8 Extension For PSDs (Public Suffix Domains) 9 draft-ietf-dmarc-psd-05 11 Abstract 13 DMARC (Domain-based Message Authentication, Reporting, and 14 Conformance) is a scalable mechanism by which a mail-originating 15 organization can express domain-level policies and preferences for 16 message validation, disposition, and reporting, that a mail-receiving 17 organization can use to improve mail handling. DMARC policies can be 18 applied to individual domains or to all domains within an 19 organization. The design of DMARC precludes grouping policies for 20 domains based on policy published above the organizational level, 21 such as TLDs (Top Level Domains). Domains at this higher level of 22 the DNS tree (but not necessarily at the top of the DNS tree) can be 23 collectively referred to as Public Suffix Domains (PSDs). This 24 document describes an extension to DMARC to enable DMARC 25 functionality PSDs. 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 January 28, 2020. 44 Copyright Notice 46 Copyright (c) 2019 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 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 63 2.1. Conventions Used in This Document . . . . . . . . . . . . 5 64 2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 5 65 2.3. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.4. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 5 67 2.5. PSO Controlled Domain Names . . . . . . . . . . . . . . . 5 68 2.6. Non-existent Domains . . . . . . . . . . . . . . . . . . 5 69 3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 6 70 3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 6 71 3.2. Section 6.1 DMARC Policy Record . . . . . . . . . . . . . 6 72 3.3. Section 6.3 General Record Format . . . . . . . . . . . . 6 73 3.4. Section 6.5. Domain Owner Actions . . . . . . . . . . . 7 74 3.5. Section 6.6.3. Policy Discovery . . . . . . . . . . . . 7 75 3.6. Section 7. DMARC Feedback . . . . . . . . . . . . . . . 7 76 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 77 4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 8 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 6.1. Subdomain Policy Tag . . . . . . . . . . . . . . . . . . 9 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 83 7.2. Informative References . . . . . . . . . . . . . . . . . 10 84 Appendix A. The Experiment . . . . . . . . . . . . . . . . . . . 11 85 A.1. PSD DMARC Privacy Concern Mitigation . . . . . . . . . . 11 86 A.2. Non-Existent Subdomain Policy . . . . . . . . . . . . . . 12 87 Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 12 88 B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 12 89 B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 12 90 Appendix C. Implementation . . . . . . . . . . . . . . . . . . . 13 91 C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 13 92 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 95 1. Introduction 97 DMARC [RFC7489] provides a mechanism for publishing organizational 98 policy information to email receivers. DMARC allows policy to be 99 specified for both individual domains and for organizational domains 100 and their sub-domains within a single organization. For TLDs and 101 domains that exist between TLDs and organization level domains, 102 policy can only be published for the exact domain. No method is 103 available for such domains to express policy or receive feedback 104 reporting for sub-domains. This missing method allows for the abuse 105 of non-existent organizational-level domains and prevents 106 identification of domain abuse in email. 108 As an example, imagine a country code TLD (ccTLD) which has public 109 subdomains for government and commercial use (.gov.example and 110 .com.example). Within the .gov.example public suffix, use of DMARC 111 has been mandated and .gov.example has published its own DMARC 112 record: 114 "v=DMARC1; p=reject; rua=mailto:dmarc@dmarc.service.gov.example" 116 at 118 _dmarc.gov.example. 120 This DMARC record provides policy and a reporting destination for 121 mail sent from @gov.example. However, due to DMARC's current method 122 of discovering and applying policy at the organizational domain 123 level, the non-existent organizational domain of @tax.gov.example 124 does not and cannot fall under a DMARC policy. 126 This document provides a simple extension to DMARC [RFC7489] to allow 127 operators of Public Suffix Domains (PSDs) to express policy at the 128 level of the PSD that covers all organizational domains that do not 129 explicitly publish DMARC records, extends the DMARC policy query 130 functionality to detect and process such a policy, describes receiver 131 feedback for such policies, and provides controls to mitigate 132 potential privacy considerations associated with this extension. 134 This document also provides a new DMARC [RFC7489] tag to indicate 135 requested handling policy for non-existent subdommains. This is 136 provided specifically to support phased deployment of PSD DMARC, but 137 is expected to be useful more generally. Undesired rejection risks 138 for mail purporting to be from domains that do not exist are 139 substantially lower than for those that do, so the operational risk 140 of requesting harsh policy treatment (e.g. reject) is lower. 142 As an additional benefit, the PSD DMARC extension clarifies existing 143 requirements. Based on the requirements of DMARC [RFC7489], DMARC 144 should function above the organizational level for exact domain 145 matches (i.e. if a DMARC record were published for 'example', then 146 mail from example@example should be subject to DMARC processing). 147 Testing had revealed that this is not consistently applied in 148 different implementations. 150 There are two types of Public Suffix Operators (PSOs) for which this 151 extension would be useful and appropriate: 153 o Branded PSDs (e.g., ".google"): These domains are effectively 154 Organizational Domains as discussed in DMARC [RFC7489]. They 155 control all subdomains of the tree. These are effectively private 156 domains, but listed in the Public Suffix List. They are treated 157 as Public for DMARC purposes. They require the same protections 158 as DMARC Organizational Domains, but are currently excluded. 160 o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): 161 Because existing Organizational Domains using this PSD have their 162 own DMARC policy, the applicability of this extension is for non- 163 existent domains. The extension allows the brand protection 164 benefits of DMARC to extend to the entire PSD, including cousin 165 domains of registered organizations. 167 As an example, take the ".gov.example" described above and add that 168 for this entity emails about tax returns are sent from 169 tax.gov.example. It would not be surprising if fraudulent emails 170 were sent purporting to be from taxes.gov.example (taxes is a cousin 171 of tax - different enough to evade DMARC protection, but similar 172 enough to potentially confuse users). As defined in DMARC [RFC7489], 173 a DMARC record could be published for tax.gov.example, but there is 174 no general solution to publishing a DMARC policy to defend against 175 abuse of non-existent cousins such as taxes.gov.example. While an 176 explicit record could be published for this one domain, the universe 177 of possible cousins is such that this approach does not scale. 179 Due to the design of DMARC [RFC7489] and the nature of the Internet 180 email architecture [RFC5598], there are interoperability issues 181 associated with DMARC [RFC7489] deployment. These are discussed in 182 Interoperability Issues between DMARC and Indirect Email Flows 183 [RFC7960]. These issues are not typically applicable to PSDs, since 184 they (e.g., the ".gov.example" used above) do not typically send 185 mail. 187 2. Terminology and Definitions 189 This section defines terms used in the rest of the document. 191 2.1. Conventions Used in This Document 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 195 "OPTIONAL" in this document are to be interpreted as described in 196 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 197 capitals, as shown here. 199 2.2. Public Suffix Domain (PSD) 201 The global Internet Domain Name System (DNS) is documented in 202 numerous Requests for Comment (RFC). It defines a tree of names 203 starting with root, ".", immediately below which are Top Level Domain 204 names such as ".com" and ".us". They are not available for private 205 registration. In many cases the public portion of the DNS tree is 206 more than one level deep. 208 2.3. Longest PSD 210 Organizational Domain (DMARC [RFC7489] Section 3.2) with one left- 211 most label removed. 213 2.4. Public Suffix Operator (PSO) 215 A Public Suffix Operator manages operations within its PSD. 217 2.5. PSO Controlled Domain Names 219 PSO Controlled Domain Names are names in the DNS that are managed by 220 a PSO and are not available for use as Organizational Domains (the 221 term Organizational Domains is defined in DMARC [RFC7489] 222 Section 3.2). Depending on PSD policy, these will have one (e.g., 223 ".com") or more (e.g., ".co.uk") name components. 225 2.6. Non-existent Domains 227 For DMARC purposes, a non-existent domain is a domain for which there 228 is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This 229 is a broader definition than that in NXDOMAIN [RFC8020]. 231 3. PSD DMARC Updates to DMARC Requirements 233 This document updates DMARC [RFC7489] as follows: 235 3.1. General Updates 237 References to "Domain Owners" also apply to PSOs. 239 3.2. Section 6.1 DMARC Policy Record 241 PSD DMARC records are published as a subdomain of the PSD. For the 242 PSD ".example", the PSO would post DMARC policy in a TXT record at 243 "_dmarc.example". 245 3.3. Section 6.3 General Record Format 247 A new tag is added after fo: 249 np: Requested Mail Receiver policy for non-existent subdomains 250 (plain-text; OPTIONAL). Indicates the policy to be enacted by the 251 Receiver at the request of the Domain Owner. It applies only to 252 non-existent subdomains of the domain queried and not to either 253 existing subdomains or the domain itself. Its syntax is identical 254 to that of the "p" tag defined below. If the 'np' tag is absent, 255 the policy specified by the "sp" tag (if the 'sp' tag is present) 256 or the policy specified by the "p" tag, if the 'sp' tag is not 257 present, MUST be applied for non-existent subdomains. Note that 258 "np" will be ignored for DMARC records published on subdomains of 259 Organizational Domains and PSDs due to the effect of the DMARC 260 policy discovery mechanism described in DMARC [RFC7489] 261 Section 6.6.3. 263 The following tag definitions from DMARC [RFC7489] are updated: 265 p: The sentence 'Policy applies to the domain queried and to 266 subdomains, unless subdomain policy is explicitly described using 267 the "sp" tag' is updated to read 'Policy applies to the domain 268 queried and to subdomains, unless subdomain policy is explicitly 269 described using the "sp" or "np" tags.' 271 sp: The sentence 'If absent, the policy specified by the "p" tag 272 MUST be applied for subdomains' is updated to read 'If both the 273 'sp' tag is absent and the 'np' tag is either absent or not 274 applicable, the policy specified by the "p" tag MUST be applied 275 for subdomains. 277 3.4. Section 6.5. Domain Owner Actions 279 In addition to the DMARC domain owner actions, PSOs that require use 280 of DMARC and participate in PSD DMARC ought to make that information 281 available to receivers. The mechanism for doing so is one of the 282 experimental elements of this document. See the experiment 283 description (Appendix A). 285 3.5. Section 6.6.3. Policy Discovery 287 A new step between step 3 and 4 is added: 289 3A. If the set is now empty and the longest PSD (Section 2.3) of the 290 Organizational Domain is one that the receiver has determined is 291 acceptable for PSD DMARC (discussed in the experiment description 292 (Appendix A)), the Mail Receiver MUST query the DNS for a DMARC 293 TXT record at the DNS domain matching the longest PSD 294 (Section 2.3) in place of the RFC5322.From domain in the message 295 (if different). A possibly empty set of records is returned. 297 As an example, for a message with the Organizational Domain of 298 "example.compute.cloudcompany.com.cctld", the query for PSD DMARC 299 would use "compute.cloudcompany.com.cctld" as the longest PSD 300 (Section 2.3). The receiver would check to see if that PSD is listed 301 in the DMARC PSD Registry, and if so, perform the policy lookup at 302 "_dmarc.compute.cloudcompany.com.cctld". 304 Note: Because the PSD policy query comes after the Organizational 305 Domain policy query, PSD policy is not used for Organizational 306 domains that have published a DMARC policy. Specifically, this is 307 not a mechanism to provide feedback addresses (RUA/RUF) when an 308 Organizational Domain has declined to do so. 310 3.6. Section 7. DMARC Feedback 312 Operational note for PSD DMARC: For PSOs, feedback for non-existent 313 domains is desirable and useful, just as it is for org-level DMARC 314 operators. See Section 4 of this document for discussion of Privacy 315 Considerations. 317 4. Privacy Considerations 319 These privacy considerations are developed based on the requirements 320 of [RFC6973]. The Privacy Considerations of [RFC7489] apply to this 321 document. 323 4.1. Feedback leakage 325 Providing feedback reporting to PSOs can, in some cases, create 326 leakage of information outside of an organization to the PSO. This 327 leakage could potentially be utilized as part of a program of 328 pervasive surveillance (See [RFC7624]). There are roughly three 329 cases to consider: 331 o Single Organization PSDs (e.g., ".google"), RUA and RUF reports 332 based on PSD DMARC have the potential to contain information about 333 emails related to entities managed by the organization. Since 334 both the PSO and the Organizational Domain owners are common, 335 there is no additional privacy risk for either normal or non- 336 existent Domain reporting due to PSD DMARC. 338 o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): 339 PSD DMARC based reports will only be generated for domains that do 340 not publish a DMARC policy at the organizational or host level. 341 For domains that do publish the required DMARC policy records, the 342 feedback reporting addresses (RUA and RUF) of the organization (or 343 hosts) will be used. The only direct feedback leakage risk for 344 these PSDs are for Organizational Domains that are out of 345 compliance with PSD policy. Data on non-existent cousin domains 346 would be sent to the PSO. 348 o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC 349 usage: Privacy risks for Organizational Domains that have not 350 deployed DMARC within such PSDs are significant. For non-DMARC 351 Organizational Domains, all DMARC feedback will be directed to the 352 PSO. PSD DMARC is opt-out (by publishing a DMARC record at the 353 Organizational Domain level) vice opt-in, which would be the more 354 desirable characteristic. This means that any non-DMARC 355 organizational domain would have its feedback reports redirected 356 to the PSO. The content of such reports, particularly for 357 existing domains, is privacy sensitive. 359 PSOs will receive feedback on non-existent domains, which may be 360 similar to existing Organizational Domains. Feedback related to such 361 cousin domains have a small risk of carrying information related to 362 an actual Organizational Domain. To minimize this potential concern, 363 PSD DMARC feedback is best limited to Aggregate Reports. Feedback 364 Reports carry more detailed information and present a greater risk. 366 Due to the inherent Privacy and Security risks associated with PSD 367 DMARC for Organizational Domains in multi-organization PSDs that do 368 not particpate in DMARC, any Feedback Reporting related to multi- 369 organizational PSDs ought to be limited to non-existent domains 370 except in cases where the reporter knows that PSO requires use of 371 DMARC. 373 5. Security Considerations 375 This document does not change the Security Considerations of 376 [RFC7489] and [RFC7960]. 378 The risks of the issues identified in [RFC7489], Section 12.3, DNS 379 Security, are amplified by PSD DMARC. In particular, DNS cache 380 poisoning (or Name Chaining), see [RFC3833] for details, consequences 381 are increased because a sucessful attack would potentially have a 382 much wider scope. 384 The risks of the issues identified in [RFC7489], Section 12.5, 385 External Reporting Addresses, are amplified by PSD DMARC. By design, 386 PSD DMARC causes unrequested reporting of feedback to entities 387 external to the Organizational Domain. This is discussed in more 388 detail in Section 4. 390 6. IANA Considerations 392 This section describes actions requested to be completed by IANA. 394 6.1. Subdomain Policy Tag 396 IANA is requested to add a new tag to DMARC Tag Registry in the 397 Domain-based Message Authentication, Reporting, and Conformance 398 (DMARC) Parameters Registry. 400 The entry is as follows: 402 +----------+-----------+---------+-------------------------------+ 403 | Tag Name | Reference | Status | Description | 404 +----------+-----------+---------+-------------------------------+ 405 | np | this | current | Requested handling policy for | 406 | | document | | non-existent subdomains | 407 +----------+-----------+---------+-------------------------------+ 409 7. References 411 7.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, 415 DOI 10.17487/RFC2119, March 1997, 416 . 418 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 419 Message Authentication, Reporting, and Conformance 420 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 421 . 423 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 424 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 425 May 2017, . 427 7.2. Informative References 429 [psddmarc.org] 430 multiple, "PSD DMARC Web Site", April 2019, 431 . 433 [PSL] multiple, "Public Suffix List", April 2019, 434 . 436 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 437 Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August 438 2004, . 440 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 441 IANA Considerations Section in RFCs", RFC 5226, 442 DOI 10.17487/RFC5226, May 2008, 443 . 445 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 446 DOI 10.17487/RFC5598, July 2009, 447 . 449 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 450 Morris, J., Hansen, M., and R. Smith, "Privacy 451 Considerations for Internet Protocols", RFC 6973, 452 DOI 10.17487/RFC6973, July 2013, 453 . 455 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 456 Trammell, B., Huitema, C., and D. Borkmann, 457 "Confidentiality in the Face of Pervasive Surveillance: A 458 Threat Model and Problem Statement", RFC 7624, 459 DOI 10.17487/RFC7624, August 2015, 460 . 462 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, 463 E., Ed., and K. Andersen, Ed., "Interoperability Issues 464 between Domain-based Message Authentication, Reporting, 465 and Conformance (DMARC) and Indirect Email Flows", 466 RFC 7960, DOI 10.17487/RFC7960, September 2016, 467 . 469 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 470 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 471 November 2016, . 473 Appendix A. The Experiment 475 There are two experimental questions addressed in this document: one 476 regarding mitigation of PSD related privacy concerns and the other on 477 the utility of specifying separate DMARC policies for non-existent 478 sub-domains. 480 Aditionally, as of the writing of this document operational and 481 policy constraints prevent this experiment from being deployed 482 globally. If the experiment shows that PSD DMARC solves a real 483 problem and can be used at a large scale, the results could prove to 484 be useful in removing constraints outside of the IETF that would 485 permit broader deployment". 487 A.1. PSD DMARC Privacy Concern Mitigation 489 To mitigate the privacy concerns associated with Multi-organization 490 PSDs that do not mandate DMARC usage, see Section 4.1, a mechanism to 491 indicate which PSDs do not present this privacy risk is appropriate. 492 There are multiple approaches that are possible. 494 The experiment is to evaluate different possible approaches. The 495 experiment will be complete when there is rough consensus on a 496 technical approach that is demonstrated to be operationally usable 497 and effective at mitigating the privacy concern. 499 The mechanism needs the following attributes: 501 o Be reliably, publicly accessible 503 o Be under configuration control based on a public set of criteria 505 o List PSDs that either mandate DMARC for their registrants or for 506 which all lower level domains are controlled by the PSO and that 507 the relevant PSO has indicated a desire for the PSD to participate 508 in PSD DMARC 510 o Have a small operational footprint (e.g. provide a documented, 511 lightweight mechanism for developers and operators to retrieve the 512 list of PSD DMARC participants) 514 o Not allow PSO to add PSDs to the PSD DMARC participants list 515 without third party review 517 As of this writing, three approaches have been proposed. None of 518 them are ideal: 520 o An extension to the Public Suffix List at [PSL] 522 o A dedicated registry queried via DNS - an example of such a 523 service is described in Appendix B.1 below 525 o An IANA registry 527 A.2. Non-Existent Subdomain Policy 529 PSOs that plan to implement PSD DMARC have indicated that the ability 530 to describe distinct policies for existing and non- existing sub- 531 domains would facilitate PSD DMARC deployment. There are also 532 suggestions that it would be more generally useful for DMARC. 534 During the period of the experiment, uptake of the new 'np' tag will 535 be evaluated to support assessment of the utility of including 'np' 536 in a future, non-experimental update. 538 Appendix B. DMARC PSD Registry Examples 540 To facilitate experimentation around data leakage mitigation, samples 541 of the DNS based and IANA like registries are available at 542 [psddmarc.org]. 544 B.1. DMARC PSD DNS Query Service 546 A sample stand-alone DNS query service is available at 547 [psddmarc.org]. It was developed based on the contents suggested for 548 an IANA registry in an earlier revision of this draft. Usage of the 549 service is described on the web site. 551 B.2. DMARC Public Suffix Domain (PSD) Registry 553 [psddmarc.org] provides an IANA like DMARC Public Suffix Domain (PSD) 554 Registry as a stand-alone DNS query service. It follows the contents 555 and structure described below. There is a Comma Separated Value 556 (CSV) version of the listed PSD domains which is suitable for use in 557 build updates for PSD DMARC capable software. 559 Names of PSDs participating in PSD DMARC must be registered this new 560 registry. New entries are assigned only for PSDs that require use of 561 DMARC. The requirement has to be documented in a manner that 562 satisfies the terms of Expert Review,per [RFC5226]. The Designated 563 Expert needs to confirm that provided documentation adequately 564 describes PSD policy to require domain owners to use DMARC or that 565 all domain owners are part of a single organization with the PSO. 567 The initial set of entries in this registry is as follows: 569 +-------------+---------------+ 570 | PSD | Status | 571 +-------------+---------------+ 572 | .bank | current | 573 +-------------+---------------+ 574 | .insurance | current | 575 +-------------+---------------+ 576 | .gov.uk | current | 577 +-------------+---------------+ 579 Appendix C. Implementation 581 There is one known implementation of PSD DMARC available for testing. 583 C.1. Authheaders Module 585 The authheaders Python module and command line tool is available for 586 download or installation from Pypi (Python Packaging Index). 588 It supports both use of the DNS based query service and download of 589 the CSV registry file from [psddmarc.org]. 591 Acknowledgements 593 Thanks to the following individuals for their contributions (both 594 public and private) to improving this document. Special shout out to 595 Dave Crocker for naming the beast. 597 Kurt Andersen, Seth Blank, Dave Crocker, Heather Diaz, Tim Draegen, 598 Zeke Hendrickson, Andrew Kennedy, John Levine, Dr Ian Levy, Craig 599 Schwartz, Alessandro Vesely, and Tim Wicinski 601 Author's Address 602 Scott Kitterman 603 fTLD Registry Services 604 600 13th Street, NW, Suite 400 605 Washington, DC 20005 606 United States of America 608 Phone: +1 301 325-5475 609 Email: scott@kitterman.com