Why Can Domain Information Look Limited in an RDAP Response?
A field missing from an RDAP response does not by itself mean that no record exists. Review data scope, authorization, and the queried object type together.
When you query a domain through RDAP, an expected date, contact-related value, or nameserver detail may not appear. It is easy to read that as “there is no record” or “there is a problem with the domain.” However, an RDAP response is constructed for the object being queried and according to the server’s publication policy. When you see missing domain information in an RDAP response, it is safer to assess the scope of the data first.
At a glance
- RDAP servers may omit non-required registration data members according to their policies.
- Domains, nameservers, and entities are separate object classes in the RDAP model.
- Before treating a missing field as no record, review the query type, authorization, and response scope.
Short answer: A missing field is not always a missing record
RDAP is a protocol used to provide information from registration systems. You should not assume that the JSON object in a response will contain every possible item of registration data. The standard says that RDAP clients must be prepared for specified registration data members to be absent from a response. A server may omit non-required or optional members according to its own policies.
Therefore, if a date, contact-related value, or another detail is absent, the first conclusion should not be “this data does not exist in the registration system.” The more careful conclusion is: this data has not been published in this response. The existence of registration data and its display in one response are not the same thing.
- A member absent from a response may be optional registration data that the server has not published.
- Confirm which object was queried before assessing a domain.
- Do not make a definite statement about a record based only on visible fields.
Source: [2]
First check which object the query concerns
In the RDAP data model, domains, nameservers, and entities are separate object classes. This distinction matters: the absence of a nameserver or entity detail in a domain response does not by itself show that the separate object has no record.
For domain information, the query path has the form domain/domain-name, with the domain name used as a fully qualified domain name. Nameserver information is obtained through a separate query in the form nameserver/nameserver-name. Therefore, it is not correct to expect a domain/example.com response to contain every detail that a direct nameserver query could return.
Example scenario: You query example.com and do not see an expected detail about a particular nameserver. This does not necessarily mean that the nameserver does not exist. First separate the domain object from the nameserver object in this example, then query the nameserver through its own query path if needed.
The article How to Read RDAP Nameserver Information with Domain Delegation is a useful next step for interpreting separate object queries and the distinction between a domain and a nameserver.
- Domain query: domain/domain-name
- Nameserver query: nameserver/nameserver-name
- Domains, nameservers, and entities are not the same object class.
Authorization can change the scope of visible data
The scope of an RDAP response can be affected by the authorization level of the requesting client. In particular, for rdapConformance identifiers, the standard says that responses other than help responses include only the specifications used to construct the response, and that the returned set of identifiers may vary with client authorization.
The standard also gives an example of using remarks to state that an object was truncated because of authorization. The explanation says that some registration data may not have been given and that proper authorization credentials are needed to see all of it. When you see such a remark, do not immediately treat the absent field as deleted or never created.
In practice, check the remarks field for a statement that the response was truncated because of authorization. Then note the access conditions under which the response was obtained. This makes it easier to interpret responses carefully when comparing results seen at different access levels.
- Look in remarks for a statement about truncation due to authorization.
- Allow for the possibility that the rdapConformance list changes by access level.
- Do not equate visible data with all data held by the registration system.
Source: [2]
Do not mix up lookup and search responses
A successful lookup for one object returns a JSON object that is the subject of the query. In contrast, a successful search for multiple objects returns a JSON object containing an array of the found JSON objects. Identifying the response form helps you understand whether an expected value belongs to one object detail or to an object within search results.
This distinction is especially useful when reviewing a response containing multiple results. Rather than expecting the same members in every returned object, read each object according to its own published scope. The client or tool you use must also handle whether the response is a lookup or a multiple-object search correctly.
- Single-object lookup response: the JSON object that is the query subject.
- Multiple-object search response: an array containing found JSON objects.
- Do not assess an absent field before identifying the response type.
Source: [2]
Non-standard fields and the status-events distinction
An RDAP server can add JSON members not specified by the standard, and clients are advised to ignore members they do not recognize. The presence of a provider-specific field therefore does not mean that standard members must appear in every response. When processing a response, do not treat an unrecognized field as an error or infer a general standard requirement from it.
Also, do not read status and events as the same kind of information. Status is an array indicating the state of a registered object. Events represent events that have occurred on an instance of an object. One describes the object’s state and the other describes events; the appearance or absence of one does not substitute for the other.
For this distinction, the guide How to Separate Domain Status and Registration Events in RDAP can help you assess the status and events fields as separate questions.
- Unrecognized JSON members may be non-standard additions.
- status indicates the state of a registered object.
- events represent events that have occurred on an object instance.
Source: [2]
A practical order for interpreting the response
When information does not appear in RDAP output, use a consistent review order instead of making a definite statement from one visible or absent key. This order reduces the chance of reaching a conclusion from a single part of the response.
First check the query path: was a domain or a nameserver queried? Then identify whether the response is a single-object lookup or a multiple-object search. Next, allow for non-required members to be omitted by server policy. Check whether remarks include information about truncation due to authorization. Finally, read provider-specific unrecognized fields separately from standard fields, and interpret status and events according to their separate purposes.
- Identify the query subject: domain, nameserver, or another object.
- Separate the response type: single-object lookup or multiple-object search.
- Consider that optional members may not have been published.
- Check remarks for authorization-related statements.
- Interpret status and events separately.
Practical checklist
- Confirm that domain/domain-name is used for a domain and nameserver/nameserver-name for a nameserver.
- Consider that an absent field may be optional registration data.
- Check whether the response is a single-object lookup or a multiple-object search.
- Look for a statement in remarks about truncation due to authorization.
- Note that rdapConformance identifiers may vary with client authorization.
- Do not confuse non-standard JSON members with standard members.
- Do not interpret status and events as the same type of information.
Gaps in an RDAP response do not by themselves prove that a record does not exist. Consider together the object for which the response was produced, whether the data is optional, whether it was truncated because of authorization, and whether the response is a lookup or a search result. This approach helps you interpret domain data more calmly and accurately.
Frequently asked questions
Does a missing contact-related value in an RDAP response mean that no record exists?
No. RDAP servers may omit non-required or optional registration data members under their own policies. Some registration data may also not have been given because of authorization.
What does it mean if I cannot see a nameserver detail in a domain response?
Domains and nameservers are separate object classes in the RDAP model. For nameserver information that is not visible in a domain response, assess a separate query in the form nameserver/nameserver-name if needed.
Are status and events alternatives to each other?
No. status indicates the state of a registered object, while events represent events that have occurred on an object instance.
Sources
[1] rfc9082.txt
[2] rfc9083.txt
