DNS for configuration management

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.

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 host.

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 Hesiod. 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.

Hesiod

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 the DNS:

$ 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

Payoff

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. SRV records 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?