Thread: UDP responses on Mac OS 10.7/java 1.6

Hi,

I'm using dnsjava-2.1.3 on Mac OS 10.7 Lion and java 1.6:

$ java -version
java version "1.6.0_33"
Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-11M3720)
Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode)

I'm unable to receive UDP responses.  For example, using the provided dig
class:

$ java dig @192.0.2.1 example.com
Exception in thread "main" java.net.SocketTimeoutException
    at org.xbill.DNS.Client.blockUntil(Client.java:43)
    at org.xbill.DNS.UDPClient.recv(UDPClient.java:124)
    at org.xbill.DNS.UDPClient.sendrecv(UDPClient.java:150)
    at org.xbill.DNS.SimpleResolver.send(SimpleResolver.java:257)
    at dig.main(dig.java:196)

I get the same result if I use the library within my own class as well.  I
can see the packets arriving on the wire using tcpdump, but the client
isn't picking them up.  However, if I use resolver.setTCP(true), then it
works fine.  It also works fine with ISC's DiG:

$ dig @192.0.2.1 example.com

; <<>> DiG 9.7.3-P3 <<>> @192.0.2.1 example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37887
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.            IN    A

;; ANSWER SECTION:
example.com.        2170    IN    A    192.0.43.10

;; AUTHORITY SECTION:
example.com.        171370    IN    NS    a.iana-servers.net.
example.com.        171370    IN    NS    b.iana-servers.net.

;; Query time: 2 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Mon Aug  6 12:26:58 2012
;; MSG SIZE  rcvd: 93

Any ideas?

Casey

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

> Hi,
> 
> I'm using dnsjava-2.1.3 on Mac OS 10.7 Lion and java 1.6:
> 
> $ java -version
> java version "1.6.0_33"
> Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-11M3720)
> Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode)
> 
> I'm unable to receive UDP responses.  For example, using the provided dig class:
> 
> $ java dig @192.0.2.1 example.com
> Exception in thread "main" java.net.SocketTimeoutException
>     at org.xbill.DNS.Client.blockUntil(Client.java:43)
>     at org.xbill.DNS.UDPClient.recv(UDPClient.java:124)
>     at org.xbill.DNS.UDPClient.sendrecv(UDPClient.java:150)
>     at org.xbill.DNS.SimpleResolver.send(SimpleResolver.java:257)
>     at dig.main(dig.java:196)
> 
> I get the same result if I use the library within my own class as well.  I can see the packets arriving on the wire using tcpdump, but the client isn't picking them up.  However, if I use resolver.setTCP(true), then it works fine.  It also works fine with ISC's DiG:
> 
> $ dig @192.0.2.1 example.com
> 
> ; <<>> DiG 9.7.3-P3 <<>> @192.0.2.1 example.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37887
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;example.com.            IN    A
> 
> ;; ANSWER SECTION:
> example.com.        2170    IN    A    192.0.43.10
> 
> ;; AUTHORITY SECTION:
> example.com.        171370    IN    NS    a.iana-servers.net.
> example.com.        171370    IN    NS    b.iana-servers.net.
> 
> ;; Query time: 2 msec
> ;; SERVER: 192.0.2.1#53(192.0.2.1)
> ;; WHEN: Mon Aug  6 12:26:58 2012
> ;; MSG SIZE  rcvd: 93
> 
> Any ideas?

Until last week, my primary development platform was OS X Lion, and I never saw this.

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.

Brian

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.

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?

Casey

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

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"?

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.

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.

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

Casey

[1] http://systembash.com/content/a-simple-java-udp-server-and-udp-client/

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

> 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.
>
>
> [1] http://systembash.com/content/a-simple-java-udp-server-and-udp-client/
>

I forgot to mention that I modified the code, such that it was using a
remote host and not localhost, as responses from localhost aren't impeded
by the firewall apparently.

Casey

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

On 7 Aug 2012, at 00:11, Brian Wellington wrote:

> 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.

It's worth noting that dnsjnio replaces the dnsjava socket implementation with an nio implementation. This does still use Channels, and I haven't tested it against this issue. However, it might still be worth a look.

Thanks,


Alex.

I'm using dnsjnio in production and can really recommend it if you need an async way of using dnsjava :)


Am 07.08.2012 um 09:44 schrieb Alex Dalitz <Al...@no...>:

> On 7 Aug 2012, at 00:11, Brian Wellington wrote:
> 
>> 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.
> 
> It's worth noting that dnsjnio replaces the dnsjava socket implementation with an nio implementation. This does still use Channels, and I haven't tested it against this issue. However, it might still be worth a look.
> 
> Thanks,
> 
> 
> Alex.
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> dnsjava-users mailing list
> dns...@li...
> https://lists.sourceforge.net/lists/listinfo/dnsjava-users