BIND TRANSFER SECURITY
----------------------
We're going to limit zone transfer of your zones so that only
your secondary/slave name servers are allowed to request copies
of the zones.

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

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

1. Start by editing /etc/bind/named.conf.options, 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 "MYNAME" domain is auth1.grp25, for example)

acl myslaves { 10.10.25.1; 10.10.X.2; }; // ACL with IP of Group25 master

	This means "myslaves is an ACL consisting of the IP 10.10.25.1,
	and your NSD secondary 10.10.25.2.

	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


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 @auth1.grpX.ws.wacren.net MYNAME axfr

   Make sure that it still works.

4. Now try and ask someone else who 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 ?



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:

# cd /tmp/
# dnssec-keygen -a HMAC—SHA256 -b 128 -n HOST mydomain.key

	You will see something like:

Kmydomain.key.+157+32373   (the last number will change)

	Two files have been created:

	# ls -l K*

Kmydomain.key.+157+32373.key
Kmydomain.key.+157+32373.private

2. View the contents of the private key

	# cat Kmydomain.key.+157+32373.private

	You will see something similar to:

Private-key-format: v1.3
Algorithm: 163 (HMAC_SHA256)
Key: 3TZH2W33iinuLUeBW6brpw==
Bits: AAA=
Created: 20161004161802
Publish: 20161004161802
Activate: 20161004161802

	... the "Key:" is the important bit here, so copy "3TZH2W33iinuLUeBW6brpw=="
	(not the one above, but the one in YOUR file :)
	We will use this in the next steps.

3.  Modify your named.conf.options

	# 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 "mydomain-key" {
        algorithm hmac-sha256;
        secret "3TZH2W33iinuLUeBW6brpw=="; // Your key goes here, not this sample!!

};

	Change the definition for your zone:

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

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

As you can see above, we've added an "allow-transfer" statement
allowing transfer of the zone for holders of the "mydomain-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.

4. Restart named



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

	# dig @10.10.XX.1 MYNAME axfr

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

	Q: What do you notice ?

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

	# dig @10.10.XX.1 axfr mydomain -y mydomain-key:3TZH2W33iinuLUeBW6brpw==

	Q: what happens now ?

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


7. On your partner's SLAVE host (your secondary)

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

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

	# rm /etc/bind/slave/MYNAME

	- Ask them to restart named 
	

	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 logs (transfers and general) ?
	Q: What do you see in the SLAVE logs (transfers and general) ?

8. Still on the SLAVE:

Find the statement for the zone:

zone "MYNAME" {
        type slave;
        masters { 10.10.XX.1; };
        file "slave/mydomain.dns";
};

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

key mydomain-key {
        algorithm hmac-sha256;
        secret "3TZH2W33iinuLUeBW6brpw=="; 
};
server 10.10.XX.1 {		// here you put the IP of YOUR master
        keys { mydomain-key; };
};

9. Restart named


	On the SLAVE server:

	Q: Is the zone "MYNAME" back in the slave/ directory ?
	Q: What do you see in the MASTER logs (transfers and general) ?
	Q: What do you see in the SLAVE logs (transfers and general) ?

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

10. Now, do the same for your NSD "auth" server

	... since you have disabled IP ACLs, your AUTH NSD server is not
	able to get the zone!

	Read the NSD manual page (man nsd.conf) if you are in doubt about
	how to specify the key format in NSD for zone transfers. Update 
	update the "zone:" definition for MYNAME, so that it now uses
	a KEY instead of NOKEY to transfer the zone from your MASTER.

	After, you will need to run "nsdc restart".  Does the zone get
	transferred ?  Remember to check the logs on the MASTER as well!