Re: Switching key types for authorizing updates
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 >> 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 you can. > > John Thurston907-465-8591 > john.thurs...@alaska.gov > Department of Administration > State of Alaska > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Switching key types for authorizing updates
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 you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Switching key types for authorizing updates
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 statement line to let a new key with a
> different name manipulate the desired TXT records, while letting the current
> key continue to work.
I think you want something like:
update-policy {
grant "foo.bar.baz.com_aes256" subdomain "foo.bar.baz.com" TXT;
};
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...)
Tony.
--
f.anthony.n.finchhttps://dotat.at/
work to the benefit of all
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Switching key types for authorizing updates
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 master;
update-policy {
grant "foo.bar.baz.com" selfsub foo.bar.baz.com TXT;
};
};
The theory being, the holder of the key named "foo.bar.baz.com" is able
to manipulate TXT records in foo.bar.baz.com and all of its subdomains.
But now I'd like to move away from those old md5 keys. I would like to
find a way to define a second key which will work along side, during the
transition, the existing md5 key. When everyone is using the new key,
I'd then remove the old md5 key.
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 statement
line to let a new key with a different name manipulate the desired TXT
records, while letting the current key continue to work.
Is there a way to get the configuration I want? or must I make a
wholesale swap of each md5 key for something newer?
--
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
