Deconstructing DNS

[leichter]

Any system that's been around for a while divides up and organizes the world in particular ways. It's easy to come to feel that this division and organization is inherent to the problem, when in fact it may only be inherent to a particular solution to the problem. If you don't realize that, it's hard to come up with really new approaches.

Consider how we interpret a name like http://www.amazon.com. This is a hierarchical name, and we use that hierarchy for a number of different purposes.

1. To assign authority over name spaces: ICANN controls the TLD's; it assigns authority to "amazon.com" to a particular corporate entity.
2. To manage trust. There are several elements of this, so I'll have a couple of items on trust. First, we trust ICANN to arrange to give us correct resolutions of TLD's. We then trust Amazon to give us correct resolutions of names in amazon.com.
3. To manage trust. The whole proposed security mechanism for DNS is just a formalization of the transitive trust model that we've relied on informally for decades: ICANN can sign TLD's, amazon can sign the resolution for names in amazon.com. Nothing changes in principle - we've just added a level of assurance in the possible presence of liars.
4. To manage trust. SSL and certificates are based on domain names, and my extension of trust based on a certificate depends on the hierarchy. When I want a trust connection to Amazon, I am willing to use https to go to any address that ends in amazon.com. Note by the way the inherent assumption here that trust is transitive, and can flow along with name resolution.
5. To control the resolver algorithm. To resolve http://www.amazon.com, I first resolve .com, then use that to resolve amazon.com "within" .com, then use that to resolve http://www.amazon.com "within" amazon.com.
6. To enable human-friendly abbreviations. When I type just "amazon" into my browser, I expect it to add the ".com" for me (unless I'm working on some network where other prefixes are supported - common in corporate environments).
7. To carry basic semantics. Anything in .com is a corporation; anything in .net has something to do with providing network services; anything in .uk is in the United Kingdom. Or at least that was the original intent - granted, things haven't actually worked out that way. (.tv, anyone?)
   

Have I missed any?

All of these features are present simultaneously in DNS hierarchical naming - but there's no inherent reason they have to be. It's valuable to pick any two of these and split them apart: Imagine a system where one was "carried along" with the DNS hierarchy while the other wasn't. For example, there's no inherent reason why my trust that login.amazon.com belongs to Amazon should have anything to do with the fact that it ends in "amazon.com": All I need is a certificate specifically vouching for login.amazon.com that I have reason to trust really belongs to Amazon. (Yes, I know there's actually no such machine.) Much of the security difficulties that arise from companies using multiple names would go away if we didn't have the assumption that Amazon's machine must end with amazon.com.

[leichter]

Ugh. The forum software tried to be too smart for its own good: I gave many examples of DNS names like www[dot]amazon[dot]com which got turned into URL's! I didn't intend for there to be any URL's in that post - so logically strip off all the aith-tea-tea-pea nonsense.

            -- Jerry

[lauren]

I'm sure Amazon won't complain about the extra hits.

[bug1]

(12-12-2010 08:25 PM)leichter Wrote:  Ugh. The forum software tried to be too smart for its own good: I gave many examples of DNS names like www[dot]amazon[dot]com which got turned into URL's! I didn't intend for there to be any URL's in that post - so logically strip off all the aith-tea-tea-pea nonsense.

            -- Jerry

I quote your 6th rule back at you :)

6. To enable human-friendly abbreviations. When I type just "amazon" into my browser, I expect it to add the ".com" for me (unless I'm working on some network where other prefixes are supported - common in corporate environments).

[lauren]

The Forum software is pretty much following the same policy as Google Buzz, almost. This system will take a raw "www.foo.bar" and convert it to a link of the form "http://www.foo.bar" and it lights up all strings that start with typical "http://" prefixes.

Buzz doesn't *convert* strings that look like Web addresses -- and that don't start with (for example) "http://" -- but it lights them as links in their unconverted forms anyway (as well as typical "http://" prefixed strings).

Note that on this Forum if you quote the string in either form it will come through as written and won't become an actual link (as demonstrated above).

I could disable HTML support in these Forums, but that just makes things inconvenient all around.

--Lauren--

[leichter]

OK, so enough about host names versus links. I've been thinking a bit about what a system that decouples all these various features of the DNS hierarchy and reconstitutes them in a different way might look like. Here's one possibility:

A name resolution entry consists of an FQDN (to pick a definite format) and a set of IP addresses that FQDN maps to. It's an assertion that that FQDN should be resolved to those IP addresses.

An authority entry consists of an arbitrary identification string, an authority aspect, a boolean function on FQDN's, and a signing key. It asserts that the authority identified by the string holds the named kind of authority for those FQDN's for which the boolean is true. Traditionally, the boolean function is something like "ends in amazon.com", and the authority aspect is a combintation of at least two elements: "controls names" and "controls mappings". We can allow other kinds of booleans, and may distinguish between an authority that can assign names (think of it as playing the role of the Patent and Trademark office, simply making sure that names in some domain are distinct) and an authority that can maintain resolutions for names.

Either a name resolution entry, or an authority entry, can also contain one or more authority id/authority aspect pairs. These are assertions that the identified authority is attesting to that aspect of the instant entry. To allow this assertion to be validated, the authority also signs the entry.

DNS itself can be modeled quite easily, but note the important difference in point of view: In DNS, I believe information because I received it from a trusted server. (Secure DNS is just beginning to supplement that assumption.) Here, I believe information - however I happened to get it - because it's attested to by a authority I trust, or that was itself attested to by an authority I trust.

[lauren]

Yes, this is definitely along the lines of the "authority paradigm shift" I have in mind.

--Lauren--

[Joe]

I've been thinking about this for a couple of days now...

I think it's important to emphasize that IDONS will need to peacefully coexist with DNS for a time - probably for a very long time. Although the translation strategy will be radically different internally, the prominent external interface will need to mimic DNS: Here's a name - I need an address.

Furthermore, although the naming syntax will by necessity be similar to DNS I think we can afford small deviations to facilitate deciding whether to attempt the translation ourselves or to forward the request to a DNS server. Also, as far as any hierarchy is allowed, I think the order should be reversed so that the name progresses from general to specific in order to be consistent with other accepted naming schemes (modern file systems come to mind).

DNS: host.domain[.domain][...].tld
IDONS: (...)(population name)(community name)(host name)

For example, my computer could be resolved as follows:
DNS: joe-pc.theottos.org
IDONS: (USA)(Colorado)(my city)(my address)(joe-pc)
or
(Game Servers)(Game Title)(my game instance)
or
(Merchants)(Specialty Items)(my specialty)(www)

Without enforcing any particular hierarchy, my computer could be in several different communities in IDONS. Depending on the lookup algorithms and the communities of the requester, some or all of the community names could be left out: (joe-pc)

One thing worth mentioning is that if we make identifiers (UUIDs) the persistent cornerstone of the design, all of our "permanent URLs" will become effectively opaque: http://[72d1cf71ae3c7631][13cd72d84ac29d86][...]/doc.pdf

-Joe

[leichter]

My intent in separating "is trusted to provide a translation" from "is trusted to maintain uniqueness" is exactly to allow for multiple communities, as you describe them. It's the latter that defines the "community".

A while back, I read a description of Japanese trademark law. Assuming I'm remembering this right (and that it hasn't changed in the meanwhile; it was a traditional law growing out of guild practices and such), Japan had a number of defined "trademark realms", based on what you were trademarking. Trademarks had to be unique within a realm, but were unconstraint across realms. The realm definitions were ... odd; the classic example was that all cutlery except for knives fell in one realm, while knives fell in another (which also included things like swords).

If we imagine that different trademark offices are responsible for their own realms, then you get to the idea I'm proposing. Whether I can brand my new knife with a stylized J written inside of a hexagon is a decision for the knife trademark authority. Whether a particular knife with a particular symbol on it really is an instance of my trademark is a question for an expert on how symbols are formed and recognized. (OK, I'm stretching the analogy, perhap beyond the breaking point....)

