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