nicmx/rdap-server

Registration data server application, to be plugged into a servlet container along with a data access implementation.

Red Dog

Red Dog is an Open Source RDAP (Registration Data Access Protocol) Server implementation built with Java, funded and developed by NIC Mexico.

The server is a RESTful service expected to provide HTTP content in accordance with:

• RFC 7480 - HTTP Usage in the Registration Data Access Protocol (RDAP)
• RFC 7481 - Security Services for the Registration Data Access Protocol (RDAP)
• RFC 7482 - Registration Data Access Protocol (RDAP) Query Format
• RFC 7483 - JSON Responses for the Registration Data Access Protocol (RDAP).

Beside the RFCs accordance, Red Dog has the following features:

• Response render can be customized by implementing a set of interfaces; e.g. beside JSON responses, a TEXT/HTML/XML or any other response type can be returned if the implementer wishes to.
• Reference database and data access implementation to ease Red Dog's use.
• A set of Java interfaces to implement any kind of data access according to the implementer needs (e.g. data can be obtained from the implementer data repository).
• Optional Basic Authentication and the possibility to implement/customize the authentication type if needed.
• Response data privacy using general settings (e.g. everybody can see X data, nobody can see Y data, etc.) or specific settings (e.g. only the owner can see X data, certain custom user roles can see Y data).

Documentation

The documentation can be seen here.

Contact

Any comment or feedback is welcomed, issues can be reported at Red Dog's Github corner.

Visit our contact page to get more information.

License

Red Dog is licensed under Apache License 2.0.

rdap-server's Issues

objectClassName’s property still appearing even when it’s value is “none”

The property “objectClassName” located in the properties files of domain, entities and namservers was set with “none” value. But when doing a query or search, the objectClassName is still appearing in the response. This value should not be appearing in the query/search since it has a “none” value.

Authenticated-only elements not being obtained by registered user

When setting an element with the "authenticate" tag, such element is not retrieved when doing a search or query over a domain or element that contains such attribute.

Steps to reproduce:

1. Have a user created in the database
2. Set attribute to authenticate tag
3. Restart the server
4. Specify the login parameters in the URL request
5. Make a query for a domain that contains the specified element

Expected result:
If authenticated successfully, the query should bring every attribute marked with the "any" tag, as well as the "authenticate" tag

Actual result:
Query just brings attributes marked with "any"

Object not found when asking for a domain by nsIP parameter with an ipv6

When doing a search for a domain using an nsIP parameter with an ipv6, it shown an object not found, even though the object is in the bd.

This is the search that I made when asking for a domain through its nameserver ip with an ipv6
http://localhost:8080/rdap-server/domains?nsIp=1::1

Database connection is mandatory regardless of actual data access mechanism

This line should probably belong to the rdap-sql-provider project.

The Data Source is specific to the SQL mechanism. When users implement their own data access, the data source is completely undesired. The rdap-server currently requires it.

As it stands, I'm forced to require the user to provide a redundant/dummy (but valid and kicking) data source as part of the custom implementation form.

'zones' configuration value is a trap

https://www.reddog.mx/behavior-configuration.html#zones:

Zones managed by the server. The server will only serve domains that match this zone.

I find this field odd. Shouldn't the data access implementation be the one deciding this?

The field is especially jarring because it doesn't ship with a default value, so domain querying just plain doesn't work by default.

I feel that things should work by default. If the user doesn't want certain zones to be served, they will naturally lock them in the data access implementation. On the other hand, as it is, this field will be a natural trap for new users (who are just testing Red Dog) to fall straight into.

I think that this field should be purged. Either that or default to "manage everything".

Default value of `owner_roles` doesn't make sense to me

Quoting RDAP Operational Profile for gTLD Registries and Registrars:

1.5.8. The domain object in the RDAP response MUST contain entities with the following roles. Exactly one entity per role MUST be present in the response, each of them with a handle (ROID of the contact object, contact:roid, as defined in RFC5733) and valid members fn, adr, tel, email (as specified in RFC6350, the vCard Format Specification and its corresponding JSON mapping RFC7095):

• registrant
• administrative
• technical

