Repository navigation
SocketTimeoutException on MacOS >= 12.5 #260
Description
Maven repo dnsjava 2.0.8 Lookup.run returns SocketTimeoutException on MacOS 12.5
Using some basic DNS test code:
import org.xbill.DNS.*;
import java.util.*;
...
Options.set("verbose", "true");
Lookup look = new Lookup("google.com");
String looked = Arrays.toString(look.run());
System.out.println(looked);
I get the result:
adding server <dns server IP>
lookup google.com. A
unknown
Sending to <dns server IP>:53
ExtendedResolver: got java.net.SocketTimeoutException
I can see in wireshark that there is a response from the DNS server, it seems it is not parsed by dnsjava:
Activity
ibauersachs commentedon Aug 19, 2022
dnsjava v2.0.8 is 12 (!) years old. Please use the latest version, which is currently v3.5.1. Also, if
Lookup.run()fails, the result isnull. UsegetErrorString()to find out why the lookup failed.chris-cyberark commentedon Aug 30, 2022
@ibauersachs Thanks for the reply, I had no idea my ver was so old!
Tried again using 3.5.1, and included getErrorString():
The output is now:
So... in a roundabout way the error is still the same (I think?) 'network error' does sound similar to SocketTimeoutException
But I've already confirmed that we get an answer via wireshark, is there a way to get more info about the error, or somewhere I could put a break and debug the answer processing?
Thanks
ibauersachs commentedon Aug 30, 2022
Which Java/JDK version are you using?
Please attach the debug (or trace) log output from dnsjava. It uses slf4j-api, so you can attach basically any logging framework. For your example, even slf4j-simple works. If you're using Gradle:
implementation 'org.slf4j:slf4j-simple:1.7.35'Also pass
-Dorg.slf4j.simpleLogger.defaultLogLevel=debug(or trace) as a JVM argument.This somehow looks similar to #194. However, there apparently v3.5.1 worked fine.
chris-cyberark commentedon Sep 5, 2022
Java 1.8 (Azul 1.8_345)
I took a look at #194 but its a different error to mine.
I double checked wireshark because it really looks like a networking issue, but it is the same as my original post, shows the query and the answer. It seems like somewhere it loses track of the result, I added the timing to slf4j and 5 seconds go by, but the response in wireshark is instant.
ibauersachs commentedon Sep 7, 2022
I mentioned #194 because in both cases the dnsjava's NIO implementation seems to behave differently. It's possible that the underlying async I/O on Mac is more strict than on Windows and Linux and we do something wrong.
As I don't have a modern enough Mac, this is really difficult for me to debug. Maybe @nresare can help here?
But maybe you can add some more information by:
chris-cyberark commentedon Sep 8, 2022
Don't know why I didn't check this fully before, but I've found the cause; PaloAlto's GlobalProtect VPN client. Although the firewall within the VPN allows the traffic, and wireshark shows the ANSWER packet get back to my local machine at the VPN tunnel utun0 interface, there is something about the VPN OS setup that messes with DNS resolution and so it 'times out'.
Closing the VPN client fully allowed Lookup.run() to complete successfully.
I tried with Java 11 with the same results.
I'm gonna follow up with my IT/GlobalProtect team, let me know if you still want that thread dump.
[-]Maven repo dnsjava 2.0.8 Lookup.run returns SocketTimeoutException on MacOS 12.5[/-][+]GlobalProtect VPN causes SocketTimeoutException on MacOS 12.5[/+]ibauersachs commentedon Sep 8, 2022
Thanks for the follow-up. I don't think the thread dump is relevant if it works without the VPN client. I'll close this issue for now, we can always reopen if there's more to it than the VPN.
chris-cyberark commentedon Sep 27, 2022
Have had no further luck with disabling the VPN, completely removing it and any other potential blocking software seems to have no effect, the problem is back (Which makes me confused as I did see it working once and since then nothing, I have no idea why that one attempt worked.
Same issue, this time I can see on wireshark the DNS request and response go via WiFi: en0, with all VPN processes killed and double checked with ps
I upgraded to masOS 12.6 with no change.
Same result with Java 11
I'm not sure how to grab the thread dump exactly at the point the UDP request is sent, could you give me some tips?
ibauersachs commentedon Oct 2, 2022
Not sure what tools you use. In IntelliJ Idea, you can click the camera symbol while debugging. Do that within the timeout, the 5s should be enough if you're prepared to click.
You can also create a thread dump via a Java API, e.g. by starting a thread, sleeping 1 or 2 seconds, then call:
@nresare You have a Mac. Could you maybe do some debugging?
[-]GlobalProtect VPN causes SocketTimeoutException on MacOS 12.5[/-][+]SocketTimeoutException on MacOS >= 12.5[/+]kevinchan-rl commentedon Jan 27, 2023
Hi, I am seeing similar problem with:
has the following trace debugging output
dig works fine
Any ideas? I am unable to disable my corporate VPN but will try to find a way to do that and try again.
16 remaining items
dsukhoroslov commentedon Oct 11, 2023
I have the same issue with my Mac 13.6, Java 17.0.8. I see it only when I specify particular DNS server address when creating SimpleResolver. If no DNS address provided, then it works fine. dig works fine from terminal with and without DNS address.
ibauersachs commentedon Oct 27, 2023
I've now tried to debug this with my colleague @mkretz from @bespinian, on MacOS 14.6 with Java 11.0.21 (aarch). We were unable to reproduce the issue.
Sorry, but I'm lost here. Someone who still experiences this issue needs to debug this. Also, #260 (comment) makes me wonder whether this really is a dnsjava issue or something in either the JVM or some other VPN or firewall tool/extension that blocks the Java process from getting the reply.
nicholas-signal commentedon Dec 19, 2023
I can consistently reproduce this on macOS 14.2 with dnsjava 3.5.3, and similarly, setting TCP to
truefixes it for me as well. This behavior extends at least as far back as dnsjava 2.1.9. Where should I start with debugging?ibauersachs commentedon Jan 2, 2024
@nicholas-signal Create simple class that you can easily execute, like in #260 (comment). Then try to debug in
NioClientandNioUdpClientif you get any events at all, try if you need to modify the selection keys. You could also try to create a very basic UDP client outside of dnsjava, send the bytes for a simple query (e.g. dumped by a previous request from dnsjava) and verify that you're actually getting results back.mohamed-elhar commentedon Jan 5, 2024
Hi!
I'm using the latest version (3.5.3) to performing NAPTR query (reversed number separated by dots and concatenated with dns suffix) e.g "6.5.4.3.2.1.example.org", and I'm facing an issue with the timeout.
when I set the timeout to 2 sec for example and I send a wrong query to dns server the timeout is not respected and the resolver used the default timeout 10 sec.
here is below my code:
Can you please help?
Thanks in advance.
ibauersachs commentedon Jan 5, 2024
@mohamed-elhar You seem to have a different issue. Also, your example runs in exactly 2s when I specify an invalid IP address as the dns server. If yours is running longer, then you probably have one or more searchPaths. Use absolute names if you can.
mohamed-elhar commentedon Jan 5, 2024
Thank you @ibauersachs for you response.
Exactly, I've logged the searchPath using ResolveConfig.searchPath() and I confirm that I have multiple ones.
Is there any option to not use the default paths mentioned in the /etc/resolv.conf and forcing only the dns server provided in the Resolver constructor?
ibauersachs commentedon Jan 5, 2024
You can clear the path on your resolver instance, otherwise have a look at the config properties as described in the readme.
mohamed-elhar commentedon Jan 8, 2024
I've some problem with Cache mechanism, I set the max records and the ttl but each time I send an enum query I visualize in the dns server that a new query is arriving. Here is bellow the code used:
ibauersachs commentedon Jan 9, 2024
Your problem has nothing to do with the Mac issue here. Please open separate issues so that people following here are not further distracted.
osxhacker commentedon Mar 6, 2024
Hi @ibauersachs ,
Here is a follow-up for anyone encountering this issue as of today, along with what rectified this problem.
Problem Verification
I ran into the same problem today using the following:
All
dnsjavatests passed whenmvn testwas executed on therelease/3.5.xbranch. However,ResolveExample.javaexhibited the query timeout symptoms both whenSimpleResolverandValidatingResolverwere used.Resolution
Downloading OpenJDK 21 for
macOS / AArch64, installing it, then using it to do a full recompile resulted inResolveExample.javarunning without exception. The output also appeared to be in order.Rebuilding the project I am working on with JDK v21 which uses
dnsjavaand running its integration tests also no longer experience "query timeouts" and performed a successful query (which it had not before).The only change in system environment was installing and then using JDK v21.
Therefore, I believe updating to:
Rectified this issue. Should I observe this to not be the case, I will update this comment accordingly.
It is unknown if JDK v20 also rectifies this issue as I did not test that distribution.
Thanks for your work on this project!
svandenakker commentedon Aug 21, 2024
I experience the same issue (MacOS 14.6.1, Java 21,
dnsjava3.6.1). The application makes the DNS request over UDP, and according totcpdump, the response arrives just fine.I wrote the following Go program. It takes the
traceoutput ofdnsjavaand makes a request for theMXRRs ofgmail.comto Quad9. It returns the DNS response just fine:I also get proper responses using
digand evenecho -n <dns-request-bytes> | xxd -r -p | nc -u 9.9.9.8 53. It just does not work withdnsjava.svandenakker commentedon Aug 21, 2024
After writing the comment directly above, I updated my Java from 21.0.x to 21.0.4, ran the application again, allowed connections to the Java app after being prompted by the MacOS firewall and voila,
dnsjavacan now make DNS queries over UDP again. I'm happy, but confused.