Hybrid resolvers and the shape of an identifying token

[simon_brooke]

DNS names have hierarchically constructed names with the elements being separated by the period ('.') character. If IDONS is to supplant DNS, then it must do so over time; we can't have a magic switch-on day on which everyone switches to IDONS, because that simply won't happen. So for a period of years we will need hybrid addressing schemes in which some names are resolved through DNS and some names resolved through IDONS, transparently to the user - so that the user can type the DNS name of one website and the IDONS identifier of another into the address bar of the same browser, and have both resolve without fuss.

Furthermore, the distinction must be entirely clear and unambiguous - no-one should be able to register, in IDONS, an identifier which is lexically identical to the DNS name of my bank, for example.

Do we have a notion, yet, of what the overall shape of an IDONS identifier is likely to be? Could we establish as a rule that the period character ('.') cannot be a valid character within an IDONS identifier?

Following from the above, do we assume that (given an appropriate resolver) an IDONS identifier can be used as the host part of any arbitrary URL? If so, it must observe lexical rules whjich are unambiguous within the overall lexical structure of a URL. Thus '@', ':', '/', and '?' also cannot be a valid characters within an identifier, because their use would be ambiguous with their special functions within [protocol-part]://[username-part]:[password-part]@[host-part]:[port-part]/[path-part]?[query part].

[bmanske]

Good food for thought and an obvious starting point. I would also like to remind everyone to consider unintended consequences and/or associations with historical constructs. For example, I believe that something that looked akin to a UUCP bang path would probably be a bad idea.

To coexist and quietly usurp (because of monetary and technical merits) should be the goal. ...And that goal won't happen overnight.

Also consider the implications of ICANN allowing (at some unknown future date) arbitrary top-level domains (probably for sale to the highest bidder) and what that means in relation to the chosen IDONS naming system.

Anyone else have anything to add?

(12-13-2010 05:30 AM)simon_brooke Wrote:  DNS names have hierarchically constructed names with the elements being separated by the period ('.') character.

[simon_brooke]

(12-13-2010 12:11 PM)bmanske Wrote:  Good food for thought and an obvious starting point. I would also like to remind everyone to consider unintended consequences and/or associations with historical constructs. For example, I believe that something that looked akin to a UUCP bang path would probably be a bad idea.

To coexist and quietly usurp (because of monetary and technical merits) should be the goal. ...And that goal won't happen overnight.

Also consider the implications of ICANN allowing (at some unknown future date) arbitrary top-level domains (probably for sale to the highest bidder) and what that means in relation to the chosen IDONS naming system.

Anyone else have anything to add?

(12-13-2010 05:30 AM)simon_brooke Wrote:  DNS names have hierarchically constructed names with the elements being separated by the period ('.') character.

I don't (yet) have a full enough understanding of the conceptual structure of an IDONS identifier to know what lexical constructs would potentially be useful. But the first thing is it is not a hierarchical identifier. There's no notion of a hierarchy of elements. The UUCP bang path was not, of course, a hierarchy of elements, but a specification of a route from here to there - so it was specific to a particular sender-receiver pair, not a global address for a receiver. So it too doesn't provide a conceptual model for what we're trying to do.

There is use in having a notion of 'hereness' or 'locality', whether that locality is geographical or virtual. For example, we're used to addressing machines on our local LAN without having to use their fully qualified domain name. When our kids tell us that they're going to be playing at Fred's house, they don't normally fully specify which Fred, because that's captured in the context of their known web of relationships - only if they have two friends called Fred will they need to disambiguate. But I'm not certain how 'locality', or 'relationship context', can be captured in the IDONS namespace.

A nameable entity may expose different services on different physical internet protocol addresses. For example, my web server may be at 217.34.156.188 and my mail server at 217.34.156.184. It's useful to be able to capture within the names which can be resolved to those addresses the fact that they expose services for the same entity - in the DNS world we've grown used to using 'www.foo.com' and 'mail.foo.com'. It would be handy to be able to represent the fact that these addresses have particular functions ('www' and 'mail') and perform those functions for the same nameable entity ('foo').

