RDAP rate limits and access tiers

RDAP has no universal rate limit. The protocol's own spec, RFC 7480, permits a server to return 429 Too Many Requests with optional rate-limit details in the body, but sets no number. Every registry picks its own, and the numbers vary by an order of magnitude.

What the limits actually look like, registry by registry

None of these are the same shape. Norid and ISNIC both cap a longer window and a short burst separately. rdap.org's Cloudflare front door only cares about the short burst. There's no header or field in an RDAP response that tells a client which of these it's talking to before it gets throttled once.

Looking up the right server in the first place adds its own cost. IANA's bootstrap registry maps a TLD to its authoritative RDAP base URL, which is the only way to stay correct as registries change endpoints, but it's an extra lookup and redirect before the real query. Some client libraries skip it and hardcode known registry URLs instead, trading a faster query today for one that silently breaks the day a registry moves its endpoint without updating the bootstrap file on its own schedule.

When a registry enforces harder than it documents

The documented number isn't always the real one. A GitHub issue against the ipwhois library reports LACNIC's RDAP service throttling well below its own stated 10-per-minute limit, tested from multiple networks with plain wget, no client-side code involved. This is the actual operational risk of hardcoding per-registry numbers into a poller: the number you coded against and the number the registry currently enforces can drift apart without any changelog telling you.

The practical response isn't a bigger hardcoded table, it's backoff. A client that treats every 429 as a signal to slow down, not just retry immediately, survives a registry tightening its limits without a code change. A client hardcoded to "LACNIC allows 10/min" doesn't.

Access tiers: RDAP was built to show different people different things

Rate limits control how often you can ask. Access tiers control what you get back when you do. WHOIS vs RDAP covers why: WHOIS had no mechanism for showing different fields to different requesters, RDAP does, which is the entire reason a public RDAP query can return less than what a logged-in registrar dashboard shows for the same domain.

That access control is visible in a real response, not just a policy statement: reading an RDAP JSON response shows blank fn, tel, and email fields on a registrar's abuse contact, values the registry chose not to return to a public requester, not a parsing failure.

RDRS: the real mechanism, not just a policy statement

The Registration Data Request Service is ICANN's standing path for requesting nonpublic gTLD registration data: consumer protection advocates, cybersecurity specialists, government officials, IP professionals, law enforcement, and others with a documented legitimate interest submit a request through a centralized system rather than emailing a registrar and hoping.

The timeline, verified directly from ICANN's own page as of 2026-08-11:

• 28 November 2023: RDRS launched as a two-year pilot, starting with 56 registrars covering 51% of domains under management.
• February 2025: participation peaked at 95 registrars covering 60% of domains under management.
• November 2025: the pilot period concluded.
• ICANN84 board resolution: operations continue for up to two more years, through 2027, while policy work on the longer-term System for Standardized Access/Disclosure (SSAD) continues.
• July 2026: a new community effort begins to build a proof-of-concept for authenticating law-enforcement requestors, developed with INTERPOL and the FBI, specifically for urgent requests.

This is still an evolving system, not a finished one. RDRS exists because RDAP's differentiated access created a real gap, structured requester types with a legitimate interest, and no standard way for them to prove it or ask. A pilot that grew from 56 to 95 participating registrars and then earned a two-year extension is a program still finding its shape, not a settled spec detail.

What this means for anything polling on a schedule

RDRS solves a different problem than scheduled domain monitoring does. Monitoring reads the public response on a cadence and watches what changes, it was never asking for the nonpublic fields RDRS exists to unlock. The two systems don't compete, a monitoring tool has no reason to authenticate as a law-enforcement requestor just to check an expiration date.

What monitoring at any real scale does need is the discipline the rate-limit section above argues for: query through IANA's bootstrap registry rather than a hardcoded per-registry URL list, and treat every 429 as a signal to back off rather than a bug to route around. The numbers in the table above are real today. They are not a contract.

It's the same discipline behind WebPixie's own domain monitoring: polling on a schedule, not authenticating as anything more than a public requester.