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

Shane Kerr Shane_Kerr at isc.org
Wed Dec 17 13:09:17 UTC 2008


Mark,

On Wed, 2008-12-17 at 22:38 +1100, Mark Andrews wrote:
> 	When you set up a TSIG key between parties you just choose
> 	something that is not currently in use.

Any time the word "just" appears in a sentence it hides a myriad of
possible problems.

> > 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. :)
> 
> 	Except now you have to remember that id-key is really
> 	key-name.  And you also have to remember that key-name is
> 	id-key.

Why is this?

With my proposed syntax you can surely define:

key "dv.isc.org.key" {
};

As well as:

key tsig-xxx-foo "tsig-xxx" {
};

key tsig-xxx-bar "tsig-xxx" {
};

Then in use one either references the name, or the number. Existing
configurations do not need to change at all.

The only issue will be if one uses an ambiguous set of identifiers (like
trying to use "tsig-xxx" as a key identifier rather than tsig-xxx-foo or
tsig-xxx-bar, in which case the software should issue a warning (or an
error).

--
Shane




More information about the bind-workers mailing list