A DNS Zone File is a text file that describes the DNS configuration for a domain. The zone file defines a mapping between subdomains and IP addresses. This mapping can be used for defining subdomains such as www or MX records for where mail should be delivered too.

The zone file can also contain additional settings to control aspects such as DNS Caching.

View Zone file

Output the contents of an example zone file for the domain example.com using cat db.example.com

Zone file structure

The first two lines define the domain for the zone and the (Time-To-Live) TTL for a cache of DNS requests. The next block defines the mapping between subdomains and IP addresses.

In this example, the domain has two name servers specified, ns1.example.com and ns2.external-domain.com. Name servers determine which servers can respond with the correct zone information for the particular domain. Domains should list at least two domains for redundancy.

The Zone lists one Mail Exchanger (MX) record for mail, mail.example.com. An MX record specifies a mail server responsible for accepting email messages on behalf of a recipient's domain.

A Records are the most basic type of DNS record and are used to point a domain or subdomain to an IP address. This zone file defines three, ns1 pointing to the IP 192.168.0.1, www to 192.168.0.2 and admin to 192.168.0.3

Finally, it defines one Canonical Name (CNAME) record called demo pointing to the www subdomain. A CNAME is an alias to another record.

A structure text file defines the CoreDNS configuration. CoreDNS has a series of middleware layers that control it's behaviour and how to handle requests.

The configuration file also defines which Zone Files to load and how to respond. CoreDNS supports multiple backend data sources for zone configuration. Other scenarios will explain the additional backend data sources.

CoreDNS Configuration

By default, a file called Corefile defines the configuration. View the configuration for this scenario using cat Corefile

The configuration has a few fundamental properties. Firstly, it defines that the DNS server should listen to requests on port 2053.

Load configured defines which files to load, in this case, example.com.

All other requests are proxied to 8.8.8.8, Google's free and open DNS server. By using Google's DNS, you can ensure requests for public domains will be responded with the correct IP address.

Task

Start the service as a background process using nohup.

nohup ./coredns -quiet >/dev/null 2>&1 &

In production, it's recommended to use an init system such as SystemD

[Unit]
Description=CoreDNS DNS server
Documentation=https://coredns.io
After=network.target

[Service]
PermissionsStartOnly=true
PIDFile=/home/coredns/coredns.pid
LimitNOFILE=8192
User=coredns
WorkingDirectory=/home/coredns
ExecStartPre=/sbin/setcap cap_net_bind_service=+ep /opt/bin/coredns
ExecStart=/opt/bin/coredns -pidfile /home/coredns/coredns.pid -conf=/etc/coredns/Corefile
ExecReload=/bin/kill -SIGUSR1 $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target

The CoreDNS server is now running on port 2053 and configured for our example.com domain.

Task

Query the DNS using the dig command. Querying for www.example.com will cause CoreDNS to look up the relevant IP address in the zone definition.

dig @localhost -p 2053 www.example.com

For this subdomain, the DNS server returns IP address 192.168.0.2 as defined in our zone file.

When querying for the CNAME will return the hops as a single round-trip lookup.

dig @localhost -p 2053 demo.example.com

For demo.example.com CNAME it first returns www.example.com and defines that it resolves to the IP 192.168.0.2.

Applications are now able to use the DNS server to map well-known names to which server is capable of handling the requests.

If we query for an external hostname then this will be proxied to Google's DNS server and return the correct IP addresses.

dig @localhost -p 2053 microsoft.com