Introduction
Linux distributions. So, what is a DNS? A DNS server is a service that helps resolve a fully qualified domain name (FQDN) into an IP address and performs a reverse translation of an IP address to a user-friendly domain name.
Why is name resolution important? Computers locate services on servers using IP. However, IPs are not as user-friendly as domain names. It would be a big headache to remember each IP address associated with every domain name. So instead, a DNS server steps in and helps resolve these domain names to computer IP addresses.
The DNS system is a hierarchy of replicated database servers worldwide that begin with the “root servers” for the top-level domains (.com, .net, .org, etc.). The root servers point to the “authoritative” servers located in ISPs and large companies that turn the names into IP addresses. The process is known as “name resolution.” Using our www.business.com example, COM is the domain name, and WWW is the hostname. The domain name is the organization’s identity on the Web, and the hostname is the name of the Web server within that domain. Debian DNS server setup can be found the link.
We will use bind9 in this tutorial. BIND 9 provides software for Domain Name System (DNS) management, including defining domain names authoritatively for a given DNS zone and recursively resolving domain names to their IP addresses. In addition to BIND 9’s DNS server itself named, this container also includes tools for performing DNS queries and dynamic updates. Read more on the BIND 9 website.
Get the dns server image
# podman pull ubuntu/bind9
Create pod for dns server
# podman pod create --name dnsapp -p 30053:53 --network bridgeCreate the dns server container
# podman run --pod dnsapp --name dns-server -d ubuntu/bind9Image parameter
| Parameter | Description |
|---|---|
-e TZ=UTC | Timezone. |
-p 1803233 | Expose bind9 on localhost:30053. |
-v /path/to/bind/configuration:/etc/bind/named.conf | Local configuration file named.conf (try this example). |
-v /path/to/cached/data:/var/cache/bind | The location where locally cached data can be dumped. |
-v /path/to/resource/records:/var/lib/bind | Location of Resource Records defining various domain information. |
Testing/Debugging
# podman logs -f dns-server
Conclusion
To correctly operate a name server, it is essential to understand the difference between a zone and a domain.
As stated previously, a zone is a point of delegation in the DNS tree. A site consists of those contiguous parts of the domain tree for which a name server has complete information and over which it has authority. It contains all domain names from a certain point downward in the domain tree except those delegated to other zones. A delegation point is marked by one or more NS records in the parent zone, which identical NS records should match at the root of the delegated area.
Consider the example.com domain, which includes names such as host.aaa.example.com and host.bbb.example.com, even though the example.com zone has only delegations for the aaa.example.com and bbb.example.com zones. A site can map precisely to a single domain but could also include only part of a domain, the rest of which could be delegated to other name servers. Every name in the DNS tree is a domain, even if it is terminal and has no subdomains. Every subdomain is a domain, and every domain except the root is also a subdomain. The terminology is not intuitive, and we suggest reading RFC 1033, RFC 1034, and RFC 1035 to gain a complete understanding of this subtle and challenging topic.
Though BIND is called a DNS, its primary goal is with zones. The primary and secondary in the named.conf file specifies zones, not domains. When BIND asks some other site if it is willing to be a secondary server, it is asking for secondary service for some collection of zones.
