tsig zone sharing between zones check + scream

[Heiko Richter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 07.08.2015 um 08:52 schrieb Lawrence K. Chen, P.Eng.:
> Grrrr....just noticed that about 12 hours ago, the business office 
> person finally update our KSK with registrar. (where window was
> last month.)
> 
> Well, apparently history must repeat....
> 
> 3 years ago, we rolled over from RSASHA256 to RSASHA256... but the 
> person that did all the interaction with registrars....where the 
> criteria is that they be in position to pay as needed (which did
> used to be dns administrator/department manager/etc....but when
> they left the new manager he didn't want us to continue to have
> that responsibility...but would've taken it...anyhoo)  They
> selected algorithm type as RSASHA1-NSEC3...
> 
> Which caused a bit of an outage, especially since they went on
> vacation right after having left it to the last minute. we had a 60
> day rollover window)...original I had gone around end of fiscal
> year, but decided to shift it...
> 
> 
> Well, this time....still going RSASHA256 to RSASHA256.... (I had
> done the roll from RSASHA1-NSEC to RSASHA256 before it was possible
> to register do such things with registrar...so only DLV was 
> involved....though I did run into a problem since I had a DS record
> in my zone, etc. the mismatch doing one than the other apparently
> was the wrong way to go...or soemething.)
> 
> So this time...RSASHA1 (#5) got selected.
> 
> --------------------------
> 
> So about tsig sharing a zone....
> 
> Is something like this right? (ignoring any typos ;)
> 
> ==================================================
> 
> key "external" { algorithm hmac-sha1; secret "xxxx"; }
> 
> key "internal" } algorith hmac-sha1; secret "yyyy"; }
> 
> options { notify explicit; allow-trasnfer { none; }; }
> 
> acl k-state { 129.130/16; 10.130/16; 10.131/16; 10.132/16; ... 
> 10.139/16; 172.21/16; 192.168.x.0/24; 10.0.0.0/24; };
> 
> acl internal { !key external; key internal; k-state; }; acl
> external { !key internal; key external; any; };
> 
> view "internal" { match-clients { internal; };
> 
> allow-transfer { key internal; };
> 
> zone "ksu.edu" { type master; file "pri/ksu.campus.signed"; 
> allow-transfer { key internal; int-secs; }; also-notify {
> 129.130.x.x; 129.130.x.y; 129.130.x.z; }; } zone "ads.ksu.edu" { 
> type slave; file "sec/zone.ads.ksu.edu"; masters { 127.0.0.1 key
> external; 129.130.y.y; 129.130.y.z; }; multi-master yes; 
> also-notify { 127.0.0.1 key external }; }; };
> 
> view "external" { match-clients { external; };
> 
> allow-transfer { key external; };
> 
> zone "ksu.edu" { type master; file "pri/ksu.edu.signed"; also
> notify { 129.130.139.150 key external; 129.130.139.151 key
> external; 129.130.254.21 key external; }; }; zone "ads.ksu.edu" { 
> type slave; file "ext/zone.ads.ksu.edu"; masters { 127.0.0.1 key
> internal; }; also notify { 129.130.139.150 key external; 
> 129.130.139.151 key external; 129.130.254.21 key external; }; }; 
> };
> 
> ==================================================
> 
> I think that's what I'm thinking....though been so long since I
> too break from monitor that I can barely see now....
> 

If you change the algorithm of your KSK it shoudn't be necessary to
change your server's configuration. Neither is it necessary to change
the TSIG keys.

Just dump the keys into your domain's key-directory and bind will
eventually import and use them. If you're in a hurry, you can force
the import by running
	rndc loadkeys

Of course you will also need to retire your old key and remove them
from the zone by running
	dnssec-keygen -D now -I now

And you should (should,  not must!) generate new ZSKs, using the same
algorithm, so change your ZSK-rollover-script to generate RSASHA1 from
now on.

But looking at your algorithm you will have a slight problem, which
you need to take care of, BEFORE you publish your new key: RSASHA1 is
not NSEC3-aware. So if you decide to run with that key, you have to
remove the NSEC3-parameters from your zone (if you have any).

Heiko
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJVxMn8AAoJECKEz6pWghImKzoP/jH2HhwZ13br5Fg1skpqwfiS
C2bQxT4W+sYHa6Vbt2fpCpb62EylnbsAR4zjAFTkipijuL1UErzsRXoghR8D9tq9
miMO+E1P2JE+VVQqeiF2TpJ3+0Phur9cYd3PyJqgaCxG2rfGkAV4NEiReWCdDmOU
OpRaWh2KxoEj/Fh6+RpoTB4yQ5Juvc8RZOmeL8HSuBxpt9Zlh/wMTz3kfg4A2try
OSQ9ZXW128sXmO2ENRqkxETIR6Bm+82YnFQPtNkCsWrxFSaLm0DPxNvZiWF/GEva
OXXrDfDwR60km64VlcdS+aOKlURK/9PZHFj0sg1hyeg5HHSKsRiJ2J2j4p4fsh9Y
/Zpy/nYClA8vvF/Y8juW8RlEid19zJ2Fav+NtkyhnkYLfu222LIKvLChiR1UhUqS
ISlTdXbsM/38p33Spc/MDXad1iCMaX69aEQd/lGGhrb1ZUKhrQ191qo+lgmrL97W
0szd9SOlyvKHDuHsl7J4OloxAQksIsIpvluoqJXP/3I9HzN4mOcKN2VBU49kHbuU
sw9d7LRUgUlKVD5X814CkUcsMQftnAhBEJvHusZ1rVOUDelEiWKxWaMWMDCp5pgN
wS1Jwif4jdNJMfzMXXErUgwj7baAdJMc5rZmG1UXvckQWNitGeqcAxqMfGxlWIGg
WhEdacerUcgmcejFQ7EY
=N3vU
-----END PGP SIGNATURE-----