How to Monitor Registration Changes with RDAP

On this page

1. Design the monitor as an evidence pipeline
2. Define exactly what is being watched
3. Discover the authoritative service for each observation
4. Poll without turning monitoring into scraping
5. Preserve the observation envelope
6. Validate before comparing
7. Compare a semantic snapshot, not serialized JSON
8. Classify changes before sending alerts
9. Keep failures, negative results and changes separate
10. Account for resource-specific change meaning
11. A reference monitoring sequence
12. Test the monitor with transitions, not isolated fixtures
13. Operational checklist
14. Frequently asked questions
15. Primary references

RDAP can be used to observe how a domain, IP network or Autonomous System registration changes over time. The difficult part is not scheduling repeated HTTP requests. It is deciding whether two responses describe a real registration change, a different representation of the same facts, a change in disclosure policy, or a request that never produced comparable evidence.

This guide describes a monitoring design rather than a specific vendor or software package. It assumes that the monitor already knows which resources it is permitted and operationally justified to observe. For a broader production-client checklist, including migration from port 43 WHOIS, use the guide to moving from WHOIS to RDAP.

Quick answer: Discover the authoritative service for every observation, retrieve the RDAP response at a bounded per-service rate, validate the response and queried object, then transform it into a semantic snapshot. Compare statuses as sets, events by action, entities by handle and role, and nameservers by name—not by array position. Store the requested and final URLs, retrieval time, HTTP outcome, bootstrap version, raw-response hash and parser version with the snapshot. Alert only on classified changes; record 429, 5xx, timeouts, invalid responses and discovery failures as inconclusive observations rather than changes to the registration.

Design the monitor as an evidence pipeline

A useful monitor separates retrieval from interpretation. Each stage should produce an explicit result that can be inspected later: the selected authority, the HTTP exchange, validation, normalized fields, the comparison, and the final alert decision.

Keep these stages separate in code and storage. A generic changed: true flag loses the information needed to answer basic questions later: Did the registry change a status? Did a redirect lead to another service? Did the response become less detailed because the access context changed? Or did a parser upgrade merely reorder output?

Define exactly what is being watched

The watch target should be a typed resource, not just an arbitrary URL. Record the resource type and normalized query together—for example, a domain watch for example.com—so the monitor knows which discovery and validation rules to apply.

Normalize the query before storing it. Domain names need a consistent internationalized-domain representation; IP addresses need a canonical textual form; ASNs need a numeric value independent of whether a user wrote 15169 or AS15169.

Do not use a previously observed endpoint as the permanent identity of the watch. RDAP service assignments and redirects can change. The resource remains the same watch target even if IANA later routes it to another base URL.

Monitor lookups, not broad searches

For change monitoring, prefer exact domain, IP and ASN lookups. Search endpoints can return changing result sets, may be truncated, and are not globally discoverable through the IANA bootstrap method. Entity handles are also scoped to registration systems rather than a universal namespace.

If the object of interest was reached through a domain, IP or ASN lookup, keep that parent lookup as the reproducible starting point. Follow entity or related links only when the monitor has a specific reason to track them and preserves the authority that supplied those links.

Discover the authoritative service for each observation

RFC 9224 defines bootstrap registries for domain names, IPv4, IPv6 and AS numbers. A monitoring run should resolve its target against a cached, validated copy of the appropriate registry, then construct the resource-specific query URL.

Do not download IANA bootstrap data before every watched lookup. Cache it according to HTTP freshness information and retain the last validated copy when a refresh fails. Record the bootstrap registry’s publication timestamp with each observation so a later authority change can be distinguished from an object-data change.

The RDAP server discovery guide explains domain suffix matching, base paths and redirects in detail. IP monitoring requires longest-prefix matching; ASN monitoring requires finding the bootstrap range containing the number.

Store both URLs:

• Requested URL: the URL constructed from the selected bootstrap base;
• Final URL: the URL that returned the response after bounded redirects.

A change in either URL is operational evidence. It should not, by itself, be reported as a change in the registered object.

Poll without turning monitoring into scraping

There is no universal safe polling interval for every RDAP service or use case. Choose the slowest interval that still supports the decision the monitor exists to make. A domain-expiration reminder may not require minute-level checks; an operational investigation may justify a shorter, time-bounded window.

Apply controls per authoritative service, because many watched resources can resolve to one endpoint:

• cap concurrency and request rate per service;
• spread scheduled requests instead of releasing a large batch at one instant;
• identify the client with a descriptive user agent and contact route when appropriate;
• honor service terms and notices returned with responses;
• treat Retry-After as a minimum wait after 429 Too Many Requests;
• use bounded backoff with jitter only for failures that can reasonably be temporary;
• stop or substantially slow a watch that repeatedly receives access-policy errors.

When a server provides HTTP validators such as ETag or Last-Modified, preserve them and use standards-compliant conditional requests where supported. A 304 Not Modified can establish that the selected representation has not changed without transferring it again. Do not invent validators from an RDAP event date: an object’s last changed event is registration data, not an HTTP cache validator.

