DNS record types
Start Of Authority record. This is the first record in any given zone file, which lays out what the zone is, who owns it, who gets notified about it, what version it currently is, and how often it needs to be checked up on / purged from cache / you name it.
dynamic.domain.net IN SOA ns1.domain.net. hostmaster.domain.net. ( 34 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 10 ; minimum (10 seconds) )
Note that the minimum TTL value is set extremely short on this example - this particular zone is intended for frequent dynamic updates, so the TTL is kept very very short to allow updates to ripple out over the internet faster. A normal, static zone that wouldn't be expected to change often if at all might have a minimum TTL of a day or more - it's a balancing act of saving CPU and network overhead (which is usually not a big concern for DNS, unless you're running a large enterprise-level nameserver) versus the convenience and flexibility of quickly-rippled updates when a dynamically generated IP changes, or even if your domain goes from one ISP to another one. (Something to keep in mind if you know ahead of time when you're going to make the move - make sure you aren't still kicking out week-long TTLs the last few days before you move, or people aren't going to be able to find your new address for days!)
NS records define the nameservers responsible for handing out information about the domain: in most cases, they'll be the nameservers defined either on the current domain or its immediate parent; in this example, ns1.domain.net and ns2.domain.net are authoritative for the dynamically generated subdomain dynamic.domain.net, but we can probably presume that they're also authoritative for the parent domain, domain.net. IMPORTANT: you need to remember that NS records point to A records, not directly to IP addresses! If you try to point an NS record directly to an IP address, your zone will fail. (We'll cover A records shortly.)
$TTL 3600 ; 1 hour NS ns1.domain.net. NS ns2.domain.net.
Note that the TTL is defined for our nameservers as noticeably longer than it was for the SOA record above: that's because we can expect them to stay where we put them. You may actually want to make the TTL considerably longer for nameservers; consider a TTL of 604800 seconds (that is, a week) - just remember if you know ahead of time that you've got an IP change coming up, you need to temporarily shorten that TTL up before the deadline gets to you, or people aren't going to be able to resolve you! You can extend the TTL back out again once you're safely moved to the new address and don't expect to go anywhere for a while.
MX records define which servers handle the email for a domain. Like NS records, they point to A records, not directly to IP addresses, so typically you'll want a longer TTL for your MX'es - even on dynamic domains. This might seem counterintuitive, since the mailserver itself might be changing IP addresses all the time... but since the MX record doesn't point directly to the IP address, the MX record doesn't need to change when the IP changes. Again, if you have any real load on your box, you might consider a TTL of a week here - even on a dynamic domain such as our example.
Notice that there's a numerical argument on our MX records that wasn't there on the NS records - that's the priority of each MX. Mail will be delivered preferentially to the records with lower priority numbers; if there are two records with the same priority, the mail will be delivered semi-randomly to whatever machine gets lucky.
In our dynamic.domain.net example, here, both of these records actually point to the same machine, which is accessible via two different ISPs through a multi-homed router. The DSL is much lower latency than satellite and considerably more reliable, so it is set with a lower priority argument - the satellite address won't have mail routed to it at all unless the dsl address becomes unreachable.
In other environments, multiple records often do point to multiple mailservers - sometimes many servers with equal priority serve to share the load of spam filtering before delivery to the "real" mailserver behind them; or sometimes a backup server is put online with a higher priority number simply to catch the mail if and when the "real" mailserver goes down, to hold on to it until the "real" mailserver comes back online.
$TTL 3600 ; 1 hour MX 5 dsl.dynamic.domain.net. MX 10 satellite.dynamic.domain.net.
A records are also known as host records. These are the records that tie resolvable DNS names, such as dynamic.domain.net, to dotted-quad IP addresses, such as 22.214.171.124. In our example dynamic domain, we keep the TTL very short on both the A records and the SOA record for the domain, to make sure that in the event of one of our frequent IP changes there won't be a long wait for third-party DNS servers to get rid of their cached copy of the record and load the updated one.
Notice that in this example, there is a line with no hostname in front of it - that's because unless specified otherwise, we're still operating under the default $ORIGIN implied in the original SOA record above. So what we see below is an A record for dynamic.domain.net that matches the one at dsl.dynamic.domain.net, because the administrator figures he's going to be giving that one out a lot more often - and he might even have a fancy trick up his sleeve, like automatically failing the IP address for dynamic.domain.net over to the one used in satellite.dynamic.domain.net if the dsl should go down.
$TTL 10 ; 10 seconds A 126.96.36.199 $ORIGIN dynamic.domain.net. $TTL 10 ; 10 seconds dsl A 188.8.131.52 satellite A 184.108.40.206
This is the same as an A record but used for resolving host names to IPv6 addresses.
The four 'A's are a play on the fact that a single A record resolves a 32bit IPv4 address and so 4 lots of A, or 4 lots of 32 bits, gives an AAAA record that resolves to a 128bit IPv6.
The canonical name record is similar to an A record in that it refers to a physical system however it uses an established A record to resolve against. It's like an alias. For example a server acting as both a mail server and a web server could have an A record for mail.domain.net with an IP 220.127.116.11 and a CNAME record for www.domain.net referring to the mail.domain.net A record. Therefore if the IP of mail.domain.net ever changed the www.domain.net would automatically be the same IP, conversely the www.domain.net address could not be changed unless the A record for mail.domain.net changed or it was recreated with its own A record.