An unnamed DNS replacement idea

DNS solves two problems:

  1. translating between human-readable domain names and machine-usable IP addresses
  2. storing a reliable, hierarchical, distributed database describing which servers provide which services and the above mapping.

It’s known that the second problem is solved inefficiently, insecurely, unreliably and centrally. Thus a different system should be designed to solve it without these problems.

The first problem is solved using globally unique names with unique meanings. This is an unreal assumption enabling useless or harmful activities like domain parking, domain squatting, trademarks being used for censorship, or just making the names difficult to type.

This probably contributes to the fact that users often use machines to store the domain names. Other issues like advertising contribute to using unreadable names and sharing them via e.g. QR codes instead of memorization by humans.

Therefore I believe a good replacement for DNS solving the second problem would not use globally unique human readable names.

Let’s assume that a single being manages the database fragment describing some machines (like a DNS zone). There is no problem with having names in the fragment. The fragment should be signed using a key pair used only for this zone with private part known only to the managing being. Probably any useful and scalable DNS alternative would do this.

The ‘name’ of the zone would be the public key used to sign the zone. It would be random-like and there practically wouldn’t be multiple zones with the same ‘name’, so this would avoid the problems of nonrandom unique names. There are algorithms using elliptic curve cryptography having good enough public keys small enough to use them in a DNS domain name, they could be used here (although having e.g. a multi-kilobyte zone ‘name’ wouldn’t be a problem for machines transferring them).

We could let anyone serve the zone data, since knowing the public key allows knowing if the untrusted server provided us the correct data, assuming the data doesn’t change. In real life such data changes, but having an outdated copy could be detected by e.g. specifying the time when the data is valid in the zone (DNS uses a similar solution, although it wouldn’t need having globally synchronized clocks). There are existing solutions for sharing such data without having a central server.

This leaves the problem of having human-typeable names for the zones in the rare cases when they are useful. This would be solved by having a local daemon having such user-specified mapping and maybe asking other such daemons for other names (e.g. if the user has many machines or uses names shared with other users in a single organization).