Preserve the observation envelope

The raw RDAP body is only one part of an observation. Store enough context to reproduce how it was obtained and interpreted:

Evidence	Why it matters
Resource type and normalized query	Identifies the intended watch target
Bootstrap publication time	Explains changes in authoritative routing
Requested and final URLs	Preserves discovery and redirect provenance
Retrieval time	Establishes when the observation was made
HTTP status and selected headers	Separates positive, negative, limited and failed requests
Content type and rdapConformance	Supports response validation and extension handling
Raw-body cryptographic hash	Detects byte-level changes without using them as the alert rule
Parser and normalization version	Explains changes caused by monitor software
Access context	Distinguishes public and authorized views without storing credentials

If you retain raw bodies, protect them as registration data rather than harmless logs. Responses can contain contact details, and disclosure can vary by authorization and policy. Define retention, access and deletion rules before collecting a long history.

Validate before comparing

An HTTP 200 response is not automatically a valid snapshot. Before normalization, verify at least:

1. the body parses as JSON;
2. the response is an RDAP representation, normally indicated by application/rdap+json;
3. top-level rdapConformance includes a profile the client understands, including rdap_level_0 for the standard model;
4. objectClassName matches the expected resource type;
5. the returned identity or range contains the queried resource;
6. required fields used by the monitor have the expected types;
7. unknown extension members are preserved or ignored safely rather than treated as errors.

For an IP query, confirm that the address lies between startAddress and endAddress. For an ASN, confirm that the number lies between startAutnum and endAutnum. For a domain, compare a normalized ldhName with the requested name and account explicitly for any intended referral behavior.

Never replace the latest valid snapshot with HTML from a proxy, an unrelated JSON response, a truncated download or a parse failure. Store those as failed observations with their own categories.

Compare a semantic snapshot, not serialized JSON

Two JSON documents can differ without expressing different registration facts. Object-member order is not significant in JSON. RDAP arrays also need field-specific treatment: statuses are naturally compared as values, while events should be identified by their actions and dates. The order of strings in a notice description can preserve semantic breaks and should not be globally sorted.

Build an internal view containing only fields the monitor can interpret deliberately. An illustrative synthetic domain snapshot could group the following information:

Group	Example normalized content
Identity	Domain object, normalized name and registry handle
Statuses	Transfer and deletion restrictions represented as a set
Events	Registration, expiration and last-change dates grouped by action
Nameservers	Normalized names represented as a set
DNSSEC	Delegation-signing state and any DS data relevant to the watch
Entities	Registry-scoped handles paired with semantic roles such as registrar

This internal view is not a replacement RDAP schema. Preserve the raw response or its hash separately, and retain unfamiliar fields for later analysis if your policy permits it.

Normalize each structure according to its meaning

• Statuses: compare normalized values as a set; link each recognized value to its defined meaning rather than array position.
• Events: key by eventAction; allow more than one event for the same action and compare complete timestamps.
• Nameservers: compare normalized ldhName values as a set; track glue addresses separately if they matter.
• Entities: identify by handle within the responding registration system and compare roles as a set. Do not identify an entity by array index.
• DNSSEC data: compare delegationSigned, zoneSigned and DS/key data separately. An RDAP change is not a substitute for live DNSSEC validation.
• Notices and remarks: preserve type, description boundaries and links. Classify policy or redaction changes separately from object changes.
• Unknown extensions: retain their conformance identifier and raw subtree. Do not flatten an extension into a core field unless its specification is implemented.

Classify changes before sending alerts

A useful alert says what changed and why the monitor considers it meaningful. At minimum, separate these classes:

Class	Examples	Typical handling
Registration state	Status added or removed; expiration event changed	Alert according to the watch purpose
Delegation or security	Nameserver set changed; DNSSEC delegation state changed	Alert promptly when operationally relevant
Registration relationship	Registrar entity or network parent changed	Alert with old and new handles and provenance
Contact or disclosure	Entity contact changed; field became redacted	Restrict access; do not imply ownership changed
Service provenance	Bootstrap route, redirect target or final authority changed	Record separately; review whether object comparison remains equivalent
Presentation only	JSON order, whitespace or non-semantic formatting changed	Suppress
Monitor implementation	Parser or normalization version changed	Rebuild a baseline or mark the comparison as software-induced

Set alert severity from the monitor’s purpose, not from a universal ranking. A nameserver change can be urgent for an incident-response watch and routine for a historical dataset. A removed public email may be important for a contact directory but should be classified as a disclosure/contact change, not proof that the underlying organization changed.

Keep failures, negative results and changes separate

The same scheduled observation can yield several kinds of evidence. Collapsing them into “changed” or “unchanged” creates false deletion alerts and hides service problems.

Use distinct stored states such as:

