A question for you all: Tor, DNS, URIs, generic TLDs, and a return to flat namespaces?

Here’s an example URL:

scheme://host.domain.tld/path/file.ext

This matches most of the URLs that you will ever encounter on the Web; don’t nitpick it too much – there can be hanging directories, portnumbers, user:password@host... additions and even full-blown URIs, but overall it’s a pretty good example.

But there’s an open problem – the URL syntax does a very good job of abstracting and separating the scheme, the host/location and the path/resource – but it assumes a unified name lookup service. A URI assumes that there is essentially only one host.domain.tld, and that it is resolvable in the DNS – except this is not exactly correct, and is likely soon to be very wrong.

Examples:

Examples of the above:

– are not like content-addressable Magnet Links because (obviously) we are not talking about content-based addressing; instead the magic cryptobabble represents a real machine to which a real connection is made, and over which real HTTP is spoken; so this challenge is not addressable by futzing with the scheme (tor-http://...)

The tactic so far has been to create fake top-level-domains like .onion – which is great, and even has historical precedent, but even though the recent approval of the .XXX top level domain is causing a ruckus, it seems pretty likely that more and financially-attractive-to-ICANN top level domains will arise.

This would flatten-out the DNS in a manner akin to UUCP or BITNET – where intra-domain hierarchies represent some clan-like hierarchical granularity, but between domains anything would be possible; I could call dibs on www.alec.muffett and have my nameserver at ns0.alec.muffett, and my cousin could have www.duncan.muffett – but anyone with the surname “onion” cannot do this because they’ll clash with Tor.

Hence the Fake TLD is probably a bad mechanism. Maybe someone farsighted at the IETF would be interested in:

scheme://resolutionamespace::host.domain.tld/path/file.ext

…instead? Or ideally something ideally better than that grotesqueness?

8 thoughts on “A question for you all: Tor, DNS, URIs, generic TLDs, and a return to flat namespaces?

  1. Peter da Silva

    Just create an arbitrary domain dedicated to the namespace, and have scheme: recognize it. Eg: tor://dsjdaskdjlsa.onion.magicword.xx/

    You could make the actual magicword.xx domain return an explanation for all pages.

    Reply
    1. alecm Post author

      @Peter: your example means ensuring that

      1) all HTML is relative-linked (which is almost fair)

      2) all browsers understand the “tor:” scheme (unfair, if Tor access is being implemented by a sitewide proxy that otherwise hides all the magic)

      3) that “.magicword.xx” is proof against domainjacking by ICANN and/or is guaranteed to be processed first in name-resolution, before a recursive resolver punts the request elsewhere and returns either “Unknown Host” or (worse) a trojan site.

      Reply
    1. alecm Post author

      @daniel: i don;’t think it is moving the problem around, because the idea is a notation outside the scope of a hostname within a URL.

      so http://dns::www.crypticide.com:8080/index.html and http://p2p::alecmuffett:8080/index.html might be equivalent.

      anything lacking the :: syntax would default to dns::

      i’ll be the first to admit that it’s not elegant, since it’s actually trying to control both name resolution and to some extent the means of establishing a connection, in both cases running HTTP over the resulting socket; but I think the idea advances the concept a little…

      Reply
  2. Dogsbody

    We we need is some sort of ID mechanism of all objects and beings. Fully flat with no hierarchy… some sort of mandatory ID card….. ;-)

    Reply
  3. Daniel

    Regardless of elegance, it generally sounds good because it is going towards decentralisation.

    But from the point of view of the ‘Fake TLD’ problem, in a world where we have shared namespaces, I’m not sure how the namespace notation of the URI would fix it. Who would define these namespaces and make sure there are no clashes? This is what I meant by moving the problem around. What am I missing?

    Reply
    1. alecm Post author

      I don’t think you’re missing anything; I just believe these issues generally sort themselves out, a-la crowdsourcing, and then the IETF eventually standardises it or ICANN comes up with a solution…

      Reply

Leave a Reply