Custom hostname resolution in Java

Custom hostname resolution has been proposed for Java 18¹ and would allow secure DNS implementations without operating system support as well as faster lookups in cloud environments. However it also makes diagnosing network problems harder.

JEP 418² seems to be a happy ‘side effect’ of Project Loom and allows for plugging custom hostname resolvers into the Java runtime using the ServiceLoader mechanism. Obvious benefits include allowing support for DNS over HTTPS and DNS over TLS without the need for operating system support or configuration.

But beyond that, it would allow cloud native applications to perform faster lookups. Rather than querying for a hostname when needed, a resolver could maintain a cache and receive push messages when a hostname is updated. Fast lookups would be especially beneficial in environment with a large number of interconnected microservices and serverless environments. Hostname level load balancing could also receive a boost, no longer needing to rely on the time-to-live (TTL), instead the resolver could implement any desirable strategy. Hypothetically, if, node utilization statistics are available, the resolver could prefer less busy nodes.

The downside of all this flexibility is that debugging network issues becomes a lot harder. Already a single hostname could resolve to different IPs based on the node resolving it. So it is already often necessary to create a shell on the node experiencing the problem in order to use a tool such as host (or dig or ping) to determine where network traffic is going. With a custom resolver these tools would become useless because the application resolver could yield a different result from the operating system resolver.

One way to counter this would be to log the resolved IP address in addition to the hostname in debug logging. For example

2021-10-31 13:42:29 DEBUG - Retrieved details from https://google.com[142.251.36.14]:443/

Obviously this would need to be the IP address from which the actual data was fetched rather than the one to which the hostname resolved at time of logging.

Diagnosing network issues in cloud environments is already non-trivial. Hopefully the people who are going to implement custom resolvers will also think about including diagnostic data.