Hacker News Reader

Comment by wtbob | Hacker News Reader

It doesn't actually matter: in a world which used that sort of addressing, one could imagine saying to com 'give me HTTP info for your example/foo/bar/baz,' to com/example 'give me HTTP info for your foo/bar/baz' and so forth; in that case, com would just say, 'hey, go talk to 266.328.0.1 (that's what I call example)' and 266.328.0.1 would cheerfully return the information stored at the filesystem path /foo/bar/baz, or it could say, 'hey, I call foo 463.622.42.17' and your browser would keep resolving.

Me, I kinda wish we wrote URLs as http://com.example.host.invalid/path/to/resource.

View on HN

> Me, I kinda wish we wrote URLs as http://com.example.host.invalid/path/to/resource.

The UK's predecessor to the DNS worked this way (a "big endian" hierarchy). Sorry I can't remember the network name; if I remember it was rooted in gb.

JANET, which routed email to Czechoslovakia, as the legend goes...

Back then mainly the Computer Science departments had email, so they'd have domain names beginning with a cs. in the ARPA scheme, but, since JANET did it backwards, you'd have to rearrange the domain name so it ended with a .cs for that network. If you did that and didn't reverse it back, the domain name would have a ccTLD of .cs, which is what Czechoslovakia used.

(The .cs ccTLD existed until 1995, years after Czechoslovakia ceased to. The .su ccTLD (Soviet Union) still exists.)

I am old enough to remember the final year of JANET with the backwards addresses.

At the time I was at Plymouth Marine Laboratory with a university email address of the type researcher@uk.ac.pml - i.e. backwards. However, in those days there were many different things about networks, you could have several connector types in a room so anything beyond email was a bit like the difference between travelling across state borders in the U.S. and travelling across the Iron Curtain. I can't remember how one got from one's VT terminal to the wider internet on VAX/VMS but that was possible. FTP and some Telnet was how it worked, none of this www stuff.

The change of address structure to normal internet style was not that big of a change, you would think it would have been as traumatic as changing what side of the road to drive on or the Millennium Bug, but, the change happened with no huge amount of work needed or resultant disruption.

I am old enough to have been a JANET site administrator.

The JANET when I used it ran over a private X.25 network with a few gateways to BT's public X.25 network. There was a gateway to the internet at University of London Computer Centre but it only provided an FTP client.

Of course that combined host/path winds up leaking not just what hosts you are interested in but what specific resources you are after to your DNS resolver - would be quite damaging to Privacy and security of https

I guess rather than handing every resolver the full path, you could go "give me example" and then respond depending on it giving a address or a directory listing in return.

True; as digi_owl indicates, you could only ask for the next element in the path, too.

Also, you are implicitly trusting each level in the tree to be honest, anyway: even if you say, 'hey com, give me example,' he could always give you the address of a computer he controls instead of the real com.example, and thus get the next item in the path from you when you ask him to resolve it.

You can't get away from trust: whether it's trust in DNS, or trust in CAs, or evne trust in the great masses reporting public keys seen in the wild, you can't get away from trust.

That's very interesting! Removing the separation between DNS resolving hosts and applications resolving paths. All paths could be resolved by a hierarchical DNS-like system which you also ran inside your service to route requests to subfolders. Cool.

Reply on news.ycombinator.com