BIND 10 #1104: support TSIG in DNS (Request) ACL

BIND 10 Development do-not-reply at isc.org
Sat Jul 23 00:48:09 UTC 2011


#1104: support TSIG in DNS (Request) ACL
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110802
                  Component:         |            Resolution:
  xfrout                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  0.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:9 stephen]:
 > Changes are OK. (Although I think you're being a bit hard on yourself
 about the "com" v "org" test - the name in question matches neither and I
 can't think of an easy way to check that you're not matching the the name
 you don't want to match against :-))

 Okay, I've pushed the change, and I'll close this ticket.

 Regarding the possible open issue...

 > > We cannot guarantee that. The assumption is that if an application
 uses a TSIG based ACL, it's application's responsibility to perform TSIG
 validation before performing the ACL check. Maybe we should document it as
 a note somewhere (but I'm not sure what's the best place for that. In
 changelog at the moment?)
 > I think that's dangerous.  As the ACL is set up by the user (who may
 decide to include a TSIG check for a whole host of reasons) and the ACL
 checking code can be used by any application, the application may not know
 that the ACL contains a TSIG check.  For that reason, it seems logical
 that once the ACL code has checked that the name matches, it should also
 check that the TSIG key data is correct.

 ...one possible solution is to enhance the TSIGRecord class so that it
 can store a state indicating the record has been verified, and have
 TSIGContext::verify() change the state to "verified" on success (to
 make it possible we need to stop constifying the 'record' parameter,
 though).  Then we can change RequestContext so that it will ignore the
 given TSIG record unless its state is "verified".

 If that works for you, I'll create a separate ticket for it.

 I'm not sure if it requires a community wide discussion at the
 bind10-dev list just yet, so I'll simply keep this ticket open for now.

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


More information about the bind10-tickets mailing list