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

BIND 10 Development do-not-reply at isc.org
Tue Aug 2 10:07:10 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:  5
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => jinmei


Comment:

 First off, I agree with the suggestion to close this ticket and open a new
 one.

 > what I suggested is to introduce a "verified" flag to the TSIGRecord
 class, not TSIGContext
 My mistake, apologies.

 > I don't think it a good idea to deceive the compiler with mutable in
 this case. When we set the "verified" flag of TSIGRecord, it actually
 changes externally observable behavior
 Only if we are allowing for the possibility that the contents of the TSIG
 keyring may have changed between two calls to verify().  If we are using
 the paradigm that all calls to verify() for a particular record are
 against the same instance of the keyring, if the first call to verify()
 succeeds, all subsequent calls will succeed.  In this case the TSIGrecord
 is still logically "const", the mutable flag being used to cache a result
 to avoid expensive computation.

 > IMO, if an application wants to handle TSIG, it should explicitly do it
 at an appropriate position of the code.
 But there is a separation between ACLs and the application; the ACL is set
 by the user, the packet is checked against it, then the (rest of the)
 application is invoked.  If we restrict the TSIG check to just the name,
 we leave open the possibility that an incorrect packet may get through the
 check.

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


More information about the bind10-tickets mailing list