Linux concept: DNS

1. The Basics

The Domain Name System turns names into the information a computer needs to reach a service. Most of the time that is an IP address, but DNS also carries where your mail goes, which certificate authorities may issue for you, and which servers are allowed to send on your behalf.

It is often described as the phone book of the internet. That comparison is comforting and slightly wrong, because a phone book is one document that somebody prints. DNS is a distributed database with delegated authority: no single machine holds it, no single organisation publishes it, and every part of it is answered by whoever was handed responsibility for that part.

That delegation is the whole design. The root delegates .nl to the Dutch registry. The Dutch registry delegates petermartin.nl to whichever name servers the owner nominated. Those name servers answer for everything below it. Each level knows only enough to point at the next one.

The right mental model: DNS is not a lookup table, it is a chain of referrals. Nobody has the whole answer; everybody knows who to ask next. Almost every confusing DNS problem is a broken link in that chain, or a cached copy of a link that has since changed.

1.1 The Four Roles

Four different kinds of software are involved in every lookup, and mixing them up is the single most common source of confusion. They are not interchangeable.

The practical consequence: "the DNS is wrong" is never a complete sentence. A record can be correct on the authoritative server, stale in a recursive resolver, and absent from your own machine's cache, all at the same moment, and all three are behaving properly.

1.2 What One Lookup Actually Does

When your browser needs www.petermartin.nl and nothing is cached anywhere, this is the journey:

your browser
    ↓  "where is www.petermartin.nl?"
stub resolver (127.0.0.53)
    ↓
recursive resolver (your ISP, or 1.1.1.1)
    ↓  asks a root server: "who handles .nl?"
    ↓  asks the .nl registry: "who handles petermartin.nl?"
    ↓  asks Cloudflare: "what is www.petermartin.nl?"
    ↓
back up the chain, cached at every step that allows it

Three requests to three different organisations, for one name. This sounds slow, and the first lookup is. Every step after that is answered from cache until the TTL runs out, which is why the second visit to a site feels instant.

The important part is what gets cached and where. The recursive resolver caches the answer and the referrals, so the next visitor asking for a different name under .nl skips the root entirely. This is also why a change you make is invisible to some people and not others: their resolvers cached at different moments.

1.3 What This Article Covers

This article is about DNS as something you design and own: who holds which piece, how to lay out a zone, how mail authentication fits together, what to do about resilience and DNSSEC, and which decisions you will regret later.

It deliberately does not repeat the mechanics of inspecting DNS from the command line. For reading records, following a delegation, checking a cache, and choosing TTL values, see the companion article on the dig command, which covers the tooling in detail. Here the question is not "how do I see it" but "what should it be".

3. A Short History

DNS was not designed as a grand architecture. It was written to solve an administrative crisis: one text file that had stopped scaling.

Before DNS, every machine on the ARPANET kept a local copy of a single file called HOSTS.TXT, maintained by the Network Information Center at the Stanford Research Institute. Every new host meant editing that file, and every machine on the network downloading it again. As the network grew, the file grew, the downloads grew, and the delay between "a host exists" and "everyone knows about it" grew with them.

In November 1983 Paul Mockapetris published the replacement as two documents: RFC 882, "Domain Names Concepts and Facilities", which described the idea, and RFC 883, "Domain Names Implementation and Specification", which defined how it worked on the wire. The insight was to stop distributing a file and start distributing authority.

Two things are worth taking from that table. The core specification is from 1987 and has never been replaced, only extended. And every extension since has been about the two things the original did not consider: proving an answer is genuine (DNSSEC), and keeping the question private (DoT and DoH). The original design assumed a small, trusting network, because in 1983 that is what it was.

5. Designing a Zone

Once the delegation points at your name servers, everything inside the zone is your decision. Most zones are small, and most of the trouble in them comes from four or five choices that were made without much thought and are painful to reverse.

5.1 The Apex, and Why CNAME Does Not Work There

The apex (or "root" of your zone) is the bare domain, example.com with nothing in front. It is special, and it catches everybody exactly once.

You cannot put a CNAME on the apex. The standards forbid a CNAME from sitting alongside any other record, and the apex always carries SOA and NS records, because that is what makes it a zone. So a CNAME there is not merely discouraged; it is unrepresentable.

This collides directly with modern hosting, where providers hand you a name rather than an address, precisely so they can change the address behind it. The answers, in order of preference:

If your provider offers flattening, use it. If it does not, that is a genuine reason to consider one that does.

5.2 Pick www or Not, Then Commit

Both work. What causes problems is serving both as equals, because then every page exists at two addresses, and search engines, cookies, and certificates all have to be told they are the same thing.

Choose one as canonical, publish both in DNS, and redirect one to the other at the web server with a permanent redirect. The DNS side is unremarkable:

