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

Johan Ihren johani at autonomica.se
Tue Dec 16 08:02:17 UTC 2008

Hash: SHA1

Hi Paul,

On 16 Dec 2008, at 00:16, 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.

Isn't this what you're talking about:

key K1 { ... };
key K2 { ... };
zone Z1 { ...
    masters { S key K1;};
zone Z2 { ...
    masters { S key K2;};

This of course only deals with the zone transfer case, but if that's  
not what you're talking about and you're looking into f.i. TSIG for  
last mile communication to stub resolvers, etc, then there are lots of  
other things to ponder before the lack of symmetry for initiator/ 

> 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 don't like the server statement. While I agree to the need for  
something like that I really dislike having a working zone transfer  
depend on stuff in three different sections of my named.conf, i.e. a  
key statement, a server statement and finally a zone statement.

Adding a zone-server statement will not exactly make this cleaner.

And hence I prefer avoiding the server statements by including the key  
in the masters {} clause directly.


Version: GnuPG v1.4.5 (Darwin)


More information about the bind-workers mailing list