BIND 10 #254: we should revisit RRset::setName()

[BIND 10 Development]

#254: we should revisit RRset::setName()
-------------------------+--------------------------------------------------
 Reporter:  jinmei       |       Owner:  jinmei              
     Type:  defect       |      Status:  new                 
 Priority:  major        |   Milestone:  feature backlog item
Component:  data source  |    Keywords:                      
Sensitive:  0            |  
-------------------------+--------------------------------------------------
 While working on trac #249, I noticed the top level data source could
 override (the content of) RRsetPtr in wildcard handling:

 {{{
             RRsetPtr rrset = wild.findRRset(RRType::CNAME(), q.qclass());
             if (rrset != NULL) {
                 rrset->setName(task->qname);
                 m.addRRset(Section::ANSWER(), rrset, q.wantDnssec());
                 chaseCname(q, task, rrset);
             }
 ...
             BOOST_FOREACH (RRsetPtr rrset, wild) {
                 rrset->setName(task->qname);
                 m.addRRset(Section::ANSWER(), rrset, q.wantDnssec());
             }
 }}}

 I now think this is a bad practice, because the underlying data source may
 want to hold the original RRset intact (in this case, with the wildcard
 owner name).  The current style of implementation will also affect hot
 spot caching because the cached wildcard RRset will be overridden, and
 will never match a wildcard request (this does not necessarily cause an
 incorrect behavior, but leads to suboptimial performance).

 IMO, what we should do is to make a copy of the returned RRset with a
 different name.  Further, we should generally change the data source
 interface so that the returned RRsetPtrs are "const" (I once tried that,
 but it was not very easy due to other dependency).  Then, as far as I can
 see this is the only usage of setName() method, so we can just remove it
 from the class.

 I'm putting this on the backlog.

-- 
Ticket URL: <https://bind10.isc.org/ticket/254>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development