## TL;DR
RDAP servers throttle aggressively, so the agent should act like every lookup costs money: cache every response on disk, deduplicate domains by registrar before querying, and back off when throttled. Most engagements need a fraction of the lookups the agent actually makes.

```text
recon agent hit RDAP rate limit mid-engagement; lookups failed on authorized targets
```

## Use this when
- RDAP lookups for authorized target domains start returning 429s or timeouts partway through enumeration.
- The agent looks up the same domain or IP block multiple times across the run.
- The failure cascade starts at the lookup stage and stalls everything downstream.

## Not for this skill when
- The RDAP server refuses the queries entirely (403, invalid responses). That is an access or format problem.
- The engagement has no domain or infrastructure enumeration phase. Then RDAP is irrelevant.
- Lookups succeed but the data is wrong. That is a data-quality problem.

## Steps
1. Add a local cache: before any RDAP query, check a JSON cache file keyed by domain or IP; after a successful query, store the response. Verify: the second run of the same target list makes zero RDAP calls.
2. Deduplicate the target list before querying: group domains by registrar and IPs by announced block, and query each group once. Verify: the deduped list is shorter than the raw list.
3. On a 429, back off exponentially with jitter and resume from the cache-aware queue instead of restarting. Verify: a forced throttle in testing pauses the queue rather than failing it.
4. Pace the queue below the server's documented limits with a fixed delay between calls. Verify: a 15-minute test batch completes without a single 429.
5. Log throttled queries with timestamps in the run notes so the tester can see whether the data is complete. Verify: the notes list any domains that never got a successful lookup.

## Variant phrasings
### RDAP throttling killed recon lookups
Same cache-and-backoff fix.
### agent re-queries RDAP for same domains
Deduplication-focused variant.
### WHOIS/RDAP rate limit mid-enumeration
Broader phrasing.

Compatibility: any RDAP client or script. The cache file pattern is client-agnostic.

## Why it happens
Recon agents expand targets enthusiastically: every subdomain becomes a lookup, every IP becomes a lookup, and the same infrastructure gets queried once per branch of the enumeration tree. RDAP providers rate-limit exactly this pattern. Without a cache the agent pays full price for every duplicate, hits the wall fast, and the whole downstream pipeline stalls on missing data.

## Edge cases / pitfalls
- Cached RDAP data goes stale; for long engagements, expire cache entries after a few days rather than trusting them forever.
- Some registries throttle harder than others. Track per-server throttle counts and pace each server separately.
- A domain that never resolves through RDAP is a data gap, not a dead end; note it and move on rather than retrying it into another rate limit.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DjsgTwS5ZjNCDJfETBH7Qg