Given that's listed among the requirements that need to be followed by both registries and registrants (and presumably also others), is there any reason why the default value of owner_roles should not be "administrative"?

In DB language’s value is stored in table Remarks, but it doesn’t appear in Entity or Nameserver.

Language’s value it’s not stored in the table of Entities or Nameservers; however, when doing a query/search this value is shown in that sections. Therefore, it is suggested to review if the language’s value should be stored in Entity or Nameservers’s tables.

Domains search by "nsLdhName" not working as expected

Hi, I'm currently implementing RDAP using your code.

The issue is: when searching domains with a valid nameserver that isn't an IDN (eg. ns1.example.com) I get a "400 - Bad Request" response; but when I search using a nameserver that is an IDN and with LDH notation, I get a valid response (eg. "200 - OK" when at least one domain is found).

The problem is at the class DomainSearchServlet private function getPartialSearch, line

if (nsNameLabel.getLabel().equals(nsNameLabel.getULabel())) {
    throw new BadRequestException("Only LDH domain labels are allowed.");
}

As said before, this logic works fine when the nameserver is an IDN and is sent in LDH notation or when the nameserver is sent with unicode chars (in this case the exception is thrown, so it´s ok).

Proposal: instead of comparing the label sent against the U-label and throw the exception when they're equal, the exception should be thrown if the A-label and the label sent aren't equal:

if (!nsNameLabel.getLabel().equals(nsNameLabel.getALabel())) {
    throw new BadRequestException("Only LDH domain labels are allowed.");
}

Greetings!!

Property “language” has inconsistencies when displayed in a query/search

The property “Language” is displayed in the tag of Entities and Nameservers when is made a query or search. However, language’s property doesn´t appear in the configuration’s files of entity or nameservers. Which means that the property could not be hidden. Therefore, it is suggested add a language’s property in the configuration’s files of entity and nameservers, with the purpose of hide this value when needed.

Does not work on *nix

The code is using backslashes in file names. This is the Windows way; it doesn't work anywhere else.

For the record, I found this issue in JsonUtil#createTermsOfService(String) and HelpResult#HelpResult(ServletContext). This is not intended to be an exhaustive list.

Differences at "configuration.properties" default file (META-INF) and configurable file (WEB-INF)

Not critical but still important to mantain consistency between the files:

• Comments on properties "zones", "owner_roles", "is_reverse_ipv4_enabled", "is_reverse_ipv6_enabled" and "anonymous_username" in file at WEB-INF indicate the default value but in file at META-INF don't indicate the default value.
• Additional comment "Optional. Profile used to operate the server,{...}" on property "operational_profile" in file at META-INF isn't at the file in WEB-INF.
• Property "allow_search_wildcards_anywhere" (and its comment) is only present in file at META-INF, it isn't at file in WEB-INF.

VCard object can't have more than one email

This case has arised in my implementation. When an entity has more than one email I can only set one email on the object VCard, so the other email is lost (at least in the response that the server will send). This is partially correct since it works, but what if I want to show both emails?

According to the RFC 6350 section 6.42 the VCard can have more than one email, so it shouldn't be a problem to place more than one email in the response. Also, if this is implemented, the emails should have the option to place the property "PREF" in case the user wants to specify the order of preference.

IllegalArgumentException when using an invalid PrivacyStatus value

Whenever an invalid value is placed at the properties in webapp/WEB-INF/privacy/*.properties an IllegalArgumentException is thrown. Eg. at the file "autnum_events.properties", set "eventAction=anyy" (note the typo) and start the server.

The issue is at mx.nic.rdap.server.util.PrivacyUtil function loadObjectPrivacySettings(String). This block is at the function, I added some comments:

String property = properties.getProperty((String) key).trim();
/** Here's the problem, the exception is never handled. The enum will never have an invalid value. **/
PrivacyStatus privacyProperty = PrivacyStatus.valueOf(property.toUpperCase());

switch (privacyProperty) {
case OWNER:
	break;
case AUTHENTICATED:
	break;
case ANY:
	break;
case NONE:
	break;
default:
	/** Good intentions, but the code is never reached **/
	isInvalidProperties = true;
	builder.append(key + "=" + property + ", ");
	continue;
}

