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 each):

 Replying to [comment:36 jinmei]:
 > 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).

 True, XFR was a bad example, of course it doesn't care about a specific
 rrtype.  But here's an UPDATE, on a BIND 9.7.1 server which is
 authoritative for example.nil:

 {{{
 $ nsupdate -l
 > ttl 3600
 > update add example.nil. IN DS 9498 7 1
 5164B0246FD74DB21DBC97B7AB2247426C79E02B
 could not find enclosing zone
 }}}

 However, that works fine for example.nil/A or example.nil/TXT.  You can
 silence the complaint from nsupdate by specifying "zone example.nil" in
 advance, but the zone won't accept the DS record--it appears successful,
 but the record doesn't show up later in an AXFR or in the zone file after
 rndc freeze.  The update failed.

 The bottom line is that example.nil is not authoritative for
 example.nil/DS; nil is.  The question "which zone is authoritative for
 this RR?" is partially dependent on rrtype.  So if I'm designing a tool to
 answer that specific question--which I was--I'd want to include an
 optional rrtype as one of the input parameters.

 (Note "optional".  The !DataSrcMatch constructor had a default
 RRType::ANY() for the third parameter, !ZoneMatch still does.  So when
 rrtype isn't relevant, you can construct with only name and rrclass and
 get the expected result.)

 > If so, this is something like a proposal that we should extend BIND 9's
 dns_zt_find()

 dns_zt_find() doesn't determine the authoritative zone for a resource
 record, it looks up a zone by name in the zone table, which BIND 10
 doesn't have.  So it's not really analogous.

 But, again, we've settled on a version that we're both okay with.  Not
 that arguing isn't fun, of course!  But let's pick a new topic.  :)

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