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