You could also switch to using SIG(0) instead of TSIG. The the client
can just update the KEY RRset which is stored in the zone.
> On 13 Aug 2021, at 03:49, John Thurston wrote:
>
> On 8/12/2021 5:00 AM, Tony Finch wrote:
>> i.e. using the "subdomain" rule type instead of "selfsub", so the
>> d
On 8/12/2021 5:00 AM, Tony Finch wrote:
i.e. using the "subdomain" rule type instead of "selfsub", so the
domain name (second foo...) doesn't need to match the keyname (first
foo...)
Yes, indeed. That's the ticket.
Thank you very much, Tony.
--
Do things because you should, not just because y
John Thurston wrote:
>
> But as far as I can tell, the name of the key needs to match the hostname in
> the update-policy statement. I can define a new aes-256 key, but it can't have
> the name "foo.bar.baz.com" while the current md5 key is defined. Nor can I
> find a way to craft an update-policy
I have a zone defined in which I permit dynamic updates. Many years ago,
I defined a key per name, and added that key into the update-policy
attribute in the zone definition.
For example:
key "foo.bar.baz.com" {
algorithm hmac-md5;
secret "12345..890";
};
zone "bar.baz.com" {
type mast
4 matches
Mail list logo