Doubtless the question you've all been asking is where did the // in URL come from? A short answer is
A: I wanted the syntax of the URI to separate the bit which the web browser has to know about (www.example.com) from the rest (the opaque string which is blindly requested by the client from the server). Within the rest of the URI, slashes (/) were the clear choice to separate parts of a hierarchical system, and I wanted to be able to make a link without having to know the name of the service (www.example.com) which was publishing the data. The relative URI syntax is just unix pathname syntax reused without apology. Anyone who had used unix would find it quite obvious. Then I needed an extension to add the service name (hostname). In fact this was similar to the problem the Apollo domain system had had when they created a network file system. They had extended the filename syntax to allow //computername/file/path/as/usual. So I just copied Apollo. Apollo was a brand of unix workstation. (The Apollo folks, who invented domain and Apollo's Remote procedure call system later I think went largely to Microsoft, and rumor has it that much of Microsoft's RPC system was).
https://www.w3.org/People/Berners-Lee/FAQ.html#etc
However, Tim goes on to say
I have to say that now I regret that the syntax is so clumsy. I would like
http://www.example.com/foo/bar/baz
to be just written
http:com/example/foo/bar/baz
which would be terrible, as how would you know where the hostname ends and the filename begins? Forcing a DNS lookup on each segment (com? example.com? foo.example.com? etc.) to see where DNS stops resolving before you've even gotten done parsing the URL seems incredibly clumsy. What happens if there is an example.com/foo, but then someone creates a foo.example.com in DNS? The web and DNS could be handled by different groups who do not really talk to one another, or someone could forget about the foo directory when creating the new host. Does example.com/foo then vanish because foo.example.com now exists?
Maybe the scheme would make more sense if there were a global filesystem, so there might be something like /afs/com/example/foo on every system, and thus only one place that a directory-or-subhostname would appear in that filesystem, but last I looked the Andrew File System (AFS), while neat in various ways, hasn't really gone anywhere, and was requiring slightly insecure DES keys in Kerberos that I dearly wanted to get rid of, the last time I had to indirectly support AFS. Also, there are portability problems that probably stem from the lack of popularity thing.
There are backwards addresses in DNS. These are PTR (reverse) records that map IP addresses to some hostname. The backwardness is so that the folks who operate 104.0.0.0/8 can delegate to whoever controls 104.207.0.0/16 and so forth on down the IP line. There is support for Classless Inter-Domain Routing (CIDR) in the event you have a /23 or suchlike delegated, but the syntax for that always made my brain hurt. Maybe it was hacked into ISC-BIND, poorly? Mostly PTR are relevant to people who want to run SMTP servers.
$ host -t A thrig.me
thrig.me has address 104.207.156.138
$ host -t PTR 138.156.207.104.in-addr.arpa
138.156.207.104.in-addr.arpa domain name pointer thrig.me.
Many DNS tools will know what to do if you give it an IP address so you don't really need to remember how to reverse an IP address into in-addr.arpa form.
$ host 104.207.156.138
138.156.207.104.in-addr.arpa domain name pointer thrig.me.
Actually, how does software tell 1.2.3.com apart from 1.2.3.4?
tags #uri #dns