An attempt to structure the field.
12-14-2010, 06:01 AM
Post: #1
An attempt to structure the field.
These days I gathered thoughts about decentral DNS.

It's too much to post in a forum.

Sources where the p2p-dns irc last month, this forum (just now) and my own experiences from implementing a p2p system.

I hope they will useful to structure the field a bit an connect frequently asked questions to their frequently proposed solutions.

Find it here: http://idons.askemos.org

Best Regards
/Jörg
Find all posts by this user
12-14-2010, 01:55 PM
Post: #2
User Experience
What worries me most ist, how the ordinary user will perceive "yet another way" to find an address on the internet.

For the time being, not even how any party would try to shape the public opinion towards whatever interest. The only question is, how this "yet another way" is going to be "enabled" for the end user.

For that matter any second(ary, unofficial, etc.) way..

Dr. med. Grandma want's to have just one button to be push.

But not just that; her rightful SPAM worries: Right beside this button there MUST always be the link to "disable this source". Hence OptIn and OptOut need to be equally (and very) easy to do. (Which indicates to me that the user interface has to be part of the client machine, not any web page. Web pages might suddenly change to a new version - making suspicious.)


Right now it's no big deal to configure any network in such that your "local DNS" overlays the global one. Just modify the configuration.
And that is basically what the software magically behind the "enable" button would do in practice.

The open question wrt. user experience is: how would the ordinary "Dr. med. Grandma" get started to use this magic? All sudden, she would need to deal with new concepts.

There is not just "the phone book", it's a bookshelf now. It does not yield either one or nothing, it yields none, one or a selection of results.

This in turn effects all software, which ever digs into DNS. Each would in one way or another need to return a "compatible result" (i.e., one/none) for the sake of compatibility.

((Let alone that the 2nd most important application of the internet often relies on a HTTP "Host" header. All clients would somehow need to be able to send the "published" host header according to the servers idea, while resolving the locally defined name and display that one in the URL bar.))

Ref: http://idons.askemos.org/MechanismSoftwareClient

/jfw
Find all posts by this user
12-14-2010, 03:28 PM
Post: #3
RE: An attempt to structure the field.
In the model of Name -> Identifier -> IP Address, what goes in a URL's host field or the host part of an email address is the Identifier (or a textual representation thereof). The mapping of Identifier -> IP Address is one/none.

At that level, the only transition issue is when URLs start appearing with IDONS Identifiers in them instead of Domain Names and someone is running a web browser that has not yet been updated to understand IDONS.
Find all posts by this user
12-14-2010, 03:45 PM
Post: #4
RE: An attempt to structure the field.
(12-14-2010 03:28 PM)rev412 Wrote:  In the model of Name -> Identifier -> IP Address, what goes in a URL's host field or the host part of an email address is the Identifier (or a textual representation thereof). The mapping of Identifier -> IP Address is one/none.

Agreed.

But as I tried to detail: the user experience is name -> IP. Any additional indirections are "only technical".

(12-14-2010 03:28 PM)rev412 Wrote:  At that level, the only transition issue is when URLs start appearing with IDONS Identifiers in them instead of Domain Names and someone is running a web browser that has not yet been updated to understand IDONS.

That's the very point! Only when Dr. med. Grandma wants to use it, problems will start. A programmers messing with their own DNS are a dime a dozend already.
Find all posts by this user
12-14-2010, 05:50 PM
Post: #5
RE: An attempt to structure the field.
The user experience currently is Name -> IP Address, no question. For example, if we want to change away from DNS, that user experience will change. If we want to avoid the trademark problem DNS has, Names are going to map to multiple, different answers. In other words, it will no longer be Name -> IP Address. This is not only technical, it's going to show.

And if we're going to field a new protocol, there are going to be people who have old software that does not implement this new protocol. They won't be able to play until they update their software. The people still running IE6 are just out of luck.