example.com.        300   IN   A       203.0.113.10
www.example.com.    300   IN   CNAME   example.com.

The CNAME is fine on www, because www is an ordinary name inside the zone, not the apex. Only the apex is restricted.

5.3 Subdomains: Records or Delegation?

There are two quite different ways to have a subdomain, and choosing the wrong one creates work later.

• Records in your own zone. shop.example.com is just another name you manage alongside everything else. This is what you want almost always.
• Delegation. You publish NS records for shop.example.com pointing at somebody else's name servers, and hand over that whole branch. From then on you cannot see or fix anything inside it.

Delegate only when a different team or platform genuinely needs to run its own records at speed, which in practice means large organisations and some cloud platforms. For a single site, delegation adds a second place for things to break and a second chain of trust to keep intact.

5.4 Wildcards Answer for Names You Never Created

A wildcard record matches anything that does not have its own entry:

*.example.com.      300   IN   A       203.0.113.10

It looks convenient and it quietly changes the meaning of your zone. Every typo now resolves. Every subdomain an attacker invents resolves. Monitoring that checks "does this name exist" always says yes. And a wildcard plus a permissive web server is the classic setup for subdomain takeover, where somebody serves their content on a name that appears to be yours.

Use a wildcard when you genuinely serve unlimited names, such as customer subdomains on a platform. Otherwise list the names you actually have. The typing is not the expensive part of running a zone.

5.5 Split Horizon: The Same Name, Two Answers

Some organisations answer differently for the same name depending on who is asking: a private address on the office network, a public one from outside. This is split horizon, and it is a legitimate design.

It is also a trap for whoever debugs it later, because two people running the same command in good faith get different answers and both conclude the other is confused. If you run split horizon, document it where the person on call will find it, and expect every external DNS checking tool to disagree with what you see at your desk.

5.6 Choosing TTLs

Every record carries a TTL, the number of seconds a resolver may cache it, and the value is a real design decision rather than a default to accept. It decides how fast you can move, and how long you keep working when your name servers do not.

The short version: 300 seconds for addresses, a day for NS records, an hour for mail and text records, and lower everything a day before a planned migration. The reasoning, with measurements from well-run domains and the trade-off in both directions, is in the dig article, which also shows how to read what a zone actually publishes rather than what a cache is telling you.

7. DNS on a Linux Machine

Everything so far has been about the domain you publish. This section is about the machine in front of you, because the client side has its own rules and they are the reason two people can run the same lookup and disagree.

7.1 Your resolv.conf Is Probably a Symlink

The traditional place a Linux machine keeps its resolver settings is /etc/resolv.conf. Generations of documentation tell you to edit it. On a modern system that advice is usually wrong, and here is the proof:

$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Apr 24  2024 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search .

The file is a symlink into a directory that is regenerated at boot. Anything you type into it is lost the next time the machine restarts, or sooner. Several pieces of software may be generating it: systemd-resolved, NetworkManager, a DHCP client, resolvconf, a VPN client, or a container runtime.

On most networks the DNS servers in that file did not come from a person at all: they arrived in a DHCP lease, along with the address and the gateway. The companion article on DHCP covers where those settings come from and why editing them here does not last.

That 127.0.0.53 is not a DNS server on the internet. It is the local stub, and the real upstream servers sit behind it, per network interface. The honest way to see them is to ask the thing that owns them:

$ resolvectl status | grep -A2 'Current DNS Server'
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1

$ resolvectl query petermartin.nl
petermartin.nl: 2a01:4f8:c0c:6848::1                        -- link: wlp0s20f3
                23.88.98.40                                 -- link: wlp0s20f3

-- Information acquired via protocol DNS in 5.2ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no

The last line is worth reading twice. It reports whether the answer was DNSSEC validated and whether it travelled encrypted, which are two questions people usually guess at. Here both are "no", which is the normal state on a laptop talking to a home router.

To change the settings, change them where they are generated: the connection profile in NetworkManager, the DHCP server, or /etc/systemd/resolved.conf. Editing the symlink target is a fix that survives until Tuesday.

7.2 The Order Linux Really Resolves In

DNS is not the only way a Linux machine turns a name into an address, and it is not necessarily the first. The order lives in /etc/nsswitch.conf:

$ grep '^hosts:' /etc/nsswitch.conf
hosts:          files mdns4_minimal [NOTFOUND=return] dns mymachines

Read left to right, that machine checks /etc/hosts first, then multicast DNS for .local names, and only then real DNS. The bracketed [NOTFOUND=return] means that if mDNS gives a definitive "no", the search stops there instead of falling through.

This single line explains a whole category of confusion. A name in /etc/hosts resolves for your browser and your scripts while DNS knows nothing about it. A .local name may never reach DNS at all. And a command-line DNS tool asks a name server directly, skipping this list entirely, so it can honestly disagree with every application on the machine.

