Using wildcards while searching domain by name/nsLdhName idn (*xn--*)

[TheRedTrainer]

Should the name and nsLdhName domain's searches including an idn and a wildcard be allowed? For example, if you execute the following searches:

example.com/rdap-server/domains?name=xn--
example.com/rdap-server/domains?nsLdhName=xn--

the server send a response. However, if you execute the following searches:

example.com/rdap-server/domains?name=xn--*
example.com/rdap-server/domains?nsLdhName=ns0.xn--.

the server answers: "400: Bad request".

[pcarana]

example.com/rdap-server/domains?name=xn--
example.com/rdap-server/domains?nsLdhName=xn--

the server send a response. However, ...

Just to clarify the description: there was a problem with the markdown, I believe that what you meant to describe was:

example.com/rdap-server/domains?name=*xn--*
example.com/rdap-server/domains?nsLdhName=*xn--*

Right?

[TheRedTrainer]

That's right. My bad. I meant xn-- for name and nsLdhName.

[pcarana]

No problem ;)

[pcarana]

This is a problem from a dependency inherited from rdap-core, specifically:

<groupId>com.ibm.icu</groupId>
<artifactId>icu4j</artifactId>
<version>58.2</version>

The issue is at com.ibm.icu.impl.UTS46 class that's used at mx.nic.rdap.core.db.DomainLabel. As seen in the source code of UTS46 class there's a comment: // "??--..." is Punycode or forbidden., which leads to the conclusion that any label that starts with "xn--" or any other thing like "ab--", "bc--", and so on, will be invalid due to this validation. Of course, if the label is validated using the functions provided by the IDNA_INSTANCE at DomainLabel class (the process of validation is made when the label transformed).

So far this issue is still present, no patch or fix has been made. Recommendations and help are welcomed.

Leaved as enhancement since it's out of scope for milestone 1.2.0.