Requests to "//domain/{existent.domain}" give a 404 code when it should be a 200 code

I hope to be clear explaining this issue, if not I'm open to receive comments. Assuming that my server context is "/" and that the domain "foo.bar" exists, a request to "/domain/foo.bar" should respond with a 200 code and its correspondent body; so far nothing new. If I make a request "//domain/foo.bar" or "////domain/foo.bar" I would expect the same result, a 200 code with the correspondent body.

What's actually happening is that I get a 400 code with the description "The requested domain does not seem to include a zone.". Just to add context, the RFC 3986 URI Generic Syntax will help us. What's understood from there is that any number of "/" after the context is valid and so it should be resolved by the server; as I understood, it should be resolved as the context. Eg. "////" should be treated like "/".

So, the error code responded by the server is because the DomainServlet is reached but is getting as a parameter the same name of the service mapped to the servlet ("domain"); in another words, is searching the domain name "domain" instead of search "foo.bar". The root of the issue seems to be at mx.nic.rdap.server.util.Util function getRequestParams(HttpServletRequest), since there is where the parameter is returned so that DomainServlet can use that parameter to make the search.

Reestructure the package mx.nic.rdap.server

This is only a suggestion so that the code organization can be improved. Currently the package mx.nic.rdap.server has many classes of many types; this classes can be moved to other packages so that they will be placed on a more appropiated package. The reestructuration that I propose is this:

• AcceptHeaderFieldParser: is used by RdapServlet, further in this list is a proposal for relocate RdapServlet, so AcceptHeaderFieldParser could be relocated to the same package or to a new package mx.nic.rdap.server.servlet.xxx.
• DataAccessServlet: could be placed at mx.nic.rdap.server.servlet.
• RdapConfiguration: could have its own package, something like mx.nic.rdap.server.configuration.
• RdapInitializer: is a WebListener, so it could have its own package mx.nic.rdap.server.listener. This new package could be useful for somebody that could want to add its own listeners.
• RdapResult: could be placed at mx.nic.rdap.server.result.
• RdapSearchRequest: is used exclusevely used by the servlets, so it can be placed at that package mx.nic.rdap.server.servlet or to a new sub-package mx.nic.rdap.server.servlet.request.
• RdapServlet: could be placed at mx.nic.rdap.server.servlet.
• Renderer: could be placed at mx.nic.rdap.server.renderer.
• RendererPool: could be placed at mx.nic.rdap.server.renderer.
• UserInfo: is only referenced by the classes at mx.nic.rdap.server.result so it could be placed at that same package.
• NoticesHandler, NoticesReader and UserNotices: the 3 classes handle XML and objects Notices, the proposal is to place them in a new package called mx.nic.rdap.server.notices or mx.nic.rdap.server.xml (honestly I prefer the first option).

Missing notices when the information can’t be displayed

By doing a query and the information of one of the nodes can’t be displayed, it shows an empty bracket. Instead of the brackets, it should appear a notice with a description about the reason the information cannot being shown.

Internal server errors are logged as warnings

The servlet "ExceptionServlet" creates an instance of "ExceptionResult" whenever its called. One of the cases in the constructor of "ExceptionResult" expects the code 500 (Internal server error); when this code is reached the error is handled as any of the others, but I believe that it should be handled in a different way.

The response for the request is ok, since the client only needs to know that an error has occurred; but internally the server should show more information about the error for the administrators to take the necessary actions on this error. It could show the stacktrace or somethig more informative than "WARNING: 500: ".

Operational profile remark is overwritten when rendering JSON

This issue can be reproduced when the server uses a profile distinct than "none". The class JsonRenderer tries to add the operational profile remark (line 60-61), and I say "tries" because after that intent the remarks are overwritten by the remarks that the result already had (line 63-64).

Precisely in the same scenario where the server has a profile, other remarks are placed before rendering the object, exactly at DomainResult and DomainSearchResult method validateResponse(). Or even this could happen if another remark is added in another flow (eg. entity search).

