After having enough time to put some finishing touches to an ACL plugin for NSD I know have something suitable for looking at. It isnt entirely functionaly just yet, but it does compile, load and work to certain extent. After untarring the source, it needs to be configured as follows: ./configure --with-nsd-source=[path] --with-nsd-modules=[path] each being the path to an unpacked NSD-1.2.0 source tree, and the location you want the module installed to, respectively. There are two main parts to the plugin. aclc and nsd_acl_plugin.so Aclc, aclc is the Access Control List Compiler, it's documented in it's manpage, aclc.8. But basically it takes a plaintext access control list, and compiles it into something suitable for the plugin to load later on. nsd_acl_plugin.so is a standard NSD 1.2 plugin. It takes one argument, which is the location of the compiled acl database. aclc sometextfile nsd.acldb nsd [option] -Xnsd_acl_plugin.so=nsd.acldb for example. The current implementation has two main limitations, I'm hoping someone may be able to help me rectify these. The plugin currently only honours "all" type ACLs, ie you can't block just "NS", "MX" .. or whatever queries. This is because I can't find an easy way to determine query_type from with the plugin. Is there an easy way ? Rules are currently not honoured for subzones. So, if you have a rule that says: deny all for example.com from 0.0.0.0/0 "host -t any example.com" will be refused by the plugin, but "host -t any www.example.com" will not. Fixing this is a matter of finding out how to get a list of all the records in a particular zone and registering data for each. Since the AXFR code must have method of finding out all this data, I'm assuming this will be relatively doable. I just havnt figured out how yet. Though the plugin has been written with this approach in mind. (see the top of nsd_acl_plugin.c). I'd appreciate any insights anyone has to offer in this regard. I havnt tested this plugin extensively, and it may not even compile on systems that arnt either my laptop or the servers I use for testing. But it's a start :) I hope to get up to useful-grade within a reasonable period of time. -- Colm MacC?rthaigh / HEAnet, Teach Brooklawn, / Innealt?ir Ghr?as?in +353 1 6609040 / B?thar Shelbourne, B?C, IE / http://www.hea.net/
Colm MacCarthaigh wrote:> After having enough time to put some finishing touches to an ACL plugin > for NSD I know have something suitable for looking at. It isnt entirely > functionaly just yet, but it does compile, load and work to certain > extent. > > After untarring the source, it needs to be configured as follows:Is there a place I can get the source? :)> for example. The current implementation has two main limitations, > I'm hoping someone may be able to help me rectify these. The plugin > currently only honours "all" type ACLs, ie you can't block just > "NS", "MX" .. or whatever queries. This is because I can't find > an easy way to determine query_type from with the plugin. Is there > an easy way ?Not yet. Right now the class and type of the query are passed explicitly to functions that need it inside NSD. They should be stored in "struct query" after the query has been analyzed. Another problem is that currently the query is overwritten with the answer... so by the time your plugin is called the original class and type are no longer available :-( Finally, what do you plan to do when a client issues a query for type "ANY" but is not allowed to see MX records? Filter out the MX records from the answer? Reject the original ANY query?> Rules are currently not honoured for subzones. So, if you have > a rule that says: > > deny all for example.com from 0.0.0.0/0 > > "host -t any example.com" will be refused by the plugin, but > "host -t any www.example.com" will not. > > Fixing this is a matter of finding out how to get a list of all the records > in a particular zone and registering data for each. Since the AXFR code > must have method of finding out all this data, I'm assuming this will > be relatively doable. I just havnt figured out how yet. Though the > plugin has been written with this approach in mind. (see the top of > nsd_acl_plugin.c). I'd appreciate any insights anyone has to offer in > this regard.Probably the easiest way is to use the HEAP_WALK macro in heap.h (which redefines RBTREE_WALK in rbtree.h) on interface->nsd->db->heap. This will give you all the domains (not just the ones specific to a zone). Obviously the internal plugin APIs aren't very well defined yet. That's one reason the plugin support is marked experimental :) But it will be a good thing to make more of the internal functionality of NSD available to plugins in a documented manner. But this will take some time. Erik