Two jobs in one program

You type `pixzo.nl` into a browser and a machine somewhere answers with `192.0.2.1`.

That machine is running BIND, and it has been answering that kind of question since the late 1980s. Not because it is elegant, but because it got there first and never left.

BIND stands for Berkeley Internet Name Domain. It is an open source implementation of the Domain Name System, maintained by the Internet Systems Consortium. If you have ever resolved a hostname on a Linux box, there is a decent chance BIND was somewhere in the chain — as the authoritative server for the zone, as the recursive resolver on your network, or as the thing your distribution quietly installed as a dependency.

The choice you are actually making is not "BIND or nothing." It is "which DNS server do I want to be responsible for at two in the morning."

Two jobs in one program

BIND can act as an authoritative server or as a recursive resolver. Those are different jobs and you should decide which one you want before you install anything.

An authoritative server holds the official records for a zone you control. Someone asks for `pixzo.nl`, your BIND answers. That is the whole job. It does not go looking for other people's domains, and it should not.

A recursive resolver does the opposite. It takes a query from a client — a browser, a container, a laptop — and walks the chain: root servers, then the top-level domain, then the zone, until it has an answer. Then it caches that answer so the next client does not pay the same cost.

You can run both roles in one BIND instance. Many people do. It works, and it is also how a single misconfiguration turns your resolver into an open relay that strangers use to amplify traffic at someone else's expense. Splitting the roles costs you a second process and a second config file. Not splitting them costs you a weekend of incident response, eventually.

What the configuration actually looks like

BIND reads `named.conf`. That file decides which zones you serve, who is allowed to query you, and how logging and security behave.

It is a plain text file with sections and key-value pairs, read top to bottom. If you have edited `ssh_config` or `rsyncd.conf`, the shape will feel familiar: blocks, directives, and an order that matters because the first matching value usually wins.

The daemon itself runs as `named`. It starts at boot, sits in the background, and answers queries until you stop it. On most modern distributions that means a systemd unit, so `systemctl status named` is your first look when something is wrong.

Zones live in separate files, referenced from `named.conf`. A zone file is a list of records: which name maps to which address, which mail server handles the domain, which nameservers are authoritative. Get a trailing dot wrong in one of those records and you will spend an hour wondering why `pixzo.nl` resolves but `www.pixzo.nl` does not.

That is not a BIND bug. That is DNS being DNS.

Controlling a running server

You do not restart BIND to reload a zone. You use `rndc`, the Remote Name Daemon Control utility.

`rndc` talks to the running server over TCP and sends signed commands. The signature matters: without it, anyone who can reach the control port can flush your cache or shut you down. With it, you get authentication and integrity for free, assuming you generated the key properly and did not paste it into a world-readable file.

The commands you will actually use are few.

``` rndc reload rndc flush rndc status ```

`reload` re-reads the configuration and zone files. `flush` empties the cache, which is what you want after you fix a bad record and cannot wait for the TTL to expire. `status` tells you whether the server is up and what it thinks it is doing.

The cost of `rndc` is that you now have a key to manage. Lose it, and you are editing config files and restarting the service like it is 1998. Leak it, and you have handed someone a remote control for your DNS.

Testing what you built

`dig` is the tool everyone reaches for, and it is fine. But it waits for each answer before sending the next query, which gets tedious when you are checking a few hundred names.

`mdig` sends multiple queries at once and does not block on each response. It is a pipelined lookup utility, and for bulk verification or chasing a performance problem it is simply faster. It is not part of BIND, so you install it separately.

Then there is `ldns-testns`, which does something different: it is a fake nameserver. You configure it to return predetermined answers — including deliberately wrong ones — so you can test how a client behaves when DNS lies to it.

That sounds like a toy. It is not. If you are writing software that depends on DNS, you want to know what happens when a resolver returns SERVFAIL, or a truncated response, or an answer for the wrong name. `ldns-testns` lets you produce those conditions on demand instead of waiting for the internet to produce them for you.

The cost is that it is another tool to learn, and it is not a substitute for BIND. It only pretends.

Where BIND sits relative to everything else

BIND does not run in isolation. It sits next to the rest of your system's name resolution, and the interactions are where people get confused.

The `hosts` file is the simplest form of name mapping there is: a static list of addresses and names, checked before DNS on most configurations. During maintenance, editing `hosts` is faster than touching the DNS server. It is also a trap, because the change is invisible to every other machine on the network.

Your system's own hostname matters too. If the machine running BIND cannot resolve its own name, zone transfers and logging will produce strange results that look like DNS failures but are not.

And if you run rsync in daemon mode alongside it, `rsyncd.conf` follows the same configuration philosophy: text file, sections, directives, read at startup. Two different services, one mental model. That consistency is not an accident, and it is worth leaning on when you are learning your way around a new server.

Security is not a feature you add later

DNS was designed in an era when the network was small and everyone on it was presumed friendly. That presumption has not aged well.

Cache poisoning — injecting false records into a resolver's cache — has been a live attack for decades. Amplification attacks use open resolvers to turn a small query into a large response aimed at a victim. If you run a recursive resolver that answers queries from the entire internet, you are participating in that, whether you meant to or not.

BIND supports DNSSEC, which uses digital signatures to prove that a DNS answer is authentic and unmodified. It works. It is also a genuine operational burden: key rotation, signed zones, and a chain of trust that breaks loudly when one link expires.

The same principle shows up in `rndc`, which signs its control commands. Verification is not bolted on at the end. It is the mechanism.

When it goes wrong

Three things bite people repeatedly.

The server starts but answers nothing. Check that `named.conf` actually includes the zone you think it does, and check the zone file for a missing trailing dot or an unbalanced parenthesis. BIND will log the parse error, usually with a line number, and usually after you have already looked at that line twice.

`rndc` refuses to connect. Almost always the key. Either the key in `rndc.conf` does not match the one in `named.conf`, or the file permissions let the wrong user read it. Verify both before you start reconfiguring the network.

Queries time out from outside but work locally. That is a firewall or an `allow-query` directive, not a DNS problem. BIND answered. Something in front of it did not let the answer out.

What you are actually choosing

BIND is not the only DNS server. Knot, NSD, PowerDNS, and dnsmasq all exist, and several of them are easier to configure for narrow use cases. dnsmasq in particular is a fine choice for a small network that just needs caching and local names.

What BIND gives you is completeness and age. It supports authoritative and recursive service, DNSSEC, views, zone transfers, and a control interface, all in one package. What it costs you is configuration surface. Every one of those features is a directive you can get wrong, and the error messages assume you already know what you were trying to do.

The honest answer is that it depends on what you are running. A single authoritative zone for one domain does not need BIND's full weight. A resolver serving a mid-sized network, where you want views and DNSSEC and a control channel that has been audited by more people than you will ever meet, is exactly what BIND was built for.

Pick the smallest server that does the job you have today. You can always migrate when the job grows — and the migration will be easier than the incident you avoided by not running more than you needed.