RFC 7484

Finding the Authoritative Registration Data (RDAP) Service

📅 published March 2015, from ietf

Finding the Authoritative Registration Data (RDAP) Service 🦋

Okay bestie, here are the deets 📋 This is RFC 7484, written by M. Blanchet from Viagenie for the Internet Engineering Task Force (IETF). It's dated March 2015, it's a Standards Track doc (so it's the real deal, not a suggestion 💅), and its ISSN is 2070-1721. The header doesn't list any RFCs it obsoletes or updates.

Abstract ✨

This doc explains how to find which Registration Data Access Protocol (RDAP) server is the authoritative one to answer queries for a requested scope, like domain names, IP addresses, or Autonomous System numbers 🔎

Status of This Memo 📜

This is an Internet Standards Track document.

It's a product of the IETF and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.

Info about the current status, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7484.

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License.

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
3.  Structure of the RDAP Bootstrap Service Registries  . . . . .   3
4.  Bootstrap Service Registry for Domain Name Space  . . . . . .   5
5.  Bootstrap Service Registries for Internet Numbers . . . . . .   6
  5.1.  Bootstrap Service Registry for IPv4 Address Space . . . .   7
  5.2.  Bootstrap Service Registry for IPv6 Address Space . . . .   8
  5.3.  Bootstrap Service Registry for AS Number Space  . . . . .   9
6.  Entity  . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
7.  Non-existent Entries or RDAP URL Values . . . . . . . . . . .  10
8.  Deployment and Implementation Considerations  . . . . . . . .  10
9.  Limitations . . . . . . . . . . . . . . . . . . . . . . . . .  11
10. Formal Definition . . . . . . . . . . . . . . . . . . . . . .  11
  10.1.  Imported JSON Terms  . . . . . . . . . . . . . . . . . .  11
  10.2.  Registry Syntax  . . . . . . . . . . . . . . . . . . . .  12
11. Security Considerations . . . . . . . . . . . . . . . . . . .  13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
  12.1.  Bootstrap Service Registry for IPv4 Address Space  . . .  14
  12.2.  Bootstrap Service Registry for IPv6 Address Space  . . .  14
  12.3.  Bootstrap Service Registry for AS Number Space . . . . .  14
  12.4.  Bootstrap Service Registry for Domain Name Space . . . .  15
13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
  13.1.  Normative References . . . . . . . . . . . . . . . . . .  15
  13.2.  Informative References . . . . . . . . . . . . . . . . .  15
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

1. Introduction 💁‍♀️

Okay so, querying and retrieving registration data is defined in the Registration Data Access Protocol (RDAP) [RFC7480] [RFC7482] [RFC7483]. Those docs don't say where to send the queries though 🙃 This doc fills that gap by specifying a method to find which server is authoritative to answer queries for the requested scope.

Top-Level Domains (TLDs), Autonomous System (AS) numbers, and network blocks are delegated by IANA to Internet registries, like TLD registries and Regional Internet Registries (RIRs), which then issue further delegations and maintain info about them. So the bootstrap info RDAP clients need is best generated from data and processes IANA already maintains. The relevant registries already exist at [ipv4reg], [ipv6reg], [asreg], and [domainreg] 🧚

Per this doc, IANA has created new registries based on a JSON format specified here, called RDAP Bootstrap Service Registries. They're built on the existing entries of the registries listed above. An RDAP client fetches the RDAP Bootstrap Service Registries, extracts the data, and then matches it against the query data to find the authoritative registration data server and the right query base URL 🎀

2. Conventions Used in This Document 🔑

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💖

3. Structure of the RDAP Bootstrap Service Registries 🧱

The RDAP Bootstrap Service Registries, as specified in Section 12 below, are available as JSON [RFC7159] objects, which can be retrieved via HTTP from locations specified by IANA. The JSON object for each registry contains a series of members with metadata about the registry, like a version identifier, a timestamp of the publication date, and a description. A "services" member also holds the registry items themselves, as an array. Each item of that array contains a second-level array with two elements, and each of those elements is a third-level array 🌈

Each element of the Services Array is a second-level array with two elements: in order, an Entry Array and a Service URL Array.

The Entry Array contains all entries that have the same set of base RDAP URLs. The Service URL Array contains the list of base RDAP URLs usable for the entries in the Entry Array. Elements within these two arrays are not sorted in any way 🫶

Here's an example structure of the JSON output of an RDAP Bootstrap Service Registry:

{
    "version": "1.0",
    "publication": "YYYY-MM-DDTHH:MM:SSZ",
    "description": "Some text",
    "services": [
      [
        ["entry1", "entry2", "entry3"],
        [
          "https://registry.example.com/myrdap/",
          "http://registry.example.com/myrdap/"
        ]
      ],
      [
        ["entry4"],
        [
          "http://example.org/"
        ]
      ]
    ]
}

The formal syntax is described in Section 10 📐

The "version" corresponds to the format version of the registry. This specification defines version "1.0" 🔢

The syntax of the "publication" value conforms to the Internet date/time format [RFC3339]. The value is the latest update date of the registry by IANA 📅

The optional "description" string can contain a comment about the content of the bootstrap object 💬

Per [RFC7258], in each array of base RDAP URLs, the secure versions of the transport protocol SHOULD be preferred and tried first. For example, if the base RDAP URLs array contains both HTTPS and HTTP URLs, the bootstrap client SHOULD try the HTTPS version first 🔐

Base RDAP URLs MUST have a trailing "/" character, because they get concatenated to the various segments defined in [RFC7482] 🧵

JSON names MUST follow the format recommendations of [RFC7480]. Any unrecognized JSON object properties or values MUST be ignored by implementations 🙈

Internationalized Domain Name labels used as entries or base RDAP URLs in the registries defined in this document MUST be represented only in their A-label form, as defined in [RFC5890] 🌸

All Domain Name labels used as entries or base RDAP URLs in the registries defined in this document MUST be represented only in lowercase 🍓

4. Bootstrap Service Registry for Domain Name Space 🌐

The JSON output of this registry contains domain label entries attached to the root, grouped by base RDAP URLs. Here's an example:

{
    "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/"
        ]
      ]
    ]
}

