Proper use of keyid in allow-transfer

[Matthew Pounsett]

On 7 December 2017 at 07:41, MURTARI, JOHN <jm5903 at att.com> wrote:

>
>
>                 The slave server defines the same key and is located at
> 192.168.1.1.  When we use the above on the master, transfers for any zone
> work fine.  If we remove the IP address and try a transfer we get
> ‘denied’.  What are we missing?  Thought we might have to associate the
> keyid with zones on the slave, but couldn’t find any options for that??? We
> don’t use TSIG on these servers.
>

The keys you've defined above are TSIG keys, so yes you're using TSIG–or
trying to at any rate. :)

I'm going to assume you're creatively redacting your key data, and that it
isn't actually "BippityBop", because that isn't a valid hmac-md5 hash.

You don't include your slave config, so I'll point out a couple of common
errors there you can look for:
1) the keys must have not only the same secret, but also the same name on
both the master and slave
2) make sure you've got a server{} clause on the slave which tells it to
use the key when speaking to that server.  And note that server{} is a
root-level directive in BIND... it doesn't go inside the options{} block.
For example, if your master is 192.168.1.2, your slave needs:
server 192.168.1.2 {
   keys { bongo; };
};
Alternatively, there's a config syntax for specifying the key to use on a
per-zone basis by adding it to each server in the masters list in a slave
zone definition.  I think the TSIG section of the BIND ARM (Administrator
Reference Manual) discusses that, and for sure the zone syntax description
will.

If it's not one of those things, then I'd suggest you include a more
complete configuration in your next email (from both sides), possibly with
some log entries showing the failed zone transfer attempts (also from both
sides).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20171207/a2ef9cbb/attachment.html>