Changes between Initial Version and Version 1 of AuthQueryLogic


Ignore:
Timestamp:
Nov 29, 2010, 1:08:45 PM (7 years ago)
Author:
jinmei
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AuthQueryLogic

    v1 v1  
     1= Introduction =
     2
     3We are going to (re)implement authoritative query logic for in memory data source.  The currently used query logic is restricted due to the less smart nature of underlying data source (i.e., sqlite3) and is not suitable for in memory data source, which is expected to be optimized for performance and implements smartness inside it.
     4
     5This is an initial "design" idea of the revised logic.  We'll fix details as we implement them, so this is not a perfect, fixed design, but is provided to show our general ideas.  Once we start the implementation, more detailed and complete design will be documented with the source code in the doxygen format, and this document will eventually be stale.
     6
     7= Background: BIND 9's query logic =
     8
     9BIND 9 implements generic query logic in
     10bind9/bin/named/query.c:query_find().  It's "generic" in that the
     11single function can support both authoritative and recursive (cache)
     12cases, and also handles the case when recursion process is
     13completed.  It's carefully written and supports various protocol
     14features and non protocol functionalities.  But, partly due to the
     15rich set of responsibilities, it's a very complicated, hard to
     16understand function, consisting of 1374 lines of code, a very big
     17switch, complicated process flow with goto's (including ones going
     18backwards).
     19
     20= Overall approach and goals =
     21
     22The plan is to reuse the high level logic of BIND 9's query_find() with:
     23 - simplifying it
     24 - focusing on most common scenarios
     25 - and, as a result, improving performance in future versions
     26   (performance is not in the goal of initial work)
     27
     28== Simplification ==
     29
     30I can think of the following simplification:
     31 - (obviously) authoritative only
     32 - single zone only: do not chase CNAME targets in other zones; do not
     33   add additional RRs in other zones (this may change in future
     34   versions, but we can begin with this without losing lookup
     35   efficiency in the client in practice)
     36 - possibly replacing the switch-case with the command design pattern,
     37   or at least delegate the logic in each case block to another method
     38
     39Then the implementation would generally look like this:
     40
     41{{{
     42    result = zone_table.find(qname);
     43    while (keep_doing) {
     44        db_result = result.zone.db.find(qname, qtype);
     45        switch (db_result) { // this could be a single dispatch of "command"
     46        case SUCCESS:
     47            // normal case: add result to answer section, fill in authority
     48            // and additional sections
     49        case DELEGATION:
     50            // add NS to authority section, fill in additional section
     51        case NXDOMAIN:
     52        case NXRRSET:
     53            // add SOA to authority section
     54        case CNAME:
     55        case DNAME:
     56            // replace qname, continue lookup (only in this case keep_doing
     57            // will be true)
     58        }
     59    }
     60}}}
     61
     62== Additional section processing ==
     63
     64In BIND 9, additional section processing is very generalized and RR
     65type-agnostic through a layer of abstractions.  Generality is good,
     66but it also makes the code unreadable, and causes performance
     67bottleneck.
     68
     69In reality, we can focus on the case of additional records for the
     70NS and MX RRs, and handle other cases as corner cases, possible in
     71less efficient way (and protocol-wise, we could even ignore some of
     72other RRs that might involve additional section processing).
     73
     74So my plan is to begin with focusing on NS (and then MX) explicitly
     75as part of query logic.  this may also help performance optimization
     76in near future.  we'll then consider generalization through
     77additional features in the RRset and Rdata classes (like BIND 9
     78does).
     79
     80= Task plans for incremental development =
     81
     82Each sub task is intended to be completed in 1-2 days, and review
     83should be pretty straightforward.
     84
     85 1. look up the zone table (which fail) and simply return SERVFAIL.
     86    (the following tasks assume zone table lookup succeeds)
     87    (ideally the underlying in memory data source is ready for use at
     88    this point.  but if not, we should be able to use a simple mock
     89    for testing)
     90 2. DB lookup succeeds.  simply return it in the answer section
     91 3. DB lookup results in NXDOMAIN. simply return SOA in the authority section
     92 4. DB lookup results in NXRRSET. simply return SOA in the authority section
     93 5. Additional processing for NS
     94 6. support CNAME case
     95 7. support DNAME case
     96 8. support type ANY query
     97
     98= TODO =
     99
     100Once the basic logic is completed, we should implement more advanced features and/or minor cases, which include:
     101
     102 - DNSSEC processing
     103 - special logic for DS query
     104 - duplicate RR suppression
     105 - generalize the logic so that we can use it with other data sources
     106 - and, eventually other advanced features such as ACL)
     107
     108The current initial design does not fully take into account these points yet.