BIND 10 #999: Integrate ACLs into b10-resolver

[BIND 10 Development]

#999: Integrate ACLs into b10-resolver
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  vorner                             |                Status:  accepted
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110628
                  Component:         |            Resolution:
  Unclassified                       |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  4.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by vorner):

 Hello

 Replying to [comment:6 jinmei]:
 > I've been thinking about the same concept for #999 and tentatively
 > defined a class named "Client":

 I didn't find the trac999 in git, so I couldn't have a look. But, do we
 really need accessor methods for something that just holds some data
 together? Anyway, it's not the main problem.

 I believe we need to integrate the two branches together sometime,
 otherwise registration of all the various checks will be problematic. I
 don't really care much about which class/struct is used as the context, I
 just put there the simplest think that looked it should work.

 > It's not a very strong opinion, but I suspect "Packet" sounds a bit
 > too generic in that it could be either incoming/outgoing
 > request/response, while this class seems to focus on the incoming
 > side, e.g., from this:

 I expected it to be incoming. The local port and address are there,
 because we accept them on some and user might want to distinguish at which
 interface it came. But that wouldn't be too common I guess.

 > I (again tentatively) define the "Client" class in lib/server_common.

 I don't think server_common is the place to go. That one is for
 implementation/technical stuff we have for our servers. The ACL should be
 a generally-available library I believe (with python bindings, etc). I
 thought of putting it as dns::acl as well, which would make some sense as
 well, but server_common feels odd.

 > I'm not sure how many things that depend on specific contexts would be
 > reasonably defined under the acl namespace.  Also, the concept of
 > "Packet" itself is not necessarily tied to access control.  By
 > defining Client, I'd envision we'll eventually use it as a higher
 > level interface between ASIO and actual (auth/resolver) server
 > classes, that is, instead of getting a set of io_message,
 > query_message, ... etc. in Resolver::processMessage(), we'd pass a
 > "Client" object that encloses these types of parameters.

 Surely a good goal, I'm not against having the „context“ out of the ACL
 thing. I'd like to have a place where we put all the TSIG checks, etc,
 which is both ACL-related and DNS-related. The important part now is, I
 believe, using the singleton loader. As you mentioned, you expect to have
 this ready for review soon, this would be one of the TBD?

 Thanks

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