dnsjava-users — The dnsjava mailing list

dnsjava 1.3.0-beta

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

I just released a beta version of dnsjava 1.3.0.  It contains a bunch of
optimizations to both speed and memory usage and a number of bug fixes. It
updates lots of code internally to use Collections, so will require Java
1.2 or greater.  Large poretions of code have been completely rewritten 
(Name.java, for example), and the new code is a lot more sane and has a 
better API (for example, Name.fromString(String) replaces Name(String), 
and handles errors properly).

Any testing would be greatly appreciated.  I expect to release the final
version in about a week, unless something major comes up.

Changelog below.

Brian

--------

10/8/2002
	- Cleanups to Cache.addMessage() and the Credibility code.

10/7/2002
	- Fix problems with search path handling in the dns class.
	- Possible race condition fixes to the Cache code.

10/6/2002
	- Fix minor bugs in Name code (Bob Halley <bob...@no...>)
	  
10/1/2002
	- Memory usage and speed improvements to the TypeMap class.

9/25/2002
	- Add the verbosecache option.
	- Significant memory usage improvements to the Name class.

9/23/2002
	- Memory usage improvements to the ARecord class.

9/16/2002
	- Support for NetWare's sys:/etc/resolv.cfg file.
	  (Scott Villinski <sc...@vi...>)

9/5/2002
	- When looking for an rdataset in a zone or cache, seeing a CNAME
	  above the name is not an error.
	  (reported by Andrew Houghton <aa...@vo...>)

8/31/2002
	- Changed the code that dynamically loads record types; hopefully
	  this will solve some of the mysterious problems that I think
	  are related to non-English versions of Windows.
	- Clean up the Name code.

8/28/2002
	- Remove support for bitstring labels, since they're now deprecated.

8/16/2002
	- Address.isDottedQuad didn't check to see if the input String
	  contained characters after an IP address.
	  (Marcos Sanz <sa...@de...>)

8/11/2002
	- Querying for a nonexistant name with exactly one label didn't return.

8/10/2002
	- Add Ant build script (Blake Ramsdell <bl...@br...>)

8/6/2002
	- The AAAARecord constructor was broken.
	- The Record class now implements Comparable.

6/22/2002
	- Significant speed improvements in the Record class and its
	  subclasses.

6/20/2002
	- Add Zone.removeRecord() (based on code from Adam Cassar
	  <ada...@ne...>)
	- Add Zone.toMasterFile() (based on code from Adam Cassar)
	- Performance enhancements to the Name object.
	- Add the "-t type" option to the lookup program.

6/16/2002
	- Update lots of code to use Collections instead of JDK 1.1
	  Vectors & Hashtables.

5/28/2002
	- fix some limitations of name parsing.
	  (reported by Tasos Kotsikonas <ta...@bo...>)

5/4/2002
	- added the 'sleep' and 'date' commands to the update client.
	  (Olafur Gudmundsson <og...@og...>)

Re: MX lookup problems

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

On Thu, 5 Sep 2002, Andrew Houghton wrote:

>    2. it doesn't always work.  For example, dig gives me an MX response
>       for the domain 'phipps.pgh.pa.us', but the dns.getAnyRecords()
>       call doesn't.

Fixed in CVS now; the code was confused by the fact that phipps.pgh.pa.us 
had a CNAME and mail.phipps.pgh.pa.us was below it.

Brian

Re: MX lookup problems

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

On Thu, 5 Sep 2002, Andrew Houghton wrote:

> Thanks for the response.  Just so I'm sure I understand what you're 
> saying about CNAMEs and getAnyRecord, could the code I showed before be 
> rewritten as:
> 
> boolean checkDomain(String domain) {
>   if (dns.getAnyRecords(domain, Type.MX) == null) {
>     // no MX records, check for A
>     if (dns.getAnyRecords(domain, Type.A) == null) {
>       return false;
>     }
>   }
>   
>   return true;
> }

