SSL - how to suppress reverse DNS lookups?

[Tim Ward]

When a client SSLSocket connects to the server, then after the SYN, SYN/ACK,
ACK handshake the next thing you see on the wire is an attempt to resolve
the domain name of the server.

The servers I'm wanting to talk to don't have DNS names, and don't have
NetBIOS names, and don't have hosts file entries, and I connect to them by
specifying the IP address. So what we see is first a failed attempt to do a
DNS lookup, then a failed repeated attempt to do a NetBIOS name lookup,
during which time some higher level application protocol times out the
connection attempt.

All previous threads I can find on this subject end up with resolutions such
as "make sure the server's name can be looked up by DNS" or "put the
server's name and address in the hosts file", neither of which solution is
useful to me.

So my question is: How do I stop Java doing these name lookups?

(As an additional question, just out of idle curiousity: what's it doing the
name lookup for anyway?? It can't be to verify that the server name embedded
in the certificate is the same as the domain name found by the name lookup
for at least two reasons:

(a) it's doing the name lookup long before it's managed to acquire a
certificate from the server

(b) if I arrange (via the hosts file) that the looked up name is not the
same as the domain name in the server certificate then the connection
succeeds anyway.)

(I tried this first on comp.lang.java.security but there only seem to be a
couple of posts a day to that newsgroup.)

 

[Rogan Dawes]

When a client SSLSocket connects to the server, then after the SYN, SYN/ACK,
ACK handshake the next thing you see on the wire is an attempt to resolve
the domain name of the server.

The servers I'm wanting to talk to don't have DNS names, and don't have
NetBIOS names, and don't have hosts file entries, and I connect to them by
specifying the IP address. So what we see is first a failed attempt to do a
DNS lookup, then a failed repeated attempt to do a NetBIOS name lookup,
during which time some higher level application protocol times out the
connection attempt.

All previous threads I can find on this subject end up with resolutions such
as "make sure the server's name can be looked up by DNS" or "put the
server's name and address in the hosts file", neither of which solution is
useful to me.

So my question is: How do I stop Java doing these name lookups?

(As an additional question, just out of idle curiousity: what's it doing the
name lookup for anyway?? It can't be to verify that the server name embedded
in the certificate is the same as the domain name found by the name lookup
for at least two reasons:

(a) it's doing the name lookup long before it's managed to acquire a
certificate from the server

(b) if I arrange (via the hosts file) that the looked up name is not the
same as the domain name in the server certificate then the connection
succeeds anyway.)

(I tried this first on comp.lang.java.security but there only seem to be a
couple of posts a day to that newsgroup.)

Here is a sample program that demonstrates a bunch of SSL functionality
in one place. Maybe some parts of it will help you?

http://dawes.za.net/rogan/PKCS11Test.java

My first suspect is the client side TrustManager, possibly doing a
pre-emptive lookup?

Rogan

 

[Mark Space]

When a client SSLSocket connects to the server, then after the SYN, SYN/ACK,
ACK handshake the next thing you see on the wire is an attempt to resolve
the domain name of the server.

This sounds like a bug to me. I don't see any reason for SSL to be
looking up domain names (hmm, unless the name is important to the
digital signature?). I'd contact the module owner(s) and ask them
what's up.

 

[Tim Ward]

This sounds like a bug to me. I don't see any reason for SSL to be
looking up domain names (hmm, unless the name is important to the
digital signature?). I'd contact the module owner(s) and ask them
what's up.

Not sure who you think "the module owners" are? As I am TTBOMKAB using only
Sun software I've asked on forum.java.sun.com, where I have received no
reply.

 

[Tim Ward]

Oh well, this one is a showstopper, so if there's no solution ...

.... then it's back to C++. (And some regret, perhaps, that I was told to
write this one in Java in the first place.)