Here's how a domain's authoritative registration data service gets found: you do a label-wise longest match of the target domain name against the domain values in the Entry Arrays in the IANA Bootstrap Service Registry for Domain Name Space. The match is done per label, from right to left. If the longest match results in multiple entries, those entries are considered equivalent. The values in the Service URL Array of the matching second-level array are the valid base RDAP URLs, as described in [RFC7482] 🔍

For example, a domain RDAP query for a.b.example.com matches the com entry in one of the arrays of the registry. The base RDAP URL for this query is then taken from the second element of the array, which is an array of base RDAP URLs valid for that entry. The client chooses one of the base URLs from this array. In this example there's only one, "https://registry.example.com/myrdap/", so that's the one it picks 💅 The segment specified in [RFC7482] then gets appended to the base URL to complete the query. The complete query is then "https://registry.example.com/myrdap/domain/a.b.example.com" ✨

If a domain RDAP query for a.b.example.com matches both the com and example.com entries in the registry, the longest match applies and the client uses the example.com entry 👑

If the registry contains entries like com and goodexample.com, then a domain RDAP query for example.com only matches the com entry, because matching is done on a per-label basis 🙌

The entry for the root of the domain name space is specified as "" 🌳

5. Bootstrap Service Registries for Internet Numbers 🔢

This section covers IPv4 and IPv6 address space, plus Autonomous System numbers 🛰️

For IP address space, the authoritative registration data service is found by doing a longest match of the target address against the values of the arrays in the corresponding RDAP Bootstrap Service Registry for Address Space. The longest match works the same way it does for routing: the addresses are converted to binary form, and then the binary strings are compared to find the longest match up to the specified prefix length. The values in the second element of the array are the base RDAP URLs, as described in [RFC7482]. The longest match method lets a covering prefix of a larger address space point to one base RDAP URL, while more specific prefixes inside that covering prefix are served by another base RDAP URL 🦄

5.1. Bootstrap Service Registry for IPv4 Address Space ✨

okay so the IPv4 registry's JSON is giving prefix entries 🎀 written in CIDR format [RFC4632], and they're grouped by RDAP URLs. Here's a little example bestie:

{
    "version": "1.0",
    "publication": "2024-01-07T10:11:12Z",
    "description": "RDAP Bootstrap file for example registries.",
    "services": [
      [
        ["1.0.0.0/8", "192.0.0.0/8"],
        [
          "https://rir1.example.com/myrdap/"
        ]
      ],
      [
        ["28.2.0.0/16", "192.0.2.0/24"],
        [
          "http://example.org/"
        ]
      ],
      [
        ["28.3.0.0/16"],
        [
          "https://example.net/rdaprir2/",
          "http://example.net/rdaprir2/"
        ]
      ]
    ]
}

