BIND 10 #496: Data scrubbing

[BIND 10 Development]

#496: Data scrubbing
-------------------------------------+-------------------------------------
                 Reporter:  shane    |                Owner:  jelte
                     Type:           |               Status:  reviewing
  enhancement                        |            Milestone:  R-Team-
                 Priority:  major    |  Sprint-20110208
                Component:           |           Resolution:
  resolver                           |            Sensitive:  0
                 Keywords:           |  Add Hours to Ticket:  0
Estimated Number of Hours:  5.0      |          Total Hours:  0
                Billable?:  1        |
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => jelte


Comment:

 Changes committed as ab2c79a8815be54d7f3482ea5608d2611b7de433

 > Some minor comments about the introduction in response_scrubber.h ...

 The introductory text has been extended.

 > Code doesn't compile for me... due to the inclusion of asio.hpp ...
 > ...
 > We have a wrapper around endpoints for that, IOEndpoint, so I think we
 should use that instead
 > of direct asio::ip::udp::endpoints.

 Fair point - the code has been modified to remove direct references to
 boost::asio and to use the asiolink wrappers.

 > Apart from that, the code looks ok (there might be room for some
 optimization in the scrubbing loop that restarts itself
 > though, but oh well, premature optimization and all that.).

 Well spotted.  The optimisation was simple and has been added (although it
 could be further optimised by extending the !SectionIterator class with
 operator+=() etc.)

 > I'm not entirely sure about the usage of this though...

 See [comment:5 above comment].

 > ...and the same for additional

 If this can be deferred for now, I'll make a separate ticket for it.  The
 current code is RR-agnostic in that it only looks at QNAMES of RRset,
 nothing else.  If we are going to do filtering on the relevance of RRs in
 the additional section, we'll need to interpret the RDATA of RRs in other
 sections, so need to know a bit about the structure of RRs.

 > Of course one question is how much of this would be 'scrubbing' and how
 much 'normal' handling of
 > response packets.

 Agreed, which is why, although the code is in its own class at the moment,
 it should logically be elsewhere - perhaps combined with
 !ResponseClassifier?  Would it be worth creating a separate ticket for
 this refactoring?

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