The rule that follows is simple. To ask "what does DNS say", use a DNS tool. To ask "what does this machine actually do", use getent, which walks the list above exactly as an application would:

$ getent hosts petermartin.nl

The companion article on the dig command covers this boundary in more detail, including why a name can work everywhere and still appear not to exist.

7.3 Containers Have Their Own DNS, and It Depends on the Network

A container does not inherit your machine's resolver settings, and the difference bites during exactly the debugging session where you can least afford a surprise. What it gets depends on which Docker network it joined, and the two cases behave completely differently.

On the default bridge, the container is handed the host's upstream server and nothing else:

$ docker run --rm alpine cat /etc/resolv.conf
nameserver 192.168.1.1
search .

$ docker run -d --name db2 alpine sleep 60
$ docker run --rm alpine getent hosts db2
                              # nothing: names do not resolve here

On a user-defined network, Docker inserts its own embedded resolver and container names start working:

$ docker network create dnstest
$ docker run --rm --network dnstest alpine cat /etc/resolv.conf
nameserver 127.0.0.11
search .
options edns0 trust-ad ndots:0

$ docker run -d --network dnstest --name db alpine sleep 60
$ docker run --rm --network dnstest alpine getent hosts db
172.19.0.2        db  db

That address, 127.0.0.11, is Docker's built-in DNS server, and it is what resolves one container name to another. This is why service names work in a Docker Compose stack without anyone configuring DNS: Compose creates a user-defined network for the project automatically.

Two practical consequences. First, when a containerised application cannot reach its database, test resolution inside the container, not on the host, because they are answering from different resolvers. Second, if you are debugging a stack where names do not resolve, check which network the containers are actually on before you look at anything else.

$ docker exec -it mycontainer cat /etc/resolv.conf
$ docker exec -it mycontainer getent hosts database

The same idea scales up. Kubernetes runs a cluster DNS service, usually CoreDNS, and gives every service a name such as database.default.svc.cluster.local so applications can find each other without hard-coded addresses. DNS stopped being only an internet directory some time ago; inside modern platforms it is the service-discovery layer.

7.4 Do Not Become an Open Resolver

You can run your own recursive resolver on Linux, and there are good reasons to: local caching, your own DNSSEC validation, independence from a third party, and logs you control. unbound is the usual choice, and BIND can do it too.

There is one way to get this badly wrong, and it is worth stating plainly. A recursive resolver that answers anyone on the internet is an open resolver, and it will be found and abused within days.

The abuse is amplification. DNS traditionally runs over UDP, which does not verify who sent a packet, so an attacker sends small queries with the victim's address forged as the source. Your server dutifully sends much larger answers to the victim. A modest request becomes a flood, the attacker spends almost nothing, and the traffic arrives from your address rather than theirs.

Preventing it is not complicated:

• Restrict recursion to clients you trust, meaning your own networks. This one setting removes the entire problem.
• Keep the two roles separate. A server that publishes your zones to the world is authoritative and needs no recursion at all. A server that resolves for your staff is recursive and should not be reachable from outside. Combining them on one public address is how this usually happens by accident.
• Turn on response rate limiting on anything that does face the internet.

The general principle is worth carrying beyond DNS: before exposing any DNS server, know whether it is meant to be authoritative, recursive, or both, because the correct configuration is different in each case and the failure mode is that somebody else uses your bandwidth to attack a stranger.

9. Best Practices

• Know your three suppliers before you need them. Write down who the registrar, the DNS host and the web host are, and who has the login for each. The middle of an outage is the wrong time to discover the domain sits in a former colleague's personal account.
• Protect the registration first. Registrar lock on, auto-renew on, a payment method that outlives employees, and a role address as the registrant contact. Everything else in DNS assumes the domain still exists.
• Monitor expiry somewhere other than the registrar's email. If the account details are wrong, the reminders are going to the wrong place too.
• Set TTLs deliberately, and lower them a day before a planned move. 300 for addresses, a day for NS, an hour for mail and text records.
• Keep the apex on a flattened ALIAS or a plain A record, never a CNAME, and pick either www or the bare domain as canonical rather than serving both as equals.
• List the subdomains you have instead of reaching for a wildcard. A wildcard answers for names you never created, including the ones somebody else invents.
• Deploy mail authentication in order. SPF and DKIM first, then DMARC at p=none, read the reports for a few weeks, and only then tighten. Going straight to p=reject silently destroys the mail you forgot about.
• Publish a CAA record naming the authority you actually use. It is two minutes of work and it limits what a mis-issued certificate can do.
• Turn on DNSSEC if your provider manages the whole lifecycle, including key rollovers and pushing the DS record to the registrar. If it would be a manual job you do once and never revisit, think harder.
• Prefer one good anycast provider over two mediocre ones. Add secondary DNS when an hour of being unreachable is genuinely expensive, not because it sounds more professional.
• Do not use round robin as failover. DNS does not know whether a server is alive. Use health-checked records or a load balancer.
• Clean the zone once a year. Delete the verification TXT records for services you stopped using and the A records for servers that no longer exist. Old records are how subdomain takeovers start.
• Do not edit /etc/resolv.conf. On most systems it is a generated symlink. Change the setting where it is produced, and use resolvectl status to see what your machine is really using.
• Test container DNS inside the container. A container answers from a different resolver than the host, and container names only resolve on a user-defined network, not on the default bridge.
• Never expose a recursive resolver to the internet. Restrict recursion to your own networks, and keep authoritative and recursive roles on separate servers. An open resolver becomes somebody else's attack tool.
• Check changes from outside your own network. Your resolver, your router and your browser all cache, and all three can show you something the rest of the world is not seeing.

