This is a (slightly modified) copy of my public DNS zone for neohippie.net. This is here mostly for my own reference, but may help others in debugging/creating DNS zones. Tthis is NOT a complete copy of my zone and some records have been removed/renamed to protect the innocent, but all the pieces you need to get the idea are still there. The following DNS zone also serves as an example of how to setup Google Apps for your domain without spending hours digging through Google help documentation.

Download text file

The TTL sets the time-to-live for each RR (resource record) when cached by another server. In this example, an RR will be cached for 3600 seconds (one hour).

The SOA (start of authority) record begins with the name of the server hosting the record and the responsible person. More info (RFC 1034, Section 6.1)

The data enclosed in parenthesis at the end of the SOA record are the serial, refresh, retry, expire, and minimum parameters. Unless you have highly specific needs, you can usually leave these alone with the exception of the serial. The serial number uniquely identifies this version of the record. BIND and other DNS servers will assume that the zone has not changed unless the serial changes. While not a standard, it is generally good practice to have your serial number represent the date/time in some fashion.

The NS records define where the authoritative name servers for this zone can be found. Usually, these will make reference to an A record created a bit further down in the zone, but your NS records can point anywhere you want. For instance, if you are using your hosting provider's servers, you'd put them here.

After your SOA and NS records are created, the zone is pretty free-form. You can put any records you want in any order you want. Comments begin with a semicolon and can be placed at the end of a line or on a line by themselves. Each line begins with a record name. The record name @ refers to the parent domain. For example, neohippie.net. Common records are described below, with a more detailed and complete list available from the BIND 9 Manual: Types of resource records and how to use them and RFC 1035, Section 3.2. Also worth noting is that if you define multiple records of the same type and name, your DNS server will usually serve them in a round-robin fashion, meaning that each time the record is requested, the next one in the list will be returned.

'A' records define direct name-to-IPv4 address lookups. You'll use these as a final destination point for a record. 'CNAME' records define name-to-name mappings for addresses. Use these if you want to create an alias to a name that already exists. Keep in mind, when you use a CNAME record, you're forcing the client to do a second query against the server to retrieve the record you're pointing at. This can lead to delays and higher utilization of your DNS server. 'MX' records define name-to-name mappings for mail servers. These will help other mail servers find yours. 'SRV' records define services available from your domain. These are application specific records that map an application to a host and port.

For more information, the following sources may prove useful.

• Bind 9 Administrator Reference Manual
• RFC 1034: Domain Names - Concepts and Facilities
• RFC 1035: Domain Names - Implementation and Specification