Recent changes
Internet Naming System (Atom feed)minor fix
diff --git a/index.mdwn b/index.mdwn index 293ccb2..ae68fa9 100644 --- a/index.mdwn +++ b/index.mdwn @@ -1,4 +1,4 @@ -***Note:** This is only the draft of a very basic description, we know it lacks details. See below how to [contact us](#Contribute) if you have questions or ideas.*<br/><br/> +***Note:** This is only the draft of a very basic description, we know it lacks details. See below how to [contact us](#contribute) if you have questions or ideas.*<br/><br/> 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.
grammar
diff --git a/index.mdwn b/index.mdwn index 7b9e976..293ccb2 100644 --- a/index.mdwn +++ b/index.mdwn @@ -58,7 +58,7 @@ Proof may be to put a special TXT record signed with the key used for the INS re 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 managing cooperatively a single namespace ?) +- 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 ?
fourth draft
diff --git a/index.mdwn b/index.mdwn index 0c773fa..7b9e976 100644 --- a/index.mdwn +++ b/index.mdwn @@ -4,58 +4,49 @@ The Internet Naming System ( INS ) project aims to create a database capable It is meant to replace the <abbr title="Domain Name System">DNS</abbr> but also to be a global <abbr title="Public Key Infrastructure">PKI</abbr> easing use of cryptography on the Internet, especially removing the need for <abbr title="Certificate Authorities">CAs</abbr>. -## Problematic +You may want to read [DNS: problems and alternatives](http://changaco.net/blog/DNS_problems_and_alternatives/) to better understand the context before reading the INS proposal. -### DNS +## Principles -The INS tries to undermine the following problems of the DNS : +### Non-P2P allocation -- censorship -- name parking, i.e. registering a name for the sole purpose of selling it or filling the namespace -- organizations amassing a lot of money they don't deserve (ICANN, registries, registrars, CAs) -- generic and meaningless TLDs that break the unicity of the namespace -- slow propagation -- single points of failure in the resolution process +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 ». -### Other projects +The main reason for having an authority is to be able to protect the namespace, with the following means : -There are similar projects aiming to replace one or both sides of the DNS (allocation and resolution), but we believe the INS to be better. +- limit the rate of registrations, both globally and based on the request's source ; +- use proof-of-work and/or [[!wikipedia_en CAPTCHA]]s to make massive registrations more costly ; +- revoke or reassign names when these protections aren't enough. -A first category of alternatives is composed of projects, such as CoDoNS, aimed at making resolution faster and more resilient by making it P2P. These projects are great but they don't change how allocation of names works so most of our problems with the the DNS remain. +The second reason is that keys can be lost or compromised, the allocator will be the last resort in these situations. -A second category regroups projects that rely on trusting peers. We feel that the risk is too great to trust the majority and we believe that a web of trust is too complicated. +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. -A third category consists of alternative roots, i.e. put the power in other hands. Needless to say that this doesn't solve any problem in the long run. +### No economic vampirism -Last but not least, we don't like or trust the proof-of-work concept behind Namecoin. +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. -## Proposal +### P2P name resolution -### Name allocation - -Registering an <abbr title="Internet Name">IN</abbr> is free of charge and « anonymous ». It is trusted to a nonprofit organization (referred to as « the allocator » in this document) financed by donations. Being free makes it more equitable and prevents organizations from amassing a lot of money they don't deserve. Moreover, parking is forbidden and anyone confronted to it can ask the allocator to reassign the name (though it may take a while for everyone to accept the change). Being anonymous means you don't have to reveal your identity to get a name. +Resolution of names is P2P and propagation is fast. -Anybody can register a « top-level » name freely, they are not reserved to rich people like TLDs. 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 resolvers. +## Basic technical description -The INS is based on public key cryptography. To assign a name, the allocator signs a name+key pair. This proof is then used by the name owner to publish signed records that everyone can check. +### Name allocation -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, resolvers and users can decide whether they accept these changes immediately or keep the records until their expiration. +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. -Revocation should be used as less often as possible. It may be used to protect the INS from parking or phishing. The allocator may act as a mediator when conflicts arise, but must not revoke a name for a reason not approved by the community unless forced to do so by law. +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. -To prevent (massive) parking, i.e. a <abbr title="Denial of Service">DoS</abbr> against the INS, the allocator may limit the rate of registrations, both globally and based on the request's source. - ### Name management -Every record has an expiration date. When a name expires it cannot be registered for some time, but can still be renewed by the old owner, except if it has been revoked by the allocator. - -The allocator only signs the name+key pair, so name renewals are sent directly to resolvers. It is better to get the allocator to sign a new pair when changing the key in order to keep the proof light, but it can also be done without its approval. +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. -### Name resolution +### Sub-names -Resolution of names will be peer-to-peer like CoDoNS, with the same goals of faster propagation and better resilience. +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 @@ -63,45 +54,20 @@ For a period of time to be determined, the INS will only accept registrations fr Proof may be to put a special TXT record signed with the key used for the INS registration. -### More +### TODO -Other pages : +Not necessarily in that order : -[[!map pages="name_rules or record_types"]] +- figure out the legal structure of the allocator (a single organization in a censorship-free country ? multiple organizations in different countries managing cooperatively 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 -You can : - -- participate to the [INS mailing list](http://lists.changaco.net/listinfo/ins) -- join the XMPP chat room <a href="xmpp:ins@muc.changaco.net?join">ins@muc.changaco.net</a>, using a Web interface such as [muckl](http://muc.changaco.net/muckl/?room=ins) or [Jappix](http://www.jappix.com/?r=ins@muc.changaco.net) if you don't have a native client - -## External links - -Related projects : - -- [OpenNIC](http://opennicproject.org/), [#opennic on freenode](irc://irc.freenode.net/opennic) -- [Dot-P2P](http://dot-p2p.org/), [#dns-p2p on efnet](irc://irc.efnet.org/dns-p2p) -- [Dot-BIT](http://dot-bit.org/), [#namecoin on freenode](irc://irc.freenode.net/namecoin) -- [DNS - We Re-Build](http://werebuild.eu/wiki/DNS), [#dns on telecomix IRC](irc://irc.telecomix.org/dns) -- [P2PNS](http://www.p2pns.org/), based on trusting the majority with multiple resolutions -- [CoDoNS](http://www.cs.cornell.edu/people/egs/beehive/codons.php), only replaces resolution, not allocation -- [IDONS: Internet Distributed Open Name System](http://lauren.vortex.com/archive/000787.html), [forum](http://forums.gctip.org/forum-34.html) -- [Askemos](http://www.askemos.org/) - -Relevant mailing lists : - -- [p2p-hackers](http://lists.zooko.com/mailman/listinfo/p2p-hackers) : - - [Secure, decentralized DNS (a.k.a. solving Zooko's triangle)](http://lists.zooko.com/pipermail/p2p-hackers/2010-December/002598.html) - - [.p2p domain](http://lists.zooko.com/pipermail/p2p-hackers/2010-December/002587.html) -- [OpenNIC lists](http://lists.darkdna.net/mailman/listinfo) - -Interesting writings : +There is a lot to do, if you want to help please join : -- [A simple P2P DNS proposal](http://huitema.wordpress.com/2011/01/03/a-simple-p2p-dns-proposal/), alternative to CoDoNS -- [Names: Decentralized, Secure, Human-Meaningful: Choose Two](http://zooko.com/distnames.html) aka [[!wikipedia_en Zooko's triangle]] -- [For a truly acentric Internet](http://roland.entierement.nu/blog/2010/10/02/for-a-truly-acentric-internet.html) -- [Technical Architecture shapes Social Structure: an example from the real world](http://lair.fifthhorseman.net/~dkg/tls-centralization/) -- [Problems, Goals and a Fix for Domain Names](http://www.templetons.com/brad/dns/) -- [Inventer un meilleur système de nommage: pas si facile](http://www.bortzmeyer.org/no-free-lunch.html) [fr] -- [Confessions d'un voleur](http://www.chemla.org/textes/voleur.html) [fr] +- the [INS mailing list](http://lists.changaco.net/listinfo/ins) +- the XMPP chat room <a href="xmpp:ins@muc.changaco.net?join">ins@muc.changaco.net</a>, using a Web interface such as [muckl](http://muc.changaco.net/muckl/?room=ins) or [Jappix](http://www.jappix.com/?r=ins@muc.changaco.net) if you don't have a native client diff --git a/name_rules.mdwn b/name_rules.mdwn deleted file mode 100644 index 88ed6db..0000000 --- a/name_rules.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -TODO - -- 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 ? like 3 or 4 bytes diff --git a/record_types.mdwn b/record_types.mdwn deleted file mode 100644 index 0cc2360..0000000 --- a/record_types.mdwn +++ /dev/null @@ -1 +0,0 @@ -What record types do we need ? See [[!wikipedia_en List of DNS record types]].
remove pagetemplate misc
diff --git a/site_map.mdwn b/site_map.mdwn index b26abcf..c1338f8 100644 --- a/site_map.mdwn +++ b/site_map.mdwn @@ -1,3 +1 @@ -[[!pagetemplate template="misc.tmpl"]] - [[!map pages="* and !*/*/* and !smileys/* and !ikiwiki/* and !*/sidebar and !*/tags/* and !site_map and !script/* and !style/* and !*templates/* and !admin and !*/Comments and !images/*"]]
left/right → before/after
diff --git a/name_rules.mdwn b/name_rules.mdwn index 8675348..88ed6db 100644 --- a/name_rules.mdwn +++ b/name_rules.mdwn @@ -1,5 +1,5 @@ TODO -- what separator for subdomains and do they expand to the left like the DNS or to the right ? +- 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 ? like 3 or 4 bytes
redefine parking
diff --git a/index.mdwn b/index.mdwn index 8167054..0c773fa 100644 --- a/index.mdwn +++ b/index.mdwn @@ -11,7 +11,7 @@ It is meant to replace the <abbr title="Domain Name System">DNS</abbr> but also The INS tries to undermine the following problems of the DNS : - censorship -- name parking, i.e. register a name for the sole purpose of selling it to someone else +- name parking, i.e. registering a name for the sole purpose of selling it or filling the namespace - organizations amassing a lot of money they don't deserve (ICANN, registries, registrars, CAs) - generic and meaningless TLDs that break the unicity of the namespace - slow propagation
add site map
diff --git a/site_map.mdwn b/site_map.mdwn new file mode 100644 index 0000000..b26abcf --- /dev/null +++ b/site_map.mdwn @@ -0,0 +1,3 @@ +[[!pagetemplate template="misc.tmpl"]] + +[[!map pages="* and !*/*/* and !smileys/* and !ikiwiki/* and !*/sidebar and !*/tags/* and !site_map and !script/* and !style/* and !*templates/* and !admin and !*/Comments and !images/*"]]
new pages: name_rules and record_types
diff --git a/index.mdwn b/index.mdwn index 149668e..8167054 100644 --- a/index.mdwn +++ b/index.mdwn @@ -57,12 +57,18 @@ The allocator only signs the name+key pair, so name renewals are sent directly t Resolution of names will be peer-to-peer like CoDoNS, with the same goals of faster propagation and better resilience. -## Transition from the DNS +### 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. +### More + +Other pages : + +[[!map pages="name_rules or record_types"]] + ## Contribute You can : @@ -70,12 +76,6 @@ You can : - participate to the [INS mailing list](http://lists.changaco.net/listinfo/ins) - join the XMPP chat room <a href="xmpp:ins@muc.changaco.net?join">ins@muc.changaco.net</a>, using a Web interface such as [muckl](http://muc.changaco.net/muckl/?room=ins) or [Jappix](http://www.jappix.com/?r=ins@muc.changaco.net) if you don't have a native client -### To be discussed - -- what separator for subdomains and do they expand to the left like the DNS or to the right ? -- minimum size for names ? like 3 or 4 bytes -- lots of other details… - ## External links Related projects : diff --git a/name_rules.mdwn b/name_rules.mdwn new file mode 100644 index 0000000..8675348 --- /dev/null +++ b/name_rules.mdwn @@ -0,0 +1,5 @@ +TODO + +- what separator for subdomains and do they expand to the left like the DNS or to the right ? +- what maximum size for names ? +- minimum size for top-level names ? like 3 or 4 bytes diff --git a/record_types.mdwn b/record_types.mdwn new file mode 100644 index 0000000..0cc2360 --- /dev/null +++ b/record_types.mdwn @@ -0,0 +1 @@ +What record types do we need ? See [[!wikipedia_en List of DNS record types]].
subdomains → sub-names
diff --git a/index.mdwn b/index.mdwn index e4ff985..149668e 100644 --- a/index.mdwn +++ b/index.mdwn @@ -35,7 +35,7 @@ Last but not least, we don't like or trust the proof-of-work concept behind Name Registering an <abbr title="Internet Name">IN</abbr> is free of charge and « anonymous ». It is trusted to a nonprofit organization (referred to as « the allocator » in this document) financed by donations. Being free makes it more equitable and prevents organizations from amassing a lot of money they don't deserve. Moreover, parking is forbidden and anyone confronted to it can ask the allocator to reassign the name (though it may take a while for everyone to accept the change). Being anonymous means you don't have to reveal your identity to get a name. -Anybody can register a « top-level » name freely, they are not reserved to rich people like TLDs. Subdomains are allowed but their publishing in the P2P resolution network is limited to prevent DoS attacks. Name owners wanting to use a lot of subdomains can store them somewhere else and use an NS-like record to point resolvers to them. +Anybody can register a « top-level » name freely, they are not reserved to rich people like TLDs. 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 resolvers. The INS is based on public key cryptography. To assign a name, the allocator signs a name+key pair. This proof is then used by the name owner to publish signed records that everyone can check.
precisions on parking
diff --git a/index.mdwn b/index.mdwn index 5596874..e4ff985 100644 --- a/index.mdwn +++ b/index.mdwn @@ -11,7 +11,7 @@ It is meant to replace the <abbr title="Domain Name System">DNS</abbr> but also The INS tries to undermine the following problems of the DNS : - censorship -- name parking +- name parking, i.e. register a name for the sole purpose of selling it to someone else - organizations amassing a lot of money they don't deserve (ICANN, registries, registrars, CAs) - generic and meaningless TLDs that break the unicity of the namespace - slow propagation @@ -33,9 +33,9 @@ Last but not least, we don't like or trust the proof-of-work concept behind Name ### Name allocation -Registering an <abbr title="Internet Name">IN</abbr> is free of charge and « anonymous ». It is trusted to a nonprofit organization (referred to as « the allocator » in this document) financed by donations. Being free makes it more equitable, discourages parking, and prevents organizations from amassing a lot of money they don't deserve. Being anonymous means you don't have to reveal your identity to get a name. +Registering an <abbr title="Internet Name">IN</abbr> is free of charge and « anonymous ». It is trusted to a nonprofit organization (referred to as « the allocator » in this document) financed by donations. Being free makes it more equitable and prevents organizations from amassing a lot of money they don't deserve. Moreover, parking is forbidden and anyone confronted to it can ask the allocator to reassign the name (though it may take a while for everyone to accept the change). Being anonymous means you don't have to reveal your identity to get a name. -Anybody can register a « top-level » name freely, TLDs are not reserved to rich people. Subdomains are allowed but their publishing in the P2P resolution network is limited to prevent DoS attacks. Name owners wanting to use a lot of subdomains can store them somewhere else and use an NS-like record to point resolvers to them. +Anybody can register a « top-level » name freely, they are not reserved to rich people like TLDs. Subdomains are allowed but their publishing in the P2P resolution network is limited to prevent DoS attacks. Name owners wanting to use a lot of subdomains can store them somewhere else and use an NS-like record to point resolvers to them. The INS is based on public key cryptography. To assign a name, the allocator signs a name+key pair. This proof is then used by the name owner to publish signed records that everyone can check.
third draft: more details and more external links
diff --git a/index.mdwn b/index.mdwn index 27e3a19..5596874 100644 --- a/index.mdwn +++ b/index.mdwn @@ -1,66 +1,107 @@ -***Note:** This is only the second draft of a very basic description, we know it lacks details, if you have questions or want to help, join us in the XMPP chat room <a href="xmpp:ins@muc.changaco.net?join">ins@muc.changaco.net</a>, using a Web interface such as [muckl](http://muc.changaco.net/muckl/?room=ins) or [Jappix](http://www.jappix.com/?r=ins@muc.changaco.net) if you don't have a native client.<br/><br/>* +***Note:** This is only the draft of a very basic description, we know it lacks details. See below how to [contact us](#Contribute) if you have questions or ideas.*<br/><br/> -The Internet Naming System ( INS ) project aims to create a database capable of mapping unique names to values such as IP addresses and public keys. +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 <abbr title="Domain Name System">DNS</abbr> but also to be a global <abbr title="Public Key Infrastructure">PKI</abbr> easing use of cryptography on the Internet, especially removing the need for <abbr title="Certificate Authorities">CAs</abbr>. -## Concepts +## Problematic -Observing that full-P2P alternatives to the DNS all have flaws, we propose another approach : reducing the power of the registration authority by basing the system on public key cryptography. +### DNS -### The registrar +The INS tries to undermine the following problems of the DNS : -Registration is trusted to a nonprofit organization. It is free and «anonymous». Names are unique. +- censorship +- name parking +- organizations amassing a lot of money they don't deserve (ICANN, registries, registrars, CAs) +- generic and meaningless TLDs that break the unicity of the namespace +- slow propagation +- single points of failure in the resolution process -The registrar can revoke a name or change its owner, but everybody can see that they aren't regular updates, because they are signed with the registrar's key instead of the name owner's key. Therefore, resolvers and users can decide whether they accept these changes immediately or keep the records until their expiration. +### Other projects -Revocation should be used as less often as possible. It is encouraged in only one case : to protect the INS from parking. The registrar may act as a mediator when other types of conflict arise, but must not revoke a name for a reason not approved by the community unless ordered so by a court. +There are similar projects aiming to replace one or both sides of the DNS (allocation and resolution), but we believe the INS to be better. -The registrar 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 the registrar from unjustly refusing registrations. +A first category of alternatives is composed of projects, such as CoDoNS, aimed at making resolution faster and more resilient by making it P2P. These projects are great but they don't change how allocation of names works so most of our problems with the the DNS remain. -To prevent (massive) parking, i.e. a <abbr title="Denial of Service">DoS</abbr> against the INS, the registrar may limit the rate of registrations, both globally and based on the request's source. +A second category regroups projects that rely on trusting peers. We feel that the risk is too great to trust the majority and we believe that a web of trust is too complicated. -### Push updates +A third category consists of alternative roots, i.e. put the power in other hands. Needless to say that this doesn't solve any problem in the long run. -An annoying thing about the DNS is slow propagation due to time-based cache, i.e. polling changes instead of pushing them. +Last but not least, we don't like or trust the proof-of-work concept behind Namecoin. -TODO: can we reuse CoDoNS or else ? +## Proposal -### Name expiration and key changes +### Name allocation -Every record has an expiration date. When a name expires it cannot be registered for some time, but can still be renewed by the old owner, except if it has been revoked by the registrar. +Registering an <abbr title="Internet Name">IN</abbr> is free of charge and « anonymous ». It is trusted to a nonprofit organization (referred to as « the allocator » in this document) financed by donations. Being free makes it more equitable, discourages parking, and prevents organizations from amassing a lot of money they don't deserve. Being anonymous means you don't have to reveal your identity to get a name. -The registrar only signs the name+key pair, so name renewals are sent directly to resolvers. It is better to get the registrar to sign a new pair when changing the key in order to keep the proof light, but it can also be done without its approval. +Anybody can register a « top-level » name freely, TLDs are not reserved to rich people. Subdomains are allowed but their publishing in the P2P resolution network is limited to prevent DoS attacks. Name owners wanting to use a lot of subdomains can store them somewhere else and use an NS-like record to point resolvers to them. -### Non-hierarchical +The INS is based on public key cryptography. To assign a name, the allocator signs a name+key pair. This proof is then used by the name owner to publish signed records that everyone can check. -The INS is not hierarchical, it doesn't have TLDs and only one level of subdomains is allowed. +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, resolvers and users can decide whether they accept these changes immediately or keep the records until their expiration. + +Revocation should be used as less often as possible. It may be used to protect the INS from parking or phishing. The allocator may act as a mediator when conflicts arise, but must not revoke a name for a reason not approved by the community unless forced to do so by law. + +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. + +To prevent (massive) parking, i.e. a <abbr title="Denial of Service">DoS</abbr> against the INS, the allocator may limit the rate of registrations, both globally and based on the request's source. + +### Name management + +Every record has an expiration date. When a name expires it cannot be registered for some time, but can still be renewed by the old owner, except if it has been revoked by the allocator. + +The allocator only signs the name+key pair, so name renewals are sent directly to resolvers. It is better to get the allocator to sign a new pair when changing the key in order to keep the proof light, but it can also be done without its approval. + +### Name resolution + +Resolution of names will be peer-to-peer like CoDoNS, with the same goals of faster propagation and better resilience. ## 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 an existing domain name. For example by putting a special TXT record containing the public key used for the INS registration. The organizations behind the most visited domain names will be contacted first. +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. + +## Contribute + +You can : + +- participate to the [INS mailing list](http://lists.changaco.net/listinfo/ins) +- join the XMPP chat room <a href="xmpp:ins@muc.changaco.net?join">ins@muc.changaco.net</a>, using a Web interface such as [muckl](http://muc.changaco.net/muckl/?room=ins) or [Jappix](http://www.jappix.com/?r=ins@muc.changaco.net) if you don't have a native client + +### To be discussed + +- what separator for subdomains and do they expand to the left like the DNS or to the right ? +- minimum size for names ? like 3 or 4 bytes +- lots of other details… ## External links Related projects : +- [OpenNIC](http://opennicproject.org/), [#opennic on freenode](irc://irc.freenode.net/opennic) - [Dot-P2P](http://dot-p2p.org/), [#dns-p2p on efnet](irc://irc.efnet.org/dns-p2p) - [Dot-BIT](http://dot-bit.org/), [#namecoin on freenode](irc://irc.freenode.net/namecoin) - [DNS - We Re-Build](http://werebuild.eu/wiki/DNS), [#dns on telecomix IRC](irc://irc.telecomix.org/dns) -- [P2PNS](http://www.p2pns.org/), based on multiple resolutions for majority vote checking -- [CoDoNS](http://www.cs.cornell.edu/people/egs/beehive/codons.php), only replaces resolution, not registration +- [P2PNS](http://www.p2pns.org/), based on trusting the majority with multiple resolutions +- [CoDoNS](http://www.cs.cornell.edu/people/egs/beehive/codons.php), only replaces resolution, not allocation - [IDONS: Internet Distributed Open Name System](http://lauren.vortex.com/archive/000787.html), [forum](http://forums.gctip.org/forum-34.html) +- [Askemos](http://www.askemos.org/) Relevant mailing lists : - [p2p-hackers](http://lists.zooko.com/mailman/listinfo/p2p-hackers) : - [Secure, decentralized DNS (a.k.a. solving Zooko's triangle)](http://lists.zooko.com/pipermail/p2p-hackers/2010-December/002598.html) - [.p2p domain](http://lists.zooko.com/pipermail/p2p-hackers/2010-December/002587.html) +- [OpenNIC lists](http://lists.darkdna.net/mailman/listinfo) Interesting writings : - [A simple P2P DNS proposal](http://huitema.wordpress.com/2011/01/03/a-simple-p2p-dns-proposal/), alternative to CoDoNS - [Names: Decentralized, Secure, Human-Meaningful: Choose Two](http://zooko.com/distnames.html) aka [[!wikipedia_en Zooko's triangle]] - [For a truly acentric Internet](http://roland.entierement.nu/blog/2010/10/02/for-a-truly-acentric-internet.html) +- [Technical Architecture shapes Social Structure: an example from the real world](http://lair.fifthhorseman.net/~dkg/tls-centralization/) +- [Problems, Goals and a Fix for Domain Names](http://www.templetons.com/brad/dns/) - [Inventer un meilleur système de nommage: pas si facile](http://www.bortzmeyer.org/no-free-lunch.html) [fr] - [Confessions d'un voleur](http://www.chemla.org/textes/voleur.html) [fr]
replace link by latest post on the same topic
diff --git a/index.mdwn b/index.mdwn index f15e34d..27e3a19 100644 --- a/index.mdwn +++ b/index.mdwn @@ -62,5 +62,5 @@ Interesting writings : - [A simple P2P DNS proposal](http://huitema.wordpress.com/2011/01/03/a-simple-p2p-dns-proposal/), alternative to CoDoNS - [Names: Decentralized, Secure, Human-Meaningful: Choose Two](http://zooko.com/distnames.html) aka [[!wikipedia_en Zooko's triangle]] - [For a truly acentric Internet](http://roland.entierement.nu/blog/2010/10/02/for-a-truly-acentric-internet.html) -- [Un DNS en pair-à-pair ?](http://www.bortzmeyer.org/dns-p2p.html) [fr] +- [Inventer un meilleur système de nommage: pas si facile](http://www.bortzmeyer.org/no-free-lunch.html) [fr] - [Confessions d'un voleur](http://www.chemla.org/textes/voleur.html) [fr]
make it clear that it's just a draft
diff --git a/index.mdwn b/index.mdwn index 62722cf..f15e34d 100644 --- a/index.mdwn +++ b/index.mdwn @@ -1,3 +1,5 @@ +***Note:** This is only the second draft of a very basic description, we know it lacks details, if you have questions or want to help, join us in the XMPP chat room <a href="xmpp:ins@muc.changaco.net?join">ins@muc.changaco.net</a>, using a Web interface such as [muckl](http://muc.changaco.net/muckl/?room=ins) or [Jappix](http://www.jappix.com/?r=ins@muc.changaco.net) if you don't have a native client.<br/><br/>* + The Internet Naming System ( INS ) project aims to create a database capable of mapping unique names to values such as IP addresses and public keys. It is meant to replace the <abbr title="Domain Name System">DNS</abbr> but also to be a global <abbr title="Public Key Infrastructure">PKI</abbr> easing use of cryptography on the Internet, especially removing the need for <abbr title="Certificate Authorities">CAs</abbr>. @@ -38,10 +40,6 @@ The INS is not hierarchical, it doesn't have TLDs and only one level of subdomai For a period of time to be determined, the INS will only accept registrations from entities who can prove they own an existing domain name. For example by putting a special TXT record containing the public key used for the INS registration. The organizations behind the most visited domain names will be contacted first. -## Contribute - -Join us in the XMPP chat room <a href="xmpp:ins@muc.changaco.net?join">ins@muc.changaco.net</a>, using a Web interface such as [muckl](http://muc.changaco.net/muckl/?room=ins) or [Jappix](http://www.jappix.com/?r=ins@muc.changaco.net) if you don't have a native client. - ## External links Related projects :
add link to XMPP MUC
diff --git a/index.mdwn b/index.mdwn index 472fbe7..62722cf 100644 --- a/index.mdwn +++ b/index.mdwn @@ -38,6 +38,10 @@ The INS is not hierarchical, it doesn't have TLDs and only one level of subdomai For a period of time to be determined, the INS will only accept registrations from entities who can prove they own an existing domain name. For example by putting a special TXT record containing the public key used for the INS registration. The organizations behind the most visited domain names will be contacted first. +## Contribute + +Join us in the XMPP chat room <a href="xmpp:ins@muc.changaco.net?join">ins@muc.changaco.net</a>, using a Web interface such as [muckl](http://muc.changaco.net/muckl/?room=ins) or [Jappix](http://www.jappix.com/?r=ins@muc.changaco.net) if you don't have a native client. + ## External links Related projects :
second draft
diff --git a/index.mdwn b/index.mdwn index 9d0a7a1..472fbe7 100644 --- a/index.mdwn +++ b/index.mdwn @@ -1,38 +1,44 @@ -The Internet Naming System ( INS ) project aims to create a generic database for two primary uses : replace the <abbr title="Domain Name System">DNS</abbr> and finally provide an Internet-wide Single Sign-On system. +The Internet Naming System ( INS ) project aims to create a database capable of mapping unique names to values such as IP addresses and public keys. -Observing that full-P2P alternatives to the DNS all have flaws, we propose another approach. +It is meant to replace the <abbr title="Domain Name System">DNS</abbr> but also to be a global <abbr title="Public Key Infrastructure">PKI</abbr> easing use of cryptography on the Internet, especially removing the need for <abbr title="Certificate Authorities">CAs</abbr>. ## Concepts -### Public Key Cryptography - -INS is a <abbr title="Public Key Infrastructure">PKI</abbr>. Among other advantages, basing the naming system on cryptography improves the security of the Internet by removing trust in <abbr title="Certificate Authorities">CAs</abbr>. +Observing that full-P2P alternatives to the DNS all have flaws, we propose another approach : reducing the power of the registration authority by basing the system on public key cryptography. ### The registrar Registration is trusted to a nonprofit organization. It is free and «anonymous». Names are unique. -The registrar can revoke a name or change its owner, but such decisions do not have to be blindly trusted and can be checked by any user who wishes it. To ensure that the registrar cannot simply make a name disappear, independent parties are encouraged to participate in the root, the group of servers that stores all records. Any unjustified revocation would be detected and dealt with by the community. +The registrar can revoke a name or change its owner, but everybody can see that they aren't regular updates, because they are signed with the registrar's key instead of the name owner's key. Therefore, resolvers and users can decide whether they accept these changes immediately or keep the records until their expiration. + +Revocation should be used as less often as possible. It is encouraged in only one case : to protect the INS from parking. The registrar may act as a mediator when other types of conflict arise, but must not revoke a name for a reason not approved by the community unless ordered so by a court. + +The registrar 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 the registrar from unjustly refusing registrations. -Revocation is encouraged in only one case : to protect the INS from parking. The registrar may act as a mediator when other types of conflict arise, but must not revoke a name for a reason not approved by the community, e.g. trademark or other «intellectual property» disputes. +To prevent (massive) parking, i.e. a <abbr title="Denial of Service">DoS</abbr> against the INS, the registrar may limit the rate of registrations, both globally and based on the request's source. ### Push updates -An annoying thing about the DNS is slow propagation due to time-based cache, i.e. clients polling changes instead of servers pushing them. Obviously, broadcasting every change would be a waste of bandwidth. It is also evident that the root servers cannot keep track of who is interested in what for the whole Internet, so we need different levels of cache based on storage capacity. +An annoying thing about the DNS is slow propagation due to time-based cache, i.e. polling changes instead of pushing them. -The root servers store everything, they receive every update. Each of them pushes changes to a limited number of relays, keeping track of which names each relay cares about. Then these relays do the same for the next level of relays, etc all the way to the final cache polled by client software, typically in residential gateways or in the users' computer itself. +TODO: can we reuse CoDoNS or else ? ### Name expiration and key changes -Every record has an expiration date. When a name expires it cannot be registered for a period of time fixed by the registrar, except if it is the old owner claiming it. +Every record has an expiration date. When a name expires it cannot be registered for some time, but can still be renewed by the old owner, except if it has been revoked by the registrar. + +The registrar only signs the name+key pair, so name renewals are sent directly to resolvers. It is better to get the registrar to sign a new pair when changing the key in order to keep the proof light, but it can also be done without its approval. + +### Non-hierarchical -The registrar only signs the (name,key) pair, so name renewals can be sent directly to the root servers. It is better to get the registrar to sign a new pair when changing the key in order to keep the proof light, but it can also be done without approval of the registrar. +The INS is not hierarchical, it doesn't have TLDs and only one level of subdomains is allowed. ## 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 an existing domain name. For example by putting a special TXT record containing the public key used for the INS registration. The organizations behind the most visited domain names will be contacted first. -## Links +## External links Related projects :
add link to IDONS
diff --git a/index.mdwn b/index.mdwn index c2c2d29..9d0a7a1 100644 --- a/index.mdwn +++ b/index.mdwn @@ -41,6 +41,7 @@ Related projects : - [DNS - We Re-Build](http://werebuild.eu/wiki/DNS), [#dns on telecomix IRC](irc://irc.telecomix.org/dns) - [P2PNS](http://www.p2pns.org/), based on multiple resolutions for majority vote checking - [CoDoNS](http://www.cs.cornell.edu/people/egs/beehive/codons.php), only replaces resolution, not registration +- [IDONS: Internet Distributed Open Name System](http://lauren.vortex.com/archive/000787.html), [forum](http://forums.gctip.org/forum-34.html) Relevant mailing lists :
add link to CoDoNS alternative
diff --git a/index.mdwn b/index.mdwn index df3a148..c2c2d29 100644 --- a/index.mdwn +++ b/index.mdwn @@ -50,6 +50,7 @@ Relevant mailing lists : Interesting writings : +- [A simple P2P DNS proposal](http://huitema.wordpress.com/2011/01/03/a-simple-p2p-dns-proposal/), alternative to CoDoNS - [Names: Decentralized, Secure, Human-Meaningful: Choose Two](http://zooko.com/distnames.html) aka [[!wikipedia_en Zooko's triangle]] - [For a truly acentric Internet](http://roland.entierement.nu/blog/2010/10/02/for-a-truly-acentric-internet.html) - [Un DNS en pair-à-pair ?](http://www.bortzmeyer.org/dns-p2p.html) [fr]
first draft \o/
diff --git a/index.mdwn b/index.mdwn index 3fc3a09..df3a148 100644 --- a/index.mdwn +++ b/index.mdwn @@ -1 +1,56 @@ The Internet Naming System ( INS ) project aims to create a generic database for two primary uses : replace the <abbr title="Domain Name System">DNS</abbr> and finally provide an Internet-wide Single Sign-On system. + +Observing that full-P2P alternatives to the DNS all have flaws, we propose another approach. + +## Concepts + +### Public Key Cryptography + +INS is a <abbr title="Public Key Infrastructure">PKI</abbr>. Among other advantages, basing the naming system on cryptography improves the security of the Internet by removing trust in <abbr title="Certificate Authorities">CAs</abbr>. + +### The registrar + +Registration is trusted to a nonprofit organization. It is free and «anonymous». Names are unique. + +The registrar can revoke a name or change its owner, but such decisions do not have to be blindly trusted and can be checked by any user who wishes it. To ensure that the registrar cannot simply make a name disappear, independent parties are encouraged to participate in the root, the group of servers that stores all records. Any unjustified revocation would be detected and dealt with by the community. + +Revocation is encouraged in only one case : to protect the INS from parking. The registrar may act as a mediator when other types of conflict arise, but must not revoke a name for a reason not approved by the community, e.g. trademark or other «intellectual property» disputes. + +### Push updates + +An annoying thing about the DNS is slow propagation due to time-based cache, i.e. clients polling changes instead of servers pushing them. Obviously, broadcasting every change would be a waste of bandwidth. It is also evident that the root servers cannot keep track of who is interested in what for the whole Internet, so we need different levels of cache based on storage capacity. + +The root servers store everything, they receive every update. Each of them pushes changes to a limited number of relays, keeping track of which names each relay cares about. Then these relays do the same for the next level of relays, etc all the way to the final cache polled by client software, typically in residential gateways or in the users' computer itself. + +### Name expiration and key changes + +Every record has an expiration date. When a name expires it cannot be registered for a period of time fixed by the registrar, except if it is the old owner claiming it. + +The registrar only signs the (name,key) pair, so name renewals can be sent directly to the root servers. It is better to get the registrar to sign a new pair when changing the key in order to keep the proof light, but it can also be done without approval of the registrar. + +## 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 an existing domain name. For example by putting a special TXT record containing the public key used for the INS registration. The organizations behind the most visited domain names will be contacted first. + +## Links + +Related projects : + +- [Dot-P2P](http://dot-p2p.org/), [#dns-p2p on efnet](irc://irc.efnet.org/dns-p2p) +- [Dot-BIT](http://dot-bit.org/), [#namecoin on freenode](irc://irc.freenode.net/namecoin) +- [DNS - We Re-Build](http://werebuild.eu/wiki/DNS), [#dns on telecomix IRC](irc://irc.telecomix.org/dns) +- [P2PNS](http://www.p2pns.org/), based on multiple resolutions for majority vote checking +- [CoDoNS](http://www.cs.cornell.edu/people/egs/beehive/codons.php), only replaces resolution, not registration + +Relevant mailing lists : + +- [p2p-hackers](http://lists.zooko.com/mailman/listinfo/p2p-hackers) : + - [Secure, decentralized DNS (a.k.a. solving Zooko's triangle)](http://lists.zooko.com/pipermail/p2p-hackers/2010-December/002598.html) + - [.p2p domain](http://lists.zooko.com/pipermail/p2p-hackers/2010-December/002587.html) + +Interesting writings : + +- [Names: Decentralized, Secure, Human-Meaningful: Choose Two](http://zooko.com/distnames.html) aka [[!wikipedia_en Zooko's triangle]] +- [For a truly acentric Internet](http://roland.entierement.nu/blog/2010/10/02/for-a-truly-acentric-internet.html) +- [Un DNS en pair-à-pair ?](http://www.bortzmeyer.org/dns-p2p.html) [fr] +- [Confessions d'un voleur](http://www.chemla.org/textes/voleur.html) [fr]
short project description
diff --git a/index.mdwn b/index.mdwn new file mode 100644 index 0000000..3fc3a09 --- /dev/null +++ b/index.mdwn @@ -0,0 +1 @@ +The Internet Naming System ( INS ) project aims to create a generic database for two primary uses : replace the <abbr title="Domain Name System">DNS</abbr> and finally provide an Internet-wide Single Sign-On system.
initial commit
diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..b84c806 --- /dev/null +++ b/.gitignore @@ -0,0 +1,2 @@ +/.ikiwiki +/recentchanges