DNS

From HerzbubeWiki
Jump to navigation Jump to search

This page contains general information about the Domain Name System (DNS).


References

http://www.howtoforge.com/traditional_dns_howto
Traditional DNS HOWTO. Essentially shows how to configure an authorative DNS server for one domain. Also provides valuable information to the novice about the basics of DNS, and explains some DNS jargon.
http://en.wikipedia.org/wiki/Domain_Name_System
The main Wikipedia page on DNS
http://en.wikipedia.org/wiki/DNS_zone
Wikipedia page with a good definition of what a DNS zone is. Especially interesting is the section with the example of zone authority in DNS queries
http://en.wikipedia.org/wiki/Zone_file
Wikipedia page with an example of a zone file. This is mainly interesting because it provides some discussion of TTL and the SOA record type.
http://en.wikipedia.org/wiki/List_of_DNS_record_types
Good overview over the different DNS record types.
http://www.dnsstuff.com/reverse-dns-faq
Responsibilities for setting up reverse DNS


Glossary

The terms in this glossary section are not in alphabetical order by design. Hopefully they can be read in order to build up some basic knowledge about DNS.

DNS
Domain Name System
BIND
Berkeley Internet Name Domain. The de-facto reference DNS implementation (includes both server and client).
Resolver
The client side of DNS software
Root server
One of the DNS servers that are at the root of the DNS tree hierarchy. A root server is represented by a period character ("."), e.g. in my own DNS configuration my IP address to name mapping ends with a period character.
TLD
Top Level Domain. Traditional examples are com, net, org, etc. Another set of TLDs are the country-specific ones, for instance ch or de. A third set of TLDs are "new generation" such as info or travel. See the Wikipedia article
Infrastructure TLD
There is exactly one infrastructure TLD, arpa
ccTLD
Country-code TLD. See the Wikipedia article
gTLD
Generic TLD. Any TLD that is not a ccTLD and not the arpa infrastructure TLD. Examples are com and info. Some gTLD such as com or org are unrestricted, i.e. they are available for registrations by any person or organization for any use. Other gTLD such as travel or jobs are restricted, i.e. registrations within them require proof of eligibility within the guidelines set for each.
Authorative server
One of the DNS servers that are authorative for a specific domain (e.g. herzbube.ch). When a domain is registered, at least two authorative DNS servers must be specified to the registrar. The registrar will then delegate responsibility for the domain to the authorative DNS servers. Often the authorative servers are provided by the ISP that hosts the domain, however up until now I have used dyndns.org for that purpose. Note that both primary and secondary DNS servers of a zone are authorative.
Forward resolution
Forward resolution is host name to IP address resolution.
Reverse resolution
Reverse resolution is IP address to host name resolution. Reverse resolution must be configured by whomever controls the IP address - this usually is an Internet provider. The reverse DNS entry is a PTR record that points to a concrete host (i.e. not the "abstract" domain). Wikipedia says the PTR record should point to a "canonical name" (i.e. a CNAME). Stackoverflow has the advice, in relation to MTA configuration, to let the PTR record point to the name that is provided with HELO/EHLO, or more generally that the PTR must point to a name that resolves to the same IP address for which the reverse lookup was made.
named.conf
The main configuration file for BIND. It references "zone" files.
DNS zone
A portion of the global DNS namespace for which administrative responsibility has been delegated. Examples are the root zone, the local zone, or (at the lowest level) any domain such as my personal domain herzbube.ch. See the Wikipedia article. Another explanation attempt: A zone is a domain less any sub-domains delegated to other DNS servers.
Root zone
The zone at the root of the DNS tree hierarchy. This zone is unnamed and represented by a period character ("."). The root zone contains all TLDs. Delegation is handed down to governments and various organizations that administer these TLDs.
Zone file
A text file that describes a portion of the domain name system (DNS) called a DNS zone. See the Wikipedia article
Hints file
One of the zone files. This file contains the names and addresses of the root servers on the Internet.
Local host file
One of the zone files. Name servers are the masters of their own loopback domain (127.0.0.1). The point of creating local zone files for each aspect of your of localhost is to reduce traffic and allow the same software to work on your system as it does on the network.
Primary zone file
One of the zone files. This file, also called the domain database, defines most of the information needed to resolve queries about the domain you administer. It maps names to IP addresses and provides information about the services offered by your Internet computer including your web and ftp server, email, telnet, name servers, etc. The zone file uses several record types, for instance SOA, MX or CNAME.
Reverse zone file
One of the zone files. This file maps IP addresses to host names. It's a mirror image of the primary zone file.
Resource Record (RR)
The basic data element in the DNS. Each record has a type (A, MX, etc.), an expiration time limit, a class, and some type-specific data. This Wikipedia article lists all the possible DNS record types.
SOA
Record type "start of authority"; a SOA record must not refer to a CNAME. The SOA record identifies the primary DNS server of a zone.
NS
Record type "name server"; an NS record must not refer to a CNAME, and it must not use an IP address. NS records identify the authorative DNS servers (primary and secondary) of a zone. It can be said that an NS record delegates a DNS zone to use the given authoritative name server.
A
Record type "address"; maps a host name to an IP address
PTR
Record type "pointer"; maps an IP address to a host name
MX
Record type "mail exchanger"; identifies the mail servers in the domain; an MX record must not refer to a CNAME, and it must not use an IP address.
CNAME
Record type "canonical name"; defines an alias for a host name; a CNAME must always refer to an A record, never to another CNAME (to prevent circular references).
Host name
Refers to a domain name that has one or more associated IP addresses. For instance, herzbube.ch is a host name, whereas ch is not.
Primary DNS server
The server where the master copies of a domain's zone files are located
Secondary DNS server
A server that has slave copies of a domain's zone files, obtained via a zone transfer
Zone transfer
The process of transferring zone files from one system to another, usually from a primary to a secondary DNS server. A DNS server may specify which servers are authorized to do zone transfers.
Non-recursive query
When a DNS server answers authoratively for one of its own domains, without consulting any other DNS server
Recursive query
When a DNS server answers a query by querying other DNS servers
Stub resolver
A simple-minded resolver that relies on a recursive DNS server to perform the work of finding information for them. In contrast, a normal resolver would itself perform each query, iterating through several DNS servers (starting with the root servers) to find the needed information
dig
Domain Information Groper. Command line utility for querying DNS servers.
FQDN
Fully qualified domain name. Sometimes referred to as an "absolute domain name". A domain name that specifies its exact location in the tree hierarchy of the DNS. It specifies all domain levels, including the top-level domain, relative to the root domain. A fully qualified domain name is distinguished by its unambiguity; it can only be interpreted one way. In the DNS, and most notably, in DNS zone files, a FQDN is specified with a trailing period character (".").
TTL
Time to live. A value associated with DNS records that tells clients how long they may cache the record before the authorative DNS server has to be queried again.
Negative Cache TTL
This special TTL, which is defined in the SOA record of a zone, is used for negative responses to queries, i.e. if a query is made for something that does not have a DNS record. The negative response may then be cached for the duration specified by the Negative Cache TTL.
DDNS
Dynamic DNS. If a DNS server allows external clients (e.g. a DHCP server) to dynamically modify its zones.


