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

Johan Ihren johani at autonomica.se
Wed Dec 17 14:50:48 UTC 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+1 for Shane's proposal.

And while we're at it I repeat my old plea for something slightly less  
idiotic than having to repeat endless lists of "also-notify {}"  
clauses that include every individual server for every zone. With non- 
trivial numbers of both servers and zones this is no longer an  
inconvenience but rather a real PITA.

I.e. for every zone we anycast I have this:

...
also-notify { IP1; IP2; IP3; IP4; ...; };
...

where the list of IP addresses have the two properties of

a) being very long (and growing)
b) being mostly the same between zones

If I could collapse these lists into "also-notify { cloud-A-admin- 
addresses; };" where the actual list is defined separately I would be  
much obliged.

Johan

PS. Remember that Christmas is close...

On 17 Dec 2008, at 14:09, Shane Kerr wrote:

> 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
>
> _______________________________________________
> bind-workers mailing list
> bind-workers at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-workers
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBSUkRy/otlDfa2H4ZAQK7DwP/YWRlq15vL2z4D2qw/sD/tK8yjlfezaGo
kVcOrAaCl2UFpsaama5/nMGs43jTKRXDd4+WjmFbRJ8LeD6wvqq0oni4d4m+joo7
UX7oaXzc76iEDhoJE1x76Ei878xH/sfqz3XjfwRRNN44Ht3ORED6xp9RV4Wj/J8c
Mjyt4spz3NA=
=N0b6
-----END PGP SIGNATURE-----



More information about the bind-workers mailing list