BIND 10 #987: b10-auth should chase CNAME in the same zone

[BIND 10 Development]

#987: b10-auth should chase CNAME in the same zone
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:         |             Milestone:  Year 3 Task
  defect                             |  Backlog
                   Priority:  major  |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  0.0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:1 each]:

 > But there was a bug in the interface between the BIND 9 recursive query
 code and the authoritative server code, so that the authority part didn't
 always give the full chain back to the recursive part.  If this had been
 an interaction between a recursive server and a separate authoritative
 server, then the recursive server would simply have sent another query for
 the target name, and assembled the CNAME chain that way.  (In fact, it
 would probably do this even if it ''had'' received a complete CNAME chain
 from the authority server, as the authoritative response isn't necessarily
 trustworthy for the target name.)  But, as this particular recursive
 server was querying ''itself'', it assumed it had received all the
 information the authoritative server had, and it returned a broken chain.

 Thanks for the clarification, but I'm afraid I really don't understand
 how it's related to the internal interaction betwen the hybrid
 configuration of auth and recursive in BIND 9.

 According to Mark:
 https://lists.isc.org/pipermail/bind-users/2011-May/083723.html
 "it was a simple bug", and this fix doesn't seem to be relevant to
 such an interaction.  And, in fact, 9.8.0-P2 with this patch returns a
 full chain whether or not the query has the RD bit on.

 But in any event.  I knew returning a full chain only (in practice)
 matters for a query with RD being on.  Maybe what you tried to point
 out is that this incident was a real problem because the BIND 9 named
 in question is a hybrid auth/recursive server and it's not the case
 for b10-auth (by definition).  If so, I see the point.  And if so,

 > What BIND 10 needs to do is ensure that a recursive (RD=1) request gets
 a complete chain.  RD=0 requests don't need to.  There may be a slight
 performance benefit to providing one when possible, but there are costs in
 security and complexity that IMHO outweigh it.

 for b10-auth I'd rather either
 1. keep the current implementation (because this wouldn't be a problem
   for an authoritative *only* server), or
 2. always return a full (as much as possible) chain regardless of RD

 I think I understood the so called security discussion, but as I think
 I stated at that time the security argument for the chain from the
 same zone (from the point of the auth server) isn't convincing.  But I
 like keeping the implementation simpler, so I'd support the idea of
 cutting the chain itself for the different reason.  So I prefer option 1.
 If we have some reason for b10-auth to return a longer chain, I'd
 rather keep it as simple as possible, i.e, unconditionally do so
 rather than adding an addition condition check for the RD bit.

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