On 4/29/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
Yes. Please see the patch that I just committed. Are you in a position to
test the result in-situ?
Thanks for fixing this Noel! I cannot readily test because my "test"
is running it in production and seeing thousands of RBL cache entries
accumulate for spammers and zombies. :)
> or ideally send it to disk?
Actually, I suspect that from a performance perspective, this might be
counter-productive. Let your local DNS servers provide additional caching,
rather than get involved in disk I/O.
I would prefer to have dnsjava lib abstract the cache impl. That way
for 90% of the users out there, they could use the basic bundled impl
they have, or for the advanced users like the James project, we could
configure an oscache or jdbm (have to look into that) impl.
Should see where this is coming from, since we should generally use
InetAddress as little as possible, due to its naive implementation.
Actually, I seem to recall running into some issues with the standard Java
code sticking its figurative nose where it doesn't belong, and not giving us
a clean chain down to the DNS SPI. We would have to see if that is (still)
the case. Personally, I'd prefer to stick with a dnsjava, and can agree
with Stefano that we could expose the DNSServer service and use it, rather
than call the static methods in dnsjava directly.
I don't see how we could drop use of dnsjava. The SPI only allows
standard hostname to IP address lookups to be handled by a 3rd party
library. The whole reason we got dnsjava in the first place is to be
able to query MX records, and AFAIK, we still cannot do that. Maybe
JNDI, but I didn't think so.
Anyway, I think there were some optional lookups we converted from
InetAddress to dnsjava, but that would just to deal with the sun
leak... InetAddress always caches everything, meaning you're stuck
with a timed out dns entries (not to mention cache heap space used).
My memory is similarly foggy on whether those got in and the small bug
we saw.
Also, AFAIK SPF information in the TXT record, so dnsjava should have
no trouble retrieving that record type. jSPF would largely just be
parsing of that TXT record into the appropriate rule set, no? If it
intends to do more, it would almost have to depend on dnsjava to be
able to get those TXT records, I would think.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
