RDAP was created as a WHOIS system successor and is ultimately expected to replace WHOIS as the official source for IP addresses, Domain Names, Autonomous Systems, and many other registry data. RDAP uses an HTTP RESTful interface and implements a series of additional security features, internationalization features and uniform query/response definitions.
What is Registration Data Access Protocol (RDAP)?
RDAP is a protocol that delivers registration data like WHOIS, but its implementation will change and standardize data access and query response formats. RDAP has several advantages over the WHOIS protocol, including support for internationalization, secure access to data, and the ability to provide differentiated access to registration data.
The Registration Data Access Protocol (RDAP) enables users to access current registration data and was created as an eventual replacement for the WHOIS protocol. RDAP was developed by the technical community in the Internet Engineering Task Force (IETF).
RDAP offers the possibility of accessing further information on basic internet resources, including:
- Domain names
- IP addresses
- Autonomous System Numbers (ASNs)
What are the milestones for RDAP?
- 26 August 2019 is the deadline for the technical implementation of an RDAP service
- On 27 February 2019, the ICANN org issued a legal notification to generic top-level domain (gTLD) registries and registrars of the requirement to implement an RDAP service by 26 August 2019.
- On 31 August 2018, the ICANN org posted a proposed RDAP profile and opened a public comment period to collect feedback from the community.
- On 17 May 2018, the ICANN Board passed a resolution adopting a Temporary Specification for gTLD Registration Data. As part of that Temporary Specification, gTLD registries and registrars are required to implement a Registration Data Access Protocol (RDAP) service within 135 days of ICANN org requesting implementation. The Temporary Specification also called for a gTLD RDAP Profile, SLA, and registry Reporting requirements to be developed prior to RDAP deployment.
- On 1 September 2017, the ICANN org accepted the proposal to implement RDAP and started the first phase: an RDAP pilot.
- On 1 August 2017, the gTLD Registries Stakeholder Group with support from the Registrar Stakeholder Group submitted a proposal to the ICANN org to implement RDAP with a first phase in the form of an RDAP pilot.
- On 26 July 2016, ICANN org published a gTLD RDAP profile. Subsequently, the gTLD Registries Stakeholder Group requested that ICANN org not use that profile and instead work together on a modified plan to implement RDAP.
- In September 2015, ICANN org published a proposed draft of the RDAP operational profile for gTLD registries and registrars for discussion with the community. These discussions took place over the next 10 months, including a public comment period.
- In March 2015, the Web Extensible Internet Registration Data Service (WEIRDS) working group finalized the RFCs defining the Registration Data Access Protocol, a standardized replacement for WHOIS.
- On 4 June 2012, ICANN org published a Roadmap for the coordination of the technical and policy discussions necessary to implement the recommendations outlined in SAC 051:
- improve Whois terminology to enhance and disambiguate the discussion; and
- replace the Whois protocol to address various technical issues (e.g., internationalization).
- The Internet Engineering Task Force (IETF) chartered the WEIRDS working group to develop a protocol to replace WHOIS
- On 19 September, the Security and Stability Advisory Committee issued SAC 051 [PDF, 236 KB], which advised the ICANN community to evaluate and adopt a replacement for the existing domain name registration data access protocol (WHOIS).
- On 28 October, the ICANN Board adopted SAC 051 directing staff to produce, in consultation with the community, a roadmap for the coordination of the technical and policy discussions necessary to implement it. They also requested staff to forward SAC 051 to the Whois Review Team and ICANN's Advisory Committees and Supporting Organizations for their advice.
- The ICANN community held discussions about the need for the technical evolution of the WHOIS service.
- The IETF issued a protocol for a directory service for ARPANET users. This protocol has been in use ever since; it is referred to as WHOIS.
How does RDAP differ from Whois?
- While Whois is a protocol based on a text using a specialized Protocol and a port, RDAP is an HTTP-based REST protocol with structured responses defined in JSON. For web-based RESTful protocol, RDAP follows the industry-accepted definition. It uses URLs to differentiate between different services for JSON responses via HTTP/HTTPS. RDAP uses HEAD and GET as the only HTTP options.
- Data objects for RDAP response may be simply converted into non-english languages, while data objects for whois response cannot.
- RDAP responses give clear references to other RIRs, though Whois does not define queries or responses and there may be greatly variable interactions with DNRs and RIRs.
Why was RDAP developed?
The working group of the IEFT focused on the vulnerabilities of the old protocol and therefore on the stability, security, and internationalization of the new query protocol. Several new features have been created, including:
- Structured request and answer semantics (including standardized error messages)
- Secure access to the requested contact details (e.g. via HTTPS)
- Expandability (e.g., addition of output elements)
- ‘Bootstrapping’ mechanism (supported by the search for a suitable authoritative DNS server)
- Web-based (HTTP) and REST compliant
- Uncomplicated translation of output data
- Possibility of granting differentiated access to contact details
What is Bootstrapping?
A bootstrap server is a special type of server for helping clients find an authoritative server to query (this is called bootstrapping). Query bootstrapping can be an expensive process for some clients, and a bootstrap server can alleviate that expense by preloading the bootstrapping information. To utilize an RDAP bootstrap server, an RDAP client simply sends RDAP queries and receives HTTP redirects to the authoritative server.
The Internet Assigned Numbers Authority (IANA) publishes the following files:
- Autonomous System Numbers
- IPv4 Allocations
- IPv6 Allocations
- Domain Registries
What are the RDAP Specifications?
The RDAP protocol is specified in the RFCs:
- RFC 7480 – HTTP Usage in the Registration Data Access Protocol (RDAP)
- RFC 7481 – Security Services for the Registration Data Access Protocol (RDAP)
- RFC 7482 – Registration Data Access Protocol (RDAP) Query Format
- RFC 7483 – JSON Responses for the Registration Data Access Protocol (RDAP)
- RFC 7484 – Finding the Authoritative Registration Data (RDAP) Service
- RFC 7485 – Inventory and Analysis of WHOIS Registration Objects
What is RDAP.org and How to use it?
RDAP.org aims to support users and developers of RDAP clients by providing a "bootstrap server", i.e., single end point for RDAP queries. RDAP.org aggregates information about all known RDAP servers. RDAP clients can send RDAP queries to RDAP.org, which will then redirect requests to the appropriate RDAP service.
- Client Implementers
If you are developing an RDAP client, configure it to send HTTP requests to https://rdap.org/<type>/<object>, where <type> is the object type (one of domain, ip, autnum etc) and <object> is the object identifier (eg example.com, 192.168.0.1, 64496, etc).
- HTTP Status Codes
- 302 – occurs when RDAP.org knows of an RDAP service which is authoritative for the requested resource. Follow the URL listed in the Location header.
- 400 – occurs when RDAP.org receives an invalid request (malformed path, unsupported object type, invalid IP address, etc).
- 404 – occurs when RDAP.org doesn’t know of an RDAP service which is authoritative for the requested resource.
- 429 – occurs if you have exceeded the rate limits.
- 500 – occurs when RDAP.org is broken in some way.
- 504 – occurs if RDAP.org needs to refresh the IANA bootstrap registry, but cannot.
- Rate Limits
RDAP.org will return a 429 response if you send more than 3,000 requests in a rolling 300-second (5 minute) window. So you need to stay below 10 queries per second to avoid this limit.
If you are interested in doing high-volume data mining of registration data, please (a) don’t, but if you must, (b) consume the IANA registries directly. Net::RDAP::Registry, which is part of Net::RDAP, provides a simple interface to these registries.
Identify unauthorized and malicious signs fast with SOCRadar
Keeping a watchful eye on essential internet infrastructure including domains and IP addresses can be challenging and time-consuming. SOCRadar can do the heavy lifting for you. Streaming a massive, trackable WHOIS database, SOCRadar allows you to monitor all of your domains while maintaining an up-to-date view of your internet infrastructure including subdomains and IP addresses. Through SOCRadar Portal, all of your domains with subdomains and IP infrastructure can be maintained and monitored as an important part of your attack surface.
- Forgotten/unused domains: Auto-discover forgotten domains to prevent from being a possible phishing website.
- Auto-discover the related domains: Discover, track and map the domains associated with your organization.
- Detect malicious signs: Get notified if your IP addresses are blacklisted for spam, malware or bad reputation.
- Identify torrents/DHT traffic: Know immediately if your network appears to share or download possibly malicious torrents.
- Prevent subdomain takeover attacks: Be wary of dormant subdomains not to face takeover attacks damaging your brand image.
- Monitor WHOIS records: Spot early issues of unauthorized changes in your WHOIS information.
- Auto-track the renewals: Get notified if your domains’ expiry times are approaching for unwanted surprises.
With SOCRadar® Community Edition, you’ll be able to:
- Discover your unknown hacker-exposed assets
- Check if your IP addresses tagged as malicious
- Monitor your domain name on hacked websites and phishing databases
- Get notified when a critical zero-day vulnerability is disclosed