[bug1]

You raise an important point, we dont want to confuse our hostnames with ICANN's.

Just to throw some other ideas around, instead of banning a character required by ICANN's hostnames, we could including one of their banned characters in our hostnames, but then if they change their rules it can hurt us.

Or we could "invent" our own tld and use it to grandfather in ICANN names, like if we see amazon.com.icann we dont try and parse it, we leave it to the traditional dns system. That would leave us free to use '.' in our names, downside would be people would inevitable forget (or not be aware of) the extension and accidentally going to amazon.com in our system.

';' is a special character we can add to the list of '@', ':', '/', and '?', its used by a few URI's sip for example.

Another thing we might need to consider is internationalization, different languages and character sets. But im not sure what considerations it requires myself.

[rev412]

It seems that the easiest way to do this would be to just usurp an unused top-level domain, say .idons. Software that doesn't yet implement IDONS will simply fail on the name lookup and return an error; at least it won't crash, probably. So long as ICANN isn't so vindictive as to then go and assign that TLD, no problem. If there turns out to be structure in the IDONS names, we could still use dots for separators. Something like asdf.trew.iutt.IDONS ought to work just fine.

I might also suggest changing http:// into http-idons://asdf.trew.iutt/ except that only works for things based off URLs. Name lookups really ought to work for everything that takes a hostname: email addresses, ping, traceroute, various config files.

Staying with the TLD idea, could also go with a single character TLD. I think those are disallowed in DNS somewhere along the line. Not really suggesting this, I like .idons better, just another idea.

If we go with something that looks entirely different, besides avoiding bang paths, I'd suggest avoiding looking like IPv6 addresses as well.

---

Your comments on http://www.foo and mail.foo are very well taken. This is another area where the DNS went off the rails. People wanted the ability to name entities functionally, the hammer they had was DNS, so that's the nail that was invented. That, along with the desire of people to have a single name for a set of servers (I think they may be related), should be given very careful consideration.

[lauren]

I would be decidedly unenthusiastic about any bastardization in the form of "fake" TLDs and the like. Forget about TLDs -- assigned, unassigned, usurped, or otherwise! Just say NO.

[rev412]

Lauren, I have the same sort of emotional reaction as you to usurping fake TLDs but it has some significant advantages from the point of view of a system architect, as far as I can see. It has the political issue that we're playing somewhat in ICANN's territory and I'd definitely prefer to stay away from that bit of ugliness.

The other "good" way I see is to come up with some syntax to prefix (or postfix) an IDONS identifier to the name. If this identifier is missing, the software assumes it's an old-style DNS name (or raw IP address). The syntax would probably be either a separator character or quotes as in:

IDONS#0x4bd793cae983f
{IDONS}0x4bd793cae983f

Then we start a search for which separator character or quoting characters cause the least disruption in all the places these names will be used.

[bug1]

Another options is to expect apps to resolve it in two steps.

1. Covert idons (or dns) name to IP
2. Use a URI with the already resolved IP.

There is already a URI scheme for DNS lookup, specified in RFC4501 (which i didnt know until 5mins ago).

