DNS record types

From FreeBSDwiki
Jump to: navigation, search

There are several record Types which can be recorded in one of named's zone files. Here are some of the most commonly seen / needed, with examples:


SOA record

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.   IN SOA (
                             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 record

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, and are authoritative for the dynamically generated subdomain, but we can probably presume that they're also authoritative for the parent domain, 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

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 record

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 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
                            MX      10

A record

A records are also known as host records. These are the records that tie resolvable DNS names, such as, to dotted-quad IP addresses, such as 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 that matches the one at, 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 over to the one used in if the dsl should go down.

$TTL 10 ; 10 seconds
$TTL 10 ; 10 seconds
dsl                         A
satellite                   A

AAAA record

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.

CNAME record

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 with an IP and a CNAME record for referring to the A record. Therefore if the IP of ever changed the would automatically be the same IP, conversely the address could not be changed unless the A record for changed or it was recreated with its own A record.

See also:

named.conf BIND (dynamic DNS) BIND (configuring)

Personal tools