All about DNS records


DNS is essentially a distributed database, and as with every DB, thisone too has different data types. On a very low level, DNS is a binary protocol; This protocol is usually abstracted away when displaying the records, for instance by using a BIND-style record syntax:

 Time To Live (TTL)    class
 ------------+-----    ,----
             |        /
             |       /
domi.sh.    3600    IN  TXT     "meow"
|       \________       \_____   \________
|       canonical       record    contents
\_____        dot         type
domain

Domain

As described in DNS Basics, DNS is divided into a hierarchy of zones. To be used on the public internet, your domain will need to consist of the canonical dot (signifying the root zone), a TLD (Top-Level Domain), and a name of your chosing. Optionally, one can also use subdomains for deeper levels of division.

Canonical dot is important to specify, because the default behavior for records without it is to append the zone onto the end; Assuming that our zone is example.org., that would mean:

asdf.example.org  -> asdf.example.org.example.org.
asdf.example.org. -> asdf.example.org. ; (proper trailing dot)

Time To Live

This field tells a DNS resolver for how long to cache the current value of the record.

High TTLLow TTL
ProsLower latency on later requestsQuicker propagation of changes
ConsSlower propagation of changesPossible higher latency

Class

DNS classes are one of the least used features of DNS; In most cases, this field will be set to IN, meaning Internet. Other possible classes include CH (Chaos) and HS (Hesiod); See RFC6895, page 12 for more details.

Record type

Defines the type of the data following in the next field. Common record types are listed lower in the document.

Contents

Depending on the record type, this may be an IP address, a domain, a string or another specified data type. In BIND-style syntax this is the last field on the line, which doesn't prohibit it from having unescaped spaces

Wildcard records

Normally, defining a record for the root of your zone doesn't touch the subdomains at all; That is to say, if you wanted to operate example.org., but also wanted ftp.example.org. to point to the same address, you'd need to define two separate records:

example.org.		3600	IN	A	127.0.0.1
ftp.example.org.	3600	IN	A	127.0.0.1

This is fine if you have one subdomain, but adding standalone records gets tedious quick, especially if you're adding both A and AAAA records for dual-stack purposes. The solution is to use a wildcard record:

example.org.		3600	IN	A	127.0.0.1
*.example.org.		3600	IN	A	127.0.0.1

This will result in all names directly under example.org. to be served this specific record. Of note, wildcards only work on one level, so meow.meow.example.org. wouldn't get the record.

Furthermore, if you define a wildcard record and then create any record on the same level as the wildcard, the wildcard won't be valid for that record, even for differing record types:

example.org.		3600	IN	A	127.0.0.1
*.example.org.		3600	IN	A	127.0.0.1
a.example.org.		3600	IN	TXT	"meow"    ; querying `A` for `a.example.org` would return empty

This behavior is often surprising for new hostmasters. Beware!

CNAME and ALIAS/ANAME

CNAME is a record specifying "for this domain, See Name another domain". It is often used like this, to avoid repetition:

example.org.		3600	IN	A		127.0.0.1
*.example.org.		3600	IN	CNAME	example.org.

CNAME records cannot be used in the root of your zone; This is due to the nature of how they work - it would override the SOA (Start Of Authority) record, which could cause trouble with resolving and propagation of your domain.

Instead, PowerDNS provides an internal ALIAS (also called ANAME) type. ALIAS isn't a real DNS record type - the authoritative server (that's us) takes it and resolves the query directly, then returns the returned value. This is transparent to the client, and can be implemented like so:

example.org.		3600	IN	ALIAS	example.net.
*.example.org.		3600	IN	CNAME	example.org.

Other common record types

(TODO)