The link structure of the web is almost completely based on domain urls, but I wonder if there's not some way to work around that in a DNS-less/P2P system.
You could most definitely change your links to go to IP addresses. But they're more fragile.
Ironically the DNS actually provides a layer of resilience against being forced offline by targeting your provider, but that moves the vulnerability up one level, now you rely on the DNS to do its thing, and it too is under the control of a single institution.
The bar is a bit higher than a C&D to your provider but apparently not nearly high enough.
The obvious problem is that, to my knowledge, you can't embed a HOST: header in a URL to fetch that resource from an arbitrary IP address (something like http://HOST:www.example.com@192.0.2.144/).
Like HTTP, SMTP servers will gladly accept messages for domains it is configured to handle. But it also depends on DNS to get MX (or A) records to deliver to domains it doesn't handle. It's trivial to support email addresses that use IPs instead of domains (like bob@192.0.2.144), but such addresses are less portable than using domains and also create conflicts because two users cannot have the same name, even if they operate in different realms. Besides, they're butt-ugly and harder to remember than domains.
tl;dr: Using IPs only creates problems and DNS is a HUGE part of the solution. Any replacement will have to solve the same problems.
When the user types http://www.example.com into the address bar, it's the web browser that figures out what to do next. Which is: realize it needs to to a HTTP request. Where to? Not an IP, ask DNS. Now connect to the IP address. But an HTTP server can host multiple domains, so include the host name in the request (that's the Host header). The web server then looks in its configuration, and sends the right page back. Note that the HTTP headers are specific to the application protocol, and are irrelevant both at the DNS and URL level. It just happens to be the same string :)
