DNS Configuration

Using code.tjhsst.edu (optional)
Go to http://code.tjhsst.edu/ and make an account.

Then go to http://code.tjhsst.edu/tjhsst-dns/tjhsst-dns and press clone this repository on gitorious. Name it whatever you want, but try to make it meaningful.

After the repository is created, clone the push url using git. For me it was git clone git@code.tjhsst.edu:~tageorgiou/tjhsst-dns/tageorgiou-tjhsst-dns.git

Then edit the configuration as normal and prepare a commit. After you commit it, run git push origin master, which will put your changes back on code. Then, press request merge on your repository's page. Fill out the form and then submit it.

Getting DNS configuration
The current config is always at /afs/csl.tjhsst.edu/service/dns.git

In order to get a copy to work on, just clone it.

For afs-enabled computers (like workstations and remote): git clone /afs/csl.tjhsst.edu/service/dns.git

For other computers: git clone username@remote.tjhsst.edu:/afs/csl.tjhsst.edu/service/dns.git

This will fetch the configuration and history and store it in a folder called "git". You can safely rename this folder if you so choose.

Editing Configuration
in tjhsst/ is where most changes will be made. The file named tjhsst.edu contains many forward records in A,AAAA,CNAME,TXT,SRV,AFSDB, etc. An example entry looks like this: shodan.csl                     IN      A       198.38.18.72 IN     AAAA    2001:468:cc0:0:21d:60ff:feee:2b1c shodan                         IN      CNAME   shodan.csl

The other file(s) that likely need to be reside in tjhsst/revpub. There is one per IP block, so for example, shodan's reverse record is in tjhsst/revpub/18.38.198.in-addr.arpa: 72     IN      PTR     shodan.csl.tjhsst.edu. Don't forget the dot at the end! It's important. Really.

The ipv6 reverse records are stored in tjhsst/revpub/csl-ip6. The ipv6 addresses in the reverse record are separated by a dot per letter. Here's the record for shodan: c.1.b.2.e.e.e.f.f.f.0.6.d.1.2.0        IN      PTR     shodan.csl.tjhsst.edu.

Using git to prepare changes for the server
Commit the file locally with git commit -a (commits all changes to files already in the index). Enter a useful commit message. If you are making many changes, consider making a series of commits. The best type of commit message starts with a short string representing what it is you changed followed by a colon, then a short description of what you've done to it. Example: shodan: make CNAME shodan -> shodan.csl

Any non emergency change to DNS should go through the staging area you originally cloned from. In order to get the changes merged there, push your changes to some readable location (github.com, gitorious.org, your own server, whatever) or alternatively have the changes in a git repository in your homedir that's readable (rl) by system:authuser.

Then request a merge from one of the DNS admins. These currently are: David Ensey, Thomas Georgiou, and Daniel Johnson. Having a few people designated as such will hopefully encourage good code and keep people from running over each other, but there will hopefully be someone available to merge your changes within an hour or so.

Merging people's changes to the server
These directions are primarily here for the admins, but are also available for those interested.

If a remote doesn't exist yet, add a one for the contributor's repository with git remote add reponame url://to/repo Then pull the changes from that repository with git pull reponame master. Don't push to the staging area, as this breaks the working directory of the staging area.

The next step is to update the serial number. Since multiple people can be working on changes at the same time, it is recommended that the serial number not be changed outside of the staging area (since the number has to be linear). After the serial number bump has been committed, you need simply run ./update-ns1.sh. This script isn't very complicated (and the process isn't that hard to do manually), but it does check the validity of the zone before updating it, and informs you of what you're going to push to the server. If the script succeeds without errors, the server should now be running with the new changes.