summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8567.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8567.txt')
-rw-r--r--doc/rfc/rfc8567.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc8567.txt b/doc/rfc/rfc8567.txt
new file mode 100644
index 0000000..9e43bcc
--- /dev/null
+++ b/doc/rfc/rfc8567.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Independent Submission E. Rye
+Request for Comments: 8567 R. Beverly
+Category: Informational CMAND
+ISSN: 2070-1721 1 April 2019
+
+
+ Customer Management DNS Resource Records
+
+Abstract
+
+ Maintaining high Quality of Experience (QoE) increasingly requires
+ end-to-end, holistic network management, including managed Customer
+ Premises Equipment (CPE). Because customer management is a shared
+ global responsibility, the Domain Name System (DNS) provides an ideal
+ existing infrastructure for maintaining authoritative customer
+ information that must be readily, reliably, and publicly accessible.
+
+ This document describes four new DNS resource record types for
+ encoding customer information in the DNS. These records are intended
+ to better facilitate high customer QoE via inter-provider cooperation
+ and management of customer data.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This is a contribution to the RFC Series, independently of any other
+ RFC stream. The RFC Editor has chosen to publish this document at
+ its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not candidates for any level of Internet Standard;
+ see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8567.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rye & Beverly Informational [Page 1]
+
+RFC 8567 Customer Management over DNS 1 April 2019
+
+
+Copyright Notice
+
+ Copyright (c) 2019 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Customer Management Resource Records . . . . . . . . . . . . 3
+ 2.1. The PASSWORD Resource Record . . . . . . . . . . . . . . 4
+ 2.2. The CREDITCARD Resource Record . . . . . . . . . . . . . 4
+ 2.3. The SSN Resource Record . . . . . . . . . . . . . . . . . 6
+ 2.4. The SSNPTR Resource Record . . . . . . . . . . . . . . . 7
+ 3. Related RR Types . . . . . . . . . . . . . . . . . . . . . . 7
+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . 9
+ 6.2. Informative References . . . . . . . . . . . . . . . . . 9
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
+
+1. Introduction
+
+ A significant portion of today's Internet is comprised of residential
+ access networks. These access networks, and their providers, are now
+ critical infrastructure, and significant research is devoted to
+ measuring residential broadband speed and reliability [SAMKNOWS].
+
+ Unfortunately, Customer Premises Equipment (CPE) is one of the
+ weakest links in the chain of network equipment connecting consumers
+ to the Internet. Customers typically do not perform proactive
+ maintenance, e.g., firmware updates, on their own CPE. In many
+ cases, CPE is even deployed with default authentication credentials,
+ a fact that has been exploited by various Internet-wide denial-of-
+ service attacks [MIRAI].
+
+ A central observation motivating this document is that customers
+ simply cannot be trusted to manage their own networks, much less the
+ path-critical CPE. Given the difficulty in maintaining the hygiene
+
+
+
+Rye & Beverly Informational [Page 2]
+
+RFC 8567 Customer Management over DNS 1 April 2019
+
+
+ and resilience of broadband access, CPE maintenance should instead be
+ treated as a shared global responsibility among Internet Service
+ Providers (ISPs).
+
+ Further complicating customer management is choice in ISP, which is
+ currently available to nearly half of US households. While customers
+ may switch providers, their biographical, billing, and technological
+ details remain constant. Therefore, service providers need
+ mechanisms to ensure that transitioning customers into and out of
+ their network is as seamless as possible from both a technical and
+ billing standpoint.
+
+ Finally, service providers, advertisers, and law enforcement agencies
+ have varying but important reasons to track unique users' behavior on
+ the Internet. While RFC 7043 [RFC7043] makes use of EUI48 and EUI64
+ Resource Record (RR) types to uniquely identify CPE devices and
+ better support third-party tracking, these mechanisms can be defeated
+ by the customer simply purchasing new CPE.
+
+ This document takes a holistic, end-to-end view of customer
+ management with the aim of enhancing customer QoE and overall network
+ security. To enable shared CPE maintenance, this document leverages
+ the Domain Name System (DNS), described in RFC 1034 [RFC1034] and
+ RFC 1035 [RFC1035], and introduces new RR types to aid network
+ management.
+
+1.1. Terminology
+
+ This document uses capitalized keywords such as MUST and MAY to
+ describe the requirements for using the registered RR types. The
+ intended meaning of those keywords in this document are the same as
+ those described in RFC 2119 [RFC2119] and RFC 8174 [RFC8174].
+ Although these keywords are often used to specify normative
+ requirements in IETF Standards, their use in this document does not
+ imply that this document is a standard of any kind.
+
+2. Customer Management Resource Records
+
+ The ubiquity of residential broadband Internet service affords myriad
+ benefits to consumers, but also poses a daunting challenge for
+ Internet Service Providers -- how to best manage sensitive customer
+ identifiers and billing details, while ensuring the resilience and
+ security of CPE devices on their network?
+
+ This document introduces four new RRs to assist in the management of
+ customer data by ISPs.
+
+
+
+
+
+Rye & Beverly Informational [Page 3]
+
+RFC 8567 Customer Management over DNS 1 April 2019
+
+
+ This section describes the purpose and wire format of the new DNS
+ RRs.
+
+2.1. The PASSWORD Resource Record
+
+ The PASSWORD RR facilitates remote management of CPE devices by
+ providing the login credentials for the CPE in a single RR. These
+ credentials are used by authorized service providers to authenticate
+ to the CPE. Authenticated users can then install important software
+ and configuration updates to benefit the security and health of the
+ provider's network.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | USERNAME |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PASSWORD |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: PASSWORD RDATA Format
+
+ Where:
+
+ USERNAME
+ The <character-string> username of the account holder located at
+ the CPE. In order to limit gratuitous expressions of
+ individuality, usernames MUST be 16 or fewer ASCII characters and
+ MUST NOT include punctuation.
+
+ PASSWORD
+ The <character-string> password associated with the USERNAME. In
+ order to keep the RR size to a minimum, passwords longer than 32
+ bits are NOT supported.
+
+ Hosts on which multiple accounts exist SHOULD have separate PASSWORD
+ RRs for each account.
+
+2.2. The CREDITCARD Resource Record
+
+ The CREDITCARD RR stores the billing details of the primary account
+ holder located at the hostname associated with the CPE. Upon gaining
+ a new subscriber, an ISP enters their billing details in a CREDITCARD
+ RR so that it MAY be queried as needed for automated billing
+ purposes. In addition, any outside entity with whom the customer
+
+
+
+Rye & Beverly Informational [Page 4]
+
+RFC 8567 Customer Management over DNS 1 April 2019
+
+
+ develops a recurring payment plan MAY query this RR for payment
+ details as well. Storing payment information in an RR, rather than
+ in the databases of disparate organizations with varying data
+ security postures, helps reduce attack vectors available to malicious
+ actors seeking this data.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | CARDNUMBER |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | EXPIRE |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CHECKSUM |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 2: CREDITCARD RDATA Format
+
+ Where:
+
+ CARDNUMBER
+ The <character-string> 16-digit credit card number used for
+ billing by the host's service provider. This field MUST NOT
+ contain punctuation or spaces; only numeric digits
+ represented in ASCII are allowed. Because this field is 16
+ digits in length, users MUST NOT use American Express cards.
+
+ EXPIRE
+ A <character-string> specifying the two-digit month and two-
+ digit year in which the credit card expires. This field MUST
+ NOT contain punctuation or spaces; only numeric digits
+ represented in ASCII are allowed.
+
+ CHECKSUM
+ In order to protect against bit errors occurring in the
+ CARDNUMBER field, this RR type MUST use error checking as
+ follows: Luhn's algorithm is employed as a simple checksum to
+ validate that none of the 16 digits were corrupted in
+ transit. Starting with the leftmost digit, we add this
+ digit's value to a running total; for every second digit
+ (beginning with the second-from-left digit), we add twice its
+ value to the running total. This algorithm continues until
+ all 16 digits have been exhausted. With this partial sum in
+
+
+
+
+
+Rye & Beverly Informational [Page 5]
+
+RFC 8567 Customer Management over DNS 1 April 2019
+
+
+ hand, we solve for the value x such that x added to our
+ partial sum is congruent to 0 modulo 10, and store x in the
+ CHECKSUM field.
+
+ When a CREDITCARD RR is queried, the recipient simply
+ computes Luhn's algorithm in the same manner as described
+ above, and validates that their computed value of x matches
+ that stored in the CHECKSUM field.
+
+ Note that this novel use of Luhn's algorithm MAY have
+ applications outside of the CREDITCARD RR.
+
+2.3. The SSN Resource Record
+
+ The SSN RR maps hostnames to the US Social Security number and birth
+ date of a user located at that host. For CPE behind which multiple
+ users reside, a separate SSN RR SHOULD be entered into the DNS for
+ each user. When residential broadband service becomes available
+ outside of the United States, those countries SHOULD adopt
+ identifiers that are compatible with the US SSN in order to ease
+ administrative burden on the DNS and multinational service providers.
+
+ During tax preparation season, the United States Internal Revenue
+ Service WILL query the SSN RR to verify residency and proof of
+ hostname ownership. In addition, the SSN RR MAY be used in
+ conjunction with the CREDITCARD RR to automate the collection of back
+ taxes owed.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SOCIAL |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BIRTHDATE |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 3: SSN RDATA Format
+
+ Where:
+
+ SOCIAL
+ The Social Security number of the user associated with the
+ host, formatted as a 32-bit unsigned integer in network byte
+ order.
+
+
+
+
+
+
+Rye & Beverly Informational [Page 6]
+
+RFC 8567 Customer Management over DNS 1 April 2019
+
+
+ BIRTHDATE
+ A 64-bit timestamp representing the number of seconds past the
+ Unix Epoch that the individual described by this RR was born.
+ Because the Unix Epoch predates the birth of all Internet
+ users, this field provides a sufficient range of values for
+ ISPs to describe their subscribers. The 64-bit timestamp field
+ is also "future proof", avoiding the Year 2038 problem and
+ ensuring SSN RR applicability into the foreseeable future.
+
+2.4. The SSNPTR Resource Record
+
+ The SSNPTR RR provides the reverse functionality of the SSN RR; it
+ maps Social Security numbers to hostnames. Every individual for whom
+ an ISP provides service, not only primary account holders, SHOULD
+ have an SSNPTR RR entry in the DNS.
+
+ One benefit provided by the SSNPTR RR is the ability to conduct some
+ population census functions remotely. For example, consider a
+ residential ISP with SSNPTR RRs for each of its subscribers.
+ Performing SSNPTR queries for all of their SSNs returns the host at
+ which those individuals are located, allowing for the trivial
+ association of family members behind the same CPE device. Further,
+ these hosts can then be geolocated using an IP geolocation service or
+ LOC RR [RFC1876], providing the ability to determine municipal
+ populations and thereby inform decisions about appropriations and
+ appropriate public policies.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / DNAME /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 4: SSNPTR RDATA Format
+
+ Where:
+
+ DNAME A <domain-name> that points to a location in the domain name
+ space.
+
+3. Related RR Types
+
+ The practice of introducing new RR types to the DNS to support
+ functionality that is either only tangentially related or wholly
+ unrelated to name resolution is well established.
+
+
+
+
+
+
+Rye & Beverly Informational [Page 7]
+
+RFC 8567 Customer Management over DNS 1 April 2019
+
+
+ [RFC2539] describes the Diffie-Hellman KEY RR type, which is used to
+ conveniently store public key parameters for a domain. The SRV RR
+ type [RFC2782] combines name resolution with transport- and
+ application-layer details, providing a "no-fuss" way for network
+ administrators to advertise the location of specific services. The
+ Name Authority PTR (NAPTR) RR [RFC2915] recognized and corrected the
+ lack of POSIX Extended Regular Expression support in the DNS,
+ allowing for DNS-based automobile parts identification systems
+ [RFC3402] among other use cases. Having established the DNS's role
+ in encryption in [RFC2539], the IPSECKEY RR resurrected the since-
+ obsoleted ability to store public key parameters for the purposes of
+ IPsec encryption [RFC4025]. [RFC4255] codified the natural inter-
+ dependency between the Secure Shell (SSH) protocol [RFC4253] and DNS
+ by providing the SSHFP RR type, which is used to verify the host key
+ of a server.
+
+ Extending the idea of distributing public key parameters via DNS,
+ [RFC4398] introduced the CERT RR type to publish X.509 and PGP
+ certificates. [RFC4701] introduces the DHCID RR type to solve the
+ problem of Fully Qualified Domain Name (FQDN) collisions when Dynamic
+ Host Configuration Protocol (DHCP) clients make DNS updates after
+ obtaining a DHCP lease. The TLSA RR type [RFC6698] is used to
+ associate a TLS certificate with a domain, leveraging DNSSEC as the
+ binding, and the CAA RR type [RFC6844] specifies the Certificate
+ Authority allowed to issue certificates for a domain. The EUI48 and
+ EUI64 RR types specified in [RFC7043] seek to eliminate boundaries in
+ the TCP/IP model by creating, in essence, A records for MAC
+ addresses.
+
+4. IANA Considerations
+
+ This document has no IANA actions.
+
+5. Security Considerations
+
+ DNSSEC [RFC4033] SHOULD be used in conjunction with the PASSWORD,
+ CREDITCARD, SSN, and SSNPTR RR types to provide data integrity.
+ Employing DNSSEC ensures that the data contained in these RRs
+ originates from an authoritative source and is not, for example, an
+ attacker attempting to provide invalid login credentials in response
+ to a legitimate request for a PASSWORD RR.
+
+
+
+
+
+
+
+
+
+
+Rye & Beverly Informational [Page 8]
+
+RFC 8567 Customer Management over DNS 1 April 2019
+
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+6.2. Informative References
+
+ [CAMEL] Hubert, B., "The DNS Camel", March 2018,
+ <https://blog.powerdns.com/2018/03/22/
+ the-dns-camel-or-the-rise-in-dns-complexit/>.
+
+ [MIRAI] Antonakakis, M., April, T., Bailey, M., Bernhard, M.,
+ Bursztein, E., Cochran, J., Durumeric, Z., Halderman, J.,
+ Invernizzi, L., Kallitsis, M., Kumar, D., Lever, C., Ma,
+ Z., Mason, J., Menscher, D., Seaman, C., Sullivan, N.,
+ Thomas, K., and Y. Zhou, "Understanding the Mirai Botnet",
+ Proceedings of the 26th USENIX Security Symposium, August
+ 2017, <https://www.usenix.org/system/files/conference/
+ usenixsecurity17/sec17-antonakakis.pdf>.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+ <https://www.rfc-editor.org/info/rfc1034>.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+ November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+
+ [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A
+ Means for Expressing Location Information in the Domain
+ Name System", RFC 1876, DOI 10.17487/RFC1876, January
+ 1996, <https://www.rfc-editor.org/info/rfc1876>.
+
+ [RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
+ Domain Name System (DNS)", RFC 2539, DOI 10.17487/RFC2539,
+ March 1999, <https://www.rfc-editor.org/info/rfc2539>.
+
+
+
+
+
+
+
+Rye & Beverly Informational [Page 9]
+
+RFC 8567 Customer Management over DNS 1 April 2019
+
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ DOI 10.17487/RFC2782, February 2000,
+ <https://www.rfc-editor.org/info/rfc2782>.
+
+ [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
+ (NAPTR) DNS Resource Record", RFC 2915,
+ DOI 10.17487/RFC2915, September 2000,
+ <https://www.rfc-editor.org/info/rfc2915>.
+
+ [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
+ Part Two: The Algorithm", RFC 3402, DOI 10.17487/RFC3402,
+ October 2002, <https://www.rfc-editor.org/info/rfc3402>.
+
+ [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
+ Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March
+ 2005, <https://www.rfc-editor.org/info/rfc4025>.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and
+ S. Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, DOI 10.17487/RFC4033, March 2005,
+ <https://www.rfc-editor.org/info/rfc4033>.
+
+ [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+ Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
+ January 2006, <https://www.rfc-editor.org/info/rfc4253>.
+
+ [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
+ Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
+ DOI 10.17487/RFC4255, January 2006,
+ <https://www.rfc-editor.org/info/rfc4255>.
+
+ [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name
+ System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006,
+ <https://www.rfc-editor.org/info/rfc4398>.
+
+ [RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource
+ Record (RR) for Encoding Dynamic Host Configuration
+ Protocol (DHCP) Information (DHCID RR)", RFC 4701,
+ DOI 10.17487/RFC4701, October 2006,
+ <https://www.rfc-editor.org/info/rfc4701>.
+
+ [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
+ of Named Entities (DANE) Transport Layer Security (TLS)
+ Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
+ 2012, <https://www.rfc-editor.org/info/rfc6698>.
+
+
+
+
+
+Rye & Beverly Informational [Page 10]
+
+RFC 8567 Customer Management over DNS 1 April 2019
+
+
+ [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification
+ Authority Authorization (CAA) Resource Record", RFC 6844,
+ DOI 10.17487/RFC6844, January 2013,
+ <https://www.rfc-editor.org/info/rfc6844>.
+
+ [RFC7043] Abley, J., "Resource Records for EUI-48 and EUI-64
+ Addresses in the DNS", RFC 7043, DOI 10.17487/RFC7043,
+ October 2013, <https://www.rfc-editor.org/info/rfc7043>.
+
+ [SAMKNOWS]
+ Crawford, S., "SamKnows: The Internet Measurement
+ Standard", <https://samknows.com/>.
+
+Acknowledgements
+
+ We thank the US Federal Communications Commission for the repeal of
+ network neutrality legislation, allowing ISPs to provide their
+ customers with the level and type of service that ISPs have come to
+ expect.
+
+ We also thank Bert Hubert for identifying the dearth of DNS RR
+ standards in his blog post and IETF lecture entitled The DNS Camel
+ [CAMEL], so named for the drought of DNS-enabled functionality of the
+ last several decades.
+
+Authors' Addresses
+
+ Erik C. Rye
+ CMAND
+ 1 University Circle
+ Monterey, CA 93943
+ United States of America
+
+ Email: rye@cmand.org
+
+
+ Robert Beverly
+ CMAND
+ 1 University Circle
+ Monterey, CA 93943
+ United States of America
+
+ Email: rbeverly@cmand.org
+
+
+
+
+
+
+
+
+Rye & Beverly Informational [Page 11]
+