Probably the quickest solution is: if the remark is to be added at this level (JsonRenderer), it should be added to the list of existent remarks so that it doesn't get lost when rendering the object. The function currently used javax.json.JsonObjectBuilder.add(String name, JsonValue value) doesn't help much right now since "If the object contains a mapping for the specified name, this method replaces the old value with the specified value". This solution could imply to modify the object received as parameter, or to add some validation at the cycle of lines 63-65, which personally I wouldn't consider the "cleanest" option.

My proposal is that this remark should be added at another level, so that the renderer do what's supposed to do: to render and not to alter the object.

Query/search not display information of domains in zone which is not mx.

It has been made a search/query for a domain which not belongs to mx’s zone, as a result is displayed a 404 error code. The zone was properly set in configuration.properties’ file.
Steps to reproduce:
1) Set several zones in configuration.properties’ file.
2) Make a search/query of a domain with a different zone than mx

Wildcards "%" and "_" can be used on partial searches

When a partial search is made using the only wildcard allowed "*", I still can use other wildcards to get more information in the response. Here are some cases assuming that the minimum of characters allowed for the search is 5:
"/domains?name=%%a%*" will search for all the domains that have the char 'a' in their names.
"/domains?name=__e_*" will search for all the domains that the 3rd char of its name is the char 'e' followed by at least another char.

The use of this wildcards is valid when I have a MySQL or Oracle DB (just to say a few databases) as my data repository. To avoid this behavior I propose this update on the server code "mx.nic.rdap.server.RdapSearchRequest" line 80:

default:
	searchReq.type = RequestSearchType.PARTIAL_SEARCH;
	// Escape special characters to avoid its use as wildcards
	if (searchReq.getParameterValue().contains("*")) {
		searchReq.setParameterValue(searchReq.getParameterValue().replaceAll("(\\%|\\_)", "\\\\$1"));
	}
	break;

The purpose of the code is to escape the wildcards if the search is to be made using the sentence "LIKE" in the implementation, which I think is the most probable case.

ExceptionResult only expects 6 error codes

The object only expects 6 error codes inside its constructor, so what happens when a different code arrives as part of the parameter? For instance, when the server returns a 429 code. In this case there's no title nor description for the error.

Maybe there aren't many error codes currently returned by the server, but the "inconsistency" will grow if someone wishes to add more codes (eg. 301, 302, 303, 40x, etc.) on its own implementation. Probably the best solution will be to place a default case for the switch statement.

Beside this, I would like to suggest another thing. The codes are harcoded, wouldn't be better to declare them as constants or use something that already exists (eg. javax.servlet.http.HttpServletResponse.SC_*)?

Default values of configuration.properties aren't used when leaving properties with empty/null value

I must admit that this "issue" isn't probably that, but I would like to get your feedback. Currently the file webapp/WEB-INF/configuration.properties states the default value for all the properties and also states that all of them are optional, eg. for the property minimum_search_pattern_length the comment is "Optional.Minimum length of the search pattern. Default 5".

It's clear that if a property isn´t uncommented, the property will have its default value loaded from resources/META-INF/configuration.properties, but whenever the property is uncommented and without value bad things happen (someting like minimum_search_pattern_length=. For the example mentioned before I will get a "InitializationException" with the message "The following required properties were not found or are invalid values in configuration file : [minimum_search_pattern_length]". I believe this is inconsistent with the comment for two reasons: if it's optional it shouldn't be throwing the exception when it doesn't have value, and if it has a default value, why isn't used when the property doesn't have a value?

The `is_reverse_ipv#_enabled` options don't really belong to the server's configuration

The reason why is_reverse_ipv4_enabled and is_reverse_ipv6_enabled exist is because these searches can be expensive.

But that's only assuming the SQL provider is being used with default queries. I don't think it's sensible for the server to be making assumptions regarding the data access implementation's performance.

These keys belong to the SQL provider.

The user migration parameter doesn’t have it default value as a true.

Description
In the configuration.properties file of the migrator, the parameter “migrate.users” was left empty. Therefore, this parameter should take the value “true” as default. However, is considered that the parameter took a value of “false” because when the database was cleaned, the information of the users wasn’t deleted.

Steps to reproduce:

