[bind10-dev] BIND 10 trac503, updated. implement ANY query logic

[JINMEI Tatuya / 神明達哉]

At Wed, 26 Jan 2011 09:36:46 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> >      response_.setHeaderFlag(Message::HEADERFLAG_AA, false);
> >      const MemoryDataSrc::FindResult result =
> >          memory_datasrc_.findZone(qname_);
> > @@ -141,20 +145,33 @@ Query::process() const {
> >      response_.setHeaderFlag(Message::HEADERFLAG_AA);
> >      while (keep_doing) {
> >          keep_doing = false;
> > -        Zone::FindResult db_result = result.zone->find(qname_, qtype_);
> > +        if (qtype_is_any) {
> > +            target = &result_rrsets;
> > +        }
> 
> This just got my attention. Not that it would be a problem, just a
> small suggestion. This way the RRsetList is created each time. It
> probably isn't much, but ANY queries are rare.

Wait...I have a more basic concern with the use of RRsetList (I didn't
notice the interface of Zone::find() was changed to use it until now).

RRsetList is not actually a "list".  It's actually a "set of RRsets",
and its "add" method internally performs "insert it if it's not
already in the set", which is expensive.

I also have a concern with the new find() interface.  It looks awkward
that it (can) return a requested type of RRset as a return value while
also providing all types of RRsets via the "target".

What I'd envision instead is that Zone::find() returns (an abstract
notion of) the "domain" for the qname.  It would point to an RBNode
for the current implementation of the in-memory data source.  We then
provide an interface to iterate over (or retrieve) all types of RRsets
on a domain.  We might also want to add an interface to retrieve a
given type of RRset (if any) of a given "domain".

Iteration/retrieval or search on a give name will be used for various
purposes,including type ANY query and additional section processing
(if we know the "domain" of a glue, we can directly retrieve AAAA and
A RRsets from it, rather than searching the entire zone again).  BIND
9 also uses these interfaces for DS, SOA, and (authoritative) NS
processing.

In some sense NSD also uses the similar concept: It first searches the
zones for a "domain" that best matches a query name, and then retrieve
necessary RRsets from it.  The fact that two independent
implementations adopt a similar concept seems to me to indicate it's
natural.

So, I'd propose revising the interface based on the "domain" concept.

Mostly independently from that, I'd also suggest not using RRsetList
if we want to provide some interface to retrieve "all RRsets".  More
straightforward data structure such as std::vector should suffice and
be more efficient.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.