Don't think TSIG Key roll-over is possible - in the DNSSEC sense. Don't
think it is as necessary either. I have separate TSIG relationships
between my Primary and Secondary peers. I use the same TSIG for all
zones that are on both peers - the TSIG is to secure the path between
the two peers. I also have 'ssh' access to the peers and in order to
perform a 'roll-over' would be logged in (ssh) to both sides of a single
pair of peers when doing the update. The job thus would be..
a) change the config files on both sides
b) signal named to reread its config - on both sided
In total - I directly look after just eight such pairs of peers - not
that hard. I change the signatures every 9 months.
The only Gotcha to changing from hmac-md5 to one of the other algorithms
is that when checking AXFR's with 'dig' you now need to add a third
argument to the '-y' option - the algorithm to use. [-y [hmac:]name:key]
In real life - I run an ISP and offer paid for 'secondary' nameserver
services to my clients (ie those with their own hosted servers). I thus
dress all this up with Web pages and a database backend. TSIG is a free
option - all made nice'n'easy ("change your named.conf to look like
this..." cut-n-paste) even with e-mail reminders to change old
signatures. Almost no one uses the TSIG option - no one seems very
interested. (Hey mark - that's a very cool feature - I'll see if I have
the time to get around to it one day....)
On Wed, 2009-09-16 at 17:08 +1200, Sebastian Castro wrote:
> Hi everyone:
>
> I was reading the document "Deprecation of HMAC-MD5 in DNS TSIG and TKEY
> Resource Records"
> (http://www.ietf.org/id/draft-ietf-dnsext-tsig-md5-deprecated-03.txt)
> and I thought "Darn, I must be prepared to do a TSIG renovation", so
> started researching how to do it.
>
> First step was checking if BIND supported a different algorithm, but the
> BIND ARM for BIND9.5 and 9.6 indicates "The algorithm, hmac-md5, is the
> only one supported by BIND". That seemed strange, considering the
> document indicated above was originally proposed in 2008. So I "used the
> source" and found out other algorithms are supported in 9.5 and 9.6, so
> there is a mistake in the documentation.
>
> Anyway, TSIG rollover is an operation needed as indicated on RFC 2385:
>
> -------------------- RFC 2385 quote -----------------------------
> 6.2. Secret keys should be changed periodically. If the client host
> has been compromised, the server should suspend the use of all
> secrets known to that client. If possible, secrets should be stored
> in encrypted form. Secrets should never be transmitted in the clear
> over any network. This document does not address the issue on how to
> distribute secrets. Secrets should never be shared by more than two
> entities.
> -------------------- RFC 2385 quote -----------------------------
>
> but again the documentation indicates: "Multiple keys may be present,
> but only the first is used."
>
> So, to coordinate the retirement of an old TSIG key and the introduction
> of a new one, it seems a close coordination between peers is needed in
> order to make it work, within a 'maintenance window' where the
> operations using the TSIG are not executed (in my particular interest,
> zone transfers)? Is it not possible to gradually introduce a new key,
> use both for a period of time and later retire the old one, similar to
> what is done in DNSSEC?
>
> Any experience on this matter that could be shared publicly or privately
> will be appreciated.
>
> Kind Regards
> Sebastian Castro
> _______________________________________________
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
. . ___. .__ Posix Systems - Sth Africa. e.164 VOIP ready
/| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