So say a query comes in for "192.0.2.1/25" 👀. It matches both the "192.0.0.0/8" entry and the "192.0.2.0/24" entry. The client picks the latter because it's the longest match, which is so iconic 💅. The base RDAP URL then comes from the second element of the array, which is a list of base RDAP URLs for that entry. The client picks one of those URLs, and here there's only one choice, "http://example.org/" 🦋. Then the {resource} from [RFC7482] gets tacked onto the base URL to finish the query, so the full thing becomes https://example.org/ip/192.0.2.1/25. Wait, it's https://example.org/ with the ip/192.0.2.1/25 part added, which is the same as the example in the original text. Literally so clean 🌸

5.2. Bootstrap Service Registry for IPv6 Address Space 💜

The IPv6 registry JSON holds IPv6 prefix entries, written using the text representation of address prefixes from [RFC4291], and grouped by base RDAP URLs. Check the vibes:

{
    "version": "1.0",
    "publication": "2024-01-07T10:11:12Z",
    "description": "RDAP Bootstrap file for example registries.",
    "services": [
      [
        ["2001:0200::/23", "2001:db8::/32"],
        [
          "https://rir2.example.com/myrdap/"
        ]
      ],
      [
        ["2600::/16", "2100:ffff::/32"],
        [
          "http://example.org/"
        ]
      ],
      [
        ["2001:0200:1000::/36"],
        [
          "https://example.net/rdaprir2/",
          "http://example.net/rdaprir2/"
        ]
      ]
    ]
}

