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 Thurston 907-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
