Uniqifiers for TSIG keys, was Re: feature consultation -- per-zone initiator-side tsig keys

Shane Kerr Shane_Kerr at isc.org
Wed Dec 17 10:52:55 UTC 2008


Mark,

On Wed, 2008-12-17 at 07:58 +1100, Mark Andrews wrote: 
> > > As long as the syntax is being improved, it would be nice if key
> > > statements also had the same ability. That is:
> > >         
> > >         key id-key "key-name" {
> > >             algorithm hmac-md5;
> > >             secret "super-secret-data...";
> > >         }
> > > 
> > > Right now there is no key-id, and the key-name is the unique identifier.
> > > However, this is a protocol element. But there is no reason two people
> > > could not use the same key-name, for example "sns-tsig", which would not
> > > be allowed with the current syntax. Eliminating this potential conflict
> > > would reduce the amount of checking and co-ordination required by zone
> > > administrators (and people writing software to administer zones).
> 
> 	The TSIG RFC already describes ways to generate names for keys
> 	that will never collide.

Sure, and the BIND ARM describes a different way.

Yet in spite of this, some sysadmins will choose things that are short
and easy to use. Sure, it's a mistake, but people will do it. Then if
there is a collision the have to either change their key (meaning the
have to co-ordinate with all of their secondaries) or they have to
maintain extra keys (meaning adding a chance of using the wrong key).

There is no need to use the TSIG key name as an identifier within a
local configuration, even though the RFC basically encourages this (whch
is totally misguided IMHO).

We can make this:

     1. Easier for administrators.
     2. Harder for administrators.

I know the traditional BIND way is #2, but I am suggesting that perhaps
in this one case we make an exception and go with #1. :)

--
Shane




More information about the bind-workers mailing list