The bug in OpenJDK (JDK-8322243) results in DirContextDnsResolver failure

[mikalai-canva]

Bug Report

Current Behavior

The bug is tracked by the OpenJDK bug tracker and occurs when sun.net.dns.ResolverConfigurationImpl fails to correctly parse certain IPv6 records from the resolv.conf file.

Lettuce documentation mentions the DirContextDnsResolver that can be desirable for setups like AWS ElastiCache. While the bug has nothing to do with Lettuce and needs to be fixed in OpenJDK, it might be useful to mention it and suggest a possible solution considering that DirContextDnsResolver is based on the com.sun.jndi.dns.DnsContextFactory which relies on sun.net.dns.ResolverConfigurationImpl.

Stack trace

java.lang.NumberFormatException: For input string: ":ffff:127.0.2.2"
at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
at java.base/java.lang.Integer.parseInt(Integer.java:668)
at java.base/java.lang.Integer.parseInt(Integer.java:786)
at jdk.naming.dns/com.sun.jndi.dns.DnsClient.<init>(DnsClient.java:125)
at jdk.naming.dns/com.sun.jndi.dns.Resolver.<init>(Resolver.java:61)
at jdk.naming.dns/com.sun.jndi.dns.DnsContext.getResolver(DnsContext.java:573)
at jdk.naming.dns/com.sun.jndi.dns.DnsContext.c_getAttributes(DnsContext.java:434)
at java.naming/com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235)
at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141)
at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129)
at java.naming/javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:171)
at io.lettuce.core.resource.DirContextDnsResolver.resolve(DirContextDnsResolver.java:263)
at io.lettuce.core.resource.DirContextDnsResolver.resolve(DirContextDnsResolver.java:199)
at io.lettuce.core.resource.DirContextDnsResolver.resolve(DirContextDnsResolver.java:175)
at io.lettuce.core.resource.SocketAddressResolver.resolve(SocketAddressResolver.java:97)
at io.lettuce.core.resource.SocketAddressResolver.resolve(SocketAddressResolver.java:80)
at io.lettuce.core.cluster.topology.DefaultClusterTopologyRefresh.openConnections(DefaultClusterTopologyRefresh.java:312)
...

Possible Solution

The suggested workaround for this issue:

1. Parse the resolv.conf and format the IPv6 records correctly (surround with square brackets), so DnsClient does not fail.
2. When setting up the DNS resolver for Redis Client Resources, instead of calling the default DirContextDnsResolver constructor, call the one that accepts the collection of correctly formatted nameserver literals produced in the previous step.

Additional context

https://bugs.openjdk.org/browse/JDK-8322243

[mp911de]

Thanks for reaching out. Parsing system-specific files isn't what the client is responsible for. Please note that DirContextDnsResolver is a leftover from the blocking hostname lookup. Arguably, it is easier to configure than Netty's AddressResolverGroup and it doesn't require additional dependencies.

If you're a AWS Elasticache user, let's try to see whether you can set up AddressResolverGroup without caching so we can migrate our docs away from DirContextDnsResolver. What do you think?

[mikalai-canva]

Parsing system-specific files isn't what the client is responsible for.

I agree. The goal was to raise awareness of the issue. Even if this won't end up anywhere in the docs, having this issue reported here possibly could be helpful for other Lettuce users.

If you're a AWS Elasticache user, let's try to see whether you can set up AddressResolverGroup without caching so we can migrate our docs away from DirContextDnsResolver. What do you think?

Thanks, this sounds like a great idea. This week is a bit jam-packed, but I am happy to experiment with this next week. Regarding the implementation, is the idea to add another DnsResolver implementation class that will wrap a Netty's DNS resolver?

[mp911de]

Thanks for helping out. We don't need/want to wrap Netty's AddressResolverGroup into DnsResolver as doing so would force non-blocking address resolution to become blocking. Instead, I suggest to configure AddressResolverGroup via ClientResources and coming up with a code snippet that we can put into the docs.