DNS Exercise 3: Delegating a subdomain ====================================== In this exercise, you will *delegate* a subdomain *to* clients of your cctld. Intructors will register subdomains: somedomain.bs.cctld.gy somedomain.bm.cctld.gy somedomain.gd.cctld.gy somedomain.gy.cctld.gy somedomain.ht.cctld.gy somedomain.jm.cctld.gy somedomain.ms.cctld.gy somedomain.tt.cctld.gy and get them delegated to: ns1.cctld.gy (master) and ns-sec.cctld.gy (slave) To start, please fill in the blanks numbered (1) to (5). If it's not clear to you what needs to be done, please ask. (1) My machine is: pc______ . cctld.gy (2) I control domain: _______________ . cctld.gy (this is the domain you set up in the previous exercise, for which your machine is the master) (3) I am going to delegate this subdomain (from instructors): _______________ . _______________ . cctld.gy (2) and I am going to delegate it to: (4) ns1.cctld.gy [master] (5) ns-sec.cctld.gy [slave] Step 1: Test before delegation of domain (3) -------------------------------------------- You are now about to delegate the domain you chose in (3) to the machines listed in (4) and (5); here you are acting in the role of a domain registry. However, before you perform this delegation, you should check that they are both set up correctly, especially that they are both authoritative for the domain in question. Otherwise, you would be creating a lame delegation, which is not good. Test the master using the following command: # dig +norec @ns1.cctld.gy. ____________.___________.cctld.gy. soa (4) (3) (2) Check: * Is the response authoritative? (Flag AA) * Does the SOA record list the correct PC as the master? * Are the nameserver (NS) records in the Authority section correct? There should be two NS records, one giving the hostname of the master (4) and one the hostname of the slave (5) * Make a note of the zone serial number And then test the slave: # dig +norec @ns-sec.cctld.gy. __________.__________.cctld.gy. soa (5) (3) (2) Check: * Is the response authoritative? (Flag AA) * Does the zone serial number match that given by the master? * Are the nameserver (NS) records in the Authority section correct? If any of these checks fail, explain what the problem was to the owners of those machines. Don't proceed until they have fixed the problems - and make sure you have *re-tested* the servers to ensure the problems really have been fixed. Step 2: Delegate domain (3) --------------------------- This is the point at which you delegate the subdomain (3); all queries for this subdomain will be referred to the servers (4) and (5). Edit the zonefile for your domain (2): # vi /etc/namedb/master/__________.cctld.gy (2) ... add these RRs __________ IN NS ns1.cctld.gy. (3) IN NS ns-sec.cctld.gy. Note: in the space marked (3) you just put the *subdomain* chosen by instructor under your domain e.g. somedomain IN NS ns1.cctld.gy. IN NS ns-sec.cctld.gy. This is because the domain origin is added automatically (e.g. if the zonefile is for `xxx.cctld.gy.` then `somedomain` becomes `somedomain.xxx.cctld.gy.`) Question: Do we need to add glue records ? if yes, justify You must also _increment_ the serial number in the SOA record at the top of the zone file; this must be done after every zone file change of course. Save your changes, then validate your modified zone file: # named-checkzone __________.cctld.gy /etc/namedb/master/__________.cctld.gy (2) (2) If it's OK then reload: # rndc reload # tail /var/log/messages That's it! Now all you need to do is to test the new subdomain by doing a normal recursive lookup for a resource record within it, for example: # dig __________.__________.cctld.gy. soa +trace (3) (2)