Network Working Group J. Bambenek Internet Draft ThreatSTOP Intended status: Standards Track R. Porter Expires: December 30, 2019 Palo Alto Networks June 30, 2019 Domain Contact Information (WHOIS) over DNS draft-bambenek-porter-dnsop-whois-over-dns-01.txt Abstract Domain contact information over DNS provides a vehicle for exchanging contact information in a programmatic and reliable manner. DNS has a ubiquitous presence within the internet infrastructure and will act as a reliable publication method for contact information exchange. This RFC provides an agreed upon structure, voluntarily, to publish points of contact for domains. This document outlines the methodology for utilizing DNS TXT records for voluntary publication of various forms of contact. The intended purpose is to provide a faster means of reliable contact for professionals, cyber-defense of domains. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Bambenek, Porter Expires December 325, 2019 [Page 1] Internet-Draft WHOIS over DNS June 2019 This Internet-Draft will expire on December 30, 2019. Copyright Notice This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction...................................................3 1.1. Rationale for Using DNS...................................3 1.2. Rationale to Publish or Not Public WHOIS over DNS Information....................................................4 2. Conventions used in this document..............................4 3. Administrative Contact Information.............................4 3.1. Administrative Contact Name...............................5 3.2. Administrative Contact Phone Number.......................5 3.3. Administrative Contact E-mail Address.....................5 3.4. Administrative Contact Address............................5 4. Technical Contact Information..................................6 4.1. Technical Contact Name....................................6 4.2. Technical Contact Phone Number............................6 4.3. Technical Contact E-mail Address..........................6 4.4. Technical Contact Address.................................7 5. Network Contact Information....................................7 5.1. Network Contact Name......................................7 5.2. Network Contact Phone Number..............................7 5.3. Network Contact E-mail Address............................7 5.4. Network Contact Address...................................8 6. Security / Abuse Contact Information...........................8 6.1. Security / Abuse Contact Name.............................8 6.2. Security / Abuse Contact Phone Number.....................8 6.3. Security / Abuse Contact E-mail Address...................9 6.4. Security / Abuse Contact Address..........................9 7. All-in-One Option..............................................9 7.1. "All" Contact Name........................................9 7.2. "All" Contact Phone Number...............................10 7.3. "All" Contact E-mail Address.............................10 7.4. "All" Contact Address....................................10 8. Security Considerations.......................................10 9. IANA Considerations...........................................11 10. References...................................................11 Bambenek, Porter Expires December 30, 2019 [Page 2] Internet-Draft WHOIS over DNS June 2019 10.1. Normative References....................................11 10.2. Informative References..................................12 11. Acknowledgments..............................................12 Appendix A. Copyright Notice.....................................13 1. Introduction In lieu of recent events and legislation that has impacted the global availability of the current WHOIS protocol and underlying model, a new method for distributing contact information for domains is necessary. This method must rely on the consent of the domain owners and be optional in order to comply with emerging privacy law. As an additional requirement, the existing protocol does not allow for internationalization and that should be corrected with whatever successor system is designed. The availability of this information has proved an invaluable resource for security and anti-abuse professionals in preventing spam, detecting malicious infrastructure, and preemptive detection of election manipulation operations. Maintaining some system to both distribute this information (should it be voluntarily published) in a manner that allows for automated retrieval and analysis is key. 1.1. Rationale for Using DNS All resources communicating on the Internet already use DNS to distribute information. In many cases, these domains are already using text records for SPF, DKIM, CAA, and other types to distribute information about their infrastructure and identity to validate communication and prevent abuse. One of the benefits of the WHOIS system outlined in RFC 3912 [RFC3912] is that records are stored and distributed by a different entity who performs some measure of validation, at least for the e- mail address. This means that if a domain owner were compromised, someone else has contact information to get in touch with the true own to organize remediation. Using WHOIS Over DNS at least separates the distribution of this information from a webserver and makes it less likely a hostile actor could manipulate the contact information as well in the event of a compromise. It is less ideal that full administrative separation in a different organization, but DNS and webservers are typically separate so compromise of both simultaneously would be rare (albeit not impossible). Bambenek, Porter Expires December 30, 2019 [Page 3] Internet-Draft WHOIS over DNS June 2019 Additionally, internationalization is already well-established in DNS using punycode as outlined in RFC 3492 [RFC3492]. DNS TXT records as specified in RFC 1463 [RFC1463] are already in wide use and is where WHOIS over DNS information SHOULD be stored. These TXT records SHALL be tied to "_whois" subdomain TXT record. This roughly follows the convention already used by DMARC records as specified in RFC 7489 [RFC7489] so implementation should be easy and DNS providers should already be able to support the addition of these new records. 1.2. Rationale to Publish or Not Public WHOIS over DNS Information There are a wide variety of reasons to publish or not publish valid contact information that is available for anyone in the world to use. Those concerned about privacy or who are otherwise at-risk based on their online activities may wish to hide this information. Others may wish to publish it so reputational engines treat their e- mail and other communication as more valid. Each use case is unique and a "one size fits all" approach cannot work on a global Internet. This document was written so that publishing or not publishing is optional, whether individual or "role-based" information is used is a choice, and that this information is preserved for use by automated systems. All commercial DNS providers and DNS servers SHALL support these record types. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying significance described in RFC 2119. In this document, exampledomain.com will be used to describe the DNS TXT records used. It is not intended to point to anything currently or planned to be in use. 3. Administrative Contact Information Administrative contact information MAY be published as a DNS TXT record that is prefaced with the letter "a". The administrative Bambenek, Porter Expires December 30, 2019 [Page 4] Internet-Draft WHOIS over DNS June 2019 contact SHOULD be the person or persons who are representatives of the domain and charged with making business and non-technical decisions. This person or persons may be on other contact records. 3.1. Administrative Contact Name The administrative contact name MAY be created, but if it is, SHALL be stored using the name "aname". This contact name may refer to an individual or a role name (i.e. "Business Administrator"). Punycode can be used to support internationalization of that name. An example record of this type would be: _whois.exampledomain.com. 14400 IN TXT "aname=John Bambenek" 3.2. Administrative Contact Phone Number The administrative contact phone number MAY be created, but if it is, SHALL be stored using the name "aphone". This phone number MAY be a direct dial to an individual or to a monitored phone by a group of individuals. It SHOULD however, be a line that would be monitored by a live person. The phone number MUST be stored in accordance with the ITU standard for international numbers [E.164]. An example of the record is would be: _whois.exampledomain.com. 14400 IN TXT "aphone=+13127254225" 3.3. Administrative Contact E-mail Address The administrative contact e-mail address MAY be created, but if it is, SHALL be stored using the name "aemail". This e-mail may be a role-based e-mail address or an individual e-mail account. In either case, it MUST be monitored for messages. An example of this record would be: _whois.exampledomain.com. 14400 IN TXT "aemail=bambenek@illinois.edu" 3.4. Administrative Contact Address The administrative contact address MAY be created, but if it is, SHALL be stored using the name "aaddress". This MUST be stored using the valid convention of mail services for the country where the address resides in and include the country at the end. This address MUST exist and MUST correctly represent an address where the administrative contact can receive mail. An example of this record would be: Bambenek, Porter Expires December 30, 2019 [Page 5] Internet-Draft WHOIS over DNS June 2019 _whois.exampledomain.com. 14400 IN TXT "aaddress=201 N. Goodwin Ave., Urbana, IL 61801, US" 4. Technical Contact Information Technical contact information MAY be published as a DNS TXT record that is prefaced with the letter "t". The technical contact SHOULD be the person or persons who are representatives of the technical aspects of Internet-facing services provided by the domain (i.e. web server administrator, e-mail administrator). This person or persons may be on other contact records. 4.1. Technical Contact Name The technical contact name MAY be created, but if it is, SHALL be stored using the name "tname". This contact name may refer to an individual or a role name (i.e. "Website Administrator"). Punycode can be used to support internationalization of that name. An example record of this type would be: _whois.exampledomain.com. 14400 IN TXT "tname=John Bambenek" 4.2. Technical Contact Phone Number The administrative contact phone number MAY be created, but if it is, SHALL be stored using the name "tphone". This phone number MAY be a direct dial to an individual or to a monitored phone by a group of individuals. It SHOULD however, be a line that would be monitored by a live person. The phone number MUST be stored in accordance with the ITU standard for international numbers [E.164]. An example of the record is would be: _whois.exampledomain.com. 14400 IN TXT "tphone=+13127254225" 4.3. Technical Contact E-mail Address The administrative contact e-mail address MAY be created, but if it is, SHALL be stored using the name "temail". This e-mail may be a role-based e-mail address or an individual e-mail account. In either case, it MUST be monitored for messages. An example of this record would be: _whois.exampledomain.com. 14400 IN TXT "temail=bambenek@illinois.edu" Bambenek, Porter Expires December 30, 2019 [Page 6] Internet-Draft WHOIS over DNS June 2019 4.4. Technical Contact Address The administrative contact address MAY be created, but if it is, SHALL be stored using the name "taddress". This MUST be stored using the valid convention of mail services for the country where the address resides in and include the country at the end. This address MUST exist and MUST correctly represent an address where the technical contact can receive mail. An example of this record would be: _whois.exampledomain.com. 14400 IN TXT "taddress=201 N. Goodwin Ave., Urbana, IL 61801, US" 5. Network Contact Information Network contact information MAY be published as a DNS TXT record that is prefaced with the letter "n". The network contact should be the person or persons who are representatives of the domain and charged with making networking decisions on behalf of the domain. This person or persons may be on other contact records. 5.1. Network Contact Name The network contact name MAY be created, but if it is, SHALL be stored using the name "nname". This contact name may refer to an individual or a role name (i.e. "Network Administrator"). Punycode can be used to support internationalization of that name. An example record of this type would be: _whois.exampledomain.com. 14400 IN TXT "nname=John Bambenek" 5.2. Network Contact Phone Number The administrative contact phone number MAY be created, but if it is, SHALL be stored using the name "nphone". This phone number MAY be a direct dial to an individual or to a monitored phone by a group of individuals responsible for networking. It SHOULD however, be a line that would be monitored by a live person. The phone number MUST be stored in accordance with the ITU standard for international numbers [E.164]. An example of the record is would be: _whois.exampledomain.com. 14400 IN TXT "nphone=+13127254225" 5.3. Network Contact E-mail Address The network contact e-mail address MAY be created, but if it is, SHALL be stored using the name "nemail". This e-mail may be a role- Bambenek, Porter Expires December 30, 2019 [Page 7] Internet-Draft WHOIS over DNS June 2019 based e-mail address or an individual e-mail account. In either case, it MUST be monitored for messages. An example of this record would be: _whois.exampledomain.com. 14400 IN TXT "nemail=bambenek@illinois.edu" 5.4. Network Contact Address The administrative contact address MAY be created, but if it is, SHALL be stored using the name "naddress". This MUST be stored using the valid convention of mail services for the country where the address resides in and include the country at the end. This address MUST exist and MUST correctly represent an address where the network contact can receive mail. An example of this record would be: _whois.exampledomain.com. 14400 IN TXT "naddress=201 N. Goodwin Ave., Urbana, IL 61801, US" 6. Security / Abuse Contact Information Security or abuse contact information MAY be published as a DNS TXT record that is prefaced with the letter "s". The security or abuse contact SHOULD be the person or persons who are representatives of the domain and should receive reports on security or abuse concerns from resources under the domain or being targeted to resources served by the domain. This person or persons may be on other contact records. 6.1. Security / Abuse Contact Name The security or abuse contact name MAY be created, but if it is, SHALL be stored using the name "sname". This contact name may refer to an individual or a role name (i.e. "Business Administrator"). Punycode can be used to support internationalization of that name. An example record of this type would be: _whois.exampledomain.com. 14400 IN TXT "sname=John Bambenek" 6.2. Security / Abuse Contact Phone Number The security or abuse contact phone number MAY be created, but if it is, SHALL be stored using the name "sphone". This phone number MAY be a direct dial to an individual or to a monitored phone by a group of individuals responsible for security and/or abuse reports for the domain. It SHOULD however, be a line that would be monitored by a live person. The phone number MUST be stored in accordance with the Bambenek, Porter Expires December 30, 2019 [Page 8] Internet-Draft WHOIS over DNS June 2019 ITU standard for international numbers [E.164]. An example of the record is would be: _whois.exampledomain.com. 14400 IN TXT "sphone=+13127254225" 6.3. Security / Abuse Contact E-mail Address The security or abuse contact e-mail address MAY be created, but if it is, SHALL be stored using the name "semail". This e-mail may be a role-based e-mail address or an individual e-mail account. In either case, it MUST be monitored for messages. An example of this record would be: _whois.exampledomain.com. 14400 IN TXT "semail=bambenek@illinois.edu" 6.4. Security / Abuse Contact Address The security or abuse contact address MAY be created, but if it is, SHALL be stored using the name "saddress". This MUST be stored using the valid convention of mail services for the country where the address resides in and include the country at the end. This address MUST exist and MUST correctly represent an address where the administrative contact can receive mail. An example of this record would be: _whois.exampledomain.com. 14400 IN TXT "saddress=201 N. Goodwin Ave., Urbana, IL 61801, US" 7. All-in-One Option In order to create a simple option for those cases where the contact would be the same for all four types of WHOIS contacts, an "all" record MAY be used to take the place of the four individual categories to simplify DNS administration for the domain owner. 7.1. "All" Contact Name The "all" contact name MAY be created, but if it is, SHALL be stored using the name "allname". This contact name may refer to an individual or a role name (i.e. "Domain Owner"). Punycode can be used to support internationalization of that name. An example record of this type would be: _whois.exampledomain.com. 14400 IN TXT "allname=John Bambenek" Bambenek, Porter Expires December 30, 2019 [Page 9] Internet-Draft WHOIS over DNS June 2019 7.2. "All" Contact Phone Number The "all" contact phone number MAY be created, but if it is, SHALL be stored using the name "allphone". This phone number MAY be a direct dial to an individual or to a monitored phone by a group of individuals. It SHOULD however, be a line that would be monitored by a live person. The phone number MUST be stored in accordance with the ITU standard for international numbers [E.164]. An example of the record is would be: _whois.exampledomain.com. 14400 IN TXT "allphone=+13127254225" 7.3. "All" Contact E-mail Address The "all" contact e-mail address MAY be created, but if it is, SHALL be stored using the name "allemail". This e-mail may be a role-based e-mail address or an individual e-mail account. In either case, it MUST be monitored for messages. An example of this record would be: _whois.exampledomain.com. 14400 IN TXT "allemail=bambenek@illinois.edu" 7.4. "All" Contact Address The "all" contact address MAY be created, but if it is, SHALL be stored using the name "alladdress". This MUST be stored using the valid convention of mail services for the country where the address resides in and include the country at the end. This address MUST exist and MUST correctly represent an address where the contact can receive mail. An example of this record would be: _whois.exampledomain.com. 14400 IN TXT "alladdress=201 N. Goodwin Ave., Urbana, IL 61801, US" 8. Security Considerations As with any publication of potentially personally identifiable information, this could lead to individuals receiving unwanted communication of various sorts. This standard does not require specific individuals to be identified, per se, as all the contact types can be role-based accounts. The purpose of this document is to establish a standard by which "someone" can be contacted in the case of a need to contact a domain owner and to help establish reputation for those looking to connect with a given domain and have transactions with services on that domain. Bambenek, Porter Expires December 30, 2019 [Page 10] Internet-Draft WHOIS over DNS June 2019 The publication of this information is immensely useful to the security and anti-abuse industry for a wide variety of reasons and this information can and should be used for reputational scoring of domains to filter out potentially abusive infrastructure. The publication of this data in DNS is optional, but third-parties are free to use the lack of this information as a negative indicator when considering interconnectivity (such as the delivery of e-mail). If the domain registration itself were seized by a hostile third- party, this system would not be able to authoritatively identify the "victim"-owner. Passive DNS, however, will help in an overwhelming majority of these cases. The limitation of this approach is that there is no true validation of any of the fields that will be published in these records. Under the current system in the general case, an e-mail address is validated before a domain is published. In this case, individuals can use unsuspecting third-parties' contact information. Those incidents, when discovered, are all but certainties that the underlying domain is abusive (except in the case of plausible typos) and provide further negative reputational data that can be used. A third-party system could be used to provide for such validation but that is outside the scope of this document. Additionally, invalid entries, fake addresses, non-working email addresses or malformed content MAY be used to negatively score a domain for security reputation purposes. DNSSEC MUST be fully deployed on any domain using these conventions to help ensure reliability of this information. 9. IANA Considerations There are no IANA considerations as this will use the existing DNS TXT (type 16) RR. 10. References 10.1. Normative References [RFC1463] Rosenbaum, R., "Using the Domain Name System to Store Arbitary String Attributes", RFC 1463, May 1993. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. Bambenek, Porter Expires December 30, 2019 [Page 11] Internet-Draft WHOIS over DNS June 2019 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003. [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004. [RFC7489] Kucherawy, M., Zwicky, E., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, March 2015. 10.2. Informative References [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, October 2008. [E.164] International Telecommunications Union, "Recommendatino E.164: The international public telecommuncations number plan", May 1997, http://www.itu.int/. 11. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Bambenek, Porter Expires December 30, 2019 [Page 12] Internet-Draft WHOIS over DNS June 2019 Appendix A. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). Authors' Addresses John Bambenek ThreatSTOP, Inc. 2720 Loker Avenue West, Suite G, Carlsbad, CA 92010, USA Email: bambenek@illinois.edu Richard Porter Palo Alto Networks 3000 Tannery Way, Santa Clara, CA 95054, USA Email: rporter@paloaltonetworks.com Bambenek, Porter Expires December 30, 2019 [Page 13]