BIND 10 #1389: xfrout should allow a message with size of 65535

[BIND 10 Development]

#1389: xfrout should allow a message with size of 65535
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20111206
                   Priority:  major  |            Resolution:
                  Component:         |             Sensitive:  0
  xfrout                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  2
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:7 vorner]:

 Thanks for the review.

 > From a design point of view, I believe this is still suboptimal, due to
 the name compression. If we compress the names, more RRs could fit in. If
 we repeatedly tried to add an RR and render the message until it
 overflows, we would get the biggest one possible, but it doesn't look very
 optimal. Maybe if there was some kind of iterative message rendering.
 Anyway, that is out of the scope of this ticket. Should I create a new one
 or did we already talked about this?

 We can talk about it.  One quick note is that this is what BIND 9
 currently does, so we basically follow existing practice.  I know it's
 suboptimal, but I'm not sure whether there's a reasonable way to make
 it optimize or whether it's even worth solving in the first place.
 Again, however, I have no problem with discussing this separately,
 probably on the bind10-dev list.  In any case let's leave it out of
 scope for this ticket.

 > The code looks sane, but the tests don't pass for me. But I'm not sure
 if it is related to this ticket:

 Ah, okay.  I suspect it's a portability issue depending on the
 implementation detail of the SQLite3 "select" statement.  If my guess
 is correct, commit 144549c should solve the problem.

 > > {{{
 > > 333.        [bug]           jinmei
 > >     b10-xfrout could potentially create an overflow response message
 > >     (exceeding the 64KB max) or could create unnecessarily small
 > >     messages.  The former was actually unlikely to happen due to the
 > >     effect of name compression, and the latter was marginal and at
 least
 > >     shouldn't cause an interoperability problem, but these were still
 > >     potential problems and should be fixed.
 > >     (Trac #1389, git TBD)
 > > }}}
 >
 > Shouldn't it be „potential problems and were fixed“? Because this would
 look like as the problem is still there and we are asking someone to fix
 it for us.

 Okay, will change it on merge.

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