Questions & Answers

How is DNS organized?
DNS is a distributed database with multiple levels. Level 1 consists of the root servers, level 2 covers the TLDs, and level 3 is usually everything else (although there may be more levels if there are more DNS zones at level 3). A resolver that needs to find the IP address of google.com first queries one of the root servers, which refers the resolver to one of the servers for the TLD com, which finally refers the resolver to the authorative server 216.239.32.10 (ns1.google.com). The last server in the chain can then tell the resolver the actual IP address of google.com.
How does caching work in the DNS environment?
An authorative DNS server (may be primary or secondary) of a zone assigns a TTL to each of its DNS records. The TTL specifies the maximum amount of time other DNS servers and applications should cache the record. They are, of course, free to query the primary DNS server again before TTL has been reached. Setting a DNS record's TTL value to zero, means that applications and DNS servers should not cache the record. When a DNS record is stored in the cache of a DNS server, the record's TTL is continuously reduced as time goes by, and when the TTL finally reaches zero the record is removed from the cache. When a DNS server passes DNS records from the cache along to applications and other DNS servers, it supplies the current TTL value - not the original. This way the original TTL is guaranteed no matter how many DNS servers the record passes through. Most DNS servers will not cache a DNS record for more than one week, regardless of the TTL. Special note on Negative Cache TTL: The last field in a zone's SOA record is the commonly called "Negative Cache TTL". If a query is made for something that does not have a DNS record, the client will receive a no domain or NXDOMAIN response with a Negative Cache TTL. Clients may thus cache negative responses in the same way as they would cache the result of a successful query.
How does recursive querying work?
(Answer copied verbatim from this page) Client applications (such as Internet browsers) typically requests that the DNS server performs recursion for them by setting an RD (Recursion Desired) flag in the request packet. This is a recursive request. Client applications do this both because they do not posses the ability to resolve domain names themselves, and also to take advantage of centralized caching on the DNS server. However, when a DNS server sends requests to other DNS servers as part of the recursion process, these requests are typically non-recursive (the RD flag is not set). The DNS server indicates back to the client if it is willing to perform recursion by setting or not setting an RA (Recursion Available) flag in the DNS response packet. When a DNS server receives a recursive request from a client that it is willing to perform recursion for, it will go through the process of resolving the requested domain name by first asking the root servers, which respond with a referral to the top level DNS servers, then asking one of those servers, which respond with a referral to the next level DNS servers, etc. When a DNS server receives a non-recursive request or a request from a client that it is not willing to perform recursion for, it typically responds immediately with whatever local data it has available at the time without doing any additional processing. [...] A recursive DNS request requires much more processing by the server compared to a non-recursive request. So it is important to only offer recursion to trusted clients.
How can I create a zone for a sub-domain?
A DNS server that is authorative for all records under the "xyz.com" domain can delegate responsibility for the sub-domain "abc.xyz.com" by defining an NS record for that sub-domain. The DNS server referenced by the NS record thus becomes authorative for the sub-domain, which effectively results in a new zone.