dns:[//host:port]/]dnsname[?dnsquery]

So for example dns://localhost/www.amazon.com?type=A should return the IP that localhost resolved http://www.amazon.com to

We could have a similar scheme say idons:[//idons host identifier[:port]/]human friendly name[?query type]

This gives us more control over our formatting, as it doesnt have to be compatible with other URI's.

e.g. idons://23AC233423/Apple
the string is numbers identifies some idons resolver (be it local or remote) and it tries to resolve ACME on that machine.

Say for example that machine is owned by Apple computers, it will resolve the IP to apple computers IP's, but if the resolver was owned by Apple records it would resolve to apple records IP's.

The Apple computer resolver machine might ban resolving Apple records and vica versa. So naming specific resolvers could add some authority to the query.

If the 23AC233423 wasnt controlled by either Apple computers or Apple Records then it might return multiple responses, which is where a human has to intervene and determine which one is reight before proceding ot stage2 of using the IP in the URI.

[bug1]

EDIT: a disadvantage with a 2 stage URI resolver is that linking is a problem

[bug1]

I think our hostnames in there full form are going to look pretty ugly, i think its shaping up to need 3 parts;

1. An IDONS identifier to distinguish it from DNS, eg IDONS
2. A unique id to identify the resolver, if its 128 bit (16 byte) at best it would need 20 ascii characters to have a unique identifier (base85).
3. The name to resolve.

Using the RFC4501 style describe above it might look like
idons://12345123451234512345/ACME Plumbing of Someplace

But if we tried to fit all that into a hyperlink using the form IDONS-[[unique id]-][name] it could end up looking like
http://myname:mypq@IDONS-12345123451234512345-ACME Plumbing of Someplace:8080/somepath?query_string#fragment_id

In more general usage where a unique resolver didnt need to be specified it could look nicer, perhaps just
http://myname:mypq@IDONS-ACME Plumbing of Someplace:8080/somepath?query_string#fragment_id

I think we will have to do our best to minimise the need for the non human friendly identifier.

[lauren]

Most or all of the "raw identifier" portion of such strings would presumably ultimately be masked (by default -- shown on demand) by applications in situations where showing such detail normally is unnecessary.

--Lauren--

[leichter]

There are a number of issues here.

First off, it's important to realize that, outside of the techie community, DNS names as such don't matter. To the vast majority of people, "the Internet" is defined by their browser, where what matters is URL's; there are no "raw" DNS names. Outside of browsers, the vast majority of remaining uses of domain names is in email - and there, again, raw DNS names don't show up as such; what shows up is user addresses (name@host), where (a) a couple of hosts (Yahoo, Hotmail, Gmail) account for most addresses; (b) most names are pulled out of address books of some sort directly. It's also worth remembering that the significance of name in mail is given by that names MX record, not its A record, so in some sense host names in mail aren't really DNS host names even now.

In the future, I would expect there to be even less use of DNS names any place users see them.

To the extent this is true, the ability to use existing name resolution code becomes less important. In fact, I would contend that if IDONS solved the problems with DNS just for browsers - say, by making up a new idons: scheme to replace http:/https:, which would differ only in how the "hostname" part of the URL was resolved - it would be a success even if it had no solution for DNS names as DNS names. Add a similar special case mechanism for mail addresses, and so little is left that one might well stop right there.

[lauren]

This seems pretty problematic to me. There have already been various ill-advised attempts to treat "The Web" (as defined by the browser experience) as being suitable for different kinds of DNS lookups than everything else, with pretty nasty possibilities. Remember VeriSign's Site Finder operation back around 2003 or so? To give credit where credit is due, ICANN appropriately killed that one at the time (and even inspired one of my notorious songs, The VeriSign Song).

Anyway, point is that treating browser addresses differently than for other applications/protocols can be a can of worms.

--Lauren--

[leichter]

I'm not saying "treat browser DNS lookups differently from other lookups"; I'm saying "the really important lookups are DNS lookups, everything else is minor". It sounds funny to say it this way, because after all browsers are just one of many classes of programs ... but in fact they are *by far* the dominant sources of lookups today. The only thing that might even come close is email - but as I noted, email has always done different lookups, having been assigned its own (MX) record type in DNS right from the beginning. (No other class of program/TCP protocol was given a private DNS record; I don't think any others exist to this day.)

The VeriSign stuff was possible because DNS resolver results are unauthenticated; you have to trust whoever you talk to. If individual results were authenticated, redirections of unknown addresses by resolvers would be impossible without the willing assent of the program doing the resolution: It has a way to determine whether it should trust the data it gets back, rather than just having to trust the party sending the data. Perhaps you tell your browser to accept DNS resolutions signed by your ISP, but don't tell other programs to accept them (unless they are for hosts at the ISP itself, of course).

Realistically: For all their faults, URI's are closer to what identifiers "ought to be" than raw DNS names are. A DNS name usually has to be supplemented with a port number, and there's no completely standard way to do that. (Many libraries accept the :port convention, but not all do, and no all programs do either. After all these years, you'd think we'd at least standardize that much....) The notion of a scheme in a URI gives it a flexibility missing from raw DNS names. Think again of the MX record: Nothing in a DNS name tells you to look for that rather than an A record. You just have to know. But a mailto: URI is unambiguous.

[simon_brooke]

Guys, I respectfully think there's a lot of point missing here...

(12-13-2010 03:59 PM)rev412 Wrote:  I might also suggest changing http:// into http-idons://asdf.trew.iutt/ except that only works for things based off URLs. Name lookups really ought to work for everything that takes a hostname: email addresses, ping, traceroute, various config files.

Exactly. What we're replacing is just the host specifier. It needs to be unambiguous - certainly to the resolver but ideally also to the user - whether a given host identifier is an ip address (dotted quad, matching the pattern [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+), a DNS name (basically a string divided into units by period characters, and not containing some particular specified characters), and an IDONS identifier.

This host specifier has to be capable of being used in any URI/URL, and, indeed, anywhere else that a host specifier can be used. So we absolutely can't require that the host specifier must itself contain a protocol specifier. It, in fact, must not contain a protocol specifier.

(12-13-2010 06:47 PM)bug1 Wrote:  Another options is to expect apps to resolve it in two steps.

1. Covert idons (or dns) name to IP
2. Use a URI with the already resolved IP.

There is already a URI scheme for DNS lookup, specified in RFC4501 (which i didnt know until 5mins ago).

dns:[//host:port]/]dnsname[?dnsquery]

We don't expect users to resolve DNS names in this way, so we must not expect users to resolve IDONS names in this way.

Quote:e.g. idons://23AC233423/Apple
the string is numbers identifies some idons resolver (be it local or remote) and it tries to resolve ACME on that machine.

We don't expect users to know where their DNS nameserver is, we must not expect them to know where they connect to the IDONS framework. We do not expect users to memorise long strings of numbers in order to access DNS, we must not expect them to memorise long strings of numbers to access IDONS.

Quick analogy: the BBC in the UK is trying to persuade radio users to switch from using analogue FM radios to a digital standard called DAB in order to save spectrum. The DAB radios are less reliable than FM radios, have poorer reception, have much shorter battery life and are more expensive. Needless to say, take up is not as fast as the BBC hoped. Users don't really care how name/address resolution happens at a technical level. They want to be able to type a memorable address and reliably access a specific resource.

Users won't adopt a new technology unless it is easier to use and/or offers actual practical advantages to them. If we want users to adopt IDONS, we have to make it at least as easy for them to use as DNS. And if we want content providers to adopt IDONS, we must persuade them that it will not make it more difficult for their users to find them.

(12-14-2010 02:21 AM)bug1 Wrote:  I think we will have to do our best to minimise the need for the non human friendly identifier.

Quoted for truth.

We may appreciate the technical elegance of IDONS. The users don't care. We can invent all sorts of technically wonderful stuff, but if it isn't easier to use than what DNS provides already, the users will stay away in droves. We need to hide the technical guts of IDONS behind a resolver library. Essentially we need to provide a replacement for

struct hostent *gethostbyname(const char *name)

so that every program on the platform which seeks to resolve names transparently becomes automatically able to resolve IDONS names in parallel to DNS names. And then we need to make the IDONS identifiers user-friendly, easy to memorise, and easy to type.