From: Brian W. <bwe...@xb...> - 2012-08-06 22:16:14
|
On Aug 6, 2012, at 2:46 PM, Casey Deccio <ca...@de...> wrote: > > On Mon, Aug 6, 2012 at 2:17 PM, Brian Wellington <bwe...@xb...> wrote: > > I suspect the problem might be firewall-related; when java is set to "Block incoming connections", I see timeouts with the same stack trace. I don't know what dnsjava is doing differently with respect to the network and firewall rules, but you might want to try allowing incoming connections for java to see if that fixes it. > > > Ugh. Yes, that was it. Thanks! Apparently I had forgotten that OS X's firewall considers processes, not just ports, which is why I didn't see the issue with ISC's dig. > > I'm curious why UDP responses for dnsjava are looked at as "incoming connections", whereas UDP responses for ISC's dig, for example, don't have this problem. I don't know. Both should be doing similar operations, but there's obviously some difference (unless there's something else giving dig extra permissions, but I don't see it). > Would a simple UDP client/server test work with DatagramPacket? I assume using the lower level interfaces in dnsjava is to obtain source port randomization? Is it possible that makes it behave differently, in terms of state? It's using the interfaces it does because of source port randomization, but opening a UDP socket by address and port shouldn't be any different, security wise, from opening a UDP socket with a given address and the wildcard port. Brian |