Summary

  • The REGEXT working-group draft on RDAP extensions says a server issuing a redirect must not blindly copy request parameters. It may forward one only if it knows the target can process it and is an appropriate recipient for its contents.
  • The draft tells extension authors not to depend on query parameters when a client must discover an authoritative server across authorities. A parameter can shape a direct search at a known server; it cannot be guaranteed a seat on every redirect.

The address is right; the question has changed

Imagine an RDAP client asking for an address record with an extension parameter requesting an extra view. The first server finds that another authority holds the answer and returns an HTTP redirect. The destination can be correct, the base record can arrive, and the extra view can disappear. That sequence is the design problem in the draft, not a reported incident. A redirect carries a destination. It does not confer permission to carry every piece of the original request to that destination.

RFC 9224 gives clients a bootstrap method based on IANA's allocation registries. The working-group draft points out the catch for number resources: an allocation map does not capture later transfers between regional registries. Redirects consequently matter when clients seek the authoritative RIR service. The question of what crosses the redirect is part of ordinary discovery, not an exotic failure path reserved for laboratory clients.

RFC 7480 tells an RDAP server to ignore unknown query parameters. Revision 17 of the extensions draft goes a step further at the next hop. It says the origin server must not blindly copy parameters from the request into the redirect URL. Parameters can contain credentials or tracking data that have no business arriving at the target. The origin may include a parameter only when it knows two things: the target can process that parameter, and the target is a proper recipient for its contents. Capability and entitlement are separate tests. A server that understands a field is not automatically entitled to receive what the field says.

This creates an awkward but honest result. The first server can suppress an extension parameter for good security reasons. A client following the Location URL may then receive an ordinary answer where it expected an enriched one. A product that labels both outcomes merely “RDAP success” will hide the material change in the question. Equally, a product that promises the extension will survive every discovery hop is promising a property the draft explicitly declines to give it.

Where an extension can use the query string

The draft does leave room for query parameters. When the client already knows the authoritative server and sends a query directly to it, a parameter can serve an extension; the draft gives search as an example. The restriction bites where finding the right server may itself require a redirect between authorities. In that setting, the extension must not rely on a query parameter to convey the resource information it needs. This is a design constraint on the extension, not a ban on useful parameters.

There is a tempting workaround: ask the client to read RDAP data returned with a redirect, reconstruct a new query and manage the parameter itself. The draft describes the cost. Some browser-based clients cannot access the RDAP content in a redirect. Client-managed handling must account for loops, parameter conflicts and URL encoding. That is a demanding way to rescue a feature that should have been designed around the discovery path in the first place.

The current Datatracker record lists revision 17 as an active REGEXT working-group Internet-Draft with an IESG state of “I-D Exists.” It has not reached RFC status. Its redirect language puts a decision with the server at the boundary: forwarding a parameter requires knowledge of the next server, not faith that an HTTP Location header will preserve the buyer's intended feature.

The public evidence gives no named operator whose parameters leaked, and no captured transaction proving an extension was lost in a live transfer. Such a transaction, with the request, Location URL, target capability and recipient policy, would turn this design risk into an operational finding.

Sources