Internet Naming System
Note: This is only the draft of a very basic description, we know it lacks details. See below how to contact us if you have questions or ideas.
The Internet Naming System ( INS ) project aims to create a database capable of mapping unique meaningful names to values such as IP addresses and public keys.
It is meant to replace the DNS but also to be a global PKI easing use of cryptography on the Internet, especially removing the need for CAs.
You may want to read DNS: problems and alternatives to better understand the context before reading the INS proposal.
Principles
Non-P2P allocation
Allocation of names is trusted to a central authority, a nonprofit organization financed by donations (referred to as « the allocator » in this document). We want to make censorship automatically detectable and thus more difficult but we don't want to sacrifice other properties such as usability to make it « impossible ».
The main reason for having an authority is to be able to protect the namespace, with the following means :
- limit the rate of registrations, both globally and based on the request's source ;
- use proof-of-work and/or CAPTCHAs to make massive registrations more costly ;
- revoke or reassign names when these protections aren't enough.
The second reason is that keys can be lost or compromised, the allocator will be the last resort in these situations.
Revocation should be used as less often as possible. The allocator must not revoke a name for a reason not approved by the community unless forced to do so by law.
No economic vampirism
Registration is free of charge and there are no TLDs, users directly register « top-level » names. Parking a name to sell it is forbidden and anyone confronted to that can ask the allocator to reassign the name.
P2P name resolution
Resolution of names is P2P and propagation is fast.
Basic technical description
Name allocation
To register a name, a client sends a message signed with his key, containing the name and expiration date. If all is well, the allocator signs the message and sends it back, which is now a proof that can be used to publish signed records that everyone can check.
The allocator can revoke a name or change its owner, but everybody can see that they aren't regular updates, because they are signed with its key instead of the name owner's key. Therefore, users can decide whether they accept these changes or not.
The allocator cannot simply make a name disappear because it doesn't participate in the resolution of names at all. However, there is no way to prevent unjust allocation refusals.
Name management
When a name expires it cannot be registered for some time, but can still be renewed by the old owner. Name renewal is done the same way as registration.
Sub-names
Sub-names are allowed but their publication in the P2P resolution network is limited to prevent DoS attacks. Name owners wanting to use a lot of them can use an NS-like record to store them on their own name servers.
Transition from the DNS
For a period of time to be determined, the INS will only accept registrations from entities who can prove they own the non-parked corresponding domain names. In case of conflict for a name owned by different entities in different TLDs, the allocator will encourage the use of more specific names, but leave it to justice if an agreement cannot be reached.
Proof may be to put a special TXT record signed with the key used for the INS registration.
TODO
Not necessarily in that order :
- figure out the legal structure of the allocator (a single organization in a censorship-free country ? multiple organizations in different countries cooperatively managing a single namespace ?)
- what separator for sub-names and do they go before (like the DNS) or after the top-level name ?
- what maximum size for names ?
- minimum size for top-level names ?
- write specs for the P2P resolution network (CoDoNS-like, PNRP-like, something else ?)
- start implementing
Contribute
There is a lot to do, if you want to help please join :
- the INS mailing list
- the XMPP chat room ins@muc.changaco.net, using a Web interface such as muckl or Jappix if you don't have a native client