Deconstructing DNS

[rev412]

Whenever I try to figure out how multiple hierarchies might work, it seems that there would have to be a means by which you name which hierarchy you're using. But that's just another level to the hierarchy and you'd need some mechanism for registering those names and that has just become your new root. Not so good.

[Joe]

To clarify, the level of trust I'm referring to here starts with "I'm where I say I am" for the address, and "I answer to the name I've given you" for the name.

What I had in mind is that any particular namespace would be hosted by multiple computers (most likely *all* of a community's members). In order for a newcomer to enter a community it would have to convince some portion of the membership that it should be admitted (and not raise a red flag with any of them). At some point after being admitted, the new member may be trusted to replicate and accept changes to the community namespace.

Each community would set appropriate requirements for new members to prove their trustworthiness.

This should provide an adequate foundation for as robust a trust infrastructure as needed for each community.

[bug1]

There could be different trust models for "trust to provide a translation" and "trust to maintain uniqueness".

"Trust to maintain uniqueness" would probably be a boolean value that is a requirement to be part of the group, it has to be agreed to before acceptance, and removable if it does something wrong.

"Trust to provide a translate" is something that would have to be earnt over time, so it would have to be a more granular value, would start low, and increase as its peers verify its response (somehow).

I suspect most of this could be automated, except the initial "trust to maintain uniqueness", how do you decide if you should trust a stranger ?

Perhaps it could be based on need, those we few peers might be more willing to take more risks to get more well known.

Sounds like an issue that needs heavy research.

[Joe]

Agreed. I don't think there'll be a one-size-fits-all solution. We should aim to provide parameters that can be tweaked and then see how it ends up being used. We may be able to do more after learning from that.

Regarding "trust to maintain uniqueness" goes, the only uniqueness I see in this system is the identifier. We'll need to support many-to-one relationships for everything else.
"Multiple names -> uid" will be needed to support aliases
"Name -> multiple uids" will be needed to support high availability
"multiple uids -> address" may be needed to support paid hosting
"uid -> multiple addresses" will be needed to support multi-homed or multi-protocol (IPv4 / IPv6) systems

The trusts I see are:
"Issue uid" requires uniqueness
"Manage names"
"Manage addresses"

[bug1]

A question we need to consider on "trust to maintain uniqueness" is;

Imagine two people create the same UID with a different signature, perhaps its a deliberate attack, or maybe just rare coincidence, how do we handle it ?

[jfw]

I see two parts in this discussion

1. Trust in a certain name resolution (maintain uniqueness)
2. "Trust" or rather "authority about trust preferences" in possible name resolutions.

#1 concerns http://idons.askemos.org/RegistrationPolicy (an open field for activity once IDONS works) and http://idons.askemos.org/MechanismSoftwarePeer . That's the easy part of the game.

#2 is about http://idons.askemos.org/SRS and effects the actual user interface/experience. Client software http://idons.askemos.org/MechanismSoftwareClient needs to deal with is, probably interacting with the end user.

The hard part is #2.

((Let alone dealing with lauren's can of worms about how to integrate the whole thing into web browsers. At one side of the wire, we would ask for the local name me,mycardealer,external. That could map to whatever server side. But the web browser would need to send www,mayorcardealer,trademarkoffice as host header.))

/jfw

[Joe]

(12-15-2010 01:50 PM)bug1 Wrote:  A question we need to consider on "trust to maintain uniqueness" is;

Imagine two people create the same UID with a different signature, perhaps its a deliberate attack, or maybe just rare coincidence, how do we handle it ?

My initial reaction would be to go by the timestamp. The first one to register wins.

Assuming trustworthy IDON server(s), the only way this could happen would involve multiple IDON servers and the same uid being generated by both within the replication timeframe. We could craft the algorithm so that different servers can't generate the same uid. Perhaps seed a uid generator with a hash of the server's uid and the requestor's MAC address? I would have to defer to someone with more knowledge than myself.

[ohir]

(12-15-2010 02:10 PM)Joe Wrote:  

(12-15-2010 01:50 PM)bug1 Wrote:  A question we need to consider on "trust to maintain uniqueness" is;

Imagine two people create the same UID with a different signature, perhaps its a deliberate attack, or maybe just rare coincidence, how do we handle it ?

My initial reaction would be to go by the timestamp. The first one to register wins.

We not need to deal with it at all if we have registree id decoupled from names (DNH, name hash) and registree then is free to create any unique DNH she wants and use it from now on. It still leaves 'DNH flood' hole that need to be dealt with. Perhaps by limitting the maximum DNH one entity can hold.

* at entity registration, assuming random RIDs, both (equal) clashing ids are disposed and new ones are generated.
* if two parties within small timeframe try to set up identical DNH, both entries are purged from system then whoever will be first to set it up wins. I.e. one that propagated to m of n authority nodes.

Regards,

[Joe]

(12-15-2010 02:09 PM)jfw Wrote:  ((Let alone dealing with lauren's can of worms about how to integrate the whole thing into web browsers. At one side of the wire, we would ask for the local name me,mycardealer,external. That could map to whatever server side. But the web browser would need to send www,mayorcardealer,trademarkoffice as host header.))

/jfw

I got the distinct impression that Lauren does not want to integrate into *any* web browser. To try to browse to one name by looking up another would be problematic at best. Lauren, could you clarify your intent?

My own opinion is that we're opening up a brand new namespace. The names should be available to any network application. They should be acceptable for web browsing, ftp, ping, whatever.

The compatibility layer should be within IDONS itself. If IDONS receives a name resolution request for a DNS name (based on the syntax of the name) it should return the same results as a DNS server would.

However, when it receives a request using the IDONS syntax, it should do an IDONS lookup.

My recommendation for the IDONS syntax is to use parenthesized community names, e.g. (Main Street)(Walmart) or (Gamers)(FPS)(Home).

- Joe

[lauren]

(12-15-2010 11:57 PM)Joe Wrote:  I got the distinct impression that Lauren does not want to integrate into *any* web browser. To try to browse to one name by looking up another would be problematic at best. Lauren, could you clarify your intent?

My own opinion is that we're opening up a brand new namespace. The names should be available to any network application. They should be acceptable for web browsing, ftp, ping, whatever.

The compatibility layer should be within IDONS itself. If IDONS receives a name resolution request for a DNS name (based on the syntax of the name) it should return the same results as a DNS server would.

However, when it receives a request using the IDONS syntax, it should do an IDONS lookup.

The names should be available for IDONS resolving as required by any application, though the results could vary, just as email now will usually get an MX record rather than an A record. Applications could alter the way the results appear to users, however. So in a Web browser, what the user sees in the address bar (or Omnibar or whatever) could, for example, be a simplified version of the full result (with some mechanism to see the entire thing on demand).

My assumption is that IDONS "stacks" would pass old-style names to existing DNS (e.g. bind) systems for handling of those names. This might be done locally or perhaps through gateways for those sites who never have had (or no longer have) an interest in dealing with DNS-style names directly.

--Lauren--