1 Internet Engineering Task Force (IETF) M. Blanchet
2 Request for Comments: 9224 Viagenie
3 STD: 95 March 2022
4 Obsoletes: 7484
5 Category: Standards Track
6 ISSN: 2070-1721
7
8
9 Finding the Authoritative Registration Data Access Protocol (RDAP)
10 Service
11
12 Abstract
13
14 This document specifies a method to find which Registration Data
15 Access Protocol (RDAP) server is authoritative to answer queries for
16 a requested scope, such as domain names, IP addresses, or Autonomous
17 System numbers. This document obsoletes RFC 7484.
18
19 Status of This Memo
20
21 This is an Internet Standards Track document.
22
23 This document is a product of the Internet Engineering Task Force
24 (IETF). It represents the consensus of the IETF community. It has
25 received public review and has been approved for publication by the
26 Internet Engineering Steering Group (IESG). Further information on
27 Internet Standards is available in Section 2 of RFC 7841.
28
29 Information about the current status of this document, any errata,
30 and how to provide feedback on it may be obtained at
31 https://www.rfc-editor.org/info/rfc9224.
32
33 Copyright Notice
34
35 Copyright (c) 2022 IETF Trust and the persons identified as the
36 document authors. All rights reserved.
37
38 This document is subject to BCP 78 and the IETF Trust's Legal
39 Provisions Relating to IETF Documents
40 (https://trustee.ietf.org/license-info) in effect on the date of
41 publication of this document. Please review these documents
42 carefully, as they describe your rights and restrictions with respect
43 to this document. Code Components extracted from this document must
44 include Revised BSD License text as described in Section 4.e of the
45 Trust Legal Provisions and are provided without warranty as described
46 in the Revised BSD License.
47
48 Table of Contents
49
50 1. Introduction
51 2. Conventions Used in This Document
52 3. Structure of the RDAP Bootstrap Service Registries
53 4. Bootstrap Service Registry for Domain Name Space
54 5. Bootstrap Service Registries for Internet Numbers
55 5.1. Bootstrap Service Registry for IPv4 Address Space
56 5.2. Bootstrap Service Registry for IPv6 Address Space
57 5.3. Bootstrap Service Registry for AS Number Space
58 6. Entity
59 7. Non-existent Entries or RDAP URL Values
60 8. Deployment and Implementation Considerations
61 9. Limitations
62 10. Formal Definition
63 10.1. Imported JSON Terms
64 10.2. Registry Syntax
65 11. Security Considerations
66 12. IANA Considerations
67 12.1. Bootstrap Service Registry for IPv4 Address Space
68 12.2. Bootstrap Service Registry for IPv6 Address Space
69 12.3. Bootstrap Service Registry for AS Number Space
70 12.4. Bootstrap Service Registry for Domain Name Space
71 13. References
72 13.1. Normative References
73 13.2. Informative References
74 Appendix A. Changes since RFC 7484
75 Acknowledgements
76 Author's Address
77
78 1. Introduction
79
80 Querying and retrieving registration data from registries are defined
81 in the Registration Data Access Protocol (RDAP) [RFC7480] [RFC7481]
82 [RFC9082] [RFC9083]. These documents do not specify where to send
83 the queries. This document specifies a method to find which server
84 is authoritative to answer queries for the requested scope.
85
86 Top-Level Domains (TLDs), Autonomous System (AS) numbers, and network
87 blocks are delegated by IANA to Internet registries such as TLD
88 registries and Regional Internet Registries (RIRs) that then issue
89 further delegations and maintain information about them. Thus, the
90 bootstrap information needed by RDAP clients is best generated from
91 data and processes already maintained by IANA; the relevant
92 registries already exist at [ipv4reg], [ipv6reg], [asreg], and
93 [domainreg]. This document obsoletes [RFC7484].
94
95 Per this document, IANA has created new registries based on a JSON
96 format specified in this document, herein named RDAP Bootstrap
97 Service Registries. These new registries are based on the existing
98 entries of the above-mentioned registries. An RDAP client fetches
99 the RDAP Bootstrap Service Registries, extracts the data, and then
100 performs a match with the query data to find the authoritative
101 registration data server and appropriate query base URL.
102
103 2. Conventions Used in This Document
104
105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
107 "OPTIONAL" in this document are to be interpreted as described in
108 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
109 capitals, as shown here.
110
111 3. Structure of the RDAP Bootstrap Service Registries
112
113 The RDAP Bootstrap Service Registries, as specified in Section 12
114 below, have been made available as JSON [RFC8259] objects, which can
115 be retrieved via HTTP from locations specified by IANA. The JSON
116 object for each registry contains a series of members containing
117 metadata about the registry such as a version identifier, a timestamp
118 of the publication date of the registry, and a description.
119 Additionally, a "services" member contains the registry items
120 themselves, as an array. Each item of the array contains a second-
121 level array, with two elements, each of them being a third-level
122 array.
123
124 Each element of the Services Array is a second-level array with two
125 elements: in order, an Entry Array and a Service URL Array.
126
127 The Entry Array contains all entries that have the same set of base
128 RDAP URLs. The Service URL Array contains the list of base RDAP URLs
129 usable for the entries found in the Entry Array. Elements within
130 these two arrays are not ordered in any way.
131
132 An example structure of the JSON output of an RDAP Bootstrap Service
133 Registry is illustrated:
134
135 {
136 "version": "1.0",
137 "publication": "YYYY-MM-DDTHH:MM:SSZ",
138 "description": "Some text",
139 "services": [
140 [
141 ["entry1", "entry2", "entry3"],
142 [
143 "https://registry.example.com/myrdap/",
144 "http://registry.example.com/myrdap/"
145 ]
146 ],
147 [
148 ["entry4"],
149 [
150 "https://example.org/"
151 ]
152 ]
153 ]
154 }
155
156 The formal syntax is described in Section 10.
157
158 The "version" corresponds to the format version of the registry.
159 This specification defines version "1.0".
160
161 The syntax of the "publication" value conforms to the Internet date/
162 time format [RFC3339]. The value is the latest update date of the
163 registry by IANA.
164
165 The optional "description" string can contain a comment regarding the
166 content of the bootstrap object.
167
168 Per [RFC7258], in each array of base RDAP URLs, the secure versions
169 of the transport protocol SHOULD be preferred and tried first. For
170 example, if the base RDAP URLs array contains both HTTPS and HTTP
171 URLs, the bootstrap client SHOULD try the HTTPS version first.
172
173 Base RDAP URLs MUST have a trailing "/" character because they are
174 concatenated to the various segments defined in [RFC9082].
175
176 JSON names MUST follow the format recommendations of Section 6 of
177 [RFC7480]. Any unrecognized JSON object properties or values MUST be
178 ignored by implementations.
179
180 Internationalized Domain Name labels used as entries or base RDAP
181 URLs in the registries defined in this document MUST be only
182 represented using their A-label form as defined in [RFC5890].
183
184 All Domain Name labels used as entries or base RDAP URLs in the
185 registries defined in this document MUST be only represented in
186 lowercase.
187
188 4. Bootstrap Service Registry for Domain Name Space
189
190 The JSON output of this registry contains domain label entries
191 attached to the root, grouped by base RDAP URLs, as shown in this
192 example.
193
194 {
195 "version": "1.0",
196 "publication": "2024-01-07T10:11:12Z",
197 "description": "Some text",
198 "services": [
199 [
200 ["net", "com"],
201 [
202 "https://registry.example.com/myrdap/"
203 ]
204 ],
205 [
206 ["org", "mytld"],
207 [
208 "https://example.org/"
209 ]
210 ],
211 [
212 ["xn--zckzah"],
213 [
214 "https://example.net/rdap/xn--zckzah/",
215 "http://example.net/rdap/xn--zckzah/"
216 ]
217 ]
218 ]
219 }
220
221 The domain name's authoritative registration data service is found by
222 doing the label-wise longest match of the target domain name with the
223 domain values in the Entry Arrays in the IANA "Bootstrap Service
224 Registry for Domain Name Space". The match is done per label, from
225 right to left. If the longest match results in multiple entries,
226 then those entries are considered equivalent. The values contained
227 in the Service URL Array of the matching second-level array are the
228 valid base RDAP URLs as described in [RFC9082].
229
230 For example, a domain RDAP query for a.b.example.com matches the com
231 entry in one of the arrays of the registry. The base RDAP URL for
232 this query is then taken from the second element of the array, which
233 is an array of base RDAP URLs valid for this entry. The client
234 chooses one of the base URLs from this array; in this example, it
235 chooses the only one available, "https://registry.example.com/
236 myrdap/". The segment specified in [RFC9082] is then appended to the
237 base URL to complete the query. The complete query is then
238 "https://registry.example.com/myrdap/domain/a.b.example.com".
239
240 If a domain RDAP query for a.b.example.com matches both com and
241 example.com entries in the registry, then the longest match applies
242 and the example.com entry is used by the client.
243
244 If the registry contains entries such as com and goodexample.com,
245 then a domain RDAP query for example.com only matches the com entry
246 because matching is done on a per-label basis.
247
248 The entry for the root of the domain name space is specified as "".
249
250 5. Bootstrap Service Registries for Internet Numbers
251
252 This section discusses IPv4 and IPv6 address space and Autonomous
253 System numbers.
254
255 For IP address space, the authoritative registration data service is
256 found by doing a longest match of the target address with the values
257 of the arrays in the corresponding RDAP Bootstrap Service Registry
258 for Address Space. The longest match is done the same way as in
259 packet forwarding: the addresses are converted in binary form and
260 then the binary strings are compared to find the longest match up to
261 the specified prefix length. The values contained in the second
262 element of the array are the base RDAP URLs as described in
263 [RFC9082]. The longest match method enables covering prefixes of a
264 larger address space pointing to one base RDAP URL while more
265 specific prefixes within the covering prefix are being served by
266 another base RDAP URL.
267
268 5.1. Bootstrap Service Registry for IPv4 Address Space
269
270 The JSON output of this registry contains IPv4 prefix entries,
271 specified in Classless Inter-domain Routing (CIDR) format [RFC4632]
272 and grouped by RDAP URLs, as shown in this example.
273
274 {
275 "version": "1.0",
276 "publication": "2024-01-07T10:11:12Z",
277 "description": "RDAP Bootstrap file for example registries.",
278 "services": [
279 [
280 ["198.51.100.0/24", "192.0.0.0/8"],
281 [
282 "https://rir1.example.com/myrdap/"
283 ]
284 ],
285 [
286 ["203.0.113.0/24", "192.0.2.0/24"],
287 [
288 "https://example.org/"
289 ]
290 ],
291 [
292 ["203.0.113.0/28"],
293 [
294 "https://example.net/rdaprir2/",
295 "http://example.net/rdaprir2/"
296 ]
297 ]
298 ]
299 }
300
301 For example, a query for "192.0.2.1/25" matches the "192.0.0.0/8"
302 entry and the "192.0.2.0/24" entry in the example registry above.
303 The latter is chosen by the client because it is the longest match.
304 The base RDAP URL for this query is then taken from the second
305 element of the array, which is an array of base RDAP URLs valid for
306 this entry. The client chooses one of the base URLs from this array;
307 in this example, it chooses the only one available,
308 "https://example.org/". The {resource} specified in [RFC9082] is
309 then appended to the base URL to complete the query. The complete
310 query is then "https://example.org/ip/192.0.2.1/25".
311
312 5.2. Bootstrap Service Registry for IPv6 Address Space
313
314 The JSON output of this registry contains IPv6 prefix entries, using
315 [RFC5952] text representation of the address prefixes format, grouped
316 by base RDAP URLs, as shown in this example.
317
318 {
319 "version": "1.0",
320 "publication": "2024-01-07T10:11:12Z",
321 "description": "RDAP Bootstrap file for example registries.",
322 "services": [
323 [
324 ["2001:db8::/34"],
325 [
326 "https://rir2.example.com/myrdap/"
327 ]
328 ],
329 [
330 ["2001:db8:4000::/36", "2001:db8:ffff::/48"],
331 [
332 "https://example.org/"
333 ]
334 ],
335 [
336 ["2001:db8:1000::/36"],
337 [
338 "https://example.net/rdaprir2/",
339 "http://example.net/rdaprir2/"
340 ]
341 ]
342 ]
343 }
344
345 For example, a query for "2001:db8:1000::/48" matches the
346 "2001:db8::/34" entry and the "2001:db8:1000::/36" entry in the
347 example registry above. The latter is chosen by the client because
348 it is the longest match. The base RDAP URL for this query is then
349 taken from the second element of the array, which is an array of base
350 RDAP URLs valid for this entry. The client chooses one of the base
351 URLs from this array; in this example, it chooses
352 "https://example.net/rdaprir2/" because it's the secure version of
353 the protocol. The segment specified in [RFC9082] is then appended to
354 the base URL to complete the query. The complete query is therefore
355 "https://example.net/rdaprir2/ip/2001:db8:1000::/48". If the target
356 RDAP server does not answer, the client can then use another URL
357 prefix from the array.
358
359 5.3. Bootstrap Service Registry for AS Number Space
360
361 The JSON output of this registry contains entries for AS number
362 ranges, grouped by base RDAP URLs, as shown in this example. The
363 Entry Array is an array containing the list of AS number ranges
364 served by the base RDAP URLs found in the second element. Each
365 element of the array contains two AS numbers represented in decimal
366 format, separated by a hyphen, that represents the range of AS
367 numbers between the two AS numbers (inclusive), where values are in
368 increasing order (e.g., 100-200, not 200-100). A single AS number is
369 represented as a range of two identical AS numbers. AS numbers are
370 represented as 'asplain' as defined in [RFC5396]. Ranges MUST NOT
371 overlap.
372
373 {
374 "version": "1.0",
375 "publication": "2024-01-07T10:11:12Z",
376 "description": "RDAP Bootstrap file for example registries.",
377 "services": [
378 [
379 ["64496-64496"],
380 [
381 "https://rir3.example.com/myrdap/"
382 ]
383 ],
384 [
385 ["64497-64510", "65536-65551"],
386 [
387 "https://example.org/"
388 ]
389 ],
390 [
391 ["64512-65534"],
392 [
393 "http://example.net/rdaprir2/",
394 "https://example.net/rdaprir2/"
395 ]
396 ]
397 ]
398 }
399
400 For example, a query for AS 65411 matches the 64512-65534 entry in
401 the example registry above. The base RDAP URL for this query is then
402 taken from the second element of the array, which is an array of base
403 RDAP URLs valid for this entry. The client chooses one of the base
404 URLs from this array; in this example, it chooses
405 "https://example.net/rdaprir2/". The segment specified in [RFC9082]
406 is then appended to the base URL to complete the query. The complete
407 query is, therefore, "https://example.net/rdaprir2/autnum/65411". If
408 the server does not answer, the client can then use another URL
409 prefix from the array.
410
411 6. Entity
412
413 Entities (such as contacts, registrants, or registrars) can be
414 queried by handle as described in [RFC9082]. Since there is no
415 global name space for entities, this document does not describe how
416 to find the authoritative RDAP server for entities. However, it is
417 possible that, if the entity identifier was received from a previous
418 query, the same RDAP server could be queried for that entity, or the
419 entity identifier itself is a fully qualified URL that can be
420 queried. The mechanism described in [RFC8521] MAY also be used.
421
422 7. Non-existent Entries or RDAP URL Values
423
424 The registries may not contain the requested value. In these cases,
425 there is no known RDAP server for that requested value, and the
426 client SHOULD provide an appropriate error message to the user.
427
428 8. Deployment and Implementation Considerations
429
430 This method relies on the fact that RDAP clients are fetching the
431 IANA registries to then find the servers locally. Clients SHOULD NOT
432 fetch the registry on every RDAP request. Clients SHOULD cache the
433 registry, but use underlying protocol signaling, such as the HTTP
434 Expires header field [RFC7234], to identify when it is time to
435 refresh the cached registry.
436
437 Some authorities of registration data may work together on sharing
438 their information for a common service, including mutual redirection
439 [REDIRECT-RDAP].
440
441 When a new object is allocated, such as a new AS range, a new TLD, or
442 a new IP address range, there is no guarantee that this new object
443 will have an entry in the corresponding bootstrap RDAP registry,
444 since the setup of the RDAP server for this new entry may become live
445 and registered later. Therefore, the clients should expect that even
446 if an object, such as TLD, IP address range, or AS range is
447 allocated, the existence of the entry in the corresponding bootstrap
448 registry is not guaranteed.
449
450 9. Limitations
451
452 This method does not provide a direct way to find authoritative RDAP
453 servers for any other objects than the ones described in this
454 document. In particular, the following objects are not bootstrapped
455 with the method described in this document:
456
457 * entities
458
459 * queries using search patterns that do not contain a terminating
460 string that matches some entries in the registries
461
462 * nameservers
463
464 * help
465
466 10. Formal Definition
467
468 This section is the formal definition of the registries. The
469 structure of JSON objects and arrays using a set of primitive
470 elements is defined in [RFC8259]. Those elements are used to
471 describe the JSON structure of the registries.
472
473 10.1. Imported JSON Terms
474
475 OBJECT: a JSON object, defined in Section 4 of [RFC8259]
476
477 MEMBER: a member of a JSON object, defined in Section 4 of [RFC8259]
478
479 MEMBER-NAME: the name of a MEMBER, defined as a "string" in
480 Section 4 of [RFC8259]
481
482 MEMBER-VALUE: the value of a MEMBER, defined as a "value" in
483 Section 4 of [RFC8259]
484
485 ARRAY: an array, defined in Section 5 of [RFC8259]
486
487 ARRAY-VALUE: an element of an ARRAY, defined in Section 5 of
488 [RFC8259]
489
490 STRING: a "string", as defined in Section 7 of [RFC8259]
491
492 10.2. Registry Syntax
493
494 Using the above terms for the JSON structures, the syntax of a
495 registry is defined as follows:
496
497 rdap-bootstrap-registry: an OBJECT containing a MEMBER version and a
498 MEMBER publication, an optional MEMBER description, and a MEMBER
499 services-list
500
501 version: a MEMBER with MEMBER-NAME "version" and MEMBER-VALUE a
502 STRING
503
504 publication: a MEMBER with MEMBER-NAME "publication" and MEMBER-
505 VALUE a STRING
506
507 description: a MEMBER with MEMBER-NAME "description" and MEMBER-
508 VALUE a STRING
509
510 services-list: a MEMBER with MEMBER-NAME "services" and MEMBER-VALUE
511 a services-array
512
513 services-array: an ARRAY, where each ARRAY-VALUE is a service
514
515 service: an ARRAY of 2 elements, where the first ARRAY-VALUE is an
516 entry-list and the second ARRAY-VALUE is a service-uri-list
517
518 entry-list: an ARRAY, where each ARRAY-VALUE is an entry
519
520 entry: a STRING
521
522 service-uri-list: an ARRAY, where each ARRAY-VALUE is a service-uri
523
524 service-uri: a STRING
525
526 11. Security Considerations
527
528 By providing a bootstrap method to find RDAP servers, this document
529 helps to ensure that the end users will get the RDAP data from an
530 authoritative source instead of from rogue sources. The method has
531 the same security properties as the RDAP protocols themselves. The
532 transport used to access the registries uses TLS [RFC8446].
533
534 Additional considerations on using RDAP are described in [RFC7481].
535
536 12. IANA Considerations
537
538 IANA has created the RDAP Bootstrap Services Registries listed below
539 and made them available as JSON objects. The contents of these
540 registries are described in Sections 3, 4, and 5, with the formal
541 syntax specified in Section 10. The registries MUST be accessible
542 only through HTTPS (TLS [RFC8446]) transport.
543
544 The process for adding or updating entries in these registries
545 differs from the normal IANA registry processes: these registries are
546 generated from the data, processes, and policies maintained by IANA
547 in their allocation registries ([ipv4reg], [ipv6reg], [asreg], and
548 [domainreg]), with the addition of new RDAP server information.
549
550 IANA updates RDAP Bootstrap Services Registries entries from the
551 allocation registries as those registries are updated.
552
553 This document does not change any policies related to the allocation
554 registries; IANA has provided a mechanism for collecting the RDAP
555 server information.
556
557 IANA has created a new top-level category on the Protocol Registries
558 page: <https://www.iana.org/protocols>. The group is called
559 "Registration Data Access Protocol (RDAP)". Each of the RDAP
560 Bootstrap Services Registries has been made available for on-demand
561 download in the JSON format by the general public, and that
562 registry's URI is listed directly on the Protocol Registries page.
563
564 Other normal registries will be added to this group by other
565 documents, but the reason the URIs for these registries are clearly
566 listed on the main page is to make those URIs obvious to implementers
567 -- these are registries that will be accessed by software, as well as
568 by humans using them for reference information.
569
570 Because these registries will be accessed by software, the download
571 demand for the RDAP Bootstrap Services Registries may be unusually
572 high compared to normal IANA registries. The technical
573 infrastructure by which registries are published has been put in
574 place by IANA to support the load. Since the publication of
575 [RFC7484], no issues have been reported regarding the load or the
576 service.
577
578 As discussed in Section 8, software that accesses these registries
579 will depend on the HTTP Expires header field to limit their query
580 rate. It is, therefore, important for that header field to be
581 properly set to provide timely information as the registries change,
582 while maintaining a reasonable load on the IANA servers.
583
584 The HTTP Content-Type returned to clients accessing these JSON-
585 formatted registries MUST be "application/json", as defined in
586 [RFC8259].
587
588 Because of how information in the RDAP Bootstrap Services Registries
589 is grouped and formatted, the registry entries may not be sortable.
590 It is, therefore, not required or expected that the entries be
591 ordered in any way.
592
593 12.1. Bootstrap Service Registry for IPv4 Address Space
594
595 Entries in this registry contain at least the following:
596
597 * a CIDR [RFC4632] specification of the network block being
598 registered
599
600 * one or more URLs that provide the RDAP service regarding this
601 registration
602
603 12.2. Bootstrap Service Registry for IPv6 Address Space
604
605 Entries in this registry contain at least the following:
606
607 * an IPv6 prefix [RFC5952] specification of the network block being
608 registered
609
610 * one or more URLs that provide the RDAP service regarding this
611 registration
612
613 12.3. Bootstrap Service Registry for AS Number Space
614
615 Entries in this registry contain at least the following:
616
617 * a range of Autonomous System numbers being registered
618
619 * one or more URLs that provide the RDAP service regarding this
620 registration
621
622 12.4. Bootstrap Service Registry for Domain Name Space
623
624 Entries in this registry contain at least the following:
625
626 * a domain name attached to the root being registered
627
628 * one or more URLs that provide the RDAP service regarding this
629 registration
630
631 13. References
632
633 13.1. Normative References
634
635 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
636 Requirement Levels", BCP 14, RFC 2119,
637 DOI 10.17487/RFC2119, March 1997,
638 <https://www.rfc-editor.org/info/rfc2119>.
639
640 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
641 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
642 <https://www.rfc-editor.org/info/rfc3339>.
643
644 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
645 (CIDR): The Internet Address Assignment and Aggregation
646 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
647 2006, <https://www.rfc-editor.org/info/rfc4632>.
648
649 [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of
650 Autonomous System (AS) Numbers", RFC 5396,
651 DOI 10.17487/RFC5396, December 2008,
652 <https://www.rfc-editor.org/info/rfc5396>.
653
654 [RFC5890] Klensin, J., "Internationalized Domain Names for
655 Applications (IDNA): Definitions and Document Framework",
656 RFC 5890, DOI 10.17487/RFC5890, August 2010,
657 <https://www.rfc-editor.org/info/rfc5890>.
658
659 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
660 Address Text Representation", RFC 5952,
661 DOI 10.17487/RFC5952, August 2010,
662 <https://www.rfc-editor.org/info/rfc5952>.
663
664 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
665 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
666 2014, <https://www.rfc-editor.org/info/rfc7258>.
667
668 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
669 Registration Data Access Protocol (RDAP)", STD 95,
670 RFC 7480, DOI 10.17487/RFC7480, March 2015,
671 <https://www.rfc-editor.org/info/rfc7480>.
672
673 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
674 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
675 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
676
677 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
678 Interchange Format", STD 90, RFC 8259,
679 DOI 10.17487/RFC8259, December 2017,
680 <https://www.rfc-editor.org/info/rfc8259>.
681
682 13.2. Informative References
683
684 [asreg] IANA, "Autonomous System (AS) Numbers",
685 <https://www.iana.org/assignments/as-numbers>.
686
687 [domainreg]
688 IANA, "Root Zone Database",
689 <https://www.iana.org/domains/root/db>.
690
691 [ipv4reg] IANA, "IANA IPv4 Address Space Registry",
692 <https://www.iana.org/assignments/ipv4-address-space>.
693
694 [ipv6reg] IANA, "IPv6 Global Unicast Address Assignments",
695 <https://www.iana.org/assignments/ipv6-unicast-address-
696 assignments>.
697
698 [REDIRECT-RDAP]
699 Martinez, C.M., Ed., Zhou, L., Ed., and G. Rada,
700 "Redirection Service for Registration Data Access
701 Protocol", Work in Progress, Internet-Draft, draft-ietf-
702 weirds-redirects-04, July 2014,
703 <https://datatracker.ietf.org/doc/html/draft-ietf-weirds-
704 redirects-04>.
705
706 [RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for
707 Reputation Interchange", RFC 7071, DOI 10.17487/RFC7071,
708 November 2013, <https://www.rfc-editor.org/info/rfc7071>.
709
710 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
711 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
712 RFC 7234, DOI 10.17487/RFC7234, June 2014,
713 <https://www.rfc-editor.org/info/rfc7234>.
714
715 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
716 Registration Data Access Protocol (RDAP)", STD 95,
717 RFC 7481, DOI 10.17487/RFC7481, March 2015,
718 <https://www.rfc-editor.org/info/rfc7481>.
719
720 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data
721 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March
722 2015, <https://www.rfc-editor.org/info/rfc7484>.
723
724 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
725 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
726 <https://www.rfc-editor.org/info/rfc8446>.
727
728 [RFC8521] Hollenbeck, S. and A. Newton, "Registration Data Access
729 Protocol (RDAP) Object Tagging", BCP 221, RFC 8521,
730 DOI 10.17487/RFC8521, November 2018,
731 <https://www.rfc-editor.org/info/rfc8521>.
732
733 [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
734 Protocol (RDAP) Query Format", STD 95, RFC 9082,
735 DOI 10.17487/RFC9082, June 2021,
736 <https://www.rfc-editor.org/info/rfc9082>.
737
738 [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
739 Registration Data Access Protocol (RDAP)", STD 95,
740 RFC 9083, DOI 10.17487/RFC9083, June 2021,
741 <https://www.rfc-editor.org/info/rfc9083>.
742
743 Appendix A. Changes since RFC 7484
744
745 There are no substantive changes except for minor clarifications.
746 This update is primarily to meet the requirements for moving to an
747 Internet Standard.
748
749 Acknowledgements
750
751 The WEIRDS Working Group had multiple discussions on this topic,
752 including a session during IETF 84, where various methods such as in-
753 DNS and others were debated. The idea of using IANA registries was
754 discovered by the author during discussions with his colleagues as
755 well as by a comment from Andy Newton. All the people involved in
756 these discussions are herein acknowledged. Linlin Zhou, Jean-
757 Philippe Dionne, John Levine, Kim Davies, Ernie Dainow, Scott
758 Hollenbeck, Arturo Servin, Andy Newton, Murray Kucherawy, Tom
759 Harrison, Naoki Kambe, Alexander Mayrhofer, Edward Lewis, Pete
760 Resnick, Alessandro Vesely, Bert Greevenbosch, Barry Leiba, Jari
761 Arkko, Kathleen Moriaty, Stephen Farrell, Richard Barnes, and Jean-
762 Francois Tremblay provided input and suggestions to the first version
763 of this document.
764
765 Guillaume Leclanche was a coauthor of this document for some
766 revisions; his support is therein acknowledged and greatly
767 appreciated. The section on formal definition was inspired by
768 Section 6.2 of [RFC7071]. This new version [This document] received
769 comments and suggestions from Gavin Brown, Patrick Mevzek, John
770 Levine, Jasdip Singh, George Michaelson, Scott Hollenbeck, Russ
771 Housley, Joel Halpern, Lars Eggert, Benjamin Kaduk, Scott Kelly, Éric
772 Vyncke, John Scudder, Erik Kline, and Robert Wilton. Errata for RFC
773 7484 were submitted by Pieter Vandepitte and were applied to this
774 document.
775
776 Author's Address
777
778 Marc Blanchet
779 Viagenie
780 246 Aberdeen
781 Quebec QC G1R 2E1
782 Canada
783 Email: Marc.Blanchet@viagenie.ca
784 URI: https://viagenie.ca
785
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.