In the 1980s, MIT set forth an ambitious plan to build a computer network capable of connecting the entire campus with graphical terminals and high speed networking to support its educational mission. Their goal was to do it with a budget of just 10% the cost of tuition per student. The project was called Athena, and its most notable achievements include the X Window System, Kerberos, and Zephyr.
But, if you’re a system administrator in the mid ’80s, how do you roll out configuration changes to hundreds of machines before Active Directory or LDAP? The solution they came up with was to use the DNS.
When the first spec was published in 1983, the DNS was treated differently than the way we tend to use it today. Hostnames were resolved from local text files, and configuration could vary depending on protocol, network, machine, and internets (not capital-I Internet). The DNS promised to sort out the naming mess.
The engineers took a great first stab at it, creating a system that’s survived almost forty years in the fastest moving technological shift in human history. In order to consolidate the madness without breaking places where the same names were being used for different protocols and internets, the DNS created resource record types and classes.
Many of the early resource record types for protocols survive to this day, like
A – the authoritative IP address of the host. Fortunately, much of the spec
has been locked down, like the
HINFO record which gave the CPU and OS of the
The same can’t be said for classes. The original RFC 882 specifies two classes:
A class field identifies the format of the resource data, such as the ARPA Internet format (IN) or the Computer Science Network format (CSNET)
The designers of Athena decided to build their distributed configuration system
on top of the DNS infrastructure they had by extending BIND to support a new
class they named
Its goal was to replace configuration files for printers, their equivalent of
/etc/fstab, system wide
environment variables, mailboxes, and
/etc/passwd – and it worked.
By 1987, Hesiod was given a formal DNS mnemonic and class number in the revised DNS spec RFC 1035:
CLASS fields appear in resource records. The following CLASS mnemonics and values are defined: IN 1 the Internet CS 2 the CSNET class (Obsolete - used only for examples in some obsolete RFCs) CH 3 the CHAOS class HS 4 Hesiod [Dyer 87]
You can query for Hesiod records to this day using
dig, but likely won’t find
anything publicly because it’s generally a bad idea to publish private info in
$ dig TXT HS example.com ; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> TXT HS example.com ;; Got answer: ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;example.com. HS TXT
And at least for a while, you can still switch your modern Linux system to use Hesiod for user configuration.
But, who knows? Using DNS for configuration isn’t a terrible idea.
are useful for service discovery within corporate networks. Resolvers also have
useful systems for trying lookups against different suffixes,
which is a handy way to roll out changes to a particular subset of services
based on region or namespace.
DNS in general is ubiquitous, robust, and good at handling hiccups meaning it could be a good replacement for things like Spring Cloud Config.
Why re-invent when you can steal?