DNS record type

This section only covers DNS record types that I have encountered so far.

References:


A and AAAA records

A and AAAA records are "address records". They are what I like to call the "foundational" records of the DNS - they map a name to an IP address. A records map to an IPv4 address, and AAAA records map to an IPv6 address.


CNAME record

"CNAME" is short for "Canonical name". This record type has its own Wikipedia article.

A CNAME record can be seen as a kind of an alias: It maps one name (the alias) to another name (the canonical name). The canonical name does not have to be in the same domain. CNAME records must always point to another domain name, never directly to an IP address.

The typical usages I have for CNAME records are these:

  • A single host provides several services that are accessible under different ports (e.g. web service, SSH service, IMAP service, etc.), or one service provides different content depending on the name under which it is contacted (e.g. web services provides different content for domain 1, domain 2, etc.). In any case, the host is reachable under a given IP address, which is encoded in an A record, while the various CNAME records all point to the A record. If the IP address changes, only the A record needs to be changed.
  • Subdomain services are hosted by different providers. The various subdomain CNAME records thus point to the actual servers run by the service providers.


MX record

"MX" is short for "Mail exchanger". This record type has its own Wikipedia article.

An MX record defines the mail server that is responsible for accepting email messages for a given name. Multiple MX records can be defined for the same name, each pointing to a different mail server.

Each MX record must contain a numeric "priority" value, which is used by sending clients, when faced with multiple MX records, to figure out which mail server they should contact first. Somewhat unintuitively, the mail server with the lowest "priority" value should be contacted first. If several MX records exist with the same "priority" value, then sending clients should try to contact them in a round-robin fashion.


TXT record

"TXT" is short for "Text". This record type has its own Wikipedia article.

A TXT record associates arbitrary text with a host or other name. Originally this was intended for human-readable information (e.g. a description of a server or network, or the address of an organization responsible for a host), but nowadays TXT records are often used to store machine-readable data. The data structure of such a machine-readable TXT record depends on the service it is catering to.

Examples that I know of:

  • SPF records
  • DKIM records
  • DMARC records
  • A record with specific content that is used to prove that one is in control of the domain.


SOA record

"SOA" is short for "Start of authority". This record type has its own Wikipedia article.

A SOA record contains authoritative information about a DNS zone, including the primary name server, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone.

