Hitting DNS with a Sledgehammer (for Fun and Profit)
About three years ago I started working part-time (20%) on SCION, a secure, available future Internet architecture. Since I wasn’t around much, I was given a nice easy project that wasn’t on anyone’s critical path: desigining the naming system for SCION (as to that time it was assumed SCION would just use DNS with new RRTYPEs to handle the new address families it introduces).
After a few months of part-time thinking about (and rejecting) blockchains and distributed hash tables, I arrived at the design of RAINS, whose recursive acronym ostensibly stands for “RAINS, Another Internet Naming System”, but is really a comment on the weather in Zürich in November. RAINS, as it turns out, looks a whole lot like DNS. Given that DNS itself is in a state of more flux than it has seen in decades – witness the DoH versus DOT controversy, fretting about the unmanageable complexity that DNS has become, and efforts to disrupt the logjam holding back DNS evolution – it seems to me that examining the ways RAINS is different than DNS might be useful in the effort to evolve and improve DNS.
The most important difference between the design of RAINS and DNS is “signatures or it didn’t happen”: an assertion about a subject name or address must have a valid signature by an authority for that name to be returned as an answer to a query about that subject. This also implies that RAINS, unlike DNS, has no relative clocks: the DNS TTL is replaced by the absolute validity timestamps on the signature. This has two advantages: first, making security non-optional avoids the poor deployment curve and the poor tooling situation plaguing DNSSEC. Second, as with DNSSEC, having the answer to a query have an absolute validity time and a signature verifiable independent of its origin separates that validity from the identity of the specific bit of infrastructure from which it was received. The guidance to DNS here is make DNSSEC non-optional, which I guess the DNS community already knows, but which is far easier said than done.
The second feature of RAINS is explicit context: replacing the various forms of implicit inconsistency in the DNS (split DNS, geolocalized DNS, captive portal interactions and so on) with an explicit form of inconsistency, essentially by allowing any authority over any part of the global namespace to mint an unlimited number of private namespaces, identified by the “context-part” of a name. I have to admit that I’ve been staring at this design for a couple of years and I still don’t grasp all of the implications of it, but one of the important ones is that together with “signatures or it didn’t happen”, RAINS can completely separate the “what” of an assertion from the “where”, allowing topologies and protocols for name services wildly different from those predominant in the DNS.
A third but still important feature is that RAINS' design separates information model from data model from protocol mechanics (or, for OSI fans, has distinct application, presentation, and session-layer parts). This seems to me to merely be good protocol engineering in the 21st century, and something not available to work on DNS because of the inertia of its legacy. (I for one find DoH’s design hilarious in that a DoH query contains a base64-encoded normalized DNS packet in its URL. Elegant given the constraints of the requirements, yes, but to me that design says more about the evolvability of DNS than any snarky blog post ever could.)
For the rest, go have a look at the draft.
