Re: UDP responses on Mac OS 10.7/java 1.6

[Brian W. <bwe...@xb...>]

On Aug 6, 2012, at 4:03 PM, Casey Deccio <ca...@de...> wrote:

> On Mon, Aug 6, 2012 at 2:50 PM, Brian Wellington <bwe...@xb...> wrote:
> 
> On Aug 6, 2012, at 2:46 PM, Casey Deccio <ca...@de...> wrote:
> 
>> 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).
> 
>  
> Hmm, this is indeed an issue.  I can see now why "java" shows up my firewall list at all.  I am running another app that listens (i.e., as a server), and when I first launched it (weeks ago), OS X asked me if I waned to allow incoming connections, to which I responded "no".  Of course, this is precisely why adding "java" to a firewall whitelist isn't the right solution at all--really that could be anything.  I tried removing the rule altogether, but that didn't help either at this point; apparently there is a "default deny" policy.  Did you have "java" listed under your firewall rules with an explicit "allow"?

I do have java set to allow; it didn't work otherwise.   I agree that having a firewall rule based on "java" is stupid, but I don't think that can be fixed.

> Of course, this doesn't help solve the issue of why a UDP response (from java anyway) looks like a new connection and is thus blocked, instead of seeing it as the response to an outgoing "connection".
>> 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.
> 
> 
> I tested a sample Client/Server example [1] for kicks to see the results, and the firewall didn't seem to impede this client from getting responses with the same configuration that had blocked the responses for dnsjava.

I suspect that the problem is the fact that dnsjava is using Channels (which probably map to select() or kqueue), while that example is just using sendto/recvfrom.  Channels are used because there more flexible, and allow better handling of timeouts.

> For the app I'm writing, I certainly could try to detect this behavior and fail gracefully, but it would be great to try to nail down this issue for clients that might be in my predicament.

There's no way that I know of to replace dnsjava's underlying socket code with something that doesn't use Channels, so I don't think there's a good way to work around this.

> By the way, thanks for your work on such an elegant, featured DNS library in java!

Thanks!  I'm glad you're finding it useful.

Brian