BIND 10 #1430: Data source error with mismatched label counts

[BIND 10 Development]

#1430: Data source error with mismatched label counts
-------------------------------------+-------------------------------------
                   Reporter:  shane  |                 Owner:  UnAssigned
                       Type:         |                Status:  assigned
  defect                             |             Milestone:
                   Priority:         |  Sprint-20120110
  critical                           |            Resolution:
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  2
            Defect Severity:         |           Total Hours:  0
  Medium                             |
Feature Depending on Ticket:  none   |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Shane:

 I've looked into the ticket, and while I see the potential problem in
 this area, the specific problem description didn't make sense to me.

 Do you mean xfrin tries to look up in the
 time-travellers.nl.eu.org. zone for borg.c-l-i.net.?  If so,
 (referring to the 20111128 release version) it seems an exception
 should be triggered at this point:
 {{{#!c++
     const size_t remove_labels(current_label_count - origin_label_count);

     // Now go trough all superdomains from origin down
     for (int i(remove_labels); i > 0; --i) {
         Name superdomain(name.split(i));
 }}}
 which is before the point your suggested patch changes.

 So it doesn't make sense to me the patch really solved the problem.

 Do you have a copy of the exception output from xfrin or can you
 reproduce the problem by reverting your fix?

 Also, if xfrin really looked up an out-of-zone name, xfrin itself is
 buggy there and should be fixed, too.  Even though find() shouldn't
 throw an exception this way (i.e., it shouldn't naively produce an
 overflow and surprise itself), the general assumption is that the
 caller is expected to call find() after identifying the correct zone.
 Any call to find() for an out-of-zone name is therefore consider a bug
 of the caller, whether or not it results in an exception.

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