Now a query for "2001:0200:1000::/48" matches two entries, "2001:0200::/23" and "2001:0200:1000::/36" 🧚. Guess which one wins? The longest match, "2001:0200:1000::/36", obviously ✨. The base RDAP URL comes from that entry's second element, the array of base URLs. The client chooses "https://example.net/rdaprir2/" because it's the secure version of the protocol 🔐 (no notes, that's the big brain move). The {resource} segment from [RFC7482] then gets appended, so the complete query is https://example.net/rdaprir2/ip/2001:0200:1000::/48. And if the target RDAP server ghosts you and doesn't answer, the client can just try another URL prefix from the array 😭 backup plan era.

5.3. Bootstrap Service Registry for AS Number Space 🌈

The AS number registry JSON is all about Autonomous Systems number ranges, grouped by base RDAP URLs. The Entry Array is the list of AS number ranges served by the base RDAP URLs in the second element. It always has exactly two AS numbers in decimal format, which together describe the range between them. A single AS number gets written as a range of two identical numbers, which is a super cute little trick 🍓

{
    "version": "1.0",
    "publication": "2024-01-07T10:11:12Z",
    "description": "RDAP Bootstrap file for example registries.",
    "services": [
      [
        ["2045-2045"],
        [
          "https://rir3.example.com/myrdap/"
        ]
      ],
      [
        ["10000-12000", "300000-400000"],
        [
          "http://example.org/"
        ]
      ],
      [
        ["64512-65534"],
        [
          "http://example.net/rdaprir2/",
          "https://example.net/rdaprir2/"
        ]
      ]
    ]
}

Say a query comes in for AS 65411. It matches the 64512-65534 entry in the example registry ✨. The base RDAP URL is then pulled from the second element, the array of base RDAP URLs for that entry. The client picks "https://example.net/rdaprir2/" from that array 💖. Then the segment from [RFC7482] gets appended, so the complete query is https://example.net/rdaprir2/autnum/65411. And again, if the server doesn't answer, the client can try another URL prefix from the array. Retry energy, periodt 🫶

6. Entity 🦋

Entities, like contacts, registrants, or registrars, can be queried by handle, as described in [RFC7482] 💅. There's no global namespace for entities though, so this document doesn't explain how to find the authoritative RDAP server for them. Still, a couple of things might help. If the entity identifier came from an earlier query, the same RDAP server could be asked about that entity. Or the entity identifier might itself be a fully referenced URL that you can query directly 🔥

7. Non-existent Entries or RDAP URL Values 💀

The registries might not have the value you asked for. When that happens, there's no known RDAP server for that value, and the client SHOULD provide an appropriate error message to the user. Not the vibe, but at least the app is honest about it 🙈

8. Deployment and Implementation Considerations ✨

This whole method depends on RDAP clients fetching the IANA registries and then finding the servers locally 🧚 Clients SHOULD NOT fetch the registry on every RDAP request, that's just too much. Clients SHOULD cache the registry instead, and use underlying protocol signaling, like the HTTP Expires header field [RFC7234], to figure out when it's time to refresh the cached copy. Smart and efficient, obsessed 💜

If the query data doesn't match any entry in the client's cached registry, the client may try various methods, such as these:

  • For a domain object, the client may first query the DNS to see whether the entry has been delegated, or whether the user just mistyped it 🤭 The DNS query could fetch the NS records for the TLD domain. If the DNS answer is negative, there's no need to fetch a new version of the registry. But if the DNS answer is positive, the cached registry may no longer be current. In that case the client could fetch the registry, parse it, and then do the normal matching as specified above. Heads up though, this method may not work for every type of RDAP object 😭
  • If the client knows about an RDAP aggregator or redirector and its base URL, and trusts that service, it could send the query to the redirector. The redirector would then redirect the client if it knows the authoritative server the client hasn't found yet 🦋

Some authorities of registration data might team up to share their information for a common service, including mutual redirection [REDIRECT-RDAP] 🤝 collab era.

When a new object gets allocated, like a new AS range, a new TLD, or a new IP address range, there's no guarantee that it'll have an entry in the matching bootstrap RDAP registry 🌸 That's because the RDAP server for the new entry might not go live and get registered until later. So clients should expect that even if a TLD, IP address range, or AS range has been allocated, its entry in the bootstrap registry isn't guaranteed. Plan accordingly, bestie.

9. Limitations 🙈

This method doesn't give you a direct way to find authoritative RDAP servers for any objects other than the ones described in this document. The following objects are NOT bootstrapped with this method, so don't expect it to work for them:

  • entities
  • queries using search patterns that don't contain a terminating string matching some entries in the registries
  • nameservers
  • help

10. Formal Definition 📜

This section is the formal definition of the registries. The structure of JSON objects and arrays, built from a set of primitive elements, is defined in [RFC7159]. Those elements are then used to describe the JSON structure of the registries. Very technical, very precise, very us 💅

10.1. Imported JSON Terms 🎀

  • OBJECT: a JSON object, defined in Section 4 of [RFC7159]
  • MEMBER: a member of a JSON object, defined in Section 4 of [RFC7159]
  • MEMBER-NAME: the name of a MEMBER, defined as a "string" in Section 4 of [RFC7159]
  • MEMBER-VALUE: the value of a MEMBER, defined as a "value" in Section 4 of [RFC7159]
  • ARRAY: an array, defined in Section 5 of [RFC7159]
  • ARRAY-VALUE: an element of an ARRAY, defined in Section 5 of [RFC7159]
  • STRING: a "string", as defined in Section 7 of [RFC7159]

10.2. Registry Syntax 🧚

Using those terms for the JSON structures, here's how the syntax of a registry is defined. Grammar is not everyone's favourite, but this one is cute ✨

o  rdap-bootstrap-registry: an OBJECT containing a MEMBER version and
   a MEMBER publication, an optional MEMBER description, and a MEMBER
   services-list

o  version: a MEMBER with MEMBER-NAME "version" and MEMBER-VALUE a
   STRING

o  publication: a MEMBER with MEMBER-NAME "publication" and MEMBER-
   VALUE a STRING

o  description: a MEMBER with MEMBER-NAME "description" and MEMBER-
   VALUE a STRING

o  services-list: a MEMBER with MEMBER-NAME "services" and MEMBER-
   VALUE a services-array

o  services-array: an ARRAY, where each ARRAY-VALUE is a service

o  service: an ARRAY of 2 elements, where the first ARRAY-VALUE is a
   an entry-list and the second ARRAY-VALUE is a service-uri-list

o  entry-list: an ARRAY, where each ARRAY-VALUE is an entry

o  entry: a STRING

o  service-uri-list: an ARRAY, where each ARRAY-VALUE is a service-
   uri

o  service-uri: a STRING

11. Security Considerations 🔐

Okay, this part is serious, so listen up 🚨 By providing a bootstrap method to find RDAP servers, this document helps make sure end users get their RDAP data from an authoritative source, and not from rogue sources 😈 The method has the same security properties as the RDAP protocols themselves. The transport used to access the registries can be made more secure by using TLS [RFC5246], which IANA supports 🔒 Totally worth turning on.

Additional considerations on using RDAP are described in [RFC7481] 📚 Go read it, it's the next level of this whole thing.

12. IANA Considerations 📋✨

okay bestie, IANA has made the RDAP Bootstrap Services Registries 🦋. There are a few of them, listed below, and they're available as JSON objects. Section 3, Section 4, and Section 5 describe what's in them, and the formal syntax lives in Section 10 💜.

The way these registries get updated is NOT like normal IANA registries, so pay attention 👀. They're generated from the data, processes, and policies IANA already keeps in their allocation registries ([ipv4reg], [ipv6reg], [asreg], and [domainreg]), plus the new RDAP server info.

IANA will create and update the entries from those allocation registries whenever the allocation registries change 🔄.

This document doesn't change any policies for the allocation registries 🙅‍♀️. IANA just built a way to collect RDAP server information. The RDAP Bootstrap Services Registries start out empty and fill up gradually as domain and address space registrants send their RDAP server info to IANA 🌱.

IANA made a brand new top-level category on the Protocol Registries page, <http://www.iana.org/protocols> 🌈. It's called "Registration Data Access Protocol (RDAP)" and it's giving organized. Every RDAP Bootstrap Services Registry can be downloaded by the general public, on demand, as JSON, and each one's URI is listed right on the Protocol Registries page 💅.

Other normal registries will get added to this group later by other documents. The reason these URIs are listed so clearly on the main page is so implementers can find them easily. These registries are going to be read by software, and humans will use them for reference too 🧚.

Because software is going to be hitting these registries, the download demand may be unusually high compared to normal IANA registries 📈😭. The infrastructure that publishes the registries will need to be reviewed and might need to be beefed up 💪.

As Section 8 explains, software that reads these registries will rely on the HTTP Expires header field to limit how often it queries them ⏰. So that header really needs to be set properly, to give timely info as the registries change, while keeping the load on IANA's servers reasonable 🫶. The HTTP Content-Type returned to clients reading these JSON-formatted registries MUST be application/json, as defined in [RFC7159] 🍓. This is non-negotiable, periodt 💀.

Here's another fun one: because of how the info in these registries is grouped and formatted, the entries may not be sortable 🙈. So it is not required or expected that the entries be sorted in any way. No sorting pressure, bestie ✨.

12.1. Bootstrap Service Registry for IPv4 Address Space 💜

Entries in this registry contain at least the following:

  • a CIDR [RFC4632] specification of the network block being registered.
  • one or more URLs that provide the RDAP service regarding this registration.

12.2. Bootstrap Service Registry for IPv6 Address Space 🌸

Entries in this registry contain at least the following:

  • an IPv6 prefix [RFC4291] specification of the network block being registered.
  • one or more URLs that provide the RDAP service regarding this registration.

12.3. Bootstrap Service Registry for AS Number Space 🎀

Entries in this registry contain at least the following:

  • a range of Autonomous System numbers being registered.
  • one or more URLs that provide the RDAP service regarding this registration.

12.4. Bootstrap Service Registry for Domain Name Space 🌈

Entries in this registry contain at least the following:

  • a domain name attached to the root being registered.
  • one or more URLs that provide the RDAP service regarding this registration.

13. References 📚

13.1. Normative References 💖

13.2. Informative References 🧠

Acknowledgements 🫶

The WEIRDS working group had lots of discussions on this topic, including a session during IETF 84, where methods like in-DNS and others got debated 🗣️. The idea of using IANA registries was discovered by the author while chatting with colleagues, and also thanks to a comment from Andy Newton 💡. Everyone involved in these discussions is acknowledged here, obviously 🌷.

Linlin Zhou, Jean-Philippe Dionne, John Levine, Kim Davies, Ernie Dainow, Scott Hollenbeck, Arturo Servin, Andy Newton, Murray Kucherawy, Tom Harrison, Naoki Kambe, Alexander Mayrhofer, Edward Lewis, Pete Resnick, Alessandro Vesely, Bert Greevenbosch, Barry Leiba, Jari Arkko, Kathleen Moriaty, Stephen Farrell, Richard Barnes, and Jean-Francois Tremblay all gave input and suggestions to this document 👑. Guillaume Leclanche was a coauthor for some revisions, and his support is acknowledged here and greatly appreciated 🥹. The formal definition section was inspired by Section 6.2 of [RFC7071] ✨.

Author's Address 🦋

Marc Blanchet Viagenie 246 Aberdeen Quebec, QC G1R 2E1 Canada

EMail: Marc.Blanchet@viagenie.ca URI: http://viagenie.ca

📦 where this page comes from