The Protocol

The core of RDAP is a simple REST-like protocol using JSON.

It defines only the GET and HEAD HTTP methods, and URL paths are defined as patterns. The following is the output of the HTTPie program invoked to get information about example.com from IANA’s RDAP servers: http https://rdap.iana.org/domain/example.com accept:application/rdap+json.

GET /domain/example.com HTTP/1.1
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Host: rdap.iana.org
User-Agent: HTTPie/3.2.2
accept: application/rdap+json



HTTP/1.1 200 OK
Strict-Transport-Security: max-age=48211200; preload
access-control-allow-origin: *
content-length: 984
content-type: application/rdap+json
date: Sat, 27 Apr 2024 19:44:49 GMT
server: uvicorn

{
    "entities": [
        {
            "objectClassName": "entity",
            "roles": [
                "registrant"
            ],
            "vcardArray": [
                "vcard",
                [
                    [
                        "version",
                        {},
                        "text",
                        "4.0"
                    ],
                    [
                        "fn",
                        {},
                        "text",
                        "Internet Assigned Numbers Authority"
                    ],
                    [
                        "role",
                        {},
                        "text",
                        "Registrant"
                    ]
                ]
            ]
        }
    ],
    "events": [
        {
            "eventAction": "last changed",
            "eventDate": "1992-01-01T00:00:00+00:00"
        },
        {
            "eventAction": "registration",
            "eventDate": "1992-01-01T00:00:00+00:00"
        }
    ],
    "ldhName": "example.com",
    "links": [
        {
            "href": "https://rdap.iana.org/domain/example.com",
            "rel": "self",
            "type": "application/rdap+json",
            "value": "https://rdap.iana.org/domain/example.com"
        }
    ],
    "notices": [
        {
            "description": [
                "Terms of Service"
            ],
            "links": [
                {
                    "href": "https://www.icann.org/privacy/tos",
                    "rel": "alternate",
                    "type": "text/html"
                }
            ],
            "title": "Terms of Service"
        },
        {
            "description": [
                "Privacy Policy"
            ],
            "links": [
                {
                    "href": "https://www.icann.org/privacy/policy",
                    "rel": "alternate",
                    "type": "text/html"
                }
            ],
            "title": "Privacy Policy"
        }
    ],
    "objectClassName": "domain",
    "rdapConformance": [
        "rdap_level_0"
    ],
    "secureDNS": {
        "delegationSigned": false
    },
    "status": [
        "active"
    ]
}  
    

This output shows an HTTP GET request of /domain/example.com from the client with a 200 OK response from the server. The response contains JSON, most of which is directly defined in RFC 9083. The parts not defined in RFC 9083 are jCard which is a JSON encoding of vCard, the standard most users encounter when exchanging contact data (aka business cards) over email.

Breaking down the output, the following is the HTTP request:

GET /domain/example.com HTTP/1.1
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Host: rdap.iana.org
User-Agent: HTTPie/3.2.2
accept: application/rdap+json    

This is all normal HTTP semantics. The RDAP specific parts are the URL, which has the defined /domain path (See Lookups and Searches), and the media type of application/rdap+json in the accept header.

The next section shows the HTTP response.

HTTP/1.1 200 OK
Strict-Transport-Security: max-age=48211200; preload
access-control-allow-origin: *
content-length: 984
content-type: application/rdap+json
date: Sat, 27 Apr 2024 19:44:49 GMT
server: uvicorn    

Here, the important parts to note are the media type in the content-type header, which uses the RDAP media type, and the access-control-allow-origin header, which is used to allow web browsers to run JavaScript sourced from one website to use the RDAP content from an RDAP HTTP server.

Next comes the JSON, which has no strict order (because JSON defines none and RDAP enforces none). To help make sense of this, the sections of JSON are re-ordered for illustrative purposes.

The rdapConformance array is an RDAP structure containing protocol and extension compatibility information. At a minimum, it must contain the string “rdap_level_0”. This array shows up in every RDAP response. Here, it is lines 98-100:

    "rdapConformance": [
        "rdap_level_0"
    ],    

Each RDAP response is either a single object (the result of a lookup) or an array of objects (the result of a search). Every object must have an objectClassName to inform the client which object(s) is in the response. Here it is on line 97:

    "objectClassName": "domain",    

Lines 60 and lines 101 to 106 have information specific to domain objects. Line 60 describes the ASCII version of the domain name:

    "ldhName": "example.com",    

While lines 101 to 106 describe the state of the domain:

    "secureDNS": {
        "delegationSigned": false
    },
    "status": [
        "active"
    ]

And this domain object has other information embedded in it using common data structures found in all the objects classes:

• Lines 19 to 49: entities or the domain’s “contacts”.
• Lines 50 to 59: events such as when the domain was first registered.
• Lines 61 to 68: links to other information relevant to the domain.

Finally, there are notices from the server operator (lines 69 to 96):

    "notices": [
        {
            "description": [
                "Terms of Service"
            ],
            "links": [
                {
                    "href": "https://www.icann.org/privacy/tos",
                    "rel": "alternate",
                    "type": "text/html"
                }
            ],
            "title": "Terms of Service"
        },
        {
            "description": [
                "Privacy Policy"
            ],
            "links": [
                {
                    "href": "https://www.icann.org/privacy/policy",
                    "rel": "alternate",
                    "type": "text/html"
                }
            ],
            "title": "Privacy Policy"
        }
    ],    

Lookups and Searches

The example above shows a query for a specific domain registration. RDAP breaks down queries into two types: lookups and searches. Queries for a specific registry item or object, such as the one above, are lookups. Queries for multiple registry objects are searches. Each query is specified by a unique path.

RFC 9082 defines six types of lookups:

RFC 9082 defines the following searches:

These are the core queries defined by RDAP. However, RDAP has an extension mechanism that allows for other lookups and searches to be defined.