This record is of importance when running a DNS server. See the BIND page on this wiki.

This record is also sometimes encountered when doing DNS lookups, e.g. with Dig. The piece of information that I find most interesting is the name of the primary name server of a domain. This is similar to the information that NS records provide about a domain, but with the difference that SOA records are maintained not by the domain registrar but by the DNS zone provider.


NS record

"NS" is short for "Name server".

The NS records of a domain identify the authorative DNS servers (primary and secondary) of a zone. NS records are defined by the registrar of a domain - the registrar thus delegates responsibility for the DNS management of the domain to the provider of the given authorative DNS servers.

An NS record must not refer to a CNAME, and it must not use an IP address.


Dos and Don'ts

Second-level domain should be an A record

The record that causes the name of the second-level domain (e.g. herzbube.ch) to be resolved should be an A record.

This is a consequence of the rule that a CNAME prohibits any other records for the same name:

  • If the record for the second-level domain were a CNAME, then it would not be possible to have other records for the second-level domain. For instance, it would not be possible to have an MX record.
  • Because an MX record is vital for receiving email for the domain, the converse conclusion is that the second-level domain record must not be a CNAME record.
  • The only other solution for resolving the second-level domain therefore is to define an A record.


Mapping a name to multiple IP addressess (aka round-robin)

Although it is not possible to have a single A record map to multiple IP addresses, it is possible to have multiple A records for the same name, each one mapping to a different IP address.

When the name is queried, the DNS server will return all A records, and the DNS client will then typically use the first of the A records. Ideally a DNS server uses a round-robin scheme when it has multiple A records for the same name, which means it hands out the A records in a different order each time it is queried, thus causing different clients to use different IP addresses.

Also see the Wikipedia article on Round-robin DNS.


CNAME prohibits any other records for the same name

RFC 1034 ("Domain Concepts and Facilities") section 3.6.2 states that:

If a CNAME RR is present at a node, no other data should be present;

Similarly, RFC 1912 ("Common DNS Operational and Configuration Errors") section 2.4 states that:

A CNAME record is not allowed to coexist with any other data.

In other words, if a CNAME record exists for a given name, you cannot have any other record types for the same name. Specifically, you cannot have A, MX, TXT or NS records.

The reason given in RFC 1034 is:

this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.

Having not thought deeply about it, this rationale is unfortunately not very clear to me, so I just accept it as a rule.


MX record should not point to a CNAME record

RFC 2181 ("Clarifications to the DNS Specification") section 10.3 states that

The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias.

The rationale given in the RFC uses many words to say, in my understanding, that if an MX record were to point to a CNAME record, this would cause a lot of additional DNS lookups.


Wildcard MX records

References:


A wildcard MX record maps a name like this "*.example.com" to a mail server. The idea is that clients will try to deliver emails addressed to all subdomain recipients to the given mail server.

A first consideration is, rather obvious, that merely directing mail deliveries for subdomains to a given mail server only works if the receiving MTA is configured to accept messages for those subdomains. If it is not configured, it will refuse the messages.

Less obvious are that, from the point of DNS, there are also rules when a wildcard record matches. The basic rules are specified in RFC 1034, although not clearly, which resulted in differing implementations. RFC 1912 has more clear statements, while RFC 4592 was written (in 2006) to clarify the rules once and for all. Judging from the Wikipedia article, the subject is exceedingly complicated, so my take away for the moment is the one from RFC 1912 which seems sufficiently clear:

A wildcard MX will apply only to names in the zone which aren't listed in the DNS at all.

In other words: For a given subdomain to match the wildcard, it must not have any kind of other DNS record. For instance:

  • foo@www.herzbube.ch: The wildcard MX record would not apply because there is a CNAME for www.herzbube.ch. The regular MX record for "herzbube.ch" would also not apply, because the message was addressed to www.herzbube.ch. The result would be that the message could not be delivered.
  • foo@bar.herzbube.ch: The wildcard MX record would apply because there is no DNS record for bar.herzbube.ch. The result would be that the a client would attempt to deliver the message to my dedicated server, but the server would refuse the message because it is not configured to accept messages for bar.herzbube.ch.
Retrieved from "https://wiki.herzbube.ch/index.php?title=DNS&oldid=7121"