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