From owner-freebsd-java@FreeBSD.ORG Tue Jul 24 23:24:08 2007 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB07216A417 for ; Tue, 24 Jul 2007 23:24:08 +0000 (UTC) (envelope-from freebsd@spatula.net) Received: from turing.morons.org (turing.morons.org [208.96.51.42]) by mx1.freebsd.org (Postfix) with ESMTP id AF44813C483 for ; Tue, 24 Jul 2007 23:24:08 +0000 (UTC) (envelope-from freebsd@spatula.net) Received: by turing.morons.org (Postfix, from userid 1001) id 7644317037; Tue, 24 Jul 2007 16:24:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by turing.morons.org (Postfix) with ESMTP id 735651702C for ; Tue, 24 Jul 2007 16:24:08 -0700 (PDT) Date: Tue, 24 Jul 2007 16:24:08 -0700 (PDT) From: Nick Johnson X-X-Sender: spatula@turing To: freebsd-java@freebsd.org In-Reply-To: <20070724133740.B82369@turing> Message-ID: <20070724160002.E82369@turing> References: <20070724133740.B82369@turing> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: possible name resolution problem in 1.5.0_11-p5 X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2007 23:24:08 -0000 I have arrived at one possible hypothesis that could explain what's happening. I've noticed in the tcpdump that the query when you specify more than one attribute is ANY, not just the attributes specified. If you request a single attribute, the resolve asks for that single attribute. Since it looks like most name servers won't volunteer their MX and A records for an ANY request, but you WILL get them in response to an ANY request if you get a cache hit from the local name server, it seems probable that the bug is in the way attributes are requested in getAttributes. (ANY vs queries for the separate attributes.) It looks like this is likely a bug in the com.sun.jndi.dns provider, and it probably succeeds on my windows box because from there I'm hitting my ISP's DNS cache, which is far more likely to have cached responses to the MX and A records already. I'm going to file a bug with Sun, since I can't find a bug referencing DNS and getAttributes that's already open. On Tue, 24 Jul 2007, Nick Johnson wrote: > I've attached a snippet of code that demonstrates the problem. > > In the example, note this line: > > Attributes attrs = attrs = ictx.getAttributes("mac.com", new String[] { "MX", "A"}); > > The behaviour is that IF the name being resolved is already in the local > name server's cache (and resolv.conf is pointing at the local name > server), it will retrieve the records requested. > > If it's not, some records will be retrieved, but they won't include an MX > record. > > If you request JUST an MX record (ie new String[] { "MX" } by itself), > then the MX record will be found. > > To use the test, you'd need to substitute "mac.com" for any foreign > hostname that isn't already in your name server's cache. This is with > Java 1.5.0_11-p5 built from ports on Jun 19 running on 6.2-STABLE built on > Sun Jan 21 2007. > > I'm not entirely certain that this problem isn't something particular to > my system / configuration. If some others could play with the test a bit > and see if they get the same behaviour, that would help. > > Nick > -- "Courage isn't just a matter of not being frightened, you know. It's being afraid and doing what you have to do anyway." Doctor Who - Planet of the Daleks This message has been brought to you by Nick Johnson 2.3b1 and the number 6. http://healerNick.com/ http://morons.org/ http://spatula.net/