idnits 2.17.1 draft-bambenek-porter-dnsop-whois-over-dns-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 20 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2019) is 1760 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1034' is defined on line 524, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 534, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1463 ** Downref: Normative reference to an Informational RFC: RFC 7489 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Bambenek 2 Internet Draft ThreatSTOP 3 Intended status: Standards Track R. Porter 4 Expires: December 30, 2019 Palo Alto Networks 5 June 30, 2019 7 Domain Contact Information (WHOIS) over DNS 8 draft-bambenek-porter-dnsop-whois-over-dns-01.txt 10 Abstract 12 Domain contact information over DNS provides a vehicle for 13 exchanging contact information in a programmatic and reliable 14 manner. DNS has a ubiquitous presence within the internet 15 infrastructure and will act as a reliable publication method for 16 contact information exchange. This RFC provides an agreed upon 17 structure, voluntarily, to publish points of contact for domains. 19 This document outlines the methodology for utilizing DNS TXT records 20 for voluntary publication of various forms of contact. The intended 21 purpose is to provide a faster means of reliable contact for 22 professionals, cyber-defense of domains. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on December 30, 2019. 46 Copyright Notice 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. 55 Table of Contents 57 1. Introduction...................................................3 58 1.1. Rationale for Using DNS...................................3 59 1.2. Rationale to Publish or Not Public WHOIS over DNS 60 Information....................................................4 61 2. Conventions used in this document..............................4 62 3. Administrative Contact Information.............................4 63 3.1. Administrative Contact Name...............................5 64 3.2. Administrative Contact Phone Number.......................5 65 3.3. Administrative Contact E-mail Address.....................5 66 3.4. Administrative Contact Address............................5 67 4. Technical Contact Information..................................6 68 4.1. Technical Contact Name....................................6 69 4.2. Technical Contact Phone Number............................6 70 4.3. Technical Contact E-mail Address..........................6 71 4.4. Technical Contact Address.................................7 72 5. Network Contact Information....................................7 73 5.1. Network Contact Name......................................7 74 5.2. Network Contact Phone Number..............................7 75 5.3. Network Contact E-mail Address............................7 76 5.4. Network Contact Address...................................8 77 6. Security / Abuse Contact Information...........................8 78 6.1. Security / Abuse Contact Name.............................8 79 6.2. Security / Abuse Contact Phone Number.....................8 80 6.3. Security / Abuse Contact E-mail Address...................9 81 6.4. Security / Abuse Contact Address..........................9 82 7. All-in-One Option..............................................9 83 7.1. "All" Contact Name........................................9 84 7.2. "All" Contact Phone Number...............................10 85 7.3. "All" Contact E-mail Address.............................10 86 7.4. "All" Contact Address....................................10 87 8. Security Considerations.......................................10 88 9. IANA Considerations...........................................11 89 10. References...................................................11 90 10.1. Normative References....................................11 91 10.2. Informative References..................................12 92 11. Acknowledgments..............................................12 93 Appendix A. Copyright Notice.....................................13 95 1. Introduction 97 In lieu of recent events and legislation that has impacted the 98 global availability of the current WHOIS protocol and underlying 99 model, a new method for distributing contact information for domains 100 is necessary. This method must rely on the consent of the domain 101 owners and be optional in order to comply with emerging privacy law. 102 As an additional requirement, the existing protocol does not allow 103 for internationalization and that should be corrected with whatever 104 successor system is designed. 106 The availability of this information has proved an invaluable 107 resource for security and anti-abuse professionals in preventing 108 spam, detecting malicious infrastructure, and preemptive detection 109 of election manipulation operations. Maintaining some system to both 110 distribute this information (should it be voluntarily published) in 111 a manner that allows for automated retrieval and analysis is key. 113 1.1. Rationale for Using DNS 115 All resources communicating on the Internet already use DNS to 116 distribute information. In many cases, these domains are already 117 using text records for SPF, DKIM, CAA, and other types to distribute 118 information about their infrastructure and identity to validate 119 communication and prevent abuse. 121 One of the benefits of the WHOIS system outlined in RFC 3912 122 [RFC3912] is that records are stored and distributed by a different 123 entity who performs some measure of validation, at least for the e- 124 mail address. This means that if a domain owner were compromised, 125 someone else has contact information to get in touch with the true 126 own to organize remediation. Using WHOIS Over DNS at least separates 127 the distribution of this information from a webserver and makes it 128 less likely a hostile actor could manipulate the contact information 129 as well in the event of a compromise. 131 It is less ideal that full administrative separation in a different 132 organization, but DNS and webservers are typically separate so 133 compromise of both simultaneously would be rare (albeit not 134 impossible). 136 Additionally, internationalization is already well-established in 137 DNS using punycode as outlined in RFC 3492 [RFC3492]. 139 DNS TXT records as specified in RFC 1463 [RFC1463] are already in 140 wide use and is where WHOIS over DNS information SHOULD be stored. 141 These TXT records SHALL be tied to "_whois" subdomain TXT record. 142 This roughly follows the convention already used by DMARC records as 143 specified in RFC 7489 [RFC7489] so implementation should be easy and 144 DNS providers should already be able to support the addition of 145 these new records. 147 1.2. Rationale to Publish or Not Public WHOIS over DNS Information 149 There are a wide variety of reasons to publish or not publish valid 150 contact information that is available for anyone in the world to 151 use. Those concerned about privacy or who are otherwise at-risk 152 based on their online activities may wish to hide this information. 153 Others may wish to publish it so reputational engines treat their e- 154 mail and other communication as more valid. 156 Each use case is unique and a "one size fits all" approach cannot 157 work on a global Internet. This document was written so that 158 publishing or not publishing is optional, whether individual or 159 "role-based" information is used is a choice, and that this 160 information is preserved for use by automated systems. 162 All commercial DNS providers and DNS servers SHALL support these 163 record types. 165 2. Conventions used in this document 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 In this document, these words will appear with that interpretation 172 only when in ALL CAPS. Lower case uses of these words are not to be 173 interpreted as carrying significance described in RFC 2119. 175 In this document, exampledomain.com will be used to describe the DNS 176 TXT records used. It is not intended to point to anything currently 177 or planned to be in use. 179 3. Administrative Contact Information 181 Administrative contact information MAY be published as a DNS TXT 182 record that is prefaced with the letter "a". The administrative 183 contact SHOULD be the person or persons who are representatives of 184 the domain and charged with making business and non-technical 185 decisions. This person or persons may be on other contact records. 187 3.1. Administrative Contact Name 189 The administrative contact name MAY be created, but if it is, SHALL 190 be stored using the name "aname". This contact name may refer to an 191 individual or a role name (i.e. "Business Administrator"). Punycode 192 can be used to support internationalization of that name. An example 193 record of this type would be: 195 _whois.exampledomain.com. 14400 IN TXT "aname=John Bambenek" 197 3.2. Administrative Contact Phone Number 199 The administrative contact phone number MAY be created, but if it 200 is, SHALL be stored using the name "aphone". This phone number MAY 201 be a direct dial to an individual or to a monitored phone by a group 202 of individuals. It SHOULD however, be a line that would be monitored 203 by a live person. The phone number MUST be stored in accordance with 204 the ITU standard for international numbers [E.164]. An example of 205 the record is would be: 207 _whois.exampledomain.com. 14400 IN TXT "aphone=+13127254225" 209 3.3. Administrative Contact E-mail Address 211 The administrative contact e-mail address MAY be created, but if it 212 is, SHALL be stored using the name "aemail". This e-mail may be a 213 role-based e-mail address or an individual e-mail account. In either 214 case, it MUST be monitored for messages. An example of this record 215 would be: 217 _whois.exampledomain.com. 14400 IN TXT 218 "aemail=bambenek@illinois.edu" 220 3.4. Administrative Contact Address 222 The administrative contact address MAY be created, but if it is, 223 SHALL be stored using the name "aaddress". This MUST be stored using 224 the valid convention of mail services for the country where the 225 address resides in and include the country at the end. This address 226 MUST exist and MUST correctly represent an address where the 227 administrative contact can receive mail. An example of this record 228 would be: 230 _whois.exampledomain.com. 14400 IN TXT "aaddress=201 N. Goodwin 231 Ave., Urbana, IL 61801, US" 233 4. Technical Contact Information 235 Technical contact information MAY be published as a DNS TXT record 236 that is prefaced with the letter "t". The technical contact SHOULD 237 be the person or persons who are representatives of the technical 238 aspects of Internet-facing services provided by the domain (i.e. web 239 server administrator, e-mail administrator). This person or persons 240 may be on other contact records. 242 4.1. Technical Contact Name 244 The technical contact name MAY be created, but if it is, SHALL be 245 stored using the name "tname". This contact name may refer to an 246 individual or a role name (i.e. "Website Administrator"). Punycode 247 can be used to support internationalization of that name. An example 248 record of this type would be: 250 _whois.exampledomain.com. 14400 IN TXT "tname=John Bambenek" 252 4.2. Technical Contact Phone Number 254 The administrative contact phone number MAY be created, but if it 255 is, SHALL be stored using the name "tphone". This phone number MAY 256 be a direct dial to an individual or to a monitored phone by a group 257 of individuals. It SHOULD however, be a line that would be monitored 258 by a live person. The phone number MUST be stored in accordance with 259 the ITU standard for international numbers [E.164]. An example of 260 the record is would be: 262 _whois.exampledomain.com. 14400 IN TXT "tphone=+13127254225" 264 4.3. Technical Contact E-mail Address 266 The administrative contact e-mail address MAY be created, but if it 267 is, SHALL be stored using the name "temail". This e-mail may be a 268 role-based e-mail address or an individual e-mail account. In either 269 case, it MUST be monitored for messages. An example of this record 270 would be: 272 _whois.exampledomain.com. 14400 IN TXT 273 "temail=bambenek@illinois.edu" 275 4.4. Technical Contact Address 277 The administrative contact address MAY be created, but if it is, 278 SHALL be stored using the name "taddress". This MUST be stored using 279 the valid convention of mail services for the country where the 280 address resides in and include the country at the end. This address 281 MUST exist and MUST correctly represent an address where the 282 technical contact can receive mail. An example of this record would 283 be: 285 _whois.exampledomain.com. 14400 IN TXT "taddress=201 N. Goodwin 286 Ave., Urbana, IL 61801, US" 288 5. Network Contact Information 290 Network contact information MAY be published as a DNS TXT record 291 that is prefaced with the letter "n". The network contact should be 292 the person or persons who are representatives of the domain and 293 charged with making networking decisions on behalf of the domain. 294 This person or persons may be on other contact records. 296 5.1. Network Contact Name 298 The network contact name MAY be created, but if it is, SHALL be 299 stored using the name "nname". This contact name may refer to an 300 individual or a role name (i.e. "Network Administrator"). Punycode 301 can be used to support internationalization of that name. An example 302 record of this type would be: 304 _whois.exampledomain.com. 14400 IN TXT "nname=John Bambenek" 306 5.2. Network Contact Phone Number 308 The administrative contact phone number MAY be created, but if it 309 is, SHALL be stored using the name "nphone". This phone number MAY 310 be a direct dial to an individual or to a monitored phone by a group 311 of individuals responsible for networking. It SHOULD however, be a 312 line that would be monitored by a live person. The phone number MUST 313 be stored in accordance with the ITU standard for international 314 numbers [E.164]. An example of the record is would be: 316 _whois.exampledomain.com. 14400 IN TXT "nphone=+13127254225" 318 5.3. Network Contact E-mail Address 320 The network contact e-mail address MAY be created, but if it is, 321 SHALL be stored using the name "nemail". This e-mail may be a role- 322 based e-mail address or an individual e-mail account. In either 323 case, it MUST be monitored for messages. An example of this record 324 would be: 326 _whois.exampledomain.com. 14400 IN TXT 327 "nemail=bambenek@illinois.edu" 329 5.4. Network Contact Address 331 The administrative contact address MAY be created, but if it is, 332 SHALL be stored using the name "naddress". This MUST be stored using 333 the valid convention of mail services for the country where the 334 address resides in and include the country at the end. This address 335 MUST exist and MUST correctly represent an address where the network 336 contact can receive mail. An example of this record would be: 338 _whois.exampledomain.com. 14400 IN TXT "naddress=201 N. Goodwin 339 Ave., Urbana, IL 61801, US" 341 6. Security / Abuse Contact Information 343 Security or abuse contact information MAY be published as a DNS TXT 344 record that is prefaced with the letter "s". The security or abuse 345 contact SHOULD be the person or persons who are representatives of 346 the domain and should receive reports on security or abuse concerns 347 from resources under the domain or being targeted to resources 348 served by the domain. This person or persons may be on other contact 349 records. 351 6.1. Security / Abuse Contact Name 353 The security or abuse contact name MAY be created, but if it is, 354 SHALL be stored using the name "sname". This contact name may refer 355 to an individual or a role name (i.e. "Business Administrator"). 356 Punycode can be used to support internationalization of that name. 357 An example record of this type would be: 359 _whois.exampledomain.com. 14400 IN TXT "sname=John Bambenek" 361 6.2. Security / Abuse Contact Phone Number 363 The security or abuse contact phone number MAY be created, but if it 364 is, SHALL be stored using the name "sphone". This phone number MAY 365 be a direct dial to an individual or to a monitored phone by a group 366 of individuals responsible for security and/or abuse reports for the 367 domain. It SHOULD however, be a line that would be monitored by a 368 live person. The phone number MUST be stored in accordance with the 369 ITU standard for international numbers [E.164]. An example of the 370 record is would be: 372 _whois.exampledomain.com. 14400 IN TXT "sphone=+13127254225" 374 6.3. Security / Abuse Contact E-mail Address 376 The security or abuse contact e-mail address MAY be created, but if 377 it is, SHALL be stored using the name "semail". This e-mail may be a 378 role-based e-mail address or an individual e-mail account. In either 379 case, it MUST be monitored for messages. An example of this record 380 would be: 382 _whois.exampledomain.com. 14400 IN TXT 383 "semail=bambenek@illinois.edu" 385 6.4. Security / Abuse Contact Address 387 The security or abuse contact address MAY be created, but if it is, 388 SHALL be stored using the name "saddress". This MUST be stored using 389 the valid convention of mail services for the country where the 390 address resides in and include the country at the end. This address 391 MUST exist and MUST correctly represent an address where the 392 administrative contact can receive mail. An example of this record 393 would be: 395 _whois.exampledomain.com. 14400 IN TXT "saddress=201 N. Goodwin 396 Ave., Urbana, IL 61801, US" 398 7. All-in-One Option 400 In order to create a simple option for those cases where the contact 401 would be the same for all four types of WHOIS contacts, an "all" 402 record MAY be used to take the place of the four individual 403 categories to simplify DNS administration for the domain owner. 405 7.1. "All" Contact Name 407 The "all" contact name MAY be created, but if it is, SHALL be stored 408 using the name "allname". This contact name may refer to an 409 individual or a role name (i.e. "Domain Owner"). Punycode can be 410 used to support internationalization of that name. An example record 411 of this type would be: 413 _whois.exampledomain.com. 14400 IN TXT "allname=John Bambenek" 415 7.2. "All" Contact Phone Number 417 The "all" contact phone number MAY be created, but if it is, SHALL 418 be stored using the name "allphone". This phone number MAY be a 419 direct dial to an individual or to a monitored phone by a group of 420 individuals. It SHOULD however, be a line that would be monitored by 421 a live person. The phone number MUST be stored in accordance with 422 the ITU standard for international numbers [E.164]. An example of 423 the record is would be: 425 _whois.exampledomain.com. 14400 IN TXT "allphone=+13127254225" 427 7.3. "All" Contact E-mail Address 429 The "all" contact e-mail address MAY be created, but if it is, SHALL 430 be stored using the name "allemail". This e-mail may be a role-based 431 e-mail address or an individual e-mail account. In either case, it 432 MUST be monitored for messages. An example of this record would be: 434 _whois.exampledomain.com. 14400 IN TXT 435 "allemail=bambenek@illinois.edu" 437 7.4. "All" Contact Address 439 The "all" contact address MAY be created, but if it is, SHALL be 440 stored using the name "alladdress". This MUST be stored using the 441 valid convention of mail services for the country where the address 442 resides in and include the country at the end. This address MUST 443 exist and MUST correctly represent an address where the contact can 444 receive mail. An example of this record would be: 446 _whois.exampledomain.com. 14400 IN TXT "alladdress=201 N. Goodwin 447 Ave., Urbana, IL 61801, US" 449 8. Security Considerations 451 As with any publication of potentially personally identifiable 452 information, this could lead to individuals receiving unwanted 453 communication of various sorts. This standard does not require 454 specific individuals to be identified, per se, as all the contact 455 types can be role-based accounts. 457 The purpose of this document is to establish a standard by which 458 "someone" can be contacted in the case of a need to contact a domain 459 owner and to help establish reputation for those looking to connect 460 with a given domain and have transactions with services on that 461 domain. 463 The publication of this information is immensely useful to the 464 security and anti-abuse industry for a wide variety of reasons and 465 this information can and should be used for reputational scoring of 466 domains to filter out potentially abusive infrastructure. 468 The publication of this data in DNS is optional, but third-parties 469 are free to use the lack of this information as a negative indicator 470 when considering interconnectivity (such as the delivery of e-mail). 472 If the domain registration itself were seized by a hostile third- 473 party, this system would not be able to authoritatively identify the 474 "victim"-owner. Passive DNS, however, will help in an overwhelming 475 majority of these cases. 477 The limitation of this approach is that there is no true validation 478 of any of the fields that will be published in these records. Under 479 the current system in the general case, an e-mail address is 480 validated before a domain is published. In this case, individuals 481 can use unsuspecting third-parties' contact information. Those 482 incidents, when discovered, are all but certainties that the 483 underlying domain is abusive (except in the case of plausible typos) 484 and provide further negative reputational data that can be used. 486 A third-party system could be used to provide for such validation 487 but that is outside the scope of this document. Additionally, 488 invalid entries, fake addresses, non-working email addresses or 489 malformed content MAY be used to negatively score a domain for 490 security reputation purposes. 492 DNSSEC MUST be fully deployed on any domain using these conventions 493 to help ensure reliability of this information. 495 9. IANA Considerations 497 There are no IANA considerations as this will use the existing DNS 498 TXT (type 16) RR. 500 10. References 502 10.1. Normative References 504 [RFC1463] Rosenbaum, R., "Using the Domain Name System to Store 505 Arbitary String Attributes", RFC 1463, May 1993. 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, DOI 509 10.17487/RFC2119, March 1997. 511 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 512 for Internationalized Domain Names in Applications 513 (IDNA)", RFC 3492, March 2003. 515 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 516 September 2004. 518 [RFC7489] Kucherawy, M., Zwicky, E., "Domain-based Message 519 Authentication, Reporting, and Conformance (DMARC)", RFC 520 7489, March 2015. 522 10.2. Informative References 524 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 525 RFC 1034, November 1987. 527 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 528 Specification", RFC 1035, November 1987. 530 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 531 Rose, "DNS Security Introduction and Requirements", RFC 532 4033, March 2005. 534 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, October 535 2008. 537 [E.164] International Telecommunications Union, "Recommendatino 538 E.164: The international public telecommuncations number 539 plan", May 1997, http://www.itu.int/. 541 11. Acknowledgments 543 This document was prepared using 2-Word-v2.0.template.dot. 545 Appendix A. Copyright Notice 547 Copyright (c) 2019 IETF Trust and the persons identified as the 548 document authors. All rights reserved. 550 Redistribution and use in source and binary forms, with or without 551 modification, is permitted pursuant to, and subject to the license 552 terms contained in, the Simplified BSD License set forth in Section 553 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 554 (http://trustee.ietf.org/license-info). 556 Authors' Addresses 558 John Bambenek 559 ThreatSTOP, Inc. 560 2720 Loker Avenue West, Suite G, Carlsbad, CA 92010, USA 562 Email: bambenek@illinois.edu 564 Richard Porter 565 Palo Alto Networks 566 3000 Tannery Way, Santa Clara, CA 95054, USA 568 Email: rporter@paloaltonetworks.com