1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
|
<pre>Independent Submission E. Rye
Request for Comments: 8567 R. Beverly
Category: Informational CMAND
ISSN: 2070-1721 1 April 2019
<span class="h1">Customer Management DNS Resource Records</span>
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 <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8567">https://www.rfc-editor.org/info/rfc8567</a>.
<span class="grey">Rye & Beverly Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8567">RFC 8567</a> Customer Management over DNS 1 April 2019</span>
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) 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
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Customer Management Resource Records . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. The PASSWORD Resource Record . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. The CREDITCARD Resource Record . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.3">2.3</a>. The SSN Resource Record . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.4">2.4</a>. The SSNPTR Resource Record . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3">3</a>. Related RR Types . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4">4</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6">6</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6.1">6.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6.2">6.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
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 [<a href="#ref-SAMKNOWS">SAMKNOWS</a>].
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 [<a href="#ref-MIRAI" title=""Understanding the Mirai Botnet"">MIRAI</a>].
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
<span class="grey">Rye & Beverly Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8567">RFC 8567</a> Customer Management over DNS 1 April 2019</span>
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 <a href="./rfc7043">RFC 7043</a> [<a href="./rfc7043" title=""Resource Records for EUI-48 and EUI-64 Addresses in the DNS"">RFC7043</a>] 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 <a href="./rfc1034">RFC 1034</a> [<a href="./rfc1034" title=""Domain names - concepts and facilities"">RFC1034</a>] and
<a href="./rfc1035">RFC 1035</a> [<a href="./rfc1035" title=""Domain names - implementation and specification"">RFC1035</a>], and introduces new RR types to aid network
management.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] and <a href="./rfc8174">RFC 8174</a> [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>].
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.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Customer Management Resource Records</span>
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.
<span class="grey">Rye & Beverly Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8567">RFC 8567</a> Customer Management over DNS 1 April 2019</span>
This section describes the purpose and wire format of the new DNS
RRs.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. The PASSWORD Resource Record</span>
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.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. The CREDITCARD Resource Record</span>
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
<span class="grey">Rye & Beverly Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8567">RFC 8567</a> Customer Management over DNS 1 April 2019</span>
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
<span class="grey">Rye & Beverly Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8567">RFC 8567</a> Customer Management over DNS 1 April 2019</span>
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.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. The SSN Resource Record</span>
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.
<span class="grey">Rye & Beverly Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8567">RFC 8567</a> Customer Management over DNS 1 April 2019</span>
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.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. The SSNPTR Resource Record</span>
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 [<a href="./rfc1876" title=""A Means for Expressing Location Information in the Domain Name System"">RFC1876</a>], 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.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Related RR Types</span>
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.
<span class="grey">Rye & Beverly Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8567">RFC 8567</a> Customer Management over DNS 1 April 2019</span>
[<a id="ref-RFC2539">RFC2539</a>] describes the Diffie-Hellman KEY RR type, which is used to
conveniently store public key parameters for a domain. The SRV RR
type [<a href="./rfc2782" title=""A DNS RR for specifying the location of services (DNS SRV)"">RFC2782</a>] 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 [<a href="./rfc2915" title=""The Naming Authority Pointer (NAPTR) DNS Resource Record"">RFC2915</a>] recognized and corrected the
lack of POSIX Extended Regular Expression support in the DNS,
allowing for DNS-based automobile parts identification systems
[<a href="./rfc3402" title=""Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm"">RFC3402</a>] among other use cases. Having established the DNS's role
in encryption in [<a href="./rfc2539" title=""Storage of Diffie-Hellman Keys in the Domain Name System (DNS)"">RFC2539</a>], the IPSECKEY RR resurrected the since-
obsoleted ability to store public key parameters for the purposes of
IPsec encryption [<a href="./rfc4025" title=""A Method for Storing IPsec Keying Material in DNS"">RFC4025</a>]. [<a href="./rfc4255" title=""Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints"">RFC4255</a>] codified the natural inter-
dependency between the Secure Shell (SSH) protocol [<a href="./rfc4253" title=""The Secure Shell (SSH) Transport Layer Protocol"">RFC4253</a>] 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,
[<a href="./rfc4398" title=""Storing Certificates in the Domain Name System (DNS)"">RFC4398</a>] introduced the CERT RR type to publish X.509 and PGP
certificates. [<a href="./rfc4701" title=""A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)"">RFC4701</a>] 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 [<a href="./rfc6698" title=""The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA"">RFC6698</a>] is used to
associate a TLS certificate with a domain, leveraging DNSSEC as the
binding, and the CAA RR type [<a href="./rfc6844" title=""DNS Certification Authority Authorization (CAA) Resource Record"">RFC6844</a>] specifies the Certificate
Authority allowed to issue certificates for a domain. The EUI48 and
EUI64 RR types specified in [<a href="./rfc7043" title=""Resource Records for EUI-48 and EUI-64 Addresses in the DNS"">RFC7043</a>] seek to eliminate boundaries in
the TCP/IP model by creating, in essence, A records for MAC
addresses.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
This document has no IANA actions.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
DNSSEC [<a href="./rfc4033" title=""DNS Security Introduction and Requirements"">RFC4033</a>] 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.
<span class="grey">Rye & Beverly Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8567">RFC 8567</a> Customer Management over DNS 1 April 2019</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-CAMEL">CAMEL</a>] Hubert, B., "The DNS Camel", March 2018,
<<a href="https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/">https://blog.powerdns.com/2018/03/22/</a>
<a href="https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/">the-dns-camel-or-the-rise-in-dns-complexit/</a>>.
[<a id="ref-MIRAI">MIRAI</a>] 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, <<a href="https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-antonakakis.pdf">https://www.usenix.org/system/files/conference/</a>
<a href="https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-antonakakis.pdf">usenixsecurity17/sec17-antonakakis.pdf</a>>.
[<a id="ref-RFC1034">RFC1034</a>] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, <a href="./rfc1034">RFC 1034</a>, DOI 10.17487/RFC1034, November 1987,
<<a href="https://www.rfc-editor.org/info/rfc1034">https://www.rfc-editor.org/info/rfc1034</a>>.
[<a id="ref-RFC1035">RFC1035</a>] Mockapetris, P., "Domain names - implementation and
specification", STD 13, <a href="./rfc1035">RFC 1035</a>, DOI 10.17487/RFC1035,
November 1987, <<a href="https://www.rfc-editor.org/info/rfc1035">https://www.rfc-editor.org/info/rfc1035</a>>.
[<a id="ref-RFC1876">RFC1876</a>] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A
Means for Expressing Location Information in the Domain
Name System", <a href="./rfc1876">RFC 1876</a>, DOI 10.17487/RFC1876, January
1996, <<a href="https://www.rfc-editor.org/info/rfc1876">https://www.rfc-editor.org/info/rfc1876</a>>.
[<a id="ref-RFC2539">RFC2539</a>] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", <a href="./rfc2539">RFC 2539</a>, DOI 10.17487/RFC2539,
March 1999, <<a href="https://www.rfc-editor.org/info/rfc2539">https://www.rfc-editor.org/info/rfc2539</a>>.
<span class="grey">Rye & Beverly Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8567">RFC 8567</a> Customer Management over DNS 1 April 2019</span>
[<a id="ref-RFC2782">RFC2782</a>] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", <a href="./rfc2782">RFC 2782</a>,
DOI 10.17487/RFC2782, February 2000,
<<a href="https://www.rfc-editor.org/info/rfc2782">https://www.rfc-editor.org/info/rfc2782</a>>.
[<a id="ref-RFC2915">RFC2915</a>] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", <a href="./rfc2915">RFC 2915</a>,
DOI 10.17487/RFC2915, September 2000,
<<a href="https://www.rfc-editor.org/info/rfc2915">https://www.rfc-editor.org/info/rfc2915</a>>.
[<a id="ref-RFC3402">RFC3402</a>] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm", <a href="./rfc3402">RFC 3402</a>, DOI 10.17487/RFC3402,
October 2002, <<a href="https://www.rfc-editor.org/info/rfc3402">https://www.rfc-editor.org/info/rfc3402</a>>.
[<a id="ref-RFC4025">RFC4025</a>] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", <a href="./rfc4025">RFC 4025</a>, DOI 10.17487/RFC4025, March
2005, <<a href="https://www.rfc-editor.org/info/rfc4025">https://www.rfc-editor.org/info/rfc4025</a>>.
[<a id="ref-RFC4033">RFC4033</a>] Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "DNS Security Introduction and Requirements",
<a href="./rfc4033">RFC 4033</a>, DOI 10.17487/RFC4033, March 2005,
<<a href="https://www.rfc-editor.org/info/rfc4033">https://www.rfc-editor.org/info/rfc4033</a>>.
[<a id="ref-RFC4253">RFC4253</a>] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", <a href="./rfc4253">RFC 4253</a>, DOI 10.17487/RFC4253,
January 2006, <<a href="https://www.rfc-editor.org/info/rfc4253">https://www.rfc-editor.org/info/rfc4253</a>>.
[<a id="ref-RFC4255">RFC4255</a>] Schlyter, J. and W. Griffin, "Using DNS to Securely
Publish Secure Shell (SSH) Key Fingerprints", <a href="./rfc4255">RFC 4255</a>,
DOI 10.17487/RFC4255, January 2006,
<<a href="https://www.rfc-editor.org/info/rfc4255">https://www.rfc-editor.org/info/rfc4255</a>>.
[<a id="ref-RFC4398">RFC4398</a>] Josefsson, S., "Storing Certificates in the Domain Name
System (DNS)", <a href="./rfc4398">RFC 4398</a>, DOI 10.17487/RFC4398, March 2006,
<<a href="https://www.rfc-editor.org/info/rfc4398">https://www.rfc-editor.org/info/rfc4398</a>>.
[<a id="ref-RFC4701">RFC4701</a>] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource
Record (RR) for Encoding Dynamic Host Configuration
Protocol (DHCP) Information (DHCID RR)", <a href="./rfc4701">RFC 4701</a>,
DOI 10.17487/RFC4701, October 2006,
<<a href="https://www.rfc-editor.org/info/rfc4701">https://www.rfc-editor.org/info/rfc4701</a>>.
[<a id="ref-RFC6698">RFC6698</a>] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", <a href="./rfc6698">RFC 6698</a>, DOI 10.17487/RFC6698, August
2012, <<a href="https://www.rfc-editor.org/info/rfc6698">https://www.rfc-editor.org/info/rfc6698</a>>.
<span class="grey">Rye & Beverly Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8567">RFC 8567</a> Customer Management over DNS 1 April 2019</span>
[<a id="ref-RFC6844">RFC6844</a>] Hallam-Baker, P. and R. Stradling, "DNS Certification
Authority Authorization (CAA) Resource Record", <a href="./rfc6844">RFC 6844</a>,
DOI 10.17487/RFC6844, January 2013,
<<a href="https://www.rfc-editor.org/info/rfc6844">https://www.rfc-editor.org/info/rfc6844</a>>.
[<a id="ref-RFC7043">RFC7043</a>] Abley, J., "Resource Records for EUI-48 and EUI-64
Addresses in the DNS", <a href="./rfc7043">RFC 7043</a>, DOI 10.17487/RFC7043,
October 2013, <<a href="https://www.rfc-editor.org/info/rfc7043">https://www.rfc-editor.org/info/rfc7043</a>>.
[<a id="ref-SAMKNOWS">SAMKNOWS</a>]
Crawford, S., "SamKnows: The Internet Measurement
Standard", <<a href="https://samknows.com/">https://samknows.com/</a>>.
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
[<a href="#ref-CAMEL" title=""The DNS Camel"">CAMEL</a>], 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]
</pre>
|
