feature consultation -- per-zone initiator-side tsig keys

[Shane Kerr]

Paul,

On Mon, 2008-12-15 at 23:16 +0000, Paul Vixie wrote:
> for reasons i won't go into, bind's configuration of tsig keys has an
> unfortunate assymetry.  responders can specify what key has to be used
> at a per-zone level, while requestors can only specify what key is to
> be used at a per-responder level.  this makes it impossible for someone
> to use key K1 when talking to server S about zone Z1, yet use key K2
> when talking to the same server S about zone Z2.
> 
> i was thinking of a simple syntax change and couldn't find one, so i'm
> currently thinking of a relatively complicated syntax change, which is
> to clone the "server" statement and call the clone "zone-server".  so
> whereas "server" takes one selector (the server address or ip prefix),
> the "zone-server" statement would take two selectors, one being a zone
> name and the other being the server address or ip prefix.
> 
> the logic would just be, when about to search for a "server" statement,
> first search for a "zone-server" statement matching the zone you're
> acting on behalf of.  if there's a "zone-server" statement, use it.  if
> not, then search for a "server" statement in the traditional manner.  i
> think, though, that this kind of thing warrants some community input,
> so i'm asking for feedback, workarounds, or alternative suggestions.

I think a better approach may be to allow an (optional) arbitrary symbol
name to define servers, in addition to using IP address. So, you could
have:

        server id-foo 67.215.198.150 { keys { ipso; }; };
        server id-bar 67.215.198.150 { keys { facto; }; };

Then you could use these server definition within multiple zones by
referring to the server identifier:

zone "foo.com" {
    type slave;
    masters { 
        id-foo;
         ...
}

zone "bar.com" {
    type slave;
    masters {
        id-bar;
         ...
}

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).

Cheers,

--
Shane