BIND 10 #1771: database datasource incorrectly rejects "on zonecut" glue

[BIND 10 Development]

#1771: database datasource incorrectly rejects "on zonecut" glue
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  muks
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20120612
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:  data   |           Sub-Project:  DNS
  source                             |  Estimated Difficulty:  3
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => muks


Comment:

 Hello

 Replying to [comment:11 muks]:
 > Replying to [comment:9 vorner]:
 > > I think this should work. However, I'd appreciate two things:
 > >  * Test that the glue can be extracted by calling find.
 >
 > This bug (tests which were broken) doesn't use FIND_GLUE_OK though.

 That is true. But getting the glue from the place where the NS is is valid
 usage and it was not possible before this fix (maybe that's why the test
 was not written) and it should be possible now, thanks to the change. So I
 think a new test should be written to check the scenario.

 > > Also, this allows the domain name to contain any A/AAAA, not just the
 glue one. I'm not sure there's a reasonable way to check the A/AAAA is
 really glue, though. So maybe comment the check may have a false negative
 in that regard?
 >
 > I didn't follow what you mean here by any A/AAAA. Can you give me an
 example of what case you mean?

 Well, let's say we have this in the same domain name domain.example.org:
 NS sub.domain.example.org.
 NS sub2.domain.example.org.
 A 192.0.2.1

 The A record is not the glue, it is not referenced by the NS. But this
 will not complain. However, such checks would be crazy to code and mostly
 useless anyway. I just wanted to note it.

 > > And, as this is a publicly-observable bug, I think it should have a
 changelog entry.
 >
 > How about this:
 > {{{
 > XYZ.    [bug]           muks
 >         The database datasource has been fixed to not reject glue
 records.
 > }}}

 Not all glue records were rejected before, were they?

 Replying to [comment:12 muks]:
 > Replying to [comment:10 jinmei]:
 > > Maybe we should discuss this in a wider place (in terms of the
 > > possibly philosophical discussion of the definition of "glue"), but
 > > I personally wouldn't limit the search to A/AAAA.
 >
 > This restriction has been removed now, so all 'other' RRtypes are
 allowed.

 This raises another question. What is the situation when the exception is
 thrown? Can it happen at all? And if so, in what circumstances? Can it be
 a false positive too?

 {{{#!c++
     if (check_ns && seen_ns && (!may_have_glue && seen_other)) {
         isc_throw(DataSourceError, "NS shares domain " << name <<
                   " with something else");
     }
 }}}

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