11. Summary

DNS looks like a lookup table and behaves like an organisation chart. Almost everything that confuses people about it comes from that gap.

• DNS is a distributed database with delegated authority. The root delegates to registries, registries delegate to your name servers, and each level knows only who to ask next.
• Four kinds of software are involved and they are not interchangeable: the stub resolver on your machine, the recursive resolver that does the chasing and caches, the authoritative server that holds the truth, and the registry that publishes the delegation.
• A domain is three arrangements with three companies: the registrar you rent it from, the DNS host that answers queries, and the web host that runs the site. Knowing which one to log into is most of the work.
• Name server changes happen at the registrar. Record changes happen at the DNS host. Confusing the two costs a day.
• DNS replaced a single HOSTS.TXT file in 1983, and the specification everything still runs on is RFC 1034 and RFC 1035 from 1987. Every addition since has been about proving answers are genuine or keeping questions private.
• The apex cannot hold a CNAME. Use ALIAS or flattening if your provider offers it, or a plain A record if it does not.
• Pick www or the bare domain as canonical and redirect the other. Serving both as equals creates work at every layer above DNS.
• Wildcards answer for names you never created. List what you have instead.
• Mail authentication is one system: MX for receiving, SPF for authorised servers, DKIM for signed messages, DMARC for the decision, and PTR at your hosting provider. Deploy in that order and start DMARC at p=none.
• DNS is also where the internet keeps proof of ownership: ACME DNS-01 challenges, service verification records, and CAA to name the authorities allowed to issue for you.
• DNSSEC proves answers are genuine and fails hard when it breaks. Turn it on when your provider manages the whole lifecycle, including the DS record at the registrar.
• The 13 root servers are 13 addresses, not 13 machines: around two thousand anycast instances, twelve operators. Anycast is also what a good DNS provider sells you.
• Round robin distributes load but is not failover, because DNS never checks whether a server is alive.
• You rent your domain. Registrar lock, auto-renew, a role email, and expiry monitoring that does not depend on the registrar's own reminders.
• On a Linux machine, /etc/resolv.conf is generated and /etc/nsswitch.conf decides the real order: files before dns, so getent and a DNS tool can honestly disagree.
• Containers resolve through their own server. On a user-defined Docker network that is 127.0.0.11 and container names work; on the default bridge they do not.
• A recursive resolver open to the internet gets abused for amplification. Restrict recursion, and keep authoritative and recursive roles apart.
• For reading records, tracing a delegation, comparing a cache with the source and choosing TTL values, the companion article on the dig command covers the tooling.

This is the checklist worth keeping when you take on a domain you did not set up:

WHO HOLDS IT
  registrar        who it is renewed with, and who has that login
  DNS host         which name servers the registrar publishes
  web host         who owns the IP the A record points at

IS IT SAFE
  registrar lock   on
  auto-renew       on, with a payment method nobody personally owns
  registrant email a role address, not an individual
  expiry alert     somewhere other than the registrar's own email

IS IT SANE
  apex             A or ALIAS, never CNAME
  www              canonical one way, redirected the other
  wildcards        none, unless you genuinely serve unlimited names
  stale records    A records for dead servers, TXT for dead services

ON THIS MACHINE
  resolvectl status      which upstream servers are really in use
  /etc/nsswitch.conf     the order: files, mdns, dns
  getent hosts NAME      what an application sees, not what DNS says

IS IT TRUSTED
  SPF, DKIM        published and passing
  DMARC            at least p=none, with reports going somewhere read
  CAA              names the authority you actually use
  DNSSEC           signed AND the DS record published at the registrar

A domain that resolves the same way everywhere, delivers its mail, renews its certificates and survives its own renewal date is not luck: it is a handful of decisions made deliberately and written down. Most of them cost nothing at the time and are expensive to retrofit.

If you have inherited a domain nobody documented, or you are moving one between providers and want the delegation, the zone and the mail records checked before the cutover rather than during it, that is worth an hour of somebody's attention before it becomes an outage.