I believe so.

> The only difference being that the traversal is depth-first in this 
> case, so to speak.

Right.

> In any case, it looks like I'll have to implement the timeout myself.

Yes.

Brian

Re: MX lookup problems

[Andrew H. <aa...@vo...>]

Thanks for the response.  Just so I'm sure I understand what you're 
saying about CNAMEs and getAnyRecord, could the code I showed before be 
rewritten as:

boolean checkDomain(String domain) {
  if (dns.getAnyRecords(domain, Type.MX) == null) {
    // no MX records, check for A
    if (dns.getAnyRecords(domain, Type.A) == null) {
      return false;
    }
  }
  
  return true;
}


The only difference being that the traversal is depth-first in this 
case, so to speak.

In any case, it looks like I'll have to implement the timeout myself.

Thanks,

Andrew

Re: MX lookup problems

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

On Thu, 5 Sep 2002, Andrew Houghton wrote:

> I saw a post on the sourceforge discussion boards about this same 
> question, followed by a response of Brian's saying the lists were a 
> better spot to ask questions, so here I am..
> 
> We're using dnsjava to do minimal domain validation on email addresses. 
>  The java code looks something like (this is from memory, so forgive any 
> syntax/semantic errors, the idea should be clear):
> 
> boolean checkDomain(String domain) {
>   Record[] records = dns.getAnyRecords(domain, Type.MX);
> 
>   if (records == null) {
>     // no MX records, check for CNAME
>     records = dns.getAnyRecords(domain, Type.CNAME);
> 
>     if (records != null) {
>       // found a CNAME, start over
>       return checkDomain(records[0].rdataToString());
>     }
> 
>     // no CNAME records, check for A
>     records = dns.getAnyRecords(domain, Type.A);
> 
>     if (records == null) {
>       return false;
>     }
>   }
>   
>   return true;
> }
> 
> 
> I think this satisfies the RFC 2821 address discovery protocol.  I have 
> a couple of questions, however:
> 
>    1. it doesn't handle CNAME loops nicely.  I'm willing to hear any
>       suggestions on this; I'll probably simply limit the recursion depth.

dns.getAnyRecords() should already follow CNAMEs.  In fact, there's no way 
to tell dns.getAnyRecords() to not follow CNAMEs.

>    2. it doesn't always work.  For example, dig gives me an MX response
>       for the domain 'phipps.pgh.pa.us', but the dns.getAnyRecords()
>       call doesn't.

That's a good question.  It appears to be a bug somewhere; I'll look into 
it later today.

>    3. it doesn't timeout nicely.  I'd like to set a timeout across all
>       of these queries -- that is, I'd like a way to say that the
>       top-level call to checkDomain() will respond within 2 seconds.
>        Can anyone think of a reasonably simple way of ensuring that?
>        I'd really rather not have to write my own thread pool
>       implementation.

Not really.  You could use a Timer, but there's no way of doing it within 
dnsjava.

>    4. the granularity of the Resolver.setTimeout() method is one second
>       (why?), which makes it hard for me to even fake the 2 second
>       timeout.. with a recursion limit of 1 and the timeout set to it's
>       minimum, I could still end up with a 4 second wait.

The granularity is one second because I didn't think anyone would need 
anything finer.  It would be pretty easy to add a

	setTimeout(int secs, int millisecs);

function to the Resolver interface, if you think that would be useful.


> I'm looking for any suggestions I can get here.. I seem to have 
> identified a bug in the package (point 2, above) but the others are 
> purely design problems.  I'd also like to thank Brian for producing what 
> appears to be a great package -- sure beats having to try and cobble 
> together something like this myself.

I'm glad it's useful.  Thanks!

Brian

MX lookup problems

[Andrew H. <aa...@vo...>]

I saw a post on the sourceforge discussion boards about this same 
question, followed by a response of Brian's saying the lists were a 
better spot to ask questions, so here I am..

