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

[Joao Damas]

being able to refer to lists by tags/names is always a good thing, IMHO

Joao

On 17 Dec 2008, at 15:50, Johan Ihren wrote:

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