RFC 8567

Customer Management DNS Resource Records

📅 published April 2019, from ietf

Customer Management DNS Resource Records 🌸

Okay bestie, let's get into RFC 8567 💖 It's titled Customer Management DNS Resource Records, and it came in as an Independent Submission, so it wasn't produced by an IETF working group. Its category is Informational, its ISSN is 2070-1721, and it's dated 1 April 2019. The authors are E. Rye and R. Beverly, and CMAND is listed in the header next to them 🎀 The title block doesn't list anything it obsoletes or updates, so this one's a solo main character 🦋

Abstract 🦋

Okay so, keeping customers happy (that's Quality of Experience, or QoE) is getting harder 😭 Network management has to be end-to-end and holistic now, and that includes the managed Customer Premises Equipment (CPE) sitting in people's homes. Customer management is a shared global responsibility, so the Domain Name System (DNS) is the perfect existing infrastructure for storing authoritative customer info that has to be easy to reach, reliable, and publicly accessible ✨

This doc describes four brand-new DNS resource record types for encoding customer information in the DNS. The goal is to boost customer QoE through cooperation between providers and smarter handling of customer data 💅

Status of This Memo 🎀

This doc is not an Internet Standards Track specification. It's published for informational purposes 💜

It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard, see Section 2 of RFC 7841 🙈

For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc8567 🌈

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved ✨

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read those carefully, because they spell out your rights and restrictions for 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 big chunk of today's Internet is residential access networks 🏠 These networks and their providers are now critical infrastructure, which is why so much research goes into measuring residential broadband speed and reliability [SAMKNOWS] 📶

Here's the tea, though: Customer Premises Equipment (CPE) is one of the weakest links between consumers and the Internet 💀 Customers usually don't do proactive maintenance, like firmware updates, on their own CPE. In lots of cases the CPE even ships with default authentication credentials, and various Internet-wide denial-of-service attacks have exploited that [MIRAI] 😭

The central idea here is that customers simply can't be trusted to manage their own networks, let alone the path-critical CPE. Since keeping broadband access healthy and resilient is so hard, CPE maintenance should be treated as a shared global responsibility among Internet Service Providers (ISPs) 🫶

Choice of ISP complicates things too. Nearly half of US households have that choice right now 🇺🇸 Customers can switch providers, but their biographical, billing, and technological details stay the same. So service providers need mechanisms that make moving customers in and out of their network as seamless as possible, both technically and for billing 💅

Last but not least, service providers, advertisers, and law enforcement agencies all have different (but important) reasons to track unique users' behavior on the Internet 👀 RFC 7043 [RFC7043] uses the EUI48 and EUI64 Resource Record (RR) types to uniquely identify CPE devices and better support third-party tracking. The catch is that the customer can defeat those mechanisms just by buying new CPE 🙈

This document takes a holistic, end-to-end view of customer management, with the aim of boosting customer QoE and overall network security 🔥 To make shared CPE maintenance possible, it leverages the Domain Name System (DNS), described in RFC 1034 [RFC1034] and RFC 1035 [RFC1035], and introduces new RR types to help with network management 🦋

1.1. Terminology 💜

This doc uses capitalized keywords like MUST and MAY to describe the requirements for using the registered RR types. Those keywords mean the same thing here as they do in RFC 2119 [RFC2119] and RFC 8174 [RFC8174] 🎀 They're often used for normative requirements in IETF Standards, but using them in this document doesn't make it a standard of any kind 🌸

2. Customer Management Resource Records 👑

The ubiquity of residential broadband is amazing for consumers, but it's also a daunting challenge for Internet Service Providers. How do they best manage sensitive customer identifiers and billing details while keeping the CPE devices on their network resilient and secure? 😩

This document introduces four new RRs to help ISPs manage customer data ✨

This section covers the purpose and wire format of the new DNS RRs 🧚

2.1. The PASSWORD Resource Record 🔐

The PASSWORD RR makes remote management of CPE devices possible by storing the login credentials for the CPE in a single RR 🗝️ Authorized service providers use these credentials to authenticate to the CPE. Once they're authenticated, they can install important software and configuration updates that keep the provider's network secure and healthy 🌈

    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. 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. To keep the RR size to a minimum, passwords longer than 32 bits are not supported 🙃

Hosts with multiple accounts SHOULD have a separate PASSWORD RR for each account. 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 💅 When an ISP gets a new subscriber, it enters their billing details in a CREDITCARD RR so that it MAY be queried as needed for automated billing. Any outside entity the customer sets up a recurring payment plan with MAY query this RR for payment details too 🧾

Storing payment info in an RR, instead of in the databases of a bunch of different organizations with varying data security postures, helps cut down the attack vectors that malicious actors can use to get at this data 🛡️ Major "keep it safe" energy, periodt ✨

    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 long, users MUST NOT use American Express cards 🙅‍♀️
  • EXPIRE: A <character-string> giving 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: To protect against bit errors in the CARDNUMBER field, this RR type MUST use error checking, as follows. Luhn's algorithm acts as a simple checksum to confirm that none of the 16 digits got corrupted in transit ✨ Starting from the leftmost digit, add that digit's value to a running total. For every second digit (beginning with the second-from-left one), add twice its value to the running total. Keep going until all 16 digits are used up. With that partial sum in hand, solve for the value x such that x plus the partial sum is congruent to 0 modulo 10, then store x in the CHECKSUM field 🧮

When a CREDITCARD RR is queried, the recipient just computes Luhn's algorithm the same way as above, and checks that their computed value of x matches the one 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 🎀

okay bestie, the SSN RR maps hostnames to the US Social Security number and birth date of a user living at that host 🫶 when there's CPE with multiple users behind it, each user needs their own SSN RR, so a separate SSN RR SHOULD be entered into the DNS for each user. and ngl, when residential broadband shows up outside the United States, those countries SHOULD adopt identifiers that are compatible with the US SSN so the DNS and multinational providers don't have a whole admin headache 💅

during tax season, the United States Internal Revenue Service WILL query the SSN RR to verify residency and proof of hostname ownership 😭 and the SSN RR MAY be used together 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

Here's what the fields mean, bestie 🌸

  • SOCIAL: the Social Security number of the user associated with the host, formatted as a 32-bit unsigned integer in network byte order.
  • BIRTHDATE: a 64-bit timestamp counting the number of seconds past the Unix Epoch when the individual described by this RR was born. The Unix Epoch comes before the birth of every Internet user, so this field has a big enough range for ISPs to describe their subscribers 🧚 The 64-bit timestamp is also "future proof", dodging the Year 2038 problem and keeping SSN RR applicable well into the foreseeable future ⭐

2.4. The SSNPTR Resource Record 🦋

the SSNPTR RR is the reverse of the SSN RR, so it maps Social Security numbers to hostnames 🔄 Every individual an ISP serves, not just the primary account holders, SHOULD have an SSNPTR RR entry in the DNS.

one benefit of the SSNPTR RR is that you can run some population census functions remotely 👀 imagine a residential ISP with SSNPTR RRs for each of its subscribers. querying all of their SSNs returns the host where those individuals are located, which makes it super easy to link family members behind the same CPE device 🙈 and then those hosts can be geolocated with an IP geolocation service or LOC RR [RFC1876], so you can figure out municipal populations and use that to inform decisions about appropriations and public policies. it's giving surveillance energy, not okay 💀

    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

  • DNAME: a <domain-name> that points to a location in the domain name space.

the practice of adding new RR types to the DNS for stuff that's only tangentially related to name resolution, or totally unrelated, is very well established 💅

[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, giving network admins a "no-fuss" way to advertise where specific services live ✨ The Name Authority PTR (NAPTR) RR [RFC2915] recognized and fixed the DNS's lack of POSIX Extended Regular Expression support, which allowed DNS-based automobile parts identification systems [RFC3402] among other use cases 🚗 Having already established the DNS's role in encryption in [RFC2539], the IPSECKEY RR brought back the ability to store public key parameters for IPsec encryption [RFC4025], even though it had been obsoleted 🔥 [RFC4255] codified the natural relationship between the Secure Shell (SSH) protocol [RFC4253] and DNS with the SSHFP RR type, which is used to verify the host key of a server 🫶

extending the idea of distributing public keys through 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 getting a DHCP lease 🎀 The TLSA RR type [RFC6698] associates a TLS certificate with a domain, using DNSSEC as the binding, and the CAA RR type [RFC6844] specifies which Certificate Authority is allowed to issue certificates for a domain 🦋 The EUI48 and EUI64 RR types specified in [RFC7043] try to erase the boundaries in the TCP/IP model by basically creating A records for MAC addresses 🧚

4. IANA Considerations 💖

this document has no IANA actions, so no registry drama here ✨

5. Security Considerations 🚨

bestie, this one is serious. DNSSEC [RFC4033] SHOULD be used alongside the PASSWORD, CREDITCARD, SSN, and SSNPTR RR types to provide data integrity 🔐 Using DNSSEC makes sure the data in these RRs actually comes from an authoritative source, and not from an attacker trying to hand over invalid login credentials in response to a legit request for a PASSWORD RR 😭 No cap, skipping this is how people get hurt.

6. References 📚

6.1. Normative References

6.2. Informative References

Acknowledgements 💖

we thank the US Federal Communications Commission for the repeal of network neutrality legislation 🙄 which lets ISPs give their customers the level and type of service that ISPs have come to expect. iconic behavior, truly 💅

we also thank Bert Hubert for pointing out the dearth of DNS RR standards in his blog post and IETF lecture, The DNS Camel [CAMEL] 🐪 It's named that because of the drought of DNS-enabled functionality over the last several decades. so relatable 😭

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

📦 where this page comes from