We're using dnsjava to do minimal domain validation on email addresses. 
 The java code looks something like (this is from memory, so forgive any 
syntax/semantic errors, the idea should be clear):

boolean checkDomain(String domain) {
  Record[] records = dns.getAnyRecords(domain, Type.MX);

  if (records == null) {
    // no MX records, check for CNAME
    records = dns.getAnyRecords(domain, Type.CNAME);

    if (records != null) {
      // found a CNAME, start over
      return checkDomain(records[0].rdataToString());
    }

    // no CNAME records, check for A
    records = dns.getAnyRecords(domain, Type.A);

    if (records == null) {
      return false;
    }
  }
  
  return true;
}


I think this satisfies the RFC 2821 address discovery protocol.  I have 
a couple of questions, however:

   1. it doesn't handle CNAME loops nicely.  I'm willing to hear any
      suggestions on this; I'll probably simply limit the recursion depth.
   2. it doesn't always work.  For example, dig gives me an MX response
      for the domain 'phipps.pgh.pa.us', but the dns.getAnyRecords()
      call doesn't.
   3. it doesn't timeout nicely.  I'd like to set a timeout across all
      of these queries -- that is, I'd like a way to say that the
      top-level call to checkDomain() will respond within 2 seconds.
       Can anyone think of a reasonably simple way of ensuring that?
       I'd really rather not have to write my own thread pool
      implementation.
   4. the granularity of the Resolver.setTimeout() method is one second
      (why?), which makes it hard for me to even fake the 2 second
      timeout.. with a recursion limit of 1 and the timeout set to it's
      minimum, I could still end up with a 4 second wait.

I'm looking for any suggestions I can get here.. I seem to have 
identified a bug in the package (point 2, above) but the others are 
purely design problems.  I'd also like to thank Brian for producing what 
appears to be a great package -- sure beats having to try and cobble 
together something like this myself.

Thanks,

Andrew

dnsjava 1.2.4 released

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

After far too long, I built a 1.2.4 release.  It's mostly a collection of 
minor bug fixes, a few minor API enhancements, and a couple speed/memory 
usage improvements.

Changes listed below.

Brian

-------------------

4/25/2002
        - Add a constructor for building a zone from an array of records.
          (based on code from Adam Cassar <ada...@ne...>)

4/24/2002
        - Reduce the memory usage of the RRset class.
        - Add a new factory method for creating a Record from a
          String, rather than a pre-tokenized String.
        - Reduce the memory usage of the ARecord class.

4/23/2002
        - Fix potential race conditions in the RRset class.
          (David Esposito <esp...@ne...>)
        - Fix potential race condition in the WorkerThread class when two
          threads complete their run methods nearly simultaneously.
          (David Esposito)
        - Add a new factory method for creating a Record, where the length
          of the rdata is not explicitly specified, but inferred from
          data.length.

4/22/2002
        - Improve name decompression by not requiring a decompression context.

3/27/2002
        - Add support for the Delegation Signer (DS) record. (David Blacka)

3/22/2002
        - Record.equals() did not properly canonicalize names.
        - Record.equals() should ignore the TTL.

3/19/2002
        - When a compressed name is parsed, it should be added to the
          compression table, so that future pointers to that name work.
          (reported by Blake Ramsdell <bl...@br...>)

3/14/2002
        - In jnamed, AXFR responses didn't have the message ID or flags
          set correctly.
        - jnamed failed to respond to messages signed with unknown keys.
        - jnamed did not sign responses to signed AXFR queries.

1/21/2002
        - Handle empty domain statements in /etc/resolv.conf. (reported
          by Blake Ramsdell <bl...@br...>)

1/1/2002
        - Minor performance enhancments (suggested by Christopher Brind)

10/14/2001
        - Add support for the DNSSEC RSA-SHA1 algorithm (David Blacka)
        - Add rdataToWireCanonical() (David Blacka)