[Joe]

That's more or less what I had in mind. Name resolution changes internally from "name -> address" to "name -> uid -> address". And the database requirements for each are drastically different - especially when you consider increasingly prevalent mobile devices and the move to IPv6.

Back to the "name -> uid" stage, unless we plan to create, maintain, and enforce a taxonomy of realms (undesireable to say the least), we need to design a way for these realms to self-organize and reorganize as needed. If you toss in that the realms should be highly available and tamper-proof, the problem gets even more interesting.

More later...
- Joe

[bug1]

I dont see how a hierarchy can be part of the solution to trust, it moves the problem to the top of the tree and also concentrates it, this is how we got ICANN.

Multiple hierarchies might be a good source of trust metrics and have other practical uses, but i suspect they might have to be an extension rather than a core feature.

[lauren]

(12-14-2010 02:27 PM)bug1 Wrote:  I dont see how a hierarchy can be part of the solution to trust, it moves the problem to the top of the tree and also concentrates it, this is how we got ICANN.

Multiple hierarchies might be a good source of trust metrics and have other practical uses, but i suspect they might have to be an extension rather than a core feature.

Agreed.

--Lauren--

[lauren]

I believe it's important to emphasize that there is a difference between having multiple "authority contexts" from which to choose, vs. hierarchical resolving (beyond the scope of a single entity's local control) in the manner of the current DNS.

The former would seem to have a variety of useful possibilities, but the latter is to be avoided, for obvious reasons.

--Lauren--

[Joe]

Hmmm... Perhaps hierarchy isn't the right term here. Multi-parented associations, perhaps?

I use my computer at home. My home is in a community. My community is in a city. My city is in a state. Etc.

Although this clearly is hierarchical, it is not necessarily like DNS. If I use my computer for gaming, I may choose to make my computer part of a gaming community. This gaming community may include computers from many locales, and would certainly include computers that are used for various other purposes (i.e. that belong to additional communities). At the same time, that community may be a member of one or more regional gaming communities.

I think communities that are based on geography will likely tend toward an hierarchical arrangement. That's more just coincidence than by design.

As far as trust goes, a core requirement is to allow open registration. From that requirement we'll have to enforce trust from the bottom up - regardless of any community structure that may form in the aggregate.

By that I mean that registration will need to be a process whereby trust is established to some degree before gaining admission to the community. How this is done will likely vary by community. But not establishing trust first will invite dos attacks on the database.

[bug1]

Thinking purely about sources of trust, the only alternative to a centralized authority that i can think of is a web of trust, is there any other type than those 2 ?

The web of trust can be kinda hierarchical, as there can be individuals within the group who are most connected, but its ad-hoc, which i think could still fit Joe's example.