• positive: a valid object response was observed;
• negative: the correctly selected service returned an RDAP 404 for the object;
• not_modified: a valid conditional request returned 304;
• rate_limited: the service returned 429;
• policy_denied: a policy-related 4xx prevented a comparable public response;
• temporary_failure: timeout, TLS, DNS, connection or 5xx failure;
• invalid_response: the response could not be validated as the expected RDAP object;
• discovery_failure: no usable authoritative route was established.

A transition from a positive response to a correctly routed 404 is worth attention, but it still does not prove that a domain is available to register, that an IP prefix is unused, or that an ASN is absent from routing. Preserve the prior snapshot, the new negative response, and the service provenance. Depending on the operational risk, require a later independent observation before escalating the transition as a disappearance.

Account for resource-specific change meaning

The monitoring pipeline can be shared, but domain, IP and ASN objects require different interpretation.

Resource	High-value comparisons	Important limit
Domain	Statuses, expiration and change events, registrar entity, nameservers, DNSSEC delegation	RDAP does not guarantee registration availability or live DNS behavior
IP network	Start/end range, CIDR data, parent handle, allocation type, entities and abuse role	Registration data does not identify a device, user, route or physical location
ASN	Start/end ASN, handle, name/type, entities, status and events	RDAP does not show current BGP announcements, peers or RPKI validity

Use the dedicated guides to interpret domain responses, IP network responses and ASN responses before deciding which fields drive alerts.

A reference monitoring sequence

Keep the orchestration explicit even when the implementation is small:

1. discover the current authoritative route from cached bootstrap data;
2. place the request in the selected service’s bounded queue;
3. retrieve the response with saved validators, a timeout and a redirect limit;
4. classify the HTTP outcome before attempting to compare registration data;
5. store a not-modified, negative or inconclusive observation without replacing the latest valid snapshot;
6. validate and normalize a positive RDAP object;
7. compare it with the latest valid semantic snapshot;
8. store the observation and classified differences;
9. enqueue an alert only when the classification matches the watch policy.

This sequence deliberately keeps failed observations visible and preserves the previous valid snapshot. A production implementation also needs durable locks, idempotent jobs, secure storage, metrics, cancellation and tests around every response class.

Test the monitor with transitions, not isolated fixtures

A parser test proves that one response can be read. A monitoring test must prove that a pair or sequence of observations is classified correctly.

Include fixtures for:

• identical semantics with reordered JSON members and arrays;
• a status added and later removed;
• a changed expiration event alongside an unchanged registration event;
• an authority or redirect change with equivalent object data;
• a contact becoming redacted under a different access context;
• an unfamiliar extension appearing without breaking core parsing;
• a valid response followed by 429, timeout or 5xx;
• a valid response followed by a correctly routed RDAP 404;
• a parser-version upgrade that changes normalized output;
• an internationalized domain represented consistently as an A-label.

Keep synthetic fixtures clearly labeled. For end-to-end tests against public services, use a small, stable test set and a conservative schedule. Do not make a public operator absorb a large test matrix on every build.

Operational checklist

• Define a typed, normalized watch target and a documented monitoring purpose.
• Rediscover authority from cached IANA bootstrap data for each observation.
• Queue and limit requests per service, not only globally.
• Honor Retry-After and distinguish retryable from permanent outcomes.
• Store request, response and parser provenance with every observation.
• Validate the response and returned resource before comparison.
• Compare semantic structures rather than raw JSON serialization.
• Classify object, disclosure, provenance and presentation changes separately.
• Preserve the last valid snapshot through inconclusive observations.
• Protect and expire retained registration data according to policy.
• Test transitions between observations, including failures and software upgrades.
• Make every alert explain the old value, new value, source and observation times.

Frequently asked questions

Can the last changed event replace polling?

No. It is a date reported by the registration system for an event associated with the object. It is not a push notification, an HTTP validator or a promise that every field change updates that event in the way your monitor expects.

Should every raw-response hash change trigger an alert?

No. A hash is useful evidence that the bytes changed, but whitespace, member order, notices, links or extension data can change without altering the fact being monitored. Run semantic comparison before alerting.

Does a 404 mean the domain was deleted?

It means the correctly selected service returned no matching RDAP object for that request at that time. Confirm the route and response, preserve prior evidence, and avoid equating the result with domain availability. Registry reservations and registration policy exist outside RDAP.

Can a monitor switch to another endpoint after a rate limit?

Not merely to evade the limit. Authority comes from bootstrap discovery and valid redirects, not hostname guessing. Honor the operator’s instructions, lower the rate and wait. If the bootstrap entry publishes multiple base URLs, use them according to a documented client policy rather than as a way to multiply traffic.

Should monitoring run in a browser?

A browser can perform individual public lookups where CORS permits them, but a controlled backend is usually more suitable for scheduled monitoring, per-service queues, conditional requests, durable snapshots and retention controls. Review the guide to browser RDAP failures before treating browser errors as registration observations.

Primary references

• RFC 7480: HTTP Usage in RDAP
• RFC 9082: RDAP Query Format
• RFC 9083: JSON Responses for RDAP
• RFC 9224: Finding the Authoritative RDAP Service
• IANA RDAP Bootstrap Service Registries