[bind10-dev] Blog comment from BDB developer

zhanglikun zlkzhy at gmail.com
Fri Jun 25 03:04:31 UTC 2010


> On Thu, 2010-06-24 at 18:00 +0000, Francis Dupont wrote:
> > > Best we contact them soon since we need additional functionality from
> > > BDB's C API to walk the zone backward as well as forward once we do a
find.
> >
> > => the stupid answer is to create a cursor and to use it to get
> > with DB_NEXT / DB_PREV. Of course this means to set comparison
> > functions before... Now I am not an expert in BDB when a whole
> > group of experts propose their help (:-)!
> 
> The problem with this is that we need the DB_NEXT/DB_PREV for handling
> NXDOMAIN in DNSSEC. But with the C API if you get no match you doing get
> a cursor back, you get a "no data found" return.
> 
> Evan (I think) proposed a brilliant hack of:
> 
>      1. Inserting a data record if no match is found
>      2. Looking up a cursor at that record
>      3. Using DB_PREV to get the covering NSEC value
>      4. Deleting the data record we added
> 
> Clearly this is... sub-optimal. But I'm pretty sure it would work.
> 
> A better solution would be what Michael alluded to, which is to have a
> lookup which returns "I didn't find the value you wanted, but this is
> the previous/next match in the data we have". We think that the Java API
> provides this functionality, so there should be no fundamental changes
> to BDB to support it.
> 

Use the cursor with flag "DB_SET_RANGE", since the returned key/data pair is
the smallest key greater than or equal to the specified key.

see (Copied from BDB API documents):
{{{
The DB_SET_RANGE flag is identical to the DB_SET flag, except that in the
case of the Btree access method, the key is returned as well as the data
item and the returned key/data pair is the smallest key greater than or
equal to the specified key (as determined by the Btree comparison function),
permitting partial key matches and range searches.
}}}

So it will depends on how we design the key and key comparation function.

KEY:  RR_TYPE + RR_NAME

Key_compare()
{
    Compare rr type first ,
    Then compare rr name, 
}

Define two non-exist types:
TYPE_NONE  =  0
TYPE_MAX = 0xFFFF

So find next name should query with  the key "TYPE_MAX + query_name"

Oh find the prev name is a little tricky:
    first query with the key "TYPE_NONE + query_name",  then move the cursor
to the prev one, oh, we find it.


Example, the records in bdb database is:
a.cn.   A   1.1.1.1
a.cn.   NS  a.a.cn.

c.cn.   A   2.2.2.2
c.cn.   NS  a.c.cn.

query with  TYPE_MAX + 'b.cn.',  will find "c.cn." directly.

Query with TYPE_NONE + 'b.cn.',  will find  c.cn. first, then move cursor
the prev one,  'a.cn. NS a.a.cn.' is found.

Hope this can provide some help, :)

Zhang Likun









More information about the bind10-dev mailing list