BIND 10 #772: Update xfrout to use ACL checking library

BIND 10 Development do-not-reply at isc.org
Thu Jul 14 22:09:22 UTC 2011


#772: Update xfrout to use ACL checking library
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  stephen                            |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20110802
                   Priority:  major  |            Resolution:
                  Component:         |             Sensitive:  0
  xfrout                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  3.0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 First, I've made a few trivial changes/cleanups and directly pushed them.

 '''general'''
 - I'm not sure if we should reject incoming AXFR request by default.
   At least it's different from BIND 9's default.  It will also break
   current deployment of BIND 10 (although I think it's acceptable at
   the current maturity of BIND 10 as long as we warn it in a release
   note or something).

 '''misc in xfrout.py.in'''
 - parse_query_message(): shouldn't we skip performing ACL if TSIG
   check fails?  In fact, (although quite unlikely) if the fail is MAC
   mismatch, it may mean the message is broken, so performing ACL
   itself may not even make sense especially if and when we introduce
   ACl based on message content.  We may want to apply a "DROP" rule
   only by remote address even before the TSIG check, but as we
   discussed in the resolver case, that would probably be done by a
   separate ACL.
 - parse_query_message(): not sure if it's intentional, but you can
   omit "isc.acl.acl" below:
 {{{
             if acl_result == isc.acl.acl.DROP:
 ...
             elif acl_result == isc.acl.acl.REJECT:
 }}}
 - It seems we can merge reply_query_with_error_rcode() and
   reply_query_with_format_error().
 - update_config_data: we should probably log first so that it's logged
   even if load() fails with exception:
 {{{
         if 'ACL' in new_config:
             self._acl = REQUEST_LOADER.load(new_config['ACL'])
         logger.info(XFROUT_NEW_CONFIG)
 }}}
 - update_config_data: just checking, is it okay to not to protect it
   by lock?  maybe we should add comment about that.

 - config_handler: technically "Bad configuration" may be too
   restricted, because exception would happen for other (rare) reasons
   such as memory allocation failure.  maybe simply say "Failed to
   handle new configuration" or something?
 {{{
             except Exception as e:
                 answer = create_answer(1, "Bad configuration: " + str(e))
 }}}

 '''guess_remote'''
 - in the doc, "The socket must be a socket" sounds awkward.  Maybe
   "sock_fd must refer to a socket" or something?
 - The trick employed in this function seems to be the best current
   practice, but I'm afraid it's fragile.  I wouldn't be surprised
   there's a system that is more strict about the AF matching, for
   example.  For longer term, I guess we should pass some auxiliary
   information (at least the AF, socktype and protocol, and possibly
   local/remote addresses) when we pass a socket FD from one process to
   another.
 - As for this:
 {{{
             # To make it work even on hosts without IPv6 support
             # (Any idea how to simulate this in test?)
 }}}
   It seems we can override socket.has_ipv6.  So a test could tweak it
   before testing.  (but we might not bother to do this minor case -
   today's many system already supports IPv6, and if we implement the
   "longer term" solution in not far future, the problem will be gone
   anyway)

 '''xfrout_test'''
 - maybe a matter of taste, but you should be able to use assertEqual here:
 {{{
         self.assertTrue(rcode is None)
         #self.assertEqual(None, rcode)
 }}}
 - you mean "REFUSED"?
 {{{
 +        # This should be rejected, therefore NOTAUTH
 }}}

 '''xfrout_message.mes'''

 I'd explain %1 and %2 such as in '<zone name>/<zone class>'.  '%3:%4'
 to represent address+port is not a good way when it's IPv6 address.
 Ideally we should resolve the unification of the notation (should be a
 ticket for this, don't remember the number), but assuming it's not
 done yet, I'd suggest either %3#%4 (BIND 9 way) or [%3]:%4.

 '''changelog'''
 As discussed in 'general', if we keep rejecting requests by default,
 we should note it more explicitly that it's a backward incompatible
 change (and we should mark it with '*').

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


More information about the bind10-tickets mailing list