![\includegraphics[height=4cm]{fuzzball.epsi}](img1.png)
SIPB Domain Name Service
The Student Information Processing Board
Nicholas Ingolia (ingolia@mit.edu)
February 10, 2006
The SIPB Domain Name Service provides master or slave name service for personal domains of MIT affiliates in cases where doing so is consistent with the MITnet rules of use, most particularly when the domain is not being used for commercial purposes. With SIPB DNS as a master name server, your domain is generated every hour from a file in your Athena home directory. It can also serve as a slave name server, providing redundancy with existing name servers.
In order to use SIPB DNS, you must independently register your domain and tell your registrar that the SIPB name server, ns1.sipb.org, as a name server for your domain. We cannot deal with registering your domain or with adding our name server as a name server for your domain. You probably should not add our name server for your domain until it is actually serving your domain.
To use SIPB DNS as a master name server for your domain, create a publicly readable zone file somewhere within your Athena home directory and send mail to sipb-dnsreq@mit.edu with the name of your domain and the location of your zone file. When you receive email confirmation that your domain has been updated, you should confirm that the SIPB name server is serving your domain, and then add it as a name server for your domain in your registrar's records.
The zone file must be a publicly-readable file somewhere under your Athena home directory. You could create a zone file named after your zone in your Public directory. The requirement of public readability should not be worrisome; the information in the zone file will be published to the world by DNS anyway.
A zone file contains a set of records for names in your domain. Each record is a single line in the zone file. The SIPB name service supports many types of records. The four most likely to interest you are the NS, A, CNAME, and MX records. These are discussed in detail below. An example zone file for the foo.org domain is given here. If you are running a small personal domain, you could probably copy this file and use it after a few modifications.
| @ | NS | ns1.sipb.org. | |
| @ | A | 24.218.25.103 | |
| @ | MX | 100 | mail.foo.org. |
| foo | CNAME | foo.org. | |
| www | CNAME | foo.org. | |
| ftp | CNAME | foo.org. | |
| CNAME | foo.org. | ||
| bar | A | 24.218.25.96 | |
| baz | CNAME | bar.foo.org. | |
| quux | A | 24.218.25.122 |
Each record has a name on the left-most column. This name can be an @ to indicate just the name of the domain (here foo.org), or it can be a DNS name within the domain, such as www, to indicate www.foo.org. The type of the record is indicated in the second column. It must be one of the supported record types listed above.
A NS record indicates a name server for your domain. While you should put NS records in your domain, doing so does not take the place of registering those name servers with your domain registrar. Each NS record should have an @ in the name field, indicating that it is a name server for your domain. The third field should be the fully-qualified name of the name server.
An A record connects a name in your domain with an IP address. The third field is the IP address of the machine named in the first field. Although you can provide multiple A records for a single IP address, it is considered more efficient to provide just one A record and use CNAME records to give additional names to the IP address.
A CNAME record indicates that a name in your domain is merely an alias for some other name. The third field is the fully-qualified canonical name associated with the alias. A canonical name should have an A record rather than another CNAME record associated with it. That is, you should not chain aliases. Although CNAME aliases pointing to machines in other domains should in general be avoided, if you have control over the DNS records of the other domain it may be better to specify a cross-domain CNAME than to have to update multiple A records for the same IP address.
A MX record indicates specifies a mail server associated with a name in your domain. When mail is being delivered to an email address, the portion of the email address following the @ sign, such as mit.edu in ingolia@mit.edu, specifies the server to receive the email. If a MX record exists, it indicates the actual name of the server to receive the email. If there is no MX record, mail is simply delivered to the named machine. For instance, there is an MX record for mit.edu indicating the MIT mailserver fort-point-station.mit.edu. Thus, mail to ingolia@mit.edu will be delivered to fort-point-station.mit.edu. If there were no MX records for mit.edu, then the mail would be delivered to the machine named mit.edu instead.
A name can have multiple MX records, in which case the third column indicates the relative priority of these mail servers. If there is only one MX record, the priority number must still be present but has no effect. If you want to provide email for your domain, you will probably want just a single MX record, indicating that mail for your domain (name @) is to be directed to some server with priority 100.
The service also supports AAAA records, SRV records, and AFSDB records. If you need records of this sort, you should be familiar with their syntax.
The program /afs/sipb/project/zoned/bin/vrfyzone can be used to verify that your zone file will load properly. This uses the same zone file parser as the actual zone generating daemon, so if it finds no problems with your zone file, it should load properly. To use it, execute a command such as
athena% /afs/sipb/project/zoned/bin/vrfyzone your-zone-file
substituting your zone file for your-zone-file in the above example. It will print out a message indicating either that your zone file is fine, or that there is some problem with the zone file.
You can verify that the SIPB name server is providing name service for your domain using the dig command. A command such as
athena% dig @ns1.sipb.org your-domain axfr
substituting the name of your domain for your-domain, will request that the SIPB name server display all records for the named domain. If it indicates, ``Transfer failed'', then the SIPB name server has not yet loaded your zone file.
The SIPB name server checks for changed zone files every hour. To update your domain, simply edit the zone file and wait for the next reload. To avoid having the name server re-read your zone file while you are in the midst of editing it, you might want to copy it, edit it, validate it (as described in 1.1.6), and then move it into place when you are done. An example of such a transaction is given below.
athena% cd Public athena% cp foo.org.dns foo.org.new athena% emacs foo.org.new athena% /afs/sipb/project/zoned/bin/vrfyzone foo.org.new Zone source file foo.org.new appears valid athena% mv foo.org.new foo.org.dns
When the SIPB name server re-reads your zone file, it will send a Zephyr notification to class sipb-auto, instance zoned. It will also send you email indicating that your zone was reloaded.
If you already have a domain and have name servers, but you would like to use SIPB DNS as well, send mail to sipb-dnsreq@mit.edu specifying the IP addresses of your current master name server. The SIPB name server will then obtain zone information from this master name server, which you should continue to update as you have been doing. The operation of the SIPB name server should be transparent to you. You can verify that the name server is providing service for your domain as described in 1.2. Once it is providing name service, you can add it to your registrar's list of name servers for your domain.
Currently, you must contact sipb-dnsreq@mit.edu in order to change the IP addresses of your master name servers. For this reason, you should not use machines whose IP addresses change frequently as master servers for your domain.
If you would like to manage your domain from a machine you control, but do not want that machine to be an actual name server for your domain, you can use the SIPB name server as a slave to your unpublished master server. This strategy might be useful if you would like to write your own zone file on a personal machine but that personal machine isn't suitable to be a name server. In this case, request that the SIPB name server be a secondary to your desired master name server, but register only ns1.sipb.org as a name server for your domain.
$Header: /afs/sipb/project/zoned/doc/RCS/zoned.tex,v 1.7 2002/09/08 23:05:02 ingolia Exp $
This document was generated using the LaTeX2HTML translator Version 98.1 release (February 19th, 1998)
Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 zoned.tex.
The translation was initiated by Jonathan T Wang on 2006-02-10