9/27/2001
        - jnamed can now listen on specific addresses, with the "address"
          keyword in the config file.

Re: MX lookup issue for edelweb.fr

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

On Tue, 19 Mar 2002, Blake Ramsdell wrote:

> Yes, I did a C++ implementation in a prior life, and it's coming back to me
> now.  DNS name compression is funny.
> 
> By the way, this is the Windows 2000 DNS server.  I can get you version
> information if it's useful.

It's probably not important.  The compression it's doing isn't wrong, it's 
just strange.  I really should rewrite the decompression code at some 
point, but haven't gotten around to it.

> Thanks for the continued responsiveness.  You're definitely the most
> responsive maintainer that I've worked with so far.  Good job!

Thanks!

Brian

Re: MX lookup issue for edelweb.fr

[Blake R. <bl...@br...>]

----- Original Message -----
From: "Brian Wellington" <bwe...@xb...>
To: "Blake Ramsdell" <bl...@br...>
Cc: <dns...@li...>
Sent: Tuesday, March 19, 2002 2:43 PM
Subject: Re: MX lookup issue for edelweb.fr


> Aha, fixed.  For whatever reason, the server is doing name compression in
> a very strange way, and the decompression code wasn't handling it
> properly.  It's fixed in CVS, and I'll make a new release later this week.

Yes, I did a C++ implementation in a prior life, and it's coming back to me
now.  DNS name compression is funny.

By the way, this is the Windows 2000 DNS server.  I can get you version
information if it's useful.

Thanks for the continued responsiveness.  You're definitely the most
responsive maintainer that I've worked with so far.  Good job!

Blake

Re: MX lookup issue for edelweb.fr

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

On Tue, 19 Mar 2002, Blake Ramsdell wrote:

> OK, try this -- this is all of the data, and I presume that the second (in)
> is the response which is failing.

Aha, fixed.  For whatever reason, the server is doing name compression in 
a very strange way, and the decompression code wasn't handling it 
properly.  It's fixed in CVS, and I'll make a new release later this week.

Brian

Re: MX lookup issue for edelweb.fr

[Blake R. <bl...@br...>]

----- Original Message -----
From: "Brian Wellington" <bwe...@xb...>
To: "Blake Ramsdell" <bl...@br...>
Cc: <dns...@li...>
Sent: Tuesday, March 19, 2002 10:10 AM
Subject: Re: MX lookup issue for edelweb.fr


> Works for me.  Could you try setting -Ddnsjava.options=verbosemsg on the
> command line and send the contents of the received message?

OK, try this -- this is all of the data, and I presume that the second (in)
is the response which is failing.

107b (in): 74 d4 84 03 00 01 00 00 00 01 00 00 0c 73 70 65 65 62 65 65 62
  65 62 65 62 03 63 6f 6d 00 00 0f 00 01 c0 19 00 06 00 01 00 01
  51 80 00 3d 01 41 0c 47 54 4c 44 2d 53 45 52 56 45 52 53 03 4e
  45 54 00 05 6e 73 74 6c 64 0c 76 65 72 69 73 69 67 6e 2d 67 72
  73 c0 19 77 54 95 1c 00 00 07 08 00 00 03 84 00 09 3a 80 00 01
  51 80

28b (out): c0 e4 01 00 00 01 00 00 00 00 00 00 07 65 64 65 6c 77 65 62 02
  66 72 00 00 0f 00 01

60b (in): c0 e4 81 80 00 01 00 01 00 00 00 01 07 65 64 65 6c 77 65 62 02
  66 72 00 00 0f 00 01 c0 0c 00 0f 00 01 00 00 40 a2 00 04 00 01
  c0 0c c0 2a 00 01 00 01 00 00 40 a2 00 04 d4 ea 2e 10

org.xbill.DNS.WireParseException: Error parsing message
 at org.xbill.DNS.SimpleResolver.send(SimpleResolver.java:271)

Blake

