Open Snurppa opened 1 year ago
Just to clarify, you can completely work around this by doing setDnsResolver(null) and then it works fine for you?
I just want to understand how high priority this issue is.
Just to clarify, you can completely work around this by doing setDnsResolver(null) and then it works fine for you?
I just want to understand how high priority this issue is.
Sorry, that was not clear enough. The answer is yes, setting setDnsResolver(null)
is enough to fix the issue.
I guess the question is, should the same be done by default in the setProxy
method or not 🤔
Describe the bug When client side is using proxy via
WebSocketClient.setProxy
, the defaultDnsResolver
will force hostname resolution.But I think when behind a proxy, the resolving of hostnames should be done by the proxy, not by the client, living in a possibly constrained network, which might not have access to public DNS.
We bumped into this in production when a customer was using a proxy and the host running the app had no access to DNS. Establishing the connection would crash in
WebSocketClient.connect
withjava.net.UnknownHostException: public.example.com: Name or service not known.
To Reproduce Steps to reproduce the behavior:
mitmproxy
running in host, the JVM app was running in Docker container.WebSocketClient
to direct comms to that proxy. For me proxy host washost.docker.internal:8080
as I was running JVM inside a container. Also the target server was running in host OS, port 3200.java.net.Authenticator
withjava.net.Authenticator.setDefault
so JVM will pass the credentialstcpflow
to inspect what is happening, in this case between container and the host:docker run --net="container:<your-container-id-or-name>" byfcz/tcpflow -p -c
CONNECT
request to the proxy, it has already resolved the target's hostnamehost.docker.internal
to IP address (the host IP from Docker perspective). In my case, host was resolved to192.168.065.254
:mitmproxy
receives this, it can't reach192.168.065.254
. I had127.0.0.1 host.docker.internal
configured in/etc/hosts
, so if it would have let theHost
header be untouched, it would have worked. Now after some internal timeoutmitmproxy
responds with502 Bad Gateway
Example application to reproduce the issue
Expected behavior
I was thinking, when a proxy is set, the client should not do DNS resolution by default?
We were able to patch the issue by calling
setDnsResolver(null)
. After that, theHost
header was left intact and the Proxy would take it and resolve it.Should this
null
DnsResolver be default in the library, maybe done by thesetProxy
?Debug log
Environment(please complete the following information):
Additional context JVM app running in container, using
PROXY_HOST
+PROXY_PORT
and the java.net.Authenticator.getPasswordAuthentication implemented to return credentials + applied globally with java.net.Authenticator.setDefault. The exchange of the credentials works correctly between WebSocketClient and the Proxy server. Customer network where app was running needs to route everything through proxy, there is no public DNS available.The issue is just the DNS resolution, either it crashes with
UnknownHostException
or theHost
header might be wrong (in the case of using something likehost.docker.internal
at least).