BIND 10 #496: Data scrubbing

[BIND 10 Development]

#496: Data scrubbing
-------------------------------------+-------------------------------------
                 Reporter:  shane    |                Owner:  stephen
                     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 jelte):

 * owner:  jelte => stephen


Comment:

 Replying to [comment:6 stephen]:
 > > 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.
 >


 ack, works now



 > > 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.)
 >

 Originally, I was thinking that if you 'mark' them in a first iteration,
 then delete them, you'd only have to go through the list once (or twice),
 but this is probably about equivalent :)


 > > I'm not entirely sure about the usage of this though...
 >
 > See [comment:5 above comment].
 >

 ack, noted :)

 > > ...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?

 Right. I think that we can even defer that for now, and keep it in mind
 when we hook everything up, I strongly suspect that we'll know much better
 where the sweet spot is at that point. We could create one ticket to mark
 that we might need to look into this, but i'd suggest we leave specifics
 out of that right now.

 My name is Jelte and I approve of these changes.

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