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....
--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
with LOPSA Professional Recognition.
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
