heather@truebalt.caltech.edu (Heather L. Sherman) (12/15/90)
What's the best way to delegate PART of an in-addr.arpa subdomain to another nameserver? A group on campus will be sharing a gateway and subnet with a couple of other groups. They already nameserver for their subdomain and would like to nameserve for their section of the subnet as well. What's the best way to delegate something like: 151.4.215.139.in-addr.arpa through 200.4.215.139.in-addr.arpa ? Their suggestion has been to stick CNAMES in for all these to a subdomain (151.name.4.215.131.in-addr.arpa) and delegate name.4.215.131.in-addr.arpa. If we instead use NS records for each address, must there also be a matching SOA record on the delgatee's end for each address? Which method will cause the least unnecessary activity on the nameserver's part? Any ideas or warnings? Thanks! Heather Sherman heather@iago.caltech.edu
rickert@mp.cs.niu.edu (Neil Rickert) (12/15/90)
In article <1990Dec15.014421.4519@nntp-server.caltech.edu> heather@truebalt.caltech.edu (Heather L. Sherman) writes: >What's the best way to delegate PART of an in-addr.arpa subdomain to another >nameserver? A group on campus will be sharing a gateway and subnet with a >couple of other groups. They already nameserver for their subdomain and >would like to nameserve for their section of the subnet as well. >What's the best way to delegate something like: > >151.4.215.139.in-addr.arpa through 200.4.215.139.in-addr.arpa ? > The best approach is to not even try. Why not divide the data into two files included with a $include, and just have separate control over the two files. This can be done either by placing all files on one machine, and using different ownerships for the parts, or by automatic forwarding of changed data with some other means such as rdist, or even email (possibly encrypted if you worry about security). It should not be hard to run automatic scripts from cron to handle the nameserver reload when the data is changed. (For example in my setup, a modification to any $included file will cause the appropriate SOA serial number to be incremented, and the database reloaded, if 'make reload' is done). -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940