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 MASTER host: 1. Start by editing /etc/namedb/named.conf, and in the "options" section, let's define who is allowed to transfer your zone. allow-transfer { 127.0.0.1; ::1; myslaves; }; 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 master.grp25, for example) acl myslaves { 10.10.25.1; 10.10.X.3; }; // 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.3. 2. Restart named # /etc/rc.d/named 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 @master.grpX.ws.nsrc.org MYTLD axfr 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/namedb/log/transfers ? 5. Let's make swatch complain if it sees a forbidden zone transfer: Edit /usr/local/etc/swatch.conf, and add a new section -- remember to use TAB for the space at the beginning of the lines: - - - - - - - - - - - - - - - cut below - - - - - - - - - - - - - - watchfor /client ([0-9.:]+)\D\d+: zone transfer '(.*)\/.XFR\/IN' denied$/ mail=adm,subject=Denied AXFR for zone '$2' from $1 threshold type=limit,count=1,seconds=600 - - - - - - - - - - - - - - - cut above - - - - - - - - - - - - - - 6. Kill swatch # ps ax | grep swatch Find the process ID (the number on the left), and run kill on it: # kill PID_OF_SWATCH Restart swatch # /usr/local/bin/swatch -c /usr/local/etc/swatch.conf --tail-file=/etc/namedb/log/general --daemon Note: we ask SWATCH to look at the /etc/namedb/log/general file now, since BIND logs failed attempts to AXFR in the security category, and we have configued bind to log the security category in the general log file. 7. Re-run the zone transfer as in step 4 (from another machine) and see if you receive a mail when that happens. Try again 2 more times to do AXFR within a minute. Q: How many mails did you receive ? 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-MD5 -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.public Kmydomain.key.+157+32373.private 2. View the contents of the private key # cat Kmydomain.key.+157+32373.private You will see something similar: Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: tHTRSKKrmyGmPnzNCf2IRA== Bits: AAA= ... the "Key:" is the important here, so copy "tHTRSKKrmyGmPnzNCf2IRA==" (not THIS one, the one in YOUR file :) 3. Modify your named.conf # cd /etc/namedb/ 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-md5; secret "tHTRSKKrmyGmPnzNCf2IRA=="; }; Change the definition for your zone: zone "MYTLD" { zone "mytld" { type master; ... }; 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 that 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. 4. Restart named # /etc/rc.d/named restart 5. Try and make a zone transfer from ANOTER machine -- ask your neighbors: # dig @10.10.XX.1 MYTLD axfr Look at /etc/namedb/logs/general and /etc/namedb/logs/transfers Q: What do you notice ? 6. Try again with the key: # dig @10.10.XX.1 axfr mydomain.dns -y mydomain-key:tHTRSKKrmyGmPnzNCf2IRA== Q: what happens now ? Check the logs again, especially /etc/namedb/log/transfers 7. On your slave: Start by deleting the copy of the slave zone: - Remove the zone from /etc/namedb/slave/MYTLD -- remember, this is on the machine of your SLAVE partner # rm /etc/namedb/slave/MYTLD - Restart named # /etc/rc.d/named restart Check that the zone is gone AND that the slave 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 "MYTLD" { 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-md5; secret "tHTRSKKrmyGmPnzNCf2IRA=="; }; server 10.10.XX.1 { keys { mydomain-key; }; }; 9. Restart named # /etc/rc.d/named restart On the SLAVE server: Q: Is the zone "MYTLD" 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! On AUTH, using the examples in /usr/local/etc/nsd/nsd.conf.sample, near the end, update the "zone:" definition for MYTLD, 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!