Although, I suppose I could imagine going back to the suggestion that was not well received of taking a new top-level domain .idons for the syntax of the new Identifiers. With this, we might imagine building DNS servers that serve up answers from the IDONS protocol on the other side. But there are good reasons to want to stay clear of the DNS namespaces and its politics.
Find all posts by this user
12-14-2010, 08:40 PM
Post: #6
RE: An attempt to structure the field.
(12-14-2010 05:50 PM)rev412 Wrote:  The user experience currently is Name -> IP Address, no question. For example, if we want to change away from DNS, that user experience will change. If we want to avoid the trademark problem DNS has, Names are going to map to multiple, different answers. In other words, it will no longer be Name -> IP Address. This is not only technical, it's going to show.
I disagree. When do users see IP addresses? I see them when I use nslookup or digg or ping or traceroute - but the vast majority of people have never used these, don't know what they are for (there was a hilarious, apparently serious, post somewhere by a teenage "hacker" who ran traceroute to a site and thought that all the addresses he saw were people connected to the site!). Sure, many people have seen the explanations that IP addresses are the "real" ones, but that kind of thing is generally forgotten quickly, because frankly it just plain doesn't matter to almost anyone, ever. (I'm sure a phone number maps to some internal representation in SS7 but I have no idea what that might be and it makes no difference to me.)

What a user sees is a map from a name to (typically) a Web site. Nothing more, nothing less. There are no intermediate steps.

                                         -- Jerry
Find all posts by this user
12-15-2010, 03:33 AM (This post was last modified: 12-15-2010 03:36 AM by jfw.)
Post: #7
RE: An attempt to structure the field.
(12-14-2010 08:40 PM)leichter Wrote:  
(12-14-2010 05:50 PM)rev412 Wrote:  The user experience currently is Name -> IP Address, no question. For example, if we want to change away from DNS, that user experience will change. If we want to avoid the trademark problem DNS has, Names are going to map to multiple, different answers. In other words, it will no longer be Name -> IP Address. This is not only technical, it's going to show.
I disagree. When do users see IP addresses? I .... What a user sees is a map from a name to (typically) a Web site. Nothing more, nothing less. There are no intermediate steps.

Name->IP is used above in an allegoric way: user enters a name.. magic.. web page shows up. We know: last step in magic: find IP.

The problem stays the same as in http://idons.askemos.org/MechanismSoftwareClient

IDONS will hardly replace DNS. It may extend it. Probably (mostly) protocol compatible at least up to a certain point.

I'm not positive at all, that IDONS can avoid trademark problems. Those are legal matter. All it can do about it: give the user/admin the freedom to change their personal view the way they want it to be. That would be: create an infrastructure and user experience as similar to DNS as possible. The only difference from an admin(user) point of view: there are many roots to selectively choose from.
(see also http://idons.askemos.org/SRS .)

And that's what rev412 pointed out: This is not only technical, it's going to show.

I can only second that. The billion bugs question: how to present that change to the end user.

/jfw

BTW: I believe this topic where better in: http://forums.gctip.org/thread-84.html (Wile E. Coyote, ACME, and TLDs).
Find all posts by this user
12-15-2010, 06:57 PM
Post: #8
RE: An attempt to structure the field.
(12-14-2010 05:50 PM)rev412 Wrote:  If we want to avoid the trademark problem DNS has

We can not avoid 'trademark problem'. Its a daydream we could.

For the users and for the judges technical mumbo-jumbo and precious briliant dissociation on code level will not count once they type trademarked-thing and will see counterfeits-site.

Once IDONS techies tell the judge it is impossible to prevent such misuse, process of woldwide banning IDONS will begin. Law provisions for such ban are in ACTA treaty already.

(12-14-2010 05:50 PM)rev412 Wrote:  Names are going to map to multiple, different answers.
In other words, it will no longer be Name -> IP Address.

Then, in other words, it will no longer be Name System, it will be roughly tunable barely predictable search engine then.

I agree with Lauren, that we may use random unique ID. But I disagree we can use it as the main indexing vehicle. Users know names, not bits. That ID should be ID of registree.

I could slightly modify NS record structure and add Registree ID field as a second to DNH index then give registree ability to have multiple but still worldwide unique DNH fields she or he can change at will.

Registree as owner and the sole authority of the entry can point it wherever s-he wants. S-he also is responsible for lawful creation of hers DNHs.

[for the acronyms above see Distingushing namespace thread].

Name System - at least as I see it - should be very basic service of translating what human can type to something machine can use.

TODO:
1. Check whether some 'wise' folks have not patented core concepts from the bsd licensed code of kademlia-dht.
2. If its patent clean, get authority source hash living on kademlia (to prevent censorship). If its not - see alternative dhts.
3. introduce 'dispute tree' aka let lawyers to act when they are paid to do so and yet let user to choose whether s-he wants to use DNH in question.


Regards,

--
Wojciech S. Czarnecki
OHIR-RIPE
Find all posts by this user
12-15-2010, 08:11 PM
Post: #9
RE: An attempt to structure the field.
(12-15-2010 06:57 PM)ohir Wrote:  Then, in other words, it will no longer be Name System, it will be roughly tunable barely predictable search engine then.

The first step of translating Name -> Unique ID? Yes, exactly. The second step of ID -> IP Address? Incorrect.

So, are there serious efforts out there to shut down the web or search engines because of web sites that counterfeit trademarks? No, they go after the trademark infringer directly. The web itself is left out of the issue, as it should be. This is what I'd like for the name system and one of the big reasons why I want to make the primary key into the name system be not a human friendly name.

Quote:I agree with Lauren, that we may use random unique ID. But I disagree we can use it as the main indexing vehicle. Users know names, not bits. That ID should be ID of registree.

This is a serious issue. What I'm suggesting, if it's even possible technically, would be a major change for users and users don't take kindly to that sort of thing. This is the most likely failure of any proposal to change to a different name system (or to make any change really). But of course, if you come up with a name system that works just the same, so that users would have no difficulty changing, then there's no reason to change in the first place.
Find all posts by this user
12-15-2010, 08:40 PM
Post: #10
RE: An attempt to structure the field.
An allegory from the history of technology. Once upon a time, cities were lit with gas. There was a sophisticated infrastructure in place to deal with the distribution of gas to lights, armies of workers to light them each night -- it was inconceivable that a wholly different system could replace it, or that consumers would embrace such a dramatic change.

But change it did over time, as we know, with a whole range of collateral problems caused by gas lighting eliminated, and a vast array of new applications appearing that were empowered by the replacement technology.

End of allegory.

--Lauren--

Lauren Weinstein
[email protected]
GCTIP Founder
Visit this user's website Find all posts by this user
12-15-2010, 08:54 PM
Post: #11
RE: An attempt to structure the field.
(12-15-2010 08:11 PM)rev412 Wrote:  So, are there serious efforts out there to shut down the web or search engines because of web sites that counterfeit trademarks?

Yes. Exactly. It is named ACTA.
Second is so called 'Intelectual Property Theft' that ACTA deal with too.
Third is anyleaks governments want to shut down in hurry.
Fourth is any inpopular view any majority wants to disappear.

And thats why we are disussing here about censor resistant, distributed NS.

(12-15-2010 08:11 PM)rev412 Wrote:  But of course, if you come up with a name system that works just the same, so that users would have no difficulty changing

I came with one long time ago. But one that was not censorship resistant. Nowadays its more important than ever, to have NS that is both hard to censor and is easy to maintain. Including mechanisms that can prevent ACTA attacks on it.

(12-15-2010 08:11 PM)rev412 Wrote:  then there's no reason to change in the first place.

There is. Wikileaks broke the last strains of government's p.c.
Next leaks will disappear from actual DNS right before they publish anything. Or even before they get to anything. In past 11 months I have dealt with multiple projects of internet censorship including one in my home country, neighbour countries and now what we fought in february on local level is pushed thru EC (European Council) and EUP.
In United States right now so called COICA is in the Senate.

So - there is a reason. And it is high time to get backup NS ready.

Being all conscious that right now, just discussing distributed free naming service, we are putting our efforts heads and asses against a huge pile of cash (per year its just around all registered domains * average $9 each).

--
Wojciech S. Czarnecki
OHIR-RIPE
Find all posts by this user
12-16-2010, 05:04 AM
Post: #12
RE: An attempt to structure the field.
(12-15-2010 08:40 PM)lauren Wrote:  An allegory from the history of technology.
--Lauren--

... and for along time to come, gas and its replacement where provided to many housholds.
Find all posts by this user
12-16-2010, 05:39 AM
Post: #13
RE: An attempt to structure the field.
When I use a web browser, I tend to either:

a) visit a frequent site, in which case I type a few characters in the address bar and it offers me a selection of matches.

or

b) use a search engine to find what I'm looking for / follow a link on another page

