BIND 10 #626: unexpected response from bind10 (SERVFAIL from auth server) (hotcache issue)

[BIND 10 Development]

#626: unexpected response from bind10 (SERVFAIL from auth server) (hotcache
issue)
-------------------------------------+-------------------------------------
                 Reporter:  shane    |                Owner:  jinmei
                     Type:  defect   |               Status:  reviewing
                 Priority:           |            Milestone:  A-Team-
  critical                           |  Sprint-20110316
                Component:           |           Resolution:
  b10-auth                           |            Sensitive:  0
                 Keywords:           |  Add Hours to Ticket:  0
Estimated Number of Hours:  5.0      |          Total Hours:  0
                Billable?:  1        |
                Internal?:  0        |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:12 vorner]:
 > Hello
 >
 > I confirm the test throws an exception before the fix and works
 afterwards (which would be cause for the SERVFAIL problem). Also, the code
 seem to be clean.
 >
 > But I have a problem understanding what exactly was the problem and how
 this can possibly fix it. How is referral related to cached SOA? What did
 I overlook? Could you explain it little bit, please?

 The problem is this: when SOA is explicitly queried the data source API
 returns "REFERRAL" flag (which means the owner name has an NS, which
 is always the case for the owner name (=zone apex) of SOA as long as
 the zone is validly configured).  In this case hasDelegation() checks
 if the NS is really a delegation, excluding the zone apex, so it's not
 confused.

 On the other hand, in order to find SOA for a negative response,
 addSOA() performs "simple query", and rejects any result if it has a
 flag (including "REFERRAL").  The "simple query" implementation of
 sqlite3 data source (and test data source that largely emulates the
 sqlite3 behavior) cancels the REFERRAL flag internally, so it normally
 won't confuse addSOA() either.

 However, when SOA is first explicitly queried and hot spot cache is
 enabled, the result is cached with the "REFERRAL" flag.  And, in the
 original code cache.retrieve() returns the cached RRset intact, with
 the "REFERRAL" flag being on even for the "simple query" mode, which
 confused addSOA(), having it discard the result.

 My patch adds a post processing after cache.retrieve() so that it
 provides the same behavior as the non cache case.

 > Btw, I fixed a compilation problem here, and pushed (one line in
 makefile).

 Ah, okay, thanks.  Hmm, we may not want to rely on libasiolink, but
 that would be a separate issue.

 > And, as this was originaly reported by someone external to the
 > project, should we wait for his confirmation as well?

 Holding merge until we get confirmation?  In this case since we can
 reproduce the problem and should be quite confident about the cause
 and fix, I don't think we have to wait.  But we should notify the
 original reporter about the fix when we merge the fix to master.

-- 
Ticket URL: <http://bind10.isc.org/ticket/626#comment:13>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development