A specification is just a document. For DNS to actually work, someone had to write the software. That someone was a group of graduate students at the University of California, Berkeley, who created BIND — the Berkeley Internet Name Domain. For over three decades, BIND would be the most widely deployed DNS software on the internet.
The Birth of BIND
In 1984, shortly after RFC 882 and 883 were published, the Computer Systems Research Group (CSRG) at UC Berkeley took on DNS implementation as part of their work on 4.3BSD, the Berkeley Software Distribution of Unix.
Four graduate students did most of the work:
- Douglas Terry
- Mark Painter
- David Riggle
- Songnian Zhou
They created a working DNS implementation that shipped with 4.3BSD in 1986.
Why Berkeley?
Berkeley wasn’t a random choice. CSRG was the center of Unix development outside AT&T, and BSD was becoming the standard Unix for research institutions and universities. DARPA funded BSD development, making it a natural home for internet protocol implementations.
When 4.3BSD shipped with BIND included, every university running BSD automatically had DNS software. This was the killer distribution mechanism — no need to convince anyone to download and install DNS separately.
BIND Architecture
BIND introduced architectural patterns that persist today:
The Named Daemon
BIND’s DNS server runs as a daemon called named (name-daemon, pronounced “name-dee”). This background process:
- Listens on port 53 for queries
- Loads zone data from configuration files
- Answers queries from its zones
- Recursively resolves queries for other zones
- Caches results
The daemon model fit Unix philosophy perfectly — a single-purpose program that does one thing well.
Zone Files
BIND stores zone data in text files with a specific format:
$TTL 86400
@ IN SOA ns1.example.com. admin.example.com. (
2024010101 ; Serial
3600 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ) ; Minimum TTL
IN NS ns1.example.com.
IN NS ns2.example.com.
IN MX 10 mail.example.com.
www IN A 93.184.216.34
mail IN A 93.184.216.35
This human-readable format made DNS administration accessible. System administrators could edit zone files with any text editor, reload the daemon, and see changes take effect.
Configuration Separation
BIND separated:
- Zone data (what domains resolve to)
- Server configuration (who to answer, who to forward to, access controls)
- Root hints (how to find root servers)
This separation of concerns made BIND flexible for different deployment scenarios.
The BIND Monopoly
By 1990, BIND was effectively the only DNS implementation that mattered. Several factors drove this:
BSD Distribution
Since BIND shipped with BSD Unix, it spread wherever BSD spread — which was most of the academic and research internet. Installing BSD meant having BIND.
Open Source Before the Term Existed
BIND was freely available with source code. Anyone could examine, modify, and redistribute it. This was before “open source” was a term, but BIND embodied the concept.
Network Effects
Once most of the internet ran BIND, running something else meant incompatibility risks. BIND’s quirks became de facto standards because everyone had to interoperate with BIND.
Lack of Alternatives
Until the late 1990s, there simply weren’t serious alternatives. Writing a DNS server is complex, and BIND worked well enough that few saw reason to duplicate the effort.
BIND’s Evolution
BIND didn’t stay static. It evolved through several major versions:
BIND 4 (1988)
The first “production” BIND, shipped with 4.3BSD-Tahoe. This version:
- Supported the full RFC 1034/1035 specification
- Added security patches over time
- Remained the standard for nearly a decade
BIND 8 (1997)
A major rewrite addressing accumulated technical debt. BIND 8:
- Improved security
- Better configuration options
- Enhanced logging
- Dynamic update support (RFC 2136)
BIND 9 (2000)
A ground-up rewrite by the Internet Systems Consortium (ISC). BIND 9:
- Cleaned up the codebase entirely
- Added IPv6 support
- Implemented DNSSEC (after years of development)
- Introduced views (different responses for different clients)
- Remains the current version (continuously updated)
Each major version required painful transitions. BIND 4 configurations didn’t work in BIND 8. BIND 8 configurations didn’t work in BIND 9. But each rewrite addressed fundamental limitations of previous versions.
The Security Problem
BIND’s dominance had a dark side: security vulnerabilities in BIND affected the entire internet.
A Monoculture Risk
When everyone runs the same software, a single vulnerability affects everyone. BIND had numerous security issues over the years:
- Buffer overflows allowing remote code execution
- Cache poisoning vulnerabilities
- Denial of service weaknesses
- Zone transfer information leaks
Attackers knew that exploiting BIND meant exploiting a huge portion of the internet’s DNS infrastructure.
The BIND 9 Response
ISC’s complete rewrite in BIND 9 was partly motivated by accumulated security concerns. The new codebase applied modern security practices, though vulnerabilities continued to be found and patched.
Alternatives Emerge
BIND’s monopoly eventually ended. Today, several DNS implementations compete:
djbdns (1999)
Daniel J. Bernstein created djbdns as a security-focused alternative. It had:
- A radically different architecture
- Strong security claims (public security guarantee)
- Controversial licensing (placed in public domain in 2007)
PowerDNS (1999)
Open source DNS with a database backend option. Popular for hosting providers managing many domains.
NSD/Unbound (2003/2007)
NLnet Labs created NSD (authoritative-only) and Unbound (resolver-only). Separating these functions improved security and performance.
Knot DNS (2011)
Czech CZ.NIC registry created this high-performance authoritative server.
Despite alternatives, BIND remains widely deployed. As of recent surveys, BIND still runs on roughly 50% of visible DNS servers — less dominant than before, but still the leader.
Legacy and Influence
BIND’s influence extends beyond the software itself:
Zone File Format
BIND’s zone file syntax became the de facto standard. RFC 1035 specifies the format, but BIND’s extensions (like $INCLUDE and $GENERATE) are widely supported.
Operational Practices
BIND documentation established how to think about DNS operations: zones, views, ACLs, logging, caching tuning. Other implementations adopted similar concepts.
The ISC
The Internet Systems Consortium, created in 1994, now maintains BIND. ISC also maintains ISC DHCP, participates in internet standards development, and operates F-root (one of the thirteen root servers).
Key Takeaways
- BIND was created at UC Berkeley in 1984 by four graduate students
- Distribution with 4.3BSD gave BIND immediate widespread deployment
- BIND introduced zone files, the named daemon, and patterns still used today
- The BIND monopoly (80%+ market share through the 1990s) created monoculture security risks
- BIND 9 (2000) was a security-focused ground-up rewrite
- Today, BIND remains the most deployed DNS software (~50%) but faces healthy competition
Next
With BIND providing a working implementation, the DNS community gathered operational experience. This experience revealed gaps and ambiguities in the original RFCs, leading to the definitive specifications: RFC 1034 and RFC 1035.