For (a), if the 'name system' contained both a 'short name' and 'description' for a given IP address, the browser could offer the choices dynamically as the name is entered (similar to the way google instant does with search), allowing the user to choose the specific 'mysite' they wanted based upon the description.

If more authenticity was required, the use of certificates, or 'name records' being signed could help - there's obviously an overhead there but unlikely to be such a problem in the future.

In the case of (b), you'd be just as reliant on SEO as we are today, but I envisage new 'search' dynamics to evolve in the future as the current mechanism is (by the nature of the data involved) becoming more and more biased by necessity.

With a name and description tied to an IP address, signed if necessary to distinguish any remaining uniqueness, there shouldn't be a technical issue. Legal issues (Trademark) are best left to other people to worry about.

As to the task of users being confused, history shows that the 'Field of Dreams' method works well. Once the masses hear about a must-have site being available using a different browser / plugin / etc. they'll migrate and drag others with them - of course, there's a lot to be said for the mass market being coralled into the old system ;)

2p.
Find all posts by this user
12-16-2010, 06:28 AM
Post: #14
RE: An attempt to structure the field.
(Sorry, this post is a bit long. End-of-year bulk of paperwork does not allow me to spend much time here right now.)

(12-15-2010 06:57 PM)ohir Wrote:  
(12-14-2010 05:50 PM)rev412 Wrote:  If we want to avoid the trademark problem DNS has

We can not avoid 'trademark problem'. Its a daydream we could.

...

Once IDONS techies tell the judge it is impossible to prevent such misuse, process of woldwide banning IDONS will begin. Law provisions for such ban are in ACTA treaty already.

Agreed.

