BIND 10 #1351: Make TSIG configuration consistent

[BIND 10 Development]

#1351: Make TSIG configuration consistent
-------------------------------------+-------------------------------------
            Reporter:  vorner        |                        Owner:
                Type:  defect        |  vorner
            Priority:  medium        |                       Status:
           Component:  xfrin         |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20121218
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  5             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => vorner


Comment:

 Replying to [comment:17 vorner]:
 > Hello
 >
 > How I dislike XML:
 > {{{
 snip
 > }}}
 >

 Me too. Should be fixed now :)

 > This TODO probably should not be here:
 > {{{#!diff
 > -    def set_tsig_key(self, tsig_key_str):
 > +    def set_tsig_key_name(self, tsig_key_str):
 >          """Set the tsig_key for this zone, given a TSIG key string
 >             representation. If tsig_key_str is None, no TSIG key will
 >             be set. Raises XfrinZoneInfoException if tsig_key_str cannot
 > -           be parsed."""
 > +           be parsed. TODO UPDATE"""
 > }}}
 >

 Actually, it needed to be resolved :) Updated the description.

 > Also, is there a lettuce test with TSIG? (Obviously, my test-everything
 script
 > didn't get that far, so I don't know).
 >

 Yeah, features/xfrin_bind10.feature already had one, it has been updated
 to use this new config style (simply use the key name instead of the full
 string representation).

 > And, as a check about the config, we might want to try two things:
 >  * Try doing the lookup (`get_tsig_key`) when we configure.

 I considered that, but as it is not guaranteed to be present yet, this may
 be a problem (the key is highly likely to be set here and added to the
 keyring in one commit, and the Xfrin module config may be handled before
 the tsig_keys one; the keyring would be updated right after that, but we
 currently have no way to guarantee that it is done first).

 >  * Maybe try creating a TSIG key from the name and if it succeeds, warn?
 (Hmm,
 >    it would be nice if we could send warnings from the config handler).
 >

 yes, it would :) (i'd also like to be able to somehow send informational
 messages to whatever admin may be the next one to look. But some die-hards
 could rightfully argue that's what logs are for. Hmm. A logging appender
 that could send messages to a cmdctl ringbuffer to present to the
 client...).

 Come to think of it, we could probably error if constructing a tsig key
 from the given string works (as it is highly unlikely that it is possible
 to add a tsig key to the keyring where the name matches an entire key).
 But I'm not sure we want to do such a test, tbh.

 > Also, it doesn't use the current implementation of TSIG keyring. Is that
 > intentional? We may want to change the configuration place sometime
 later
 > possibly (putting all zones and tsig keys into /dns or whatever). If
 that
 > happens, we have two places to change it.

 Ah, I didn't even realize it was there in such capacity :)

 Updated to use that. Had to add a second find to TSIGKeyRing (and update
 the find() call in the wrapper) to be able to use it here though (i.e.
 getting a key with only a name, with any algorithm. Oh and removed the
 'bad keys' tests, since the keyring should now handle those.

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