Understanding DNS and DNS Records
Introduction to Domain Name Server
I have seen many experienced developers and system administrators that have not dealt with network settings are confused about Domain Name Server (DNS) settings. This is especially true if you are trying to set up your mail server or web server and configure your DNS settings to correctly direct the traffic. They are often struggling with various record types and when to add what kind of records.
This mail is to simplify these matters for newbies and even for some experienced admins.
The Domain Name System (DNS) is the Internet’s address book. DNS directs web traffic to your server and email to your inbox by mapping memorable domain names like fieldforcetracker.com to its IPv4 or IP v6 addresses like 173.42.16.8 or 123:4567:89ab:cdef:0123:4567:89ab:cdef.
This guide introduces basic DNS concepts and the different types of DNS records.
How DNS Works
Before adding any DNS records, you should learn the basics of DNS. You’ll start by dissecting a domain name, and then you’ll learn about the mechanics of DNS resolution, including name servers, zone files, and individual DNS records.
Domain Names
Domain names are best understood by reading from right to left. The broadest domain classification is on the right, and becomes more specific as you move to the left. In the examples below, the top-level domain, or TLD, is .com.
example.com
mail.hello.example.com
Every term to the left of the TLD and separated by a period is considered a more specific subdomain, although conventionally, first-level subdomains plus their TLDs (example.com) are referred to as “domains.” Moving to the left, hello and mail are the second- and third-level subdomains, respectively. Typically, subdomains are used to uniquely identify specific machines or services, but this is left up to the domain owner.
Name Servers
Choosing and specifying name servers is an essential part of domain ownership. If you don’t, the Internet won’t know where to find your DNS information, and your domain won’t resolve. Name servers host a domain’s DNS information in a text file called the zone file. They’re are also known as Start of Authority (SOA) records. You can host your DNS information on name servers in one of several locations:
- Your Server Provider
- Your Domain registrar
- Your own DNS server
- Third-party DNS hosting
Using Your Provider’s free name servers is the easiest approach, because it provides a default zone file with all the right IP addresses for your website and email. For basic DNS setups and many advanced ones, Your Provider’s name servers will work beautifully. However, you can also look into the options offered by your registrar and third-party DNS hosts, or host your own DNS if you want to take control of as much of the DNS process as possible.
You’ll specify name servers on your domain registrar’s website. They’ll take care of publishing that information to the higher-level name servers. You’ll want to specify at least two name servers. That way, if one of them is down, the next one can continue to serve your DNS information.
Zones and Records
Before we dive into various types of DNS records, it is important to understand the distinction and concept DNS Zones and DNS Records.
A DNS Record is a single entry that gives the zone instructions on how to handle any given request based on type. There are many types of DNS Records, but the ones you are most likely to encounter or need to use are:
- A Records
- CNAMES
- MX Records
- TXT Records
- SPF Records
Each individual DNS record is assigned a type and information needed for that type of record.
A DNS Zone is like a container of all the DNS records for a specific domain and only that domain. For example: fieldforcetracker.com, www.fieldforcetracker.com, blog.fieldforcetracker.com, and mail.fieldforcetracker.com are four DNS Records inside a single DNS Zone for fieldforcetracker.com.
DNS Records and Zone Files
The next aspect of DNS management is specifying DNS records, which actually match domain names to IP addresses. The DNS records are then automatically bundled up into a zone file, which is what allows the Internet to look up the correct IP address for your domain. If you decide to use Your Provider’s name servers, our DNS Manager will help you create a default zone file. It contains records similar to the following:
; example.com [448369]
$TTL 86400
@ IN SOA ns1.linode.com. admin.example.com. 2013062147 14400 14400 1209600 86400
@ NS ns1.linode.com.
@ NS ns2.linode.com.
@ NS ns3.linode.com.
@ NS ns4.linode.com.
@ NS ns5.linode.com.
@ MX 10 mail.example.com.
@ A 198.71.53.185
mail A 198.71.53.185
www A 198.71.53.185
Every domain’s zone file contains the admin’s email address, the name servers, and the DNS records. Of course, you are not limited to these default entries. You can create a variety of DNS records for as many different subdomains as you wish.
Types of DNS Records
A and AAAA
A Records are the most basic type of DNS record and are used to point a host name in a domain or subdomain to an IP address. More precisely, ( A) records specify mapping of hosts name to IP addresses. Domains contain host records (and other resource records). Host records point to IP addresses.
Assigning a value to an A record is as simple as providing your DNS management panel with an IP address to where the domain or subdomain name should point and a TTL.
An A record matches up a domain (or subdomain) host to an IP address. In other words, it points your domain name to your Your Provider’s IP address, which allows web traffic to reach your server. This is the core functionality of DNS. A typical A record looks like the following:
example.com A 198.71.53.185
You can also make A records for subdomains you want to direct to your server:
hello.example.com A 198.71.53.185
Note
You can point different subdomains to different IP addresses.
If you want to point every subdomain of example.com to your Your Provider’s IP, you can use an asterisk (***) as your subdomain:
*.example.com A 198.71.53.185
An AAAA record is just like an A record, but for IPv6 IP addresses. A typical AAAA record looks like the following:
example.com AAAA 0123:4567:89ab:cdef:0123:4567:89ab:cdef
AXFR
An AXFR record is a type of DNS record used for DNS replication, although there are also more modern ways to do DNS replication. AXFR records are not used in ordinary zone files. Rather, they are used on a slave DNS server to replicate the zone file from a master DNS server. For an example of how to configure Your Provider’s name servers as slave DNS servers using AXFR,
CAA
DNS Certification Authority Authorization uses DNS to allow the holder of a domain to specify which certificate authorities are allowed to issue certificates for that domain.
CNAME
A CNAME record is an alias for an (A) record. It points to another host record.
CNAME records are another commonly used type of DNS entry and are used to point a domain or subdomain host to another hostname.
A CNAME record or Canonical Name record matches up a domain (or subdomain) to a different domain. With a CNAME record, DNS lookups use the target domain’s DNS resolution as the alias’s resolution. Here’s an example:
alias.com CNAME example.com.
example.com A 198.71.53.185
With this setup, when alias.com is requested, the initial DNS lookup will find the CNAME entry with the target of example.com. A new DNS lookup will be started for example.com, which will find the IP address 198.71.53.185. Finally, visitors to alias.com will be directed to 198.71.53.185.
CNAME records exist so that domains can have aliases. You should not use a CNAME record for a domain that gets email, because some mail servers handle mail oddly for domains with CNAME records. Likewise, MX records cannot reference CNAME-defined hostnames. Also, the target domain for a CNAME record should have a normal A-record resolution. Chaining or looping CNAME records is not recommended.
Note
In some cases, a CNAME record can be an effective way to redirect traffic from one domain to another while keeping the same URL. However, keep in mind that a CNAME record does not function the same way as a URL redirect. A CNAME record directs web traffic for a particular domain to the target domain’s IP address. Once the visitor reaches that IP address, the local Apache (or other web server) configuration will determine how the domain is handled. If that domain is not configured on the server, the server will simply display its default web page (if any). This may or may not be the web page for the target domain in the CNAME record, depending on how the server is configured.
DKIM
A DKIM record or domain keys identified mail record displays the public key for authenticating messages that have been signed with the DKIM protocol. This practice increases the capability to check mail authenticity. A typical DKIM record looks like the following:
selector1._domainkey.example.com TXT k=rsa;p=J8eTBu224i086iK
DKIM records are implemented as text records. The record must be created for a subdomain, which has a unique selector for that key, then a period (.), and then _domainkey.example.com. The type is TXT, and the value includes the type of key, followed by the actual key.
Generating DKIM with Google Mail Verification
You can help prevent spoofing by adding a digital signature to outgoing message headers using the DKIM standard. This involves using a private domain key to encrypt your domain’s outgoing mail headers, and adding a public version of the key to the domain’s DNS records. Recipient servers can then retrieve the public key to decrypt incoming headers and verify that the message really comes from your domain and hasn’t been changed along the way.
How DKIM works
To add a digital signature to outgoing mail, you generate a domain key that Google Suite uses to create signed mail headers that are unique to your domain. You add the public key to the Domain Name System (DNS) records for your domain. Recipients can then verify the source of a mail message by retrieving your public key and using it to confirm your signature.
For enhanced security, you can now generate a 2048-bit domain key instead of a 1024-bit domain key. We recommend that you generate the stronger 2048-bit key if your registrars support the longer key length.
If you have a previously-generated 1024-bit domain key, it will not be affected by this change.
Overview of steps
Repeat these steps for each domain associated with your G Suite account.
- Generate the public domain key for your domain.
- Add the key to your domain’s DNS records so recipients can retrieve it for reading the DKIM header.
- Turn on email signing to begin adding the DKIM header to outgoing mail messages.
Skip the first 2 steps if you purchased your domain from one of our domain host partners while signing up for Google Suite. Google automatically generates the domain key and adds the necessary DNS record when you turn on authentication.
GLUE RECORDs
A glue record is simply the association of a hostname (nameserver, or DNS) with an IP address at the registry. This is only needed if you are setting your own DNS. If you are running a single server or a few servers then you can use your provider’s DNS and no need to bother about it.
The simplest solution for a handful of servers would be to use your domain providers name servers to server as your name servers. Just configure your domain(s) with an A record for the website.
You only need to configure glue records if your are running your own name server. Even then you only to configure them, if the nameserver’s domain is the domain or a sub-domain that you are configuring. (Only one of your five domains should need you to configure glue records. The others should use the name server domains, of the domain that requires glue records.
Remember, the GLUE record provide the IP address for the name servers. It is necessary to provide them if the name server’s name is a sub-domain of the domain they are a name server for.
For example ns1.example.com needs a glue record when it is the name server for example.com. However, if it is the name server for example.net a glue record does not need to be provided to the domain registrar.
When to use glue records
Glue records are needed when you want to set a domain’s nameservers to a hostname that is a subdomain of the domain itself.
In such a scenario, if you do not provide the registry with glue records, other nameservers trying to look up the IP address of example.com would ask the .com nameservers for a referral, thus encountering the catch-22 :
Glue records are created at the registrar of the domain name.
If your domain name is registered with Gandi, there are two different ways of creating a glue record, depending on the TLD.
The most common TLDs will allow you to create your glue record directly from your domain’s control panel; just click on the “Glue record management” link (in the lower right-hand corner in the “Name servers” section).
Examples of valid glue records
Let say you have accompany called – britas. It’s default nameservers have the following glue records:
a.dns.britas.com 212.64.22.11b.dns.britas.com 217.70.184.12c.dns.britas.com 217.70.182.13
In this example, the host name a.dns.britas.com is registered at Verisign (the top level registry for .com) as pointing to the machine 212.64.22.11.
Therefore, when requests are made by a domain name that use a.dns.britas.com as a nameserver, a.dns.britas.com will send the request to the DNS server hosted on the machine called 212.64.22.11 which will tell it what to do.
MX
Mail Exchanger (MX) records are used to help route email according the domain owners preference. The MX record itself specifies which server(s) to attempt to use to deliver mail to when this type of request is made to the domain. They differ from A Records and CNAMEs in the way that they also require a “priority” value as a part of their entry. The priority number is used to indicate which of the servers listed as MX records it should attempt to use first.
An MX record or mail exchange record sets the mail delivery destination for a domain (or subdomain). A typical MX record looks like the following:
example.com MX 10 mail.example.com.
mail.example.com A 198.71.53.185
The above records direct mail for example.com to the mail.example.com server. The target domain (mail.example.com above) needs to have its own A record that resolves to your Linode. Ideally, an MX record should point to a domain that is also the hostname for its server.
Your MX records don’t necessarily have to point to your Linode. If you’re using a third-party mail service, like Google Apps, you should use the MX records they provide.
Priority is another component of MX records. This is the number written between the record type and the target server (10 in the example above). Priority allows you to designate a fallback server (or servers) for mail for a particular domain. Lower numbers have a higher priority. Here’s an example of a domain that has two fallback mail servers:
example.com MX 10 mail_1.example.com
example.com MX 20 mail_2.example.com
example.com MX 30 mail_3.example.com
In this example, if mail_1.example.com is down, mail will be delivered to mail_2.example.com. If mail_2.example.com is also down, mail will be delivered to mail_3.example.com.
NS
NS records or name server records set the nameservers for a domain (or subdomain). The primary nameserver records for your domain are set both at your registrar and in your zone file. Typical nameserver records (you need at least two) look like this:
example.com NS ns1.linode.com.
example.com NS ns2.linode.com.
example.com NS ns3.linode.com.
example.com NS ns4.linode.com.
example.com NS ns5.linode.com.
The nameservers you designate at your registrar then carry the zone file for your domain.
You can also set up different nameservers for any of your subdomains. Subdomain NS records get configured in your primary domain’s zone file. For example, if you’re using Your Provider’s nameservers, you could configure separate NS records in your Linode zone file for the subdomain mail.example.com as shown below:
mail.example.com NS ns1.nameserver.com
mail.example.com NS ns2.nameserver.com
Primary nameservers get configured at your registrar; secondary subdomain nameservers get configured in the primary domain’s zone file. The order of NS records does not matter; DNS requests are sent randomly to the different servers, and if one host fails to respond, another one will be queried.
PTR
A PTR record or pointer record matches up an IP address to a domain (or subdomain), allowing reverse DNS queries to function. It performs the opposite service an A record does, in that it allows you to look up the domain associated with a particular IP address, instead of vice versa.
PTR records are usually set with your hosting provider. They are not part of your domain’s zone file. This means that you’ll always set reverse DNS for your servers with your server provider, even if your nameservers are elsewhere. Likewise, if you have servers somewhere else but are using Your Provider’s nameservers, you will still have to set up your PTR records with your hosting provider.
As a prerequisite for adding a PTR record, you need to create a valid, live A or AAAA record that points the desired domain to that IP. If you want an IPv4 PTR record, point the domain (or subdomain) to your Your Provider’s IPv4 address. If you want an IPv6 PTR record, point the domain to your Your Provider’s IPv6 address. Beyond that, IPv4 and IPv6 PTR records work the same way.
For instructions on setting up reverse DNS on your Linode, see our Reverse DNS guide.
Note
It’s possible to have different IPs (including both IPv4 and IPv6 addresses) that have the same domain set for reverse DNS. To do this, you will have to configure multiple A or AAAA records for that domain that point to the various IPs.
SOA
An SOA record or Start of Authority record labels a zone file with the name of the host where it was originally created. Next, it lists the contact email address for the person responsible for the domain. There are also various numbers, which we’ll get into in detail in a moment. First, here’s a typical SOA record:
@ IN SOA ns1.1and1.com. admin.example.com. 2013062147 14400 14400 1209600 86400
Note
The administrative email address is written with a period (.) instead of an at symbol (<@>).
Here’s what the numbers mean:
- Serial number: The revision number for this domain’s zone file. It changes when the file gets updated.
- Refresh time: The amount of time (in seconds) a secondary DNS server will keep the zone file before it checks for changes.
- Retry time: The amount of time a secondary DNS server will wait before retrying a failed zone file transfer.
- Expire time: The amount of time a secondary DNS server will wait before expiring its current zone file copy if it cannot update itself.
- Minimum TTL: The minimum amount of time other servers should keep data cached from this zone file.
The single nameserver mentioned in the SOA record is considered the primary master for the purposes of Dynamic DNS and is the server where zone file changes get made before they are propagated to all other nameservers.
SPF
An SPF record or Sender Policy Framework record lists the designated mail servers for a domain (or subdomain). It helps establish the legitimacy of your mail server and reduces the chances of spoofing, which occurs when someone fakes the headers on an email to make it look like it’s coming from your domain, even though the message did not originate from your Linode. Spammers sometimes try to do this to get around spam filters. An SPF record for your domain tells other receiving mail servers which outgoing server(s) are valid sources of email, so they can reject spoofed email from your domain that has originated from unauthorized servers. A very basic SPF record looks like the following:
example.com TXT “v=spf1 a ~all”
In your SPF record, you should list all the mail servers from which you send mail, and then exclude all the others. Your SPF record will have a domain or subdomain, type (which is TXT, or SPF if your name server supports it), and text (which starts with “v=spf1” and contains the SPF record settings).
If your Linode is the only mail server you use, you should be able to use the example record above. With this SPF record, the receiving server will check the IP addresses of both the sending server and the IP address of example.com. If the IPs match, the check passes. If not, the check will “soft fail” (i.e., the message will be marked but will not automatically be rejected for failing the SPF check).
Note
Make sure your SPF records are not too strict. If you accidentally exclude a legitimate mail server, its messages could get marked as spam. We strongly recommend visiting openspf.org to learn how SPF records work and how to construct one that works for your setup. Their examples are also helpful.
Update an SPF record with multiple servers
Multiple SPF records are not recommended and will cause authorization problems. Instead, update the existing record from your provider.
You can update your domain’s existing SPF record to authorize a new or additional mail server. For example, if you set up an outbound email gateway, your SPF record will include the G Suite server address and the outbound gateway SMTP server address.
To add a mail server to an existing SPF record, enter the server’s IP address before the ~all argument using the format ip4:address or ip6:address. For example:
v=spf1 ip4:172.16.254.1 include:_spf.google.com ~all
To add a mail server’s domain, use additional include statements for each domain. For example:
v=spf1 include:serverdomain.com include:_spf.google.com ~all
The word “include” above refers to include the spf records of your email provider.
SRV
An SRV record or service record matches up a specific service that runs on your domain (or subdomain) to a target domain. This allows you to direct traffic for specific services, like instant messaging, to another server. A typical SRV record looks like the following:
_service._protocol.example.com SRV 10 0 5060 service.example.com
Here’s a breakdown of the elements in an SRV record:
- Service: The name of the service must be preceded by an underscore (_) and followed by a period (.). The service could be something like _xmpp.
- Protocol: The name of the protocol must be proceeded by an underscore (_) and followed by a period (.). The protocol could be something like _tcp.
- Domain: The name of the domain that will receive the original traffic for this service.
- Priority: The first number (10 in the example above) allows you to set the priority for the target server. You can set different targets with different priorities, which allows you to have a fallback server (or servers) for that service. Lower numbers have a higher priority.
- Weight: If two records have the same priority, weight is used instead.
- Port: The TCP or UDP port on which the service runs.
- Target: The target domain or subdomain. This domain must have an A or AAAA record that resolves to an IP address.
An example use of SRV records would be to set up Federated VoIP.
TXT
A TXT record is used to store any text-based information that can be grabbed when necessary. We most commonly see TXT records used to hold SPF data and verify domain ownership.
A TXT record or text record provides information about the domain in question to other resources on the Internet. It’s a flexible type of DNS record that can serve many different purposes depending on the specific contents. One common use of the TXT record is to create an SPF record on nameservers that don’t natively support SPF. Another use is to create a DKIM record for mail signing.
The rule of thumb for TXT records is that they require a an attribute name, follow by an equals sign, followed by a value for the attribute. You can use this to relay any sort of information you’d like using a DNS record, so long as you have a purpose for it and the record is properly formatted.
More Information
Managing your own DNS can be a tricky endeavor, especially if you haven’t ever considered what this means or ever even seen a DNS record.
Ideally, this articls will help you understand the general how a website’s DNS works for a domain from the time it is typed into the browser to the time your name servers handle the request..