(12-15-2010 06:57 PM)ohir Wrote:  
(12-14-2010 05:50 PM)rev412 Wrote:  Names are going to map to multiple, different answers.
In other words, it will no longer be Name -> IP Address.

Then, in other words, it will no longer be Name System, it will be roughly tunable barely predictable search engine then.

That's a) a challenge b) a chance c) IMHO the main problem to think about. It's going to show to the user. So how?

It's not even a bad thing, since it would work like human interaction. If I don't know the address of someone, I ask someone else who might have it. To cope with the "roughly tunable" aspect I'm proposing (see "main problem" above) a client side "eternal" cache of ID's once used/accepted.

(12-15-2010 06:57 PM)ohir Wrote:  I agree with Lauren, that we may use random unique ID. But I disagree we can use it as the main indexing vehicle. Users know names, not bits.

That's true. That's why the system would have to work like a set of phone books to connect names to "random" numbers. (Random for the user, while they are self verifying identifiers to the crypto guy.)

Now trademark's will happily go after the publishers of phone book (i.e., registrars here) ask them to remove entries with trademarks as display name. (Rightfully so: the database publishers just got a special new right (in the CU) on the content of their databases. ;-)

At the same time, the claimed "random" unique ID not effected. It does not even have to be registered in any central database, since it can proof itself. There is no reason to go after the software.

Maybe I should put it all the other way around: once IDONS is there, the DNS is no longer the only way to resolve names on the internet. But neither will be IDONS.

Or will it? -- That depends on the question, whether or not the IDONS project will either focus on a software technology to enable arbitrary many name registries in parallel or focus on creating one registry, which follows a certain registration policy. Or split these two apart.


I myself will - once done with the daily business - try myself on a prototype implementation along the lines of ohirs proposal.

Let me outline what I'll do where I foresee that I'll get stuck.

So far I have a network of 8 peers in different cities. (Plus several personal peers most of which I do not control, which are disconnected most of the time.) Some with static IP some on dial up.

The network keep an internal map from self verifying identifiers to current IP addresses. That is, each peer knows about 10-20 peers, no more. One peer registers the ID's of peers currently connected in our DNS server.

(In a way, there's where I got stuck several weeks ago: the current code is too simple. All peers run several virtual hosts - like idons.askemos.org , but not all vhosts run at all peers; the can of worm is open already: when updating bind, it's not only to register the ID, it's also to change the effected virtual hosts.)

For the prototype I would create a SQL database and some registration logic as ohir specified - and see how far I can get.

Mirroring that database in bind should be simple enough.

For the prototype I would not think much about the client software, just configure a local bind server to resolve local before idons before everything else.

Once here, it would be simple to create a distributed database from the prototype. 5-9 of you people could join the quorum. Byzantine replication; No more central authority. If those where spread over the globe, not even a single jurisdiction. (At worst, I would have to mail you one of these bricks ;-)

Next problem: trademarks and legal trouble. For sure some of you might not be allowed to resolve certain names to the public. So: add filter logic when mirroring the database in DNS and comply with the order.

So far we would have a prototype for a p2p DNS registry.

And two problems:

a) Now I would have to come back and ask: we've got the mechanics working, what's the registration policy it shall adhere to?

b) How would Dr. med. Grandma get to use the registry?

For the time being, it might work to grab .idons. Any better solution?
Find all posts by this user
12-16-2010, 09:16 AM
Post: #15
RE: An attempt to structure the field.
I would strongly recommend against rushing into any implementations at this time. Very premature. I'm also seeing in this Forum some references to ACTA (which has been considerably watered down) and other legislative efforts -- not to mention trademark law -- that are not in sync with what I hope is my fairly robust understanding of the related issues.

A key reason for decoupling "random string" identifiers from the names that people and applications use to refer to them, is to move trademark issues out of the namespace. The reason trademarks have become such a big problem on the Internet isn't that there are 1000s of ACMEs -- because there are and trademark disputes between them in the brick and mortar world are relatively rare. The problem is that the existing DNS grossly overloads any possible DNS namespaces by creating a situation where there is enormous competition for single "identifiers" (which are directly human readable at the global level) on the Internet.

And even then, trademarks do not necessarily trump (and often do not win) in domain name disputes -- so what we're really talking about is the broad issue of competition for Internet names, a bad situation that has been created specifically by the TLD model (not by design of course, but as a consequence of the Internet's growth and evolution).

IDONS, by banishing that model to the pages of technology history, does not create such scarcity at all. Will there still be trademark disputes? Sure, but likely only of the "traditional" variety that are not Internet specific.

Once naming scarcity is removed -- and naming becomes a much more localized construct -- the game changes enormously in a positive way (not perfect, but positive).

--Lauren--

Lauren Weinstein
[email protected]
GCTIP Founder
Visit this user's website Find all posts by this user
 


Forum Jump: