Re: Switching key types for authorizing updates

2021-08-12 Thread Mark Andrews
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 >>

Re: Switching key types for authorizing updates

2021-08-12 Thread John Thurston
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

Re: Switching key types for authorizing updates

2021-08-12 Thread Tony Finch
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

Switching key types for authorizing updates

2021-08-10 Thread John Thurston
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