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      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 > > 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");
 >     }
 > }}}

 And, actually, I'd rather basically omit the "NS + seen_other" check,
 maybe except for specific cases like NS + DNAME that are prohibited by
 the protocol.

 We already ensure that records on and under a zone cut are hidden at
 the caller side of getRRsets() (unless GLUE_OK is specified), and, as
 long as it's ensured I think it's too restrictive to reject all other
 cases.  IMO this layer should be flexible about what kind of data can
 be a glue (except for those already prohibited by the protocol), and
 let the higher layer such as auth::Query class make that decision.

 In any case the current implementation seems quite tricky:

 {{{#!cpp
                 seen_ns = true;

                 if (Name(columns[DatabaseAccessor::RDATA_COLUMN]) ==
 Name(name))
                     may_have_glue = true;
 }}}

 I cannot understand from a glance what this condition really means, in
 which case it doesn't hold, and for what purpose we do this (besides,
 it needs editorial fixes: it's too long, and misses braces).  Even if
 we still want to selectively reject some cases, I'd like to see more
 intuitive (and if possible more efficient - it requires text-to-name
 conversions twice and comparison of two names, which are not very
 cheap) implementation; and, even if the end result is still this
 check, I think we need to explain it in comments.

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