Re: MX lookup issue for edelweb.fr

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

On Tue, 19 Mar 2002, Blake Ramsdell wrote:

> I realize that this problem is complicated by the fact that the records are
> coming back from my local DNS, but can someone try to do an MX lookup on
> edelweb.fr and see if you survive?
> 
> I'm basically doing (sorry in advance for wrapping issues):
> 
> Message message = Message.newQuery(Record.newRecord(new Name("edelweb.fr"),
> Type.MX, DClass.IN));
> SimpleResolver resolver = new SimpleResolver();
> 
> this.log.debug("Sending request.");
> message = resolver.send(message);
> this.log.debug("Back from send.");
> 
> And it throws an exception in send (I never see "Back from send.")  I dug
> into it a bit, and it looks like there is an A record in the additional
> records section that the name is failing to parse out of.

Works for me.  Could you try setting -Ddnsjava.options=verbosemsg on the 
command line and send the contents of the received message?

Brian

MX lookup issue for edelweb.fr

[Blake R. <bl...@br...>]

I realize that this problem is complicated by the fact that the records are
coming back from my local DNS, but can someone try to do an MX lookup on
edelweb.fr and see if you survive?

I'm basically doing (sorry in advance for wrapping issues):

Message message = Message.newQuery(Record.newRecord(new Name("edelweb.fr"),
Type.MX, DClass.IN));
SimpleResolver resolver = new SimpleResolver();

this.log.debug("Sending request.");
message = resolver.send(message);
this.log.debug("Back from send.");

And it throws an exception in send (I never see "Back from send.")  I dug
into it a bit, and it looks like there is an A record in the additional
records section that the name is failing to parse out of.

Blake
--
Blake Ramsdell
Brute Squad Labs http://www.brutesquadlabs.com

Re: getRecords doesn't return

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

On Thu, 28 Feb 2002, Rodolphe Ode wrote:

> Hi!
> It seems like I discovered a bug that is not easy to 
> reproduce. I have a java program that consists of a 
> pool of threads (500 in my example). Each thread uses 
> dnsjava to mx lookup domain names.
> 
> So I use dnsjava like this :
> 
> Record[] mxRecords = dns.getRecords(domainName, 
> Type.MX);
> 
> It works perfectly but about one time out of 10000,
> getRecords doesn't go back, there is nothing returned 
> and the thread seems to be bloqued with this 
> instruction. getRecords seems not to go back.
> Is there anyone who also had this bug ?
> 
> I catch every exception and none is fired. 

Without more information, there's no way to fix this.  If it only occurs
one of of 10000 or so times, and only with a large pool of threads (which
works really badly on linux), then there isn't much I can do.

If you want to try debugging it and determine where it's blocking, that
would help.

Brian

getRecords doesn't return

[Rodolphe O. <rod...@eo...>]

Hi!
It seems like I discovered a bug that is not easy to=20
reproduce. I have a java program that consists of a=20
pool of threads (500 in my example). Each thread uses=20
dnsjava to mx lookup domain names.

So I use dnsjava like this :

Record[] mxRecords =3D dns.getRecords(domainName,=20
Type.MX);

It works perfectly but about one time out of 10000,
getRecords doesn't go back, there is nothing returned=20
and the thread seems to be bloqued with this=20
instruction. getRecords seems not to go back.
Is there anyone who also had this bug ?

I catch every exception and none is fired.=20

RodolpheBottom of Form 1

java.nio work

[kevin g. <kg...@do...>]

Does anyone have code using the new toys from java.nio yet? I was just
starting to get into it, but figured I'd check to see if I was duplicating
effort..

..kg..

Re: MXRecord.getTarget().toString()

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

On Thu, 24 Jan 2002, Cedric Dumetz wrote:

