tsig and servers help

Terry td3201 at gmail.com
Fri Apr 24 18:23:17 UTC 2009


On Fri, Apr 24, 2009 at 12:11 PM, Jeremy C. Reed <Jeremy_Reed at isc.org> wrote:
> On Fri, 24 Apr 2009, Terry wrote:
>
>> I am a bit confused about what exactly applying a key to the servers
>> part of the config does:
>>
>> server 10.25.1.11 {
>>       keys {
>>               omajelns01.omajelns02;
>>               };
>>       };
>> key omajelns01.omajelns02 {
>>       algorithm hmac-md5;
>>       secret "asdfasdfasdfasdfasdf";
>>       };
>> zone "narf.com" {
>>       type master;
>>       file "/var/named/narf.com.hosts";
>>       also-notify {
>>               10.25.1.11;
>>               };
>>       notify yes;
>>       };
>>
>> In this config, what does the key in the server section actually do
>> for me?  I really only want zone transfers to be secured between my
>> master and slaves but I don't really want each zone to have it's own
>> key.  There's also a very high chance that I will have to exchange
>> zones with non-bind servers too.  Which I don't think is an issue if I
>> apply keys at the server level.  Thoughts?
>
> Hello Terry,
>
> The keys in the server statement is used to cause requests sent to that
> server to be signed using that key. In this case, it may be more than just
> zone transfers. It needs to be configured on both sides (so also on the
> slave at 10.25.1.11).
>
>  Jeremy C. Reed
>  ISC Sales & Support Engineer
>

Thanks for your reply.  On my slave, I have this:

server 10.25.1.10 {
	keys {
		omajelns01.omajelns02;
		};
	};

It will sign all requests between these hosts.  If requests come
across that appear to be from these hosts and they are not signed, the
server at either end will reject the requests (i am pretty sure that's
the whole idea but just clarifying)?   If that's the case, I like this
architecture, it's simple and provides a level of security without a
great deal of configuration overhead.



More information about the bind-users mailing list