1. In configuration.properties file of the migrator, the value of migrate.users should be empty.
2. Execute the method of cleanRdapDBTest located in IndividualMigrationProcessTest
3. Execute the method of migrateUsersTest located in IndividualMigrationProcessTest

Configuration placement is inconsistent through the project

This documentation from "behavior-configuration" seems to be incorrect:

The WEB-INF folder is the default location of the configuration.properties file, but you can define a new location by following these steps:

1. In WEB-INF/web.xml, find the following lines:

  <!-- <param-name> -->
  	rdapConfigurationUserPath
  <!-- </param-name> -->
  <!-- <param-value> -->
  <!-- </param-value> -->

2. Uncomment them, and write a valid directory path in param-value.
3. Save the changes and test the configuration.

First, because the "rdapConfigurationUserPath" is not commented, this doesn't seem to be valid XML. Secondly, I could not find this code in the predefined web.xml so there was nothing to uncomment. Third, it seems that it was envisioned that the user would be able to enter an absolute path to whatever file anywhere, but this is not working: The code never actually queries the filesystem outside of the classpath and the servlet context.

So this is currently a seemingly pointless feature; one can redefine the configuration file, but only if it still is within the context.

response-privacy largely suffers from the same problems.

I think that this was the original vision for all the configuration:

1. First, query the classpath (ClassLoader#getResourceAsStream(String)) to get default values.
2. Then, if the user somehow defined custom locations for configuration files, then try and find that in the servlet context (ServletContext#getResourceAsStream(String)), and if that fails, try and fall back to find them elsewhere (Files#newInputStream(Path)).
3. Otherwise (if there were no custom file definitions) find the files in their default servlet context locations (Again, ServletContext#getResourceAsStream(String)).

On the other hand, from reading the code, it seems like the situation is as follows:

• In general, servlet configuration has classpath default values (1 ok) and normally resides in the servlet context (3 ok). If the user defined custom locations, they only work if these locations are still within the context (2 bad).
• Basic data access implementation configuration lacks default values (1 ok), and normally resides in the servlet context (as the server reads it and passes it along to the implementation), though if more than a single properties file is needed, the implementation needs to use the classpath instead because it doesn't know whether it is serving a servlet application (hence, the servlet context might not exist) (2 and 3 more or less bad).
• The configuration for the help response specifically (the XMLs) is the only one where the entire original vision appears to be followed correctly.

In other words, configuration placement is a bit of a mess right now. We need to first agree on a standard and then follow it.

Object Not Found when doing a domain search with nsLdhName and Regex parameters.

When doing a Domain search by nsLdhName and Regex parameters it has shown an object not found. This search should display the information of the domain requested

Response truncation is being deferred to the data access implementation

Every search method in the API receives an integer argument called resultLimit. This is fine, but I feel like we're deferring too much responsibility to the data access implementation.

If the implementation chooses to ignore the parameter and just build a full response for the sake of simplifying itself, the RDAP server should take care of truncating it to minimize network flood and enforce configuration policy. I mean, the DA implementation is a separate entity, and we're supposed to be liberal in what we accept from others.

Remarks values are harcoded and loaded in a validation function

The remarks that are used whenever the profile is distinct than "NONE" are harcoded in mx.nic.rdap.server.util.Util, I think that could be better to have them in a file just like the notices.

My proposal is to place this remarks (EppInformationRemark, WhoisInaccuracyComplaintFormRemark, and OperationalProfileRemark) in a file similar to notices.xml, maybe remarks.xml but with an additional option to indicate on which profile the remark is going to be used. This implies to create it's own schema just to differentiate them from the notices.

Beside this, currently two of the remarks (EppInformationRemark and WhoisInaccuracyComplaintFormRemark) are being loaded at the function validateResponse() in DomainResult and DomainSearchResult. Just as its name indicates, the function should be used to validate, so I suggest that this remarks will be loaded in another function, something like loadRemarks(); of course this will depends somehow of the first proposal in this issue and also could be affected by the solution (if it's going to be solutioned) of the issue #39.

Domains can have more than one registrar at a time.

When defining relationship between entities and roles for a domain, There is the possibility that a domain can have several REGISTRARS binded with a domain at any given time. This type of relationship, in the context of the server, defines a type of ownership over the domain.
Nonetheless, such type of relation can't be more than one at any given time.

Expected behavior:
Only one registrar at any given time, having ownership of the domain. Past relationships with registrars should be with related with events.
Actual behavior:
Multiple relationships between a domain and a registrar entity are possible

Domain name should not have the ccTLD concatenated

Description
When inserting a domain using the insertDomainAndGet’s method located in DomainTest.java, the domain has the ccTLD concatenated. The domain name should not have contactenated the ccTLD, it should be just the name of the domain.
(Hint: this could be found un line 136)

Lookup paths aren't strictly used as Resource Identifiers

This a concept issue, specifically a REST concept issue. Keeping it simple, the theory is that a resource identifier can be a URL or a URN, and that "REST uses a resource identifier to identify the particular resource involved in an interaction between components" (view more); so, for this case, the URL "http://rdap.example.com/domain/foo.bar" is not the same that "http://rdap.example.com/domain/foo.bar/hello".

When both examples are resolved in the server and assuming that domain foo.bar actually exists, both will respond the same: 200 response code and the domain information. Well, this is the issue.

Currently the logic implemented is first find the servlet (eg. /domain -> DomainServlet), then get the additional path values (eg. /foo.bar/hello) to use them as parameters in the correspondent servlet. So, if there are extra parameters they are ignored (eg. DomainServlet will only use the first parameter, for the example this is "foo.bar"). Exactly at this point is where the "Resource identifier" concept is broken.

The proposal is to use the URL as it should be used, as a resource identifier, so in case that an invalid/unknown identifier is received the correspondent response will be sent (could be a response code 404, 501, 400, ...).

This souldn't affect the behavior mentioned at RFC 7480 - section 4.3.

Response code 501 on domain searches by name when zone isn't configured

This issue seems to be partially analized and fixed; right at mx.nic.rdap.server.servlet.DomainSearchServlet.getPartialSearch(String, RdapSearchRequest, DomainDAO) there's this block:

switch (request.getParameterName()) {
	case DOMAIN_NAME:
		if (!RdapConfiguration.hasZoneConfigured()) {
			// Is valid if there are no available zones, because the
			// rdap could only respond to autnum and ip networks
			// (RIR).
			throw new NotImplementedException();
		}

Fine, probably that's the case why the zones weren't configured, but what if they where intentionally not configured by other reasons, or they weren't configured just by mistake?

As I've understood, the server will return the 501 code when the configurator/user explicitly wants to, not by business validations (probably in some cases this is the best option). So, if the server "could only respond to autnum and ip networks" the most likely case is that the other servlets (domain(s), nameserver(s)) will be disabled at a higher level.

My proposal is that instead of returning "NotImplementedException" the function could return a "NotFoundException" (if possible, with a significative message), since the service actually could be implemented.

The same issue is at function getRegexSearch in the same class.

Internal Error by doing a query/search for entities

When doing a query or search for entities its shown an error 500. Apparently this could be happening because while executing the query, it is searched for the table ipn_entity_roles which doesn´t exist.

Incorrect query skips zone id's

When doing a search for a domain other than .MX, the query will bring zero results. This is due to an issue in which the "IN" part of the query fails to correctly include all the options for the possible zone_id's
Problem appears to be that instead of being ('80, 83'), listing should be in the ('80', '83') format.

Setup:
Answering for .mx and .lat zones
Domains---
foo223947726.lat
mydomain.mx
TLD's---
.mx = 80
.lat = 83
Queries performed--
SELECT d.* FROM rdap.domain d WHERE d.dom_ldh_name = 'foo223947726' AND d.zone_id IN ('80, 83') ORDER BY 1 LIMIT 5;
SELECT d.* FROM rdap.domain d WHERE d.dom_ldh_name = 'mydomain' AND d.zone_id IN ('80, 83') ORDER BY 1 LIMIT 5;

Steps:

1. Go to rdap domain search url
2. Put mydomain.mx as the ldh name
3. See result
4. Change ldh name for lat one
5. See results

Expected:
See the information regarding the .lat domain

Actual result:
404 Error

`operational_profile` is useless as presented

https://www.reddog.mx/behavior-configuration.html#operational_profile

ICANN's document lists several requirements that cannot be fulfilled by RD on its own. One quick example: 1.3.8: "RDAP services MUST be available over both IPv4 and IPv6 transport."

The operational_profile field is completely useless if its documentation fails to state what is covered by RD and what needs extra effort. We can't have users enable this switch and assume they are automatically compliant. Are we seriously expecting them to dive into the source code?

I guess what I'm asking for is a table that looks somewhat like this:

Requirement	registry	registrar	none
1.2	✓	✓	x
1.3	x	✓	x
1.4	✓	Needs extra effort	x
...	...	...	...

Also, the none value is puzzling. Are all the "validations and requirements" disabled when none is the active profile? Is there any reason to avoid these requirements like the plague when the user is neither a registry nor a registrar?

Internal server error when consulting a domain without a zone.

When doing a query asking for a domain without a zone, the application shows an error 500. It is suggested that in this case could be shown an error 400 for malformed query or 404 for object/zone not found.

This is an example of the query that produces the error:
http://localhost:8080/rdap-server/domain/dn19

Files at "WEB-INF/help" and "WEB-INF/terms-of-service" aren't used

The files WEB-INF/help/1Example and WEB-INF/terms-of-service/terms_of_service aren't used nor referenced anywhere in the project. I'm assuming that they shouldn't exist.

The implementation of the nameserver it’s not found.

When doing a query or search asking for a nameserver it shown an Internal Error (Error 500). Apparently the problem is because it is searching the implementation of the nameserver and it didn’t find it because it's name has a typo.

“Variant” doesn´t display information when doing a query or search.

When doing a query or search of a domain, the property “variant” displays an empty bracket. The variant should display the information related with the domain.

Reverse resolution is not working properly.

When doing a query asking for a domain in reverse resolution it shown a message error indicating that the zone it´s not found. However, the zone is set as managed in the configuration.properties.
Apparently, there is a problem when asking for something that seems to be an IP, because the error about zone not found continues appearing. Nevertheless, when doing a query with something similar like a domain name and the zone of in-addr.arpa or ip6.arpa the response said in fact that the object is not found, but there is no problem with the zone in this case.
Asking for reverse resolution
/rdap-server/domain/0.1.168.192.in-addr.arpa
Response:
{"rdapConformance":["rdap_level_0"],"errorCode":"404","title":"Object not found","description":"Zone not found."}

Asking for a domain in the zone in-addr.arpa
/rdap-server/domain/0.in-addr.arpa
Response:
{"rdapConformance":["rdap_level_0"],"errorCode":"404","title":"Object not found","description":"Object not found."}

Please fall back to 404 everything when the data source is null.

To be honest, the installation process is a huge mess, despite the demo. There are too many steps and little to no positive reinforcement between them.

One thing that would help tremendously would be the ability to start the server with no database. If the server does not find a data source in the context, it should fall back to not respond any objects but still provide simple echoes such as an index page and the help response. Currently, it throws an exception (which is, as a matter of fact, invisible to Tomcat logs by default) and refuses to start.

As it is, I'm finding myself driven to fuse several documentation pages (1 2 3) because they are in fact one single massive atomic step, and their separation feels rather misleading and unjustified.

Internal server error when accesing "/exception" servlet

Currently the server has a servlet to handle errors, this servlet is bounded to the location "/exception". This location may be used internally, but still it can be accessed externally; so when somebody access "rdap-server/exception" the server throws a NullPointerException and responds a 500 error.

I would like to make a suggestion: why not use a filter instead of a servlet? The servlet works fine, but it can give this kind of problems. Also, just in case that you decide to stay with the servlet, I suggest this: when the servlet is directly accessed it should respond with a 404 code, since that service is not part of the RDAP specs.

VCard 4.0 TEL is always set as text

This issue is merely an observation based on the RFC 6350 section 6.4.1. It's stated that for the TEL property "Value type: By default, it is a single free-form text value (for backward compatibility with vCard 3), but it SHOULD be reset to a URI value. It is expected that the URI scheme will be "tel", as specified in [RFC3966], but other schemes MAY be used". The server uses this property for the distinct phones that a VCard could have (cellphone, voice, fax) as seen at mx.nic.rdap.server.renderer.json.VCardJsonWriter functions getVoice(String), getCellphone(String), getFax(String).

The functions use "text" as value type, this isn't incorrect just as is mentioned in the RFC to allow backward compatibility, but the same text states that version 4.0 SHOULD use a URI value not a TEXT value. So, taking this to an example (based from RFC 7095 appendix B.1, if I have this number:
+1.1234567x890

I SHOULD expect that VCard v4.0 will display it as:
tel:[phone];ext=890

"Text" renderer should be associated with text/plain content-type

When using the "text" renderer the content-type is supposed to be set to text/html.

However, the result is plain text. The rendering behaviour of user tools is probably undefined.

One could:

• wrap the text in pre tags in order to have well-formed html
  or
• use the text/plain content-type

Mistaken error code for a zone which is not being managed

Description
It has been made a query for a domain name which has a zone that is not being managed. The error code resulting for that request was “400”. However, the error code should be “404” because the request does not contain a malformed query, it’s just that the server doesn’t have the information being requested neither the knowledge of where the information can be found. This situation only happens when doing a query. (In the case of the search the code error appears correctly)

Internal Error when not finding an object instead of showing a 404 Error message

When doing a query by IP with an object that is not in the BD it shown an Internal Error (Error 500) but instead that, it should show a 404 not found message.

Does not allow multiple implementations of the data access API in the classpath.

This is not that diffucult to work around, but it makes the installation process somewhat awkward.

If the RDAP server finds multiple implementations of the data access API, it crashes and refuses to start. This means that, in order to install a new data access implementation, the old one has to be explicitly removed.

One problem with this is that it forces the user to fake-deploy before the data access implementation can be replaced. The default implementation ships with the server WAR, so to switch the implementation I need to

1. Start the servlet container (expand the WAR).
2. Remove the old implementation from the classpath.
3. Copy the new implementation in.
4. Restart the servlet container to apply changes.

Starting the servlet container before the app is configured is unnatural. This should be less traumatic:

1. Copy the new implementation in.
2. Tell Red Dog which implementation should be used via configuration.
3. Start the server.

Another drawback is that forcing one implementation per classpath forces the user to keep track of which implementations have been installed in the past. This would not be the case if only the valid one has to be referred to in a file.

Wrong objectClassName value in Ip Network response.

The "objectClassName" attribute value should be "ip network" (https://tools.ietf.org/html/rfc7483#section-5.4), the server sends "IpNetwork" (https://github.com/NICMx/rdap-server/blob/master/src/main/java/mx/nic/rdap/server/renderer/json/IpNetworkJsonWriter.java#L36)

sample response of server:
{
"rdapConformance": [
"rdap_level_0"
],
"objectClassName": "IpNetwork",
.
.
.
}

Default values in privacy configuration are not working.

Description
According to the documentation the default value of privacy is “any”. However, when those values are left empty the server fails to start. The server should not fail to start; it just has to interpret that when there is empty in whichever privacy configuration’s properties means that the value is “any”.
This situation happens with every privacy configuration property located in the privacy_default’s folder.

Zone validation is case sensitive in domain search

Assuming that the server has configured the zone "bar" at configuration.properties, it will only allow the search of domains of such zone (nothing new). The issue appears when the zone of the searched domain isn't literally "bar". This is easier to explain with an example, if the following search is made:
/domain/foo.bar
assuming that "foo.bar" exists in my database, the response code will be 200 (OK). But if the search is:
/domain/foo.BAR
the response will be 404 (Not found), and in the body will contain the text "The zone is unmanaged by this server.".

The zones are loaded in the application just as they are written in the configuration file (mx.nic.rdap.server.RdapConfiguration.validateConfiguredZones()), so whenever they are validated (isValidZone(String) or even at isValidReverseAddress(String)) the validation will succeed if it's an exact match. I would suggest that the zone can be case insensitive.