BIND TRANSFER SECURITY
----------------------

We're going to limit zone transfer of your zones so that only
your secondary/slave nameservers are allowed to request copies
of the zones.

ACL based security
------------------

To start with, we'll enable IP based ACLs -- on the AUTH1 host:

1. Start by editing /etc/bind/named.conf, and in the "options" section,
   let's define who is allowed to transfer your zone.

   allow-transfer { 127.0.0.1; ::1; YOUR_OWN_IP; myslaves; };

   ... replace "YOUR_OWN_IP" with the IP of your machine :)

   Now we need to define the ACL "myslaves".  To do so, AFTER the options
   section (find the '};' symbol at the end of the section), add something
   similar to this:

   (If the slave for your "MYTLD" domain is auth1.grpY, for example)

   acl myslaves { 10.192.Y.1; }; // ACL with IP of Group Y master

   This means "myslaves is an ACL consisting of the IP 10.192.Y.1.

   NOTE: remember to enter the correct values! You must write the IP
   of the machine who is your secondary in the class - remember !

2. Restart named

   $ sudo service bind9 restart

3. Make sure that you didn't break the zone transfer, by asking your
   slave partner to run a zone transfer against YOUR machine.

   From their server:

   $ dig @10.192.X.1 MYTLD axfr

   Make sure that it still works.  (X = you)

4. Now try and ask someone else in the class whose server is NOT in the
   ACL to try the same axfr command as above.

   Q: Do they succeed ?

   Q: What do you see in the logs in /etc/bind/log/general ?
      What do you see in the logs in /etc/bind/log/transfers ?

TSIG KEY based security
-----------------------

Instead of using IP addresses, we'll now be using cryptographic keys
to authenticate zone transfer -- this uses TSIG, a mechanism by which
the communication between the master and slave server will be authenticated
using this key.

1. Run:

   $ dd if=/dev/urandom of=/dev/stdout count=1 bs=32 | openssl enc -base64

   You will see something similar to this:

   1+0 records in
   1+0 records out
   32 bytes transferred in 0.000034 secs (945195 bytes/sec)
   q8y9VrmVTclnwL1R8eqVePxokn9OwJUpLYNUNWenovQ=

   ... the last line is the important bit here, so copy
   "q8y9VrmVTclnwL1R8eqVePxokn9OwJUpLYNUNWenovQ=", but of 
   course not the one above.

   We will use this in the next steps.

2.  Modify your named.conf

   # cd /etc/bind/

   Edit the file, and change the allow-transfer statement, so that it looks
   like this:

   options {
        ...
        allow-transfer { 127.0.0.1; ::1; };  // myslaves is removed!
        ...
   };

   Note: We have removed "myslaves"

   Now, after the options (or at the bottom of the file), add a new
   declaration for the key

   key "MYTLD-key" {
      algorithm hmac-sha256;
      secret "q8y9VrmVTclnwL1R8eqVePxokn9OwJUpLYNUNWenovQ="; // Your REAL key goes here!
   };

   Don't forget to replace MYTLD by the name of your domain! 

   Change the definition for your zone:

   zone "MYTLD" {
        type master; 
        file "/etc/bind/master/MYTLD";

        allow-transfer { key MYTLD-key; };	// <-- Add this!
   };

   As you can see above, we've added an "allow-transfer" statement
   allowing transfer of the zone for holders of the "MYTLD-key".

   Note: the allow-transfer is now placed INSIDE the zone definition,
   and not globally inside the options section -- BIND can control zone
   transfer either globally, or by zone. We could have chosen to allow
   transfers GLOBALLY (for all zones), by leaving the allow-transfer
   statement in the main "options" section.

3. Restart named

    $ sudo service bind9 restart

4. Try and make a zone transfer from ANOTHER machine -- ask your neighbors
   to do:

   $ dig @10.192.X.1 MYTLD axfr

   Look at /etc/bind/log/general and /etc/bind/log/transfers

   Q: What do you notice ?

5. Then, ask them to try again with the key:

   $ dig @10.192.X.1 axfr MYTLD -y hmac-sha256:MYTLD-key:q8y9VrmVTclnwL1R8eqVePxokn9OwJUpLYNUNWenovQ=

   Q: what happens now ?

   Check the logs again, especially /etc/bind/log/transfers

6. On your partner's SLAVE host

    Start by asking your partner to delete their copy of your zone:

    - Have them remove the zone from /etc/bind/slave/MYTLD --
    remember, this is on the machine of your SLAVE partner:

    $ sudo rm /etc/bind/slave/MYTLD

    - Ask them to restart named 
	
    $ sudo service bind9 restart

    Check with them that the zone is gone AND that their server wasn't
    able to reload it.

    Q: What do you see in the MASTER (auth1) logs (transfers and general) ?

    Q: What do you see in the SLAVE logs (transfers and general) ?

7. Still on the SLAVE

    Find the statement for the zone in named.conf:

    zone "MYTLD" {
        type slave;
        masters { 10.192.X.1; };
        file "/etc/bind/slave/MYTLD";
    };

    ... and add the key, and a statement to tell which key to use
    when talking to "10.192.X.1" (the master):

    key MYTLD-key {
        algorithm hmac-sha256;
        secret "q8y9VrmVTclnwL1R8eqVePxokn9OwJUpLYNUNWenovQ="; 
    };
    server 10.192.X.1 {		// here you put the IP of YOUR master
        keys { MYTLD-key; };
    };

8. Restart named on the SLAVE server:

    $ sudo service bind9 restart

    Q: Is the zone "MYTLD" back in the slave/ directory ?

    Q: What do you see in the SLAVE logs (transfers and general) ?

    On the MASTER server:

    Q: What do you see in the MASTER (auth1) logs (transfers and general) ?

    Can you see a general benefit from using keys instead of IP ACLs ?

9. Only if you are running NSD instead of BIND

   Inside nsd.conf update the "zone:" definition for MYTLD, so
   that it now uses a KEY instead of NOKEY to transfer the zone
   from your MASTER (auth1).

   On the SLAVE:

   - find the line:

   request-xfr: AXFR 10.192.X.1 NOKEY

   - and make it:

   request-xfr: AXFR 10.192.X.1 MYTLD-key

   - add:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
key:
        name: "MYTLD-key"
        algorithm: hmac-sha256
        secret: "q8y9VrmVTclnwL1R8eqVePxokn9OwJUpLYNUNWenovQ="
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   - save and exit the file.

   After, you will need to restart nsd:

   # service nsd restart

   Does the zone get transferred to the SLAVE? Remember to check the logs!

   On the MASTER:

   - replace:

   provide-xfr: 0.0.0.0/0 NOKEY

   - with
       
   provide-xfr: 10.192.X.1/32 MYTLD-key

   - add

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
key:
        name: "MYTLD-key"
	algorithm: hmac-sha256
        secret: "q8y9VrmVTclnwL1R8eqVePxokn9OwJUpLYNUNWenovQ="
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
			
   - save and exit the file.

   After, you will need to restart nsd:

   # service nsd restart

   Check the logs