tsig zone sharing between zones check + scream

Lawrence K. Chen, P.Eng. lkchen at ksu.edu
Fri Aug 7 06:52:25 UTC 2015


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



More information about the bind-users mailing list