RE: DB extensions

> -----Original Message-----
> From: opendkim-dev-bounce_at_lists.opendkim.org [mailto:opendkim-dev-
> bounce_at_lists.opendkim.org] On Behalf Of Daniel Black
> Sent: Friday, October 30, 2009 11:53 PM
> To: opendkim-dev_at_lists.opendkim.org
> Subject: Re: DB extensions
>
> On Saturday 31 October 2009 10:39:17 Murray S. Kucherawy wrote:
> > There are two important DB-related things that need to be addressed
> after
> > the overhaul I did this week. Looking for feedback on one of them.
> >
> > The first one is the fact that the new DB code does not yet cover the
> > internal/external host lists, since they're not stored as simple
> linked
> > lists; they are in fact data structures that contain either a
> hostname or
> > an IP address and mask (as 32-bit quantities). I need to come up
> with a
> > way to add those as special database types which also be queried,
> > preferably without any changes to the new interface. So that's
> still to
> > be done before 1.2.0 is ready for real testing.
>
> sounds like two keycolumns in the DSN syntax for IP,mask is maybe the
> easy
> way. This would make the query at least simple. Though overkill for
> internal/external host lists other policy items it could potentially
> use a
> good CIDR lookup mechanism.

The current database is a linked list of nodes that either contain hostnames or domain names, or a CIDR expression. When walking the list for the latter case, the CIDR expression is converted internally to a pair of 32-bit quantities (the address and the mask) and those are used to determine if there's a match. But in either case, it's still just a bunch of strings, which means the new DB code can handle it via dkimf_db_walk().

Since it's just a text list, it seems to me an easy switch to the new DB code; we'd do a "get" for the hostname and each possible domain name, and then a "walk" in the CIDR case.

> i'm thinking truely dynamic is definite overkill and if desired could
> be
> handled in a policy API way perhaps.
>
> I've got small inclinations towards signaling/periodic checks.

I'll pencil that in for a "later" then. Maybe something like "rndc" for DNS, i.e. a control mechanism for telling it to reload/reopen a specific database?

> note for doco - requires openDBX 1.3.7 or later though 1.3.11
> recommended if
> your going to compile it yourself (to avoid stupid compile error in
> opendbx)

Added to INSTALL.
Received on Mon Nov 02 2009 - 18:48:48 PST