BIND 10 #192: Data source hotspot cache

[BIND 10 Development]

#192: Data source hotspot cache
-------------------------+--------------------------------------------------
 Reporter:  each         |        Owner:  jinmei                                        
     Type:  enhancement  |       Status:  reviewing                                     
 Priority:  major        |    Milestone:  05. 3rd Incremental Release: Serious Secondary
Component:  b10-auth     |   Resolution:                                                
 Keywords:               |    Sensitive:  0                                             
-------------------------+--------------------------------------------------

Comment(by jinmei):

 Replying to [comment:35 each]:

 > > As for "what other context", I can think of various cases, but as you
 yourself noted (in the next paragraph) dynamic update is one possibility.
 XFR is another.

 > However, I'm content with the code we have, so let's agree to disagree.
 :)

 Okay, but I'm afraid we were probably not on the same page, so let me
 clarify a few things.

 > But, whether you're doing an update or an XFR or a query, the
 authoritative zone for example.com/DS is *always* going to be different
 from the authoritative zone for example.com/NS or any other qtype.  So I
 don't see the point of omitting it from consideration by the DataSrcMatch
 class.

 I don't understand the logic.  Neither update nor XFR request takes into
 account the "RR type" (DS or NS, etc) in identifying the appropriate
 authoritative zone (or the data source that stores the zone).  For XFR
 requests the server checks its question, which is a tuple of "zone name,
 class (and type=AXFR)".  For update requests the server checks its zone
 section, which is a tuple of "zone name, class (and type=SOA)".  There's
 another example, notify, in which case the server checks its question,
 which is a tuple of "zone name, class (and type=SOA)".

 Only the DS query in normal queries require special considerations.

 And, I'd expect a C++ implementation of xfr/update/notify handlers would
 use the !DataSrcMatch interface to identify the appropriate data source
 for the request, in which case the additional information for qtype is
 just distracting.  (I know in our current development plan of BIND 10
 these will be python scripts, but I'm talking in the context of the design
 of a public API, which will be used by any external developers)

 Do you mean, by "don't see the point of omitting it from consideration by
 the !DataSrcMatch class", we should include this special consideration in
 !DataSrcMatch simply because the specific case of DS normal query requires
 it while others don't need it?

 If so, this is something like a proposal that we should extend BIND 9's
 dns_zt_find() (which are called from query/update/xfrout/notify routines)
 by adding a type argument and having it behave differently if the type is
 DS (and even more differently if the qname is root) because among various
 usage cases query.c:query_find() requires this consideration.

 If you also don't see the point of why this is awkaward, yeah, I must
 admit we have to disagree.

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