💾 Archived View for rawtext.club › ~ak › glog › dns-replacement.gmi captured on 2023-04-26 at 13:34:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-03-01)
-=-=-=-=-=-=-
Those ideas are raw and unfiltered. Written in the hope someone will be able to understand them. If I will have time, I will try to write them down in a more structured way later.
Also, English is not my native language, so sorry for mistakes, if any.
It is obvious for everybody that the DNS system is centralized and has been used for censorship and corporate takeovers in cases of trademarks violations. We need an alternative.
There are a couple of projects aiming to provide us with a replacement. But I think they all share a common issue in design. That eventually will strike us back with a "domain name" takeover or blocking of a domain. I do not believe in crypto-hyped systems as well: I'm sure that companies witch promote them will eventually control their base software and will have the ability to interfere.
The core problem that every DNS systems share, even fancy new ones, they assume monopolistic ownership of a human-friendly domain name. And that is the reason for takeovers: the right to own the name.
In real life, we are all able to handle naming issues. For example, my name is quite common: "Alex". But none of my friends and family find that confusing. They are all able to distinguish me from other persons with the same name. I even have three friends with name Alex and we handing out together with no naming issues.
But how do we solve that issue? We intuitively use different name variations when we are together or nicknames. We choose something unique enough for the current situation. Then we just remembered and used pairs "name" + "identity" within our group. That happens fluently. With no need to negotiate something between us. Imagine a naming system with ownership of names when we all want to own the name "Alex". How many people in the world will compete for the name "alex.com" or "alex.org"?
I've been following the ideas of solderpunk and ploum. I think they think big. And someone was writing about applying "Web of trust" to a system of content distribution.
ploum on "Offline and Distributed Gemini"
ploum on "Offline and Distributed Gemini: Part 2"
But nobody raised the topic that system will be totally dependent on DNS. And naming is crucial for the system to work. I suggest we start to define a new naming system, to make the specification for it. And then using it by conventions developed.
So DNS works like that:
Sound quite long chain? That queue of requests is hidden from us by caching. We see cached responses pretty fast. But the real way to get information looks like above.
Since we live in IPv4/IPv6 world we need a system that can transform names to IP addresses. Let's assume the temporary name for the system to be "local names".
Let's throw away monopolistic name ownership. And instead will think about a name as an alias.
For example, how do you add a person's phone number to your contact list on the phone? You get the person's name and then check your contact list if there is a name conflict. If no conflicts are there then you write the person's real name, but with some tags for yourself to remember (where we met, or where the person works). If there is a conflict then you resolve it by changing the name slightly or by adding more extra information.
In the same way when a user asks for sites available he gets "preferred name" + "naming server IP". And if that name is associated with another "naming server", the system should ask the user about naming conflict resolution. And those names are local only, so the user should be able to write any name he prefers.
Somewhere in the system, there is a file named "~/.names.local"
File contains pairs of records "name" + "address of its naming server". For example, the name server might sit on zaibatsu.circumlunar.space while Gemini web site on rawtext.club:
<name> <naming server IP address> <back naming server IP addresses> "Alex's Public Gemlog" gemini://167.88.113.156/~ak/.names.public
The protocol could be anything we can use to request a text file. The file ".names.public" will contain main IP addresses like that:
SHORT_NAME: ak # Name website might try to claim FULL_NAME: Alex's Public Gemlog # More like expanded name description GEMINI_ROOT: /~ak # Yes, we might link this path as an full domain DNS_NAME: rawtext.club # Just in case ACTUAL_ON: <unixtime_utc> IP4: 45.33.66.185
Caching of them is always a good idea, so there will be an "~/.names.local.cache" in the file system with contents:
<unixtime_utc> ak 45.33.66.185
Reading is simple but for concurrent writing, there should be a locking mechanism so we need a frontend. Let it be a simple bash script for a start, so any who want to do a name query will just execute something like "$ local-names <name>" and will get IP addresses to the stdout. Then any Gemini client might find if that command is available and use it by default instead of DNS.
As said before:
if a name is associated with another "naming server", the system should ask the user about naming conflict resolution. And those names are local only, so the user should be able to write any name he prefers.
That is the real reason why all DNS systems are centralized :).
That is why we need multiple "root-like" naming servers available. And that is when we come to git-like p2p. And if one naming server is down or not available we need a list of "trusted" friends to ask them.
You should not host ".names.public" from a dynamic IP address. For naming servers, there is a need for static long-running IP. But there are plenty of public UNIX servers that can provide such services to its users.
It is possible to create command-line software for users to add records to the server's list by editing local "~/.names.public" on the server. And then the server may have software to respond concatenated list of "name - IP" associations when queries with "HTTP GET /.names.public" or via Gemini.
Even more, that file may contain a list of backup naming servers in it, so if the main one is not available client software may query an alternative server.
And that alternative server (let's call it mirror) might have records of a friend's server in ".names.friends" file. So if the main server is not responding user will be able to ask its known friends for the info.
If the original naming server IP address is down forever a mirror might start to claim to have not mirrored records, but real ones.
That's where PGP might come into the play. Lines should be signed and then the only key owner will be able to change them. And client software should check that signature was not faked before responding to the user.
Also, there might be an "-f" flag to start trusting the new signature.