1 Internet Engineering Task Force (IETF) S. Hollenbeck
2 Request for Comments: 8521 Verisign Labs
3 BCP: 221 A. Newton
4 Updates: 7484 ARIN
5 Category: Best Current Practice November 2018
6 ISSN: 2070-1721
7
8
9 Registration Data Access Protocol (RDAP) Object Tagging
10
11 Abstract
12
13 The Registration Data Access Protocol (RDAP) includes a method that
14 can be used to identify the authoritative server for processing
15 domain name, IP address, and autonomous system number queries. The
16 method does not describe how to identify the authoritative server for
17 processing other RDAP query types, such as entity queries. This
18 limitation exists because the identifiers associated with these query
19 types are typically unstructured. This document updates RFC 7484 by
20 describing an operational practice that can be used to add structure
21 to RDAP identifiers and that makes it possible to identify the
22 authoritative server for additional RDAP queries.
23
24 Status of This Memo
25
26 This memo documents an Internet Best Current Practice.
27
28 This document is a product of the Internet Engineering Task Force
29 (IETF). It represents the consensus of the IETF community. It has
30 received public review and has been approved for publication by the
31 Internet Engineering Steering Group (IESG). Further information on
32 BCPs is available in Section 2 of RFC 7841.
33
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 https://www.rfc-editor.org/info/rfc8521.
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Hollenbeck & Newton Best Current Practice [Page 1]
53 RFC 8521 RDAP Object Tagging November 2018
54
55
56 Copyright Notice
57
58 Copyright (c) 2018 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (https://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 Table of Contents
72
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
74 2. Object Naming Practice . . . . . . . . . . . . . . . . . . . 3
75 3. Bootstrap Service Registry for Provider Object Tags . . . . . 9
76 3.1. Registration Procedure . . . . . . . . . . . . . . . . . 10
77 4. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 10
78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
79 5.1. Bootstrap Service Registry Structure . . . . . . . . . . 11
80 5.2. RDAP Extensions Registry . . . . . . . . . . . . . . . . 11
81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
83 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
84 7.2. Informative References . . . . . . . . . . . . . . . . . 12
85 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Hollenbeck & Newton Best Current Practice [Page 2]
108 RFC 8521 RDAP Object Tagging November 2018
109
110
111 1. Introduction
112
113 The Registration Data Access Protocol (RDAP) includes a method
114 [RFC7484] that can be used to identify the authoritative server for
115 processing domain name, IP address, and Autonomous System Number
116 (ASN) queries. This method works because each of these data elements
117 is structured in a way that facilitates automated parsing of the
118 element and association of the data element with a particular RDAP
119 service provider. For example, domain names include labels (such as
120 "com", "net", and "org") that are associated with specific service
121 providers.
122
123 As noted in Section 9 of RFC 7484 [RFC7484], the method does not
124 describe how to identify the authoritative server for processing
125 entity queries, name server queries, help queries, or queries using
126 certain search patterns. This limitation exists because the
127 identifiers bound to these queries are typically not structured in a
128 way that makes it easy to associate an identifier with a specific
129 service provider. This document describes an operational practice
130 that can be used to add structure to RDAP identifiers and makes it
131 possible to identify the authoritative server for additional RDAP
132 queries.
133
134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
136 "OPTIONAL" in this document are to be interpreted as described in BCP
137 14 [RFC2119] [RFC8174] when, and only when, they appear in all
138 capitals, as shown here.
139
140 2. Object Naming Practice
141
142 Tagging object identifiers with a service provider tag makes it
143 possible to identify the authoritative server for processing an RDAP
144 query using the method described in RFC 7484 [RFC7484]. A service
145 provider tag is constructed by prepending the Unicode HYPHEN-MINUS
146 character "-" (U+002D, described as an "unreserved" character in RFC
147 3986 [RFC3986]) to an IANA-registered value that represents the
148 service provider. For example, a tag for a service provider
149 identified by the string value "ARIN" is represented as "-ARIN".
150
151 In combination with the rdapConformance attribute described in
152 Section 4, service provider tags are concatenated to the end of RDAP
153 query object identifiers to unambiguously identify the authoritative
154 server for processing an RDAP query. Building on the example from
155 Section 3.1.5 of RFC 7482 [RFC7482], an RDAP entity handle can be
156 constructed to allow an RDAP client to bootstrap an entity query.
157
158
159
160
161
162 Hollenbeck & Newton Best Current Practice [Page 3]
163 RFC 8521 RDAP Object Tagging November 2018
164
165
166 The following identifier is used to find information for the entity
167 associated with handle "XXXX" at service provider "ARIN":
168
169 XXXX-ARIN
170
171 Clients that wish to bootstrap an entity query can parse this
172 identifier into distinct handle and service provider identifier
173 elements. Handles can themselves contain HYPHEN-MINUS characters;
174 the service provider identifier is found following the last HYPHEN-
175 MINUS character in the tagged identifier. The service provider
176 identifier is used to retrieve a base RDAP URL from an IANA registry.
177 The base URL and entity handle are then used to form a complete RDAP
178 query path segment. For example, if the base RDAP URL
179 "https://example.com/rdap/" is associated with service provider
180 "YYYY" in an IANA registry, an RDAP client will parse a tagged entity
181 identifier "XXXX-YYYY" into distinct handle ("XXXX") and service
182 provider ("YYYY") identifiers. The service provider identifier
183 "YYYY" is used to query an IANA registry to retrieve the base RDAP
184 URL "https://example.com/rdap/". The RDAP query URL is formed using
185 the base RDAP URL and entity path segment described in Section 3.1.5
186 of RFC 7482 [RFC7482] and using "XXXX-YYY" as the value of the handle
187 identifier. The complete RDAP query URL becomes
188 "https://example.com/rdap/entity/XXXX-YYYY".
189
190 Implementation of this practice requires tagging of unstructured
191 potential query identifiers in RDAP responses. Consider these elided
192 examples ("..." is used to note elided response objects) from
193 Section 5.3 of RFC 7483 [RFC7483] in which the handle identifiers
194 have been tagged with service provider tags "RIR", "DNR", and "ABC",
195 respectively:
196
197 {
198 "objectClassName" : "domain",
199 "handle" : "XXXX-RIR",
200 "ldhName" : "0.2.192.in-addr.arpa",
201 "nameservers" :
202 [
203 ...
204 ],
205 "secureDNS":
206 {
207 ...
208 },
209 "remarks" :
210 [
211 ...
212 ],
213 "links" :
214
215
216
217 Hollenbeck & Newton Best Current Practice [Page 4]
218 RFC 8521 RDAP Object Tagging November 2018
219
220
221 [
222 ...
223 ],
224 "events" :
225 [
226 ...
227 ],
228 "entities" :
229 [
230 {
231 "objectClassName" : "entity",
232 "handle" : "XXXX-RIR",
233 "vcardArray":
234 [
235 ...
236 ],
237 "roles" : [ "registrant" ],
238 "remarks" :
239 [
240 ...
241 ],
242 "links" :
243 [
244 ...
245 ],
246 "events" :
247 [
248 ...
249 ]
250 }
251 ],
252 "network" :
253 {
254 "objectClassName" : "ip network",
255 "handle" : "XXXX-RIR",
256 "startAddress" : "192.0.2.0",
257 "endAddress" : "192.0.2.255",
258 "ipVersion" : "v4",
259 "name": "NET-RTR-1",
260 "type" : "DIRECT ALLOCATION",
261 "country" : "AU",
262 "parentHandle" : "YYYY-RIR",
263 "status" : [ "active" ]
264 }
265 }
266
267 Figure 1
268
269
270
271
272 Hollenbeck & Newton Best Current Practice [Page 5]
273 RFC 8521 RDAP Object Tagging November 2018
274
275
276 {
277 "objectClassName" : "domain",
278 "handle" : "XXXX-YYY-DNR",
279 "ldhName" : "xn--fo-5ja.example",
280 "unicodeName" : "foo.example",
281 "variants" :
282 [
283 ...
284 ],
285 "status" : [ "locked", "transfer prohibited" ],
286 "publicIds":
287 [
288 ...
289 ],
290 "nameservers" :
291 [
292 {
293 "objectClassName" : "nameserver",
294 "handle" : "XXXX-DNR",
295 "ldhName" : "ns1.example.com",
296 "status" : [ "active" ],
297 "ipAddresses" :
298 {
299 ...
300 },
301 "remarks" :
302 [
303 ...
304 ],
305 "links" :
306 [
307 ...
308 ],
309 "events" :
310 [
311 ...
312 ]
313 },
314 {
315 "objectClassName" : "nameserver",
316 "handle" : "XXXX-DNR",
317 "ldhName" : "ns2.example.com",
318 "status" : [ "active" ],
319 "ipAddresses" :
320 {
321 ...
322 },
323 "remarks" :
324
325
326
327 Hollenbeck & Newton Best Current Practice [Page 6]
328 RFC 8521 RDAP Object Tagging November 2018
329
330
331 [
332 ...
333 ],
334 "links" :
335 [
336 ...
337 ],
338 "events" :
339 [
340 ...
341 ]
342 }
343 ],
344 "secureDNS":
345 {
346 ...
347 },
348 "remarks" :
349 [
350 ...
351 ],
352 "links" :
353 [
354 ...
355 ],
356 "port43" : "whois.example.net",
357 "events" :
358 [
359 ...
360 ],
361 "entities" :
362 [
363 {
364 "objectClassName" : "entity",
365 "handle" : "XXXX-ABC",
366 "vcardArray":
367 [
368 ...
369 ],
370 "status" : [ "validated", "locked" ],
371 "roles" : [ "registrant" ],
372 "remarks" :
373 [
374 ...
375 ],
376 "links" :
377 [
378 ...
379
380
381
382 Hollenbeck & Newton Best Current Practice [Page 7]
383 RFC 8521 RDAP Object Tagging November 2018
384
385
386 ],
387 "events" :
388 [
389 ...
390 ]
391 }
392 ]
393 }
394
395 Figure 2
396
397 As described in Section 5 of RFC 7483 [RFC7483], RDAP responses can
398 contain "self" links. Service provider tags and self references
399 SHOULD be consistent. If they are inconsistent, the service provider
400 tag is processed with higher priority when using these values to
401 identify a service provider.
402
403 There is a risk of unpredictable processing behavior if the HYPHEN-
404 MINUS character is used for naturally occurring, non-separator
405 purposes in an entity handle. This could lead to a client mistakenly
406 assuming that a HYPHEN-MINUS character represents a separator and
407 that the text that follows HYPHEN-MINUS is a service provider
408 identifier. A client that queries the IANA registry for what they
409 assume is a valid service provider will likely receive an unexpected,
410 invalid result. As a consequence, use of the HYPHEN-MINUS character
411 as a service provider tag separator MUST be noted by adding an
412 rdapConformance value to query responses as described in Section 4.
413
414 The HYPHEN-MINUS character was chosen as a separator for two reasons:
415 1) it is a familiar separator character in operational use, and 2) it
416 avoids collision with URI-reserved characters. The list of
417 unreserved characters specified in Section 2.3 of RFC 3986 [RFC3986]
418 provided multiple options for consideration:
419
420 unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
421
422 ALPHA and DIGIT characters were excluded because they are commonly
423 used in entity handles for non-separator purposes. HYPHEN-MINUS is
424 commonly used as a separator, and recognition of this practice will
425 reduce implementation requirements and operational risk. The
426 remaining characters were excluded because they are not broadly used
427 as separators in entity handles.
428
429
430
431
432
433
434
435
436
437 Hollenbeck & Newton Best Current Practice [Page 8]
438 RFC 8521 RDAP Object Tagging November 2018
439
440
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
441 3. Bootstrap Service Registry for Provider Object Tags
442
443 The bootstrap service registry for the RDAP service provider space is
444 represented using the structure specified in Section 3 of RFC 7484
445 [RFC7484]. The JSON output of this registry contains contact
446 information for the registered service provider identifiers,
447 alphanumeric identifiers that identify RDAP service providers, and
448 base RDAP service URLs as shown in this example.
449
450 {
451 "version": "1.0",
452 "publication": "YYYY-MM-DDTHH:MM:SSZ",
453 "description": "RDAP bootstrap file for service provider object tags",
454 "services": [
455 [
456 ["contact@example.com"],
457 ["YYYY"],
458 [
459 "https://example.com/rdap/"
460 ]
461 ],
462 [
463 ["contact@example.org"],
464 ["ZZ54"],
465 [
466 "http://rdap.example.org/"
467 ]
468 ],
469 [
470 ["contact@example.net"],
471 ["1754"],
472 [
473 "https://example.net/rdap/",
474 "http://example.net/rdap/"
475 ]
476 ]
477 ]
478 }
479
480 Figure 3
481
482 Alphanumeric service provider identifiers conform to the suffix
483 portion ("\w{1,8}") of the "roidType" syntax specified in Section 4.2
484 of RFC 5730 [RFC5730].
485
486
487
488
489
490
491
492 Hollenbeck & Newton Best Current Practice [Page 9]
493 RFC 8521 RDAP Object Tagging November 2018
494
495
496 3.1. Registration Procedure
497
498 The service provider registry is populated using the "First Come
499 First Served" policy defined in RFC 8126 [RFC8126]. Provider
500 identifier values can be derived and assigned by IANA on request.
501 Registration requests include an email address to be associated with
502 the registered service provider identifier, the requested service
503 provider identifier (or an indication that IANA should assign an
504 identifier), and one or more base RDAP URLs to be associated with the
505 service provider identifier.
506
The bootstrap service registry for the RDAP service provider space is represented using the structure specified in Section 3 of RFC 7484 [RFC7484].
The bootstrap service registry for the RDAP service provider space is based on the structure specified in Section 3 of RFC 7484 [RFC7484].
The registry structure specific in RFC 8521 includes an additional contact information field that does not appear in the structure defined in RFC 7484. So, the 8521 registry is not "represented using the structure specified in Section 3 of RFC 7484". It extends the structure with the addition of the contact field.
507 4. RDAP Conformance
508
509 RDAP responses that contain values described in this document MUST
510 indicate conformance with this specification by including an
511 rdapConformance [RFC7483] value of "rdap_objectTag_level_0". The
512 information needed to register this value in the "RDAP Extensions"
513 registry is described in Section 5.2.
514
515 The following is an example rdapConformance structure with the
516 extension specified.
517
518 "rdapConformance" :
519 [
520 "rdap_level_0",
521 "rdap_objectTag_level_0"
522 ]
523
524 Figure 4
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547 Hollenbeck & Newton Best Current Practice [Page 10]
548 RFC 8521 RDAP Object Tagging November 2018
549
550
551 5. IANA Considerations
552
553 IANA has created the RDAP "Bootstrap Service Registry for Provider
554 Object Tags" listed below and made it available as a JSON object.
555 The contents of this registry are described in Section 3; the formal
556 syntax is specified in Section 10 of RFC 7484 [RFC7484].
557
558 5.1. Bootstrap Service Registry Structure
559
560 Entries in this registry contain the following information:
561
562 o an email address that identifies a contact associated with the
563 registered RDAP service provider value.
564 o an alphanumeric value that identifies the RDAP service provider
565 being registered.
566 o one or more URLs that provide the RDAP service regarding this
567 registration. The URLs are expected to supply the same data, but
568 they can differ in scheme or other components as required by the
569 service operator.
570
571 5.2. RDAP Extensions Registry
572
573 IANA has registered the following value in the "RDAP Extensions"
574 registry:
575
576 Extension identifier: rdap_objectTag
577 Registry operator: Any
578 Published specification: This document
579 Contact: IESG <iesg@ietf.org>
580
581 Intended usage: This extension describes a best practice for
582 structuring entity identifiers to enable query bootstrapping.
583
584 6. Security Considerations
585
586 This practice uses IANA as a well-known, centrally trusted authority
587 to allow users to get RDAP data from an authoritative source, which
588 reduces the risk of sending queries to non-authoritative sources and
589 divulging query information to unintended parties. Using TLS 1.2
590 [RFC5246] or TLS 1.3 [RFC8446], which obsoletes TLS 1.2, to protect
591 the connection to IANA allows the server to authenticate itself as
592 being operated by IANA and provides integrity protection for the
593 resulting referral information, as well as provides privacy
594 protection via data confidentiality. The subsequent RDAP connection
595 is performed as usual and retains the same security properties of the
596 RDAP protocols themselves as described in RFC 7481 [RFC7481].
597
598
599
600
601
602 Hollenbeck & Newton Best Current Practice [Page 11]
603 RFC 8521 RDAP Object Tagging November 2018
604
605
606 7. References
607
608 7.1. Normative References
609
610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
611 Requirement Levels", BCP 14, RFC 2119,
612 DOI 10.17487/RFC2119, March 1997,
613 <https://www.rfc-editor.org/info/rfc2119>.
614
615 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
616 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
617 <https://www.rfc-editor.org/info/rfc5730>.
618
619 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data
620 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March
621 2015, <https://www.rfc-editor.org/info/rfc7484>.
622
623 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
624 Writing an IANA Considerations Section in RFCs", BCP 26,
625 RFC 8126, DOI 10.17487/RFC8126, June 2017,
626 <https://www.rfc-editor.org/info/rfc8126>.
627
628 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
629 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
630 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
631
632 7.2. Informative References
633
634 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
635 Resource Identifier (URI): Generic Syntax", STD 66,
636 RFC 3986, DOI 10.17487/RFC3986, January 2005,
637 <https://www.rfc-editor.org/info/rfc3986>.
638
639 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
640 (TLS) Protocol Version 1.2", RFC 5246,
641 DOI 10.17487/RFC5246, August 2008,
642 <https://www.rfc-editor.org/info/rfc5246>.
643
644 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
645 Registration Data Access Protocol (RDAP)", RFC 7481,
646 DOI 10.17487/RFC7481, March 2015,
647 <https://www.rfc-editor.org/info/rfc7481>.
648
649 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access
650 Protocol (RDAP) Query Format", RFC 7482,
651 DOI 10.17487/RFC7482, March 2015,
652 <https://www.rfc-editor.org/info/rfc7482>.
653
654
655
656
657 Hollenbeck & Newton Best Current Practice [Page 12]
658 RFC 8521 RDAP Object Tagging November 2018
659
660
661 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the
662 Registration Data Access Protocol (RDAP)", RFC 7483,
663 DOI 10.17487/RFC7483, March 2015,
664 <https://www.rfc-editor.org/info/rfc7483>.
665
666 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
667 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
668 <https://www.rfc-editor.org/info/rfc8446>.
669
670
671 Acknowledgements
672
673 The authors would like to acknowledge the following individuals for
674 their contributions to the development of this document: Tom
675 Harrison, Patrick Mevzek, and Marcos Sanz. In addition, the authors
676 would like to recognize the Regional Internet Registry (RIR)
677 operators (AFRINIC, APNIC, ARIN, LACNIC, and RIPE) that have been
678 implementing and using the practice of tagging handle identifiers for
679 several years. Their experience provided significant inspiration for
680 the development of this document.
681
682 Authors' Addresses
683
684 Scott Hollenbeck
685 Verisign Labs
686 12061 Bluemont Way
687 Reston, VA 20190
688 United States of America
689
690 Email: shollenbeck@verisign.com
691 URI: http://www.verisignlabs.com/
692
693
694 Andrew Lee Newton
695 American Registry for Internet Numbers
696 PO Box 232290
697 Centreville, VA 20120
698 United States of America
699
700 Email: andy@arin.net
701 URI: http://www.arin.net
702
703
704
705
706
707
708
709
710
711
712 Hollenbeck & Newton Best Current Practice [Page 13]
713
RDAP responses that contain values described in this document MUST
indicate conformance with this specification by including an
rdapConformance [RFC7483] value of "rdap_objectTag_level_0". The
information needed to register this value in the "RDAP Extensions"
registry is described in Section 5.2.
The following is an example rdapConformance structure with the
extension specified.
"rdapConformance" :
[
"rdap_level_0",
"rdap_objectTag_level_0"
]
RDAP responses that contain values described in this document MUST
indicate conformance with this specification by including an
rdapConformance [RFC7483] value of "rdap_objectTag". The
information needed to register this value in the "RDAP Extensions"
registry is described in Section 5.2.
The following is an example rdapConformance structure with the
extension specified.
"rdapConformance" :
[
"rdap_level_0",
"rdap_objectTag"
]
The value of the rdapConformance tag MUST match the value in the IANA registry, which is "rdap_objectTag".