> Hello,
> 
> I'm using a bit of  code from the JAMES.
> 
> This for find all MX Record of a host.
> 
> I've a code like this
> MXRecord[] mxAnswers;
> ...
> ..
> System.out.println(mxAnswers[i].getTarget().toString())
> .....
> 
> On the output I always have a point at the end of each MX (ex : m4.caramail.com. )
> Why ??
> Thanks for your help and sorry for my english

Because fully qualified DNS names end in a dot.

Brian

MXRecord.getTarget().toString()

[Cedric D. <ced...@eo...>]

Hello,

I'm using a bit of  code from the JAMES.

This for find all MX Record of a host.

I've a code like this
MXRecord[] mxAnswers;
...
..
System.out.println(mxAnswers[i].getTarget().toString())
.....

On the output I always have a point at the end of each MX (ex : =
m4.caramail.com. )
Why ??
Thanks for your help and sorry for my english

Cedric

Re: Internationalization

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

On Wed, 2 Jan 2002, jim holt wrote:

> When the library is on a non-english windows computer, it would seem 
> that the output from ipconfig is in the local language.  Since the 
> string 'DNS Servers' is used to identify the name servers, this creates 
> a problem if the actual string is something like 'Serveurs DNS'.  Is 
> there a solution to this problem?

Not that I know of.  Since I speak english and don't use windows, I'm not
especially motivated to fix this.  The right way to fix it is probably 
to use an option which sets the value of the string to look for 
instead of "DNS Servers".  Feel free to submit a patch.

Brian

Internationalization

[jim h. <jh...@Me...>]

When the library is on a non-english windows computer, it would seem 
that the output from ipconfig is in the local language.  Since the 
string 'DNS Servers' is used to identify the name servers, this creates 
a problem if the actual string is something like 'Serveurs DNS'.  Is 
there a solution to this problem?

-- 
Jim Holt
MessageMachines, Inc.
186 South Street
Boston, MA 02111
617 279 8631 direct
617 279 8600 main
617 279 8650 fax
jh...@me...
www.messagemachines.com
Any Message. Anytime. Anywhere.

Re: Is dnsjava better for my app than InetAddress?

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

On Fri, 7 Dec 2001, Jennifer Orf wrote:

> Hello,
> 
> I'm building an app where I need to perform a whole bunch of reverse dns
> lookups very rapidly. Thus, the faster I can look an address up, the better.
> 
> In addition, I'd like the resolved addresses to always come back as fully
> qualified domain names.
> 
> I am curious as to whether dnsjava would be a better solution than using
> java.net.InetAddress on either or both of these counts.
> 
> Could anyone provide me insight on this, please?

I've never benchmarked dnsjava against InetAddress for straight reverse 
lookups (or forward lookups, for that matter).  It's not an especially 
complicated process, so I'd imagine the differences in speed would be 
negligible.

I believe dnsjava's caching is more correct that that of InetAddress, 
since it properly expires DNS records.  This may have a slight negative 
impact on performance if you're relying on caching and the records have 
low TTLs, but is correct behavior.

If your app is threaded, dnsjava may have an advantage, since on some 
platforms, InetAddress-based lookups can only occur in one thread at a 
time (since gethostbyaddr() blocks).

Another possible advantage of dnsjava is that asynchronous lookups are 
possible when using lower-level APIs (Resolver.send()).  The high level 
APIs (dns.getRecords*(), Address) do not have async functions, but they 
would not be particularly difficult.

As for fully qualified domain names, both dnsjava methods and InetAddress 
should give you that.

Hope this helps...

Brian

Is dnsjava better for my app than InetAddress?

[Jennifer O. <jen...@la...>]

Hello,

I'm building an app where I need to perform a whole bunch of reverse dns
lookups very rapidly. Thus, the faster I can look an address up, the better.

In addition, I'd like the resolved addresses to always come back as fully
qualified domain names.

I am curious as to whether dnsjava would be a better solution than using
java.net.InetAddress on either or both of these counts.

Could anyone provide me insight on this, please?

Thanks in advance.

-j