Special thanks to /u/releenc for reaching out to me and writing this edition of Homelab Basics. This edition is a bit longer than my other ones, but is very informative because he is a "DNS Professional" and explains the concepts very thoroughly.
Homelab Basics - DNS
By Robert Lee, /u/releenc on Reddit
DNS (the Domain Name System) is one of the most important and fundamental network services used by everyone on the Internet. Unfortunately it is also one of the most widely misunderstood and misconfigured. The meme used among IT people troubleshooting problems that “It’s always DNS” is so pervasive because it’s true. In my 30 years of experience, if you cannot connect to something and there is not a network hardware error, it’s (almost) always DNS.
The function of DNS is relatively simple. When a network device, like a PC, a smartphone, or anything else needs to contact another network device, it must do so using the IP address of that device. We as humans prefer to use addresses that are words rather than numbers, so we use DNS to lookup the IP address that corresponds to a particular name, generally called the host name of that device. That’s it.
The standards for DNS operation are defined across dozens of Internet Engineering Task Force (IETF) Request for Comments (RFC) documents. However, the key official standards are RFC-1034, RFC-1035, RFC-1123, and RFC-2181.
* Disclaimer – This article is assumed to systems and devices using Internet-standard TCP/IP networking. These are standard on modern operating systems such as Windows, Unix/Linux, Macintosh OSs, iOS, Android, etc. There are other older networking schemes and operating systems such as IPX (Netware), NetBIOS(older Windows), AppleTalk (older Macs), etc. that are not within the scope.
* Disclaimer 2 – The documentation is this article is based on IPv4 addressing schemes, using 32-bit IP addresses. Although DNS works very similarly for IPv6, there may be differences not stated or clarified here.
Within DNS text-based host names use the standard of <host>.<domain>.<top-level domain extension>. An example could be server.foo.org. There could also be multiple sub-domains between the host and domain, each separated by periods. (eg. server.north.west.foo.org) To be a valid Internet address, the TLD extension must exist and the domain name must be registered. These are all considered to be fully-qualified device/host names (FQDN).
On a private local network, any combination is permissible. It is also possible to use non-qualified host names such as just “server”. However, these must be resolved either through the use of hosts files (see below) or through configuring the device with a domain search suffix list.
When a network device needs to find the IP address of another device by name, it sends a query to the first DNS server it has listed in the IP configuration of its network adapter. That server should do one of four things - provide the address from its own DNS records, provide the IP address from its local cache of previous queries, forward the lookup to another DNS server, or return “address not found” to the device making the request.
Device IP Configurations
Before we move on to discuss DNS lookups further, it’s important to understand IP configurations. Any network adapter supporting IP (IPv4) in a computer or other network device must be configured to include 4 pieces of information. (One PC can have multiple network adapters supporting IP. Each must have its own configuration.)
- The IP address associated with the network adapter.
- The netmask for the local network. (This determines which other IP addresses are on the same local network as this device. Traffic for all other devices is sent to the default gateway.)
- The IP address of the default gateway. (This must be on the same local network as this device’s IP address. All traffic for any other network is sent to this device.
- A list of one or more DNS servers.
This information may be manually configured on the device. This results in a static IP address for the device. The information may also be assigned to the device by a DHCP (dynamic host configuration protocol) server or an older, now deprecated BOOTP (bootstrap protocol) server. With many operating systems it is possible to get the first three items from DHCP or BOOTP, but assign the DNS server(s) manually. One additional advanced configuration item is the domain search suffix list (referenced above), which is a list of <subdomain>.<domain>.<TLD> that should be used for DNS queries when a non-qualified host name is looked-up.
So back to DNS lookups, it’s very important to note that if the DNS server responds with “address not found”, the lookup will fail. Your device WILL NOT attempt to query other DNS servers listed in its IP configuration. This is one of the most fundamental mistakes made by people configuring DNS lookups. An alternate server will never be queried unless all other servers in the list before it fail to respond to the query. The primary DNS server should always be one that can provide EVERY address you expect to lookup or forward the request to another server that can.
In addition to DNS there is an older, more basic name lookup function available on most PC-based operating systems supporting IP. (This is usually not available on devices like phones, SmartTVs, IoT devices, etc.). A file named “hosts”, that resides in “/etc/hosts” in most Unix/Linux OSes or in “\Windows\System32\drivers\etc\hosts” on Windows, contains a simple list of “IP Address” “hostnames”. A unique IP address must begin each line, separated by a tab or space from the hostname. Additional host names or aliases for the same IP address may be added to the same line, separated by a tab or space. This allows you to specify both qualified and non-qualified host names.
When looking-up an IP address, a device supporting hosts files always checks it first, before querying DNS. This allows you to override DNS by specifying what you want in hosts. This is also a key issue when troubleshooting unexpected DNS problems. The troubleshooter should always check to see if a hosts file is present to ensure it is not overriding DNS.
DNS Server Configurations
DNS servers are configured for two basic tasks:
- Accept and respond to queries. Forward or find another server those that it doesn’t have a response for.
- Host a database of host records for devices that it is responsible for.
The first task requires minimal configuration. The server accepts the query and checks its local database for the host. If it doesn’t host the DNS record for the queried host, it checks it cache of previous lookups to see if the result exists there. If the result is not in the cache, it forwards the query to another DNS server (if defined). This server is caller a forwarder (see below). Alternatively, the “root-hints” can be used to find the appropriate DNS server to respond to a particular query. Note that using forwarders or “root-hints” are generally mutually exclusive. Use one or the other.
A standard configuration setting on any DNS server is the next DNS server to forward a query to if it does not contain the information to complete the query from its local database or cache. This has typically been the primary DNS server of the service provider or the next tier up. However, recently it has become standard to use DNS servers from specialized providers that are faster, prevent name lookup censors, or block queries for risky sites. These include servers like Cloudflare (22.214.171.124), Google (126.96.36.199), Quad9 (188.8.131.52), OpenDNS, and others. Note that a DNS server can configure a list of multiple forwarders, but much like the list of multiple DNS servers back on the IP Configuration settings, only the first in the list is used, unless it completely fails to reply. Queries are NOT sent to another forwarder if the lookup is not found. It is still important to have a list of multiple servers. Without a list if server is down, it is likely that external DNS lookups will fail.
Almost all DNS servers include a pre-configured list of DNS servers that are defined as “authoritative” for each of the TLDs on the Internet. If forwarders are not used, root-hosts can be used to find an authoritative server for the domain of the hostname being looked-up. If the server cannot be found or does not contain the hostname, the DNS server will reply with “address not found”.
Forwarders vs. Root Hints - Performance Considerations
Forwarders and Root Hints use different query types. Forwarders use recursive queries while root-hints uses referential queries. With recursive queries, a DNS server queries its forwarder. If that DNS server does not have a local response it queries its forwarder. This continues server-to-server until a response is found or the host is not found. The results are passed back down the line server-to-server to the original query. With referential queries the server either responds or says “I don’t own the domain, check with server x”. The local DNS server then reissues a query to server x, which either responds or points to yet another server. Your local DNS server must continue to issue queries until until it gets a response or the server replies “I own that domain and the host does not exist.” In general this makes the use of forwarders faster and less CPU intensive on your local server. However, forwarders can respond with records in their local cache from previous lookups. This means the response they provide may not be the most up-to-date. (See TTL below.)
An authoritative server is the DNS server that is the “official” host of the records for a particular domain. Within the realm of the public Internet DNS, the name(s) of the authoritative DNS server(s) are a part of the domain registration record managed by the Registrar. Big companies generally have Internet-facing DNS servers that they manage which are defined as authoritative for their domains. Many smaller domains have authoritative servers that are hosted by their registrar. Home users that own their own domain but get dynamic IP addresses from their ISP may use a Dynamic DNS provider to host their authoritative name servers.
Their may also be authoritative name servers in a local, non-Internet network context. For example, a Microsoft Windows Server domain controller typically runs DNS and is authoritative for the Windows Domain it controls.
Basic DNS Records
Since the second fundamental purpose of a DNS server is to contain a database that cross-references a fully-qualified host name to an IP address, let’s consider the types of records that make up that database. There are two primary types of records: The A (Address Mapping) record simply includes the IP address and the fully-qualified host name, and the CNAME (Canonical Name) or alias record points a particular fully-qualified host name to another fully-qualified host name. (Note: With IPv6 a server can be configured with an AAAA record which works exactly the same as a standard A record, but provides a 128-bit IPv6 address rather than a 32-bit IPv4 address.)
When a standard query is sent to a DNS server that actually contains the records for particular host, the server provides the IP address from the A record that corresponds to the appropriate host from the query.
Other DNS Records
These records provide responses to specialized queries.
SOA - The ownership record for a zone or domain
NS - Specifies the “official”or authoritative nameserver for a particular host
MX - Specifies the designated e-mail servers for a particular domain
PTR - The pointer (or reverse-lookup) record matches an IP address back to a hostname
There are a variety of other DNS record types such as TXT, HINFO, SRV, etc.that can also be returned by specialized queries. Additionally there are a number of record types associated the DNSSEC (DNS Security Extensions) protocols.
TTL (time to live) with a DNS context is a parameter on each record that represents the maximum time in seconds that a record is valid. This is important when records are cached on non-authoritative servers, since the cached records are not refreshed until the TTL value expires.
Historically, the standard TTL for DNS records was 86400. (ie. 86400 seconds or 24 hours) Most servers on the Internet change IP addresses very infrequently and this would seam to be a reasonable value to minimize unnecessary server usage. However, it also means that if an address does change, the new address might be unreachable for up to 24 hours until all Internet caches are flushed. This might be even more critical on a local network when a server was moved/replaced due to disaster recovery. Most current DNS servers use a value of 300 (5 minutes).
A zone is an organizational unit for a collection of DNS records. Usually it corresponds to all the records for a single domain or subdomain that a DNS server is responsible/authoritative for. A DNS server can host multiple zones. Dating back to times when DNS servers stored all records as plain text, a zone file contained the text of all the records. While many newer DNS server implementations store records in relational databases instead of text files, the concept of a zone is still used.
Integration with DHCP
When a client device requests an IP address from a DHCP server, it supplies its own hostname to the DHCP server. If integration is configured between the DHCP and DNS servers, that hostname and IP address can be supplied to the DNS server and used to create both A and PTR records in the database. These records are generally deleted when/if the client device does not renew the lease on its DHCP-provided IP address. This can be a quite useful function, eliminating the need to manually create static A records in DNS and DHCP reservations on the server in order to lookup dynamically-assigned IP address.
DNS Server Types
There are a large number of implementations of DNS server software that are available as open source or proprietary applications.Three of the most widely used implementations are discussed below.
The Berkeley Internet Name Domain or BIND is the de facto standard for DNS servers. It was developed in the early 1980s at University of California, Berkeley and released as a part of their version 4.3 Berkeley Software Distribution Unix operating system (4.3BSD). BIND has had three major release versions. BIND4 was developed and originally maintained by the team at Berkeley. Maintenance was taken over by Paul Vixie from DEC in the mid-1980s and responsibility for it was eventually transferred to Vixie’s non-profit Internet Systems Consortium (ISC) to continue to maintain BIND today. BIND8 was a complete re-write of the system released in 1997. BIND9 was released in fall 2000 and included many new extensions of features such as DNSSEC. Much of the funding for BIND development was provided by US military or DARPA grants. In 2009, ISC began developing BIND10 but eventually discontinued its efforts, and released the code as an open source project call Bundy. ISC still considers BIND9 as the current, supported version of the system and continues to release updates to it.
The BIND software distribution consists of three parts: a name server daemon (called named), a resolver daemon (call lwresd, for light-weight resolver daemon), and external DNS support tools such as nslookup and dig. The name server daemon responds to queries from other devices, while the resolver daemon issues queries for forwarders. BIND does not include an integrated DHCP server. (This was one of the goals of BIND10.) It can support integration with external DHCP servers.
Microsoft’s DNS server software is included with all recent versions of Windows Server as a configurable “Server Role”. This is proprietary, non-open source software licensed as a part of Windows Server and includes a GUI-based configuration tool. It also contains software extensions to manage lookups of Microsoft Active Directory information over DNS, a service historically provided by Microsoft’s proprietary WINS (Windows Internet Name Service). While Microsoft’s DHCP server software is considered a separate “role” and uses a different GUI, integration between the two services is expected.
DNSmasq is a free, non-proprietary DNS and DHCP server. It is designed to use minimal server resources while supporting all of the standard features of DNS and DHCP. There is no standard GUI-based configuration manager. All configuration settings and host records are contained within text files.
DNSmasq is included as the default DNS/DHCP server on many Linux distributions as well nearly every network device running a Linux-derived OS that requires DNS or DHCP. If your home router supports DNS or DHCP, the underlying server is likely to be DNSmasq. Some router software does include the ability to change some DNSmasq settings via the router’s configuration web page, but you may likely need the ability to edit configuration files in order to take advantage of all DNSmasq features.