gsan wrote:This is a proposal for an extended specification for the domain application of Namecoin. Basic goals are:
* Standardized support for most, if not all1, DNS record types.
* Ability to provide alternative mappings for non-IP networks, to be processed by proxy servers.
* Allowing delegation of the domain or sub-domains to master DNS servers, while still providing support for non-IP networks.
* Enabling hierarchical structures within Namecoin.
* Establish a standard for future extensions.
http://ns.bit/domainspec.html
[SPEC] Domain name specification
[SPEC] Domain name specification
NamecoinID: id/khal
GPG : 9CC5B92E965D69A9
NMC: N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9
BTC: 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T
Register Namecoin domains with BTC
My bitcoin Identity - Send messages to bitcoin users
Charity Ad - Make a good deed without paying a cent
GPG : 9CC5B92E965D69A9
NMC: N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9
BTC: 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T
Register Namecoin domains with BTC
My bitcoin Identity - Send messages to bitcoin users
Charity Ad - Make a good deed without paying a cent
Re: Domain name specification
Here is the wiki page for it:
http://dot-bit.org/Domain_names
Please feel free to ruthlessly criticize. Feature requests and discussions about use cases are extremely welcome.
http://dot-bit.org/Domain_names
Please feel free to ruthlessly criticize. Feature requests and discussions about use cases are extremely welcome.
bitcoin:13uSLCLqURqjJkfH6ny56h65oF6bfsVik1
namecoin:NEuYvWtQ8pZzFx7sAnfjeRVtzvieCWF5Ug
namecoin:NEuYvWtQ8pZzFx7sAnfjeRVtzvieCWF5Ug
Re: Domain name specification
Some remarks :
Round robin
- round robin was lacking as i said you : it's ok now. I think we should show both syntaxes when 1 ip is used :
* "ip6": ["2001:4860:0:1001::68"]
* "ip6": "2001:4860:0:1001::68"
* ip": ["192.168.1.1", "192.168.7.1"]
* ip": "192.168.1.1"
This will be json interpreted, and that's how json works (either one element without [], or a list of one or more elements with []).
I'll put some examples in this section :
http://dot-bit.org/Domain_names#IP_Addresses
Implementation section
Parsers need to take into considerations that ns (NS) and translate (DNAME) records work hierarchically and imply a wildcard. For instance, if “” is translated to “otherhost.bit.”, all sub-domain entries will need to be ignored
This only concerns compatible DNS entries i guess ? If so, we should precise it.
DNS functions vs extended functions
Should we separate DNS compatible fields from the others (which will need the use of a proxy) in the spec ?
Maybe some remarks later on sub, merge and subdomain delegation.
Edit : Mirror field :
Domains name in namecoin can't be modified by an external entity, but servers hosting the data can be stopped. Having a standard and optionnal way of mirroring a domain may be usefull. We should take a look on how things are done for linux mirrors and if it can be summarized
Round robin
- round robin was lacking as i said you : it's ok now. I think we should show both syntaxes when 1 ip is used :
* "ip6": ["2001:4860:0:1001::68"]
* "ip6": "2001:4860:0:1001::68"
* ip": ["192.168.1.1", "192.168.7.1"]
* ip": "192.168.1.1"
This will be json interpreted, and that's how json works (either one element without [], or a list of one or more elements with []).
I'll put some examples in this section :
http://dot-bit.org/Domain_names#IP_Addresses
Implementation section
Parsers need to take into considerations that ns (NS) and translate (DNAME) records work hierarchically and imply a wildcard. For instance, if “” is translated to “otherhost.bit.”, all sub-domain entries will need to be ignored
This only concerns compatible DNS entries i guess ? If so, we should precise it.
DNS functions vs extended functions
Should we separate DNS compatible fields from the others (which will need the use of a proxy) in the spec ?
Maybe some remarks later on sub, merge and subdomain delegation.
Edit : Mirror field :
Domains name in namecoin can't be modified by an external entity, but servers hosting the data can be stopped. Having a standard and optionnal way of mirroring a domain may be usefull. We should take a look on how things are done for linux mirrors and if it can be summarized
NamecoinID: id/khal
GPG : 9CC5B92E965D69A9
NMC: N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9
BTC: 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T
Register Namecoin domains with BTC
My bitcoin Identity - Send messages to bitcoin users
Charity Ad - Make a good deed without paying a cent
GPG : 9CC5B92E965D69A9
NMC: N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9
BTC: 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T
Register Namecoin domains with BTC
My bitcoin Identity - Send messages to bitcoin users
Charity Ad - Make a good deed without paying a cent
Re: Domain name specification
Cool.khal wrote: I'll put some examples in this section :
http://dot-bit.org/Domain_names#IP_Addresses
In the case of "ns", yes. But not "translate", since its function is not limited to DNS. However, it's true that it needs clarification.khal wrote: Parsers need to take into considerations that ns (NS) and translate (DNAME) records work hierarchically and imply a wildcard. For instance, if “” is translated to “otherhost.bit.”, all sub-domain entries will need to be ignored
This only concerns compatible DNS entries i guess ? If so, we should precise it.
Maybe we need to rename "ns" to "dns" (and keep "ns" as legacy support).
I think that would defeat the purpose. If that were the case, we could have used standard zone files. I think we are pretending that there is no mapping to an existing DNS system, while at the same time supplying enough record types to cover a conversion to standard DNS.khal wrote: Should we separate DNS compatible fields from the others (which will need the use of a proxy) in the spec ?
EDIT: So, as a result, some types cover both areas.
Yes, and we also need to discuss about possible implications. This also goes for public key infrastructure.khal wrote: Maybe some remarks later on sub, merge and subdomain delegation.
COMMENT DELETEDkhal wrote: Edit : Mirror field :
Domains name in namecoin can't be modified by an external entity, but servers hosting the data can be stopped. Having a standard and optionnal way of mirroring a domain may be usefull. We should take a look on how things are done for linux mirrors and if it can be summarized
OK, I get it now. This is something to think about. It's a very interesting idea...
bitcoin:13uSLCLqURqjJkfH6ny56h65oF6bfsVik1
namecoin:NEuYvWtQ8pZzFx7sAnfjeRVtzvieCWF5Ug
namecoin:NEuYvWtQ8pZzFx7sAnfjeRVtzvieCWF5Ug
Re: Domain name specification
So, we should indicate for each field if it'll be compatible with DNS bridges or not. Domain owners will need to know that, to recommend using a DNS bridge or a proxy to their users.gsan wrote:I think that would defeat the purpose. If that were the case, we could have used standard zone files. I think we are pretending that there is no mapping to an existing DNS system, while at the same time supplying enough record types to cover a conversion to standard DNS.khal wrote: Should we separate DNS compatible fields from the others (which will need the use of a proxy) in the spec ?
EDIT: So, as a result, some types cover both areas.
Here are some examples :gsan wrote:COMMENT DELETEDkhal wrote: Edit : Mirror field :
Domains name in namecoin can't be modified by an external entity, but servers hosting the data can be stopped. Having a standard and optionnal way of mirroring a domain may be usefull. We should take a look on how things are done for linux mirrors and if it can be summarized
OK, I get it now. This is something to think about. It's a very interesting idea...
Code: Select all
{
"mirror":
{
"last_update" :
{
"date": "2011-05-12", <= need a name_update to be updated...
"file": "[http://othersite]/last_update.txt", <= or this one to avoid zone update each time the archive has changed
}
"torrent": "[http://othersite]/mirror.torrent",
"archive": "[http://othersite]/archive.zip",
"rsync": "rsync://[USER@]HOST[:PORT]/SRC",
}
}
Code: Select all
{
"mirror": "[http://othersite]/mirror.txt",
}
NamecoinID: id/khal
GPG : 9CC5B92E965D69A9
NMC: N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9
BTC: 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T
Register Namecoin domains with BTC
My bitcoin Identity - Send messages to bitcoin users
Charity Ad - Make a good deed without paying a cent
GPG : 9CC5B92E965D69A9
NMC: N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9
BTC: 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T
Register Namecoin domains with BTC
My bitcoin Identity - Send messages to bitcoin users
Charity Ad - Make a good deed without paying a cent
Re: Domain name specification
So, are these static mirrors of the site? Who makes these mirror copies? If it's the site admins (presumably, since they are maintaining the list), why not use different subdomains for the mirrors instead of a different record? That way they won't need to be static. For distributed archives, which can't be dynamic, we could support additional record types, like "torrent". We already have "freenet" in the proposal, which is the same in functionality. The only thing missing from this kind of solution is the "last updated" part. Is it essential?khal wrote:Simple one, which would include an equivalent to the previous possibilities, or custom instructions :Code: Select all
{ "mirror": "[http://othersite]/mirror.txt", }
If serving from a mirror will be automatic (only in the case of proxy), the result would be identical to having priorities for IPs (i.e. try lower priorities if higher ones don't respond). We could use this system for hidden services as well. You could even fall back to hidden services if IPs fail or vice versa.
On the other hand, if you are proposing a standard way to mirror sites, that's a whole different thing of course.
Also, if there will be a list of mirrors, isn't it only useful if it was maintained by people who mirror?
bitcoin:13uSLCLqURqjJkfH6ny56h65oF6bfsVik1
namecoin:NEuYvWtQ8pZzFx7sAnfjeRVtzvieCWF5Ug
namecoin:NEuYvWtQ8pZzFx7sAnfjeRVtzvieCWF5Ug
Re: Domain name specification
All those messages to be able to understand ourself... :p You get it, good job !gsan wrote:On the other hand, if you are proposing a standard way to mirror sites, that's a whole different thing of course.
I was proposing a standard way of mirroring a website, without providing a way to declare you've created a mirror.
So, new aims of those (still incomplete) records would be to :
- allow an easy way to declare how to mirror your original site
- allow an easy way to declare you've done a mirror of the original
If the orginal site is down :
- be able to easily find existing mirrors (one can create such a website that lists all existing mirrors in 1h, if the only thing to do is a name_scan to find mirrors...)
- still be able to create new mirrors (if your .torrent is on your own website which is now unusable, you fail ! You can hope people have mirrored it too and allow mirroring of their mirror and put their own .torrent link it in their domain config)
YesSo, are these static mirrors of the site?
People who want to do a mirror, not the original ownerWho makes these mirror copies?
I look at how wikileaks's mirror are done and :If it's the site admins (presumably, since they are maintaining the list), why not use different subdomains for the mirrors instead of a different record?
- they send the data to your mirror server (your need to register on a form)
- you must provide a domain name that will be listed on a page
I don't like this solution.
I think it would be easier if there was no list to maintain.
It's easier to mirror a static website (otherwise it is a little bit complicated, but not impossible : distribute a sql file, php files, and a good doc to explain how to do it :p). You also have the solution to convert your dynamic website to a static version and put all that static pages in an archive/torrent (or you can put both in the archive).That way they won't need to be static.
I don't understand the additionnal record.For distributed archives, which can't be dynamic, we could support additional record types, like "torrent". We already have "freenet" in the proposal, which is the same in functionality. The only thing missing from this kind of solution is the "last updated" part. Is it essential?
Last update is not very usefull but would avoid to re-download the full archive to check if it has changed. Re-download a torrent file is not a problem, but a whole website in .zip...
A person which makes a mirror, for example on wikileaks.samaritain.bit, can configure his subdomain like he wants. He can put the data on a hidden tor service only and not put traditionnal ip/ns things to avoid any potential problem.If serving from a mirror will be automatic (only in the case of proxy), the result would be identical to having priorities for IPs (i.e. try lower priorities if higher ones don't respond). We could use this system for hidden services as well. You could even fall back to hidden services if IPs fail or vice versa.
On the automatic part, why not, but don't like automatic things too much.
If we keep things simple and extendable, on original.bit, here is the config to add on "" :
Code: Select all
{
"mirror":
{
"file": "http://whatyouwant.xxx/mirror.wahtyouwant", (you can put rsync command, torrent link, or several by using [])
}
}
Code: Select all
{
"mirror":
{
"source": "http://original.bit",
}
}
Code: Select all
{
"mirror":
{
"source": "http://original.bit",
"file": "http://whatyouwant.xxx/mirror.wahtyouwant"
}
}
NamecoinID: id/khal
GPG : 9CC5B92E965D69A9
NMC: N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9
BTC: 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T
Register Namecoin domains with BTC
My bitcoin Identity - Send messages to bitcoin users
Charity Ad - Make a good deed without paying a cent
GPG : 9CC5B92E965D69A9
NMC: N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9
BTC: 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T
Register Namecoin domains with BTC
My bitcoin Identity - Send messages to bitcoin users
Charity Ad - Make a good deed without paying a cent
Re: Domain name specification
Personally I don't think that it's a good idea to store that much information in the block chain. In fact, I think that no record except a NS record and possibly a DHT record (see below) should be stored in the chain.
The main advantage of the block chain is that it allows to decide which name belongs to which person and that it prevents other from taking over a given name. However, at the same time there are scalability issues as the block chain is basically a global shared state. So typically in a distributed application you would try to decrease the size of this state and to decrease the amount of updates to this state.
Instead of the suggested changes I think a different type of architecture would provide for a better scalability - In my proposal the block chain would only store exactly one out of two record types:
I know that my proposed setup might completely differ from the current plans for namecoin. But in my opinion there is already too much information that is stored in the block chain and this amount of information will decrease scalability when the system grows. In addition, I think it's better to do exactly one task and to do this good, instead of trying to offer an "allround-solution" that integrates protocol features that are currently offered on different layers. For example, including HTTP information into name records in order to facilitate easier mirroring would be an absolute no-go for me. Why should the naming protocol need to know anything about HTTP, why not just offer the same information on the HTTP level - e.g., by just storing a file called mirror.txt at a standard location?
If there is an interest in this type of architecture I can try to outline the details a little bit more on the Wiki.
The main advantage of the block chain is that it allows to decide which name belongs to which person and that it prevents other from taking over a given name. However, at the same time there are scalability issues as the block chain is basically a global shared state. So typically in a distributed application you would try to decrease the size of this state and to decrease the amount of updates to this state.
Instead of the suggested changes I think a different type of architecture would provide for a better scalability - In my proposal the block chain would only store exactly one out of two record types:
- A NS record
This works exactly as in the current version and points to a nameserver on the Internet. - A public key
The goal of the public key is to "decouple" the zone data from the name. The main idea is to keep the name in the chain, but to store the data in a DHT:
Assume a user creates a private/public key pair and that the public key (or only a hash of the key) is stored in the chain. At the same time there's a DHT, where the user stores the zone data under an ID that is equal to the hash of the public key. This zone data contains a sequence number and is signed with the user's private key.
When a host wants to resolve a name it first looks at the block chain to obtain the key value of the DHT and then obtains the information from the DHT. The zone data within the DHT can be verified as a signature has been applied with the user's private key. The respective public key can be identified, as it must hash to the ID of the element in the DHT.
This verification step can not only be used to detect manipulation, but also to prevent other's from injecting wrong data into the DHT: If a node responsible for a given ID range should store a particular data item it can first check if this data contains a valid signature that corresponds to a name in the block chain.
I know that my proposed setup might completely differ from the current plans for namecoin. But in my opinion there is already too much information that is stored in the block chain and this amount of information will decrease scalability when the system grows. In addition, I think it's better to do exactly one task and to do this good, instead of trying to offer an "allround-solution" that integrates protocol features that are currently offered on different layers. For example, including HTTP information into name records in order to facilitate easier mirroring would be an absolute no-go for me. Why should the naming protocol need to know anything about HTTP, why not just offer the same information on the HTTP level - e.g., by just storing a file called mirror.txt at a standard location?
If there is an interest in this type of architecture I can try to outline the details a little bit more on the Wiki.
Re: Domain name specification
Haven't run the numbers but I also think this is an important concern.gst wrote:However, at the same time there are scalability issues as the block chain is basically a global shared state. So typically in a distributed application you would try to decrease the size of this state and to decrease the amount of updates to this state.
I have two questions about the DHT approach:
- Wouldn't latency be a problem, at least for the first resolution?
- What about information falling off the DHT? Can we make it 100% reliable?
Maybe it's just me, but the potential of being an allround-solution is what is appealing about Namecoin. I have talked about Namecoin with some people, and they weren't really very enthusiastic about it being a decentralized DNS system. As people see it, it's too much trouble as a solution for an only slightly annoying problem. i.e. "Everyone uses Google to lookup names nowadays, and I wouldn't install new software on my system, which may or may not work on all of my systems (smartphones, etc.) just to achieve something that I can by entering 'Wikileaks' in Google search.".gst wrote:While I would really love to see namecoin-style names for Tor and I2P I think that this feature shouldn't be implemented in namecoin, as it would place additional requirements on clients (having a running Tor or I2P daemon). In addition, users would not be able to find out if a site is hosted on Tor when just looking at the domain name.
Regarding the confusion: This could be taken into consideration by the name owner. If a subdomain has both IP and .onion addresses, and you are running tor, you would connect to the .onion one, so there's no problem. If you're not running tor, you go directly to the IP. If it's a separate subdomain for TOR, then it could very well be onion.myhost.bit, so that you know. If the whole site is a hidden service though, I'm sure a lot of people would get confused, so that's a valid concern as well. I still think the benefits outweigh the risk though. Maybe there could be privacy concerns though, but I can't think of any right now.
Regarding mirror extension: People can put anything in their values. Our "standards" can only act as guides for implementors. If something is useful, people will adopt it.
bitcoin:13uSLCLqURqjJkfH6ny56h65oF6bfsVik1
namecoin:NEuYvWtQ8pZzFx7sAnfjeRVtzvieCWF5Ug
namecoin:NEuYvWtQ8pZzFx7sAnfjeRVtzvieCWF5Ug
Re: Domain name specification
Remind : the value field is limited to 1023 characters (and domain : 255).
I don't like the idea to use another namespace (s/) for the same type of data, and i hopefuly discovered another solution. In the DESIGN-namecoin.md file, vince write "The name is normally interpreted as a UTF-8 string composed of several slash-separated substrings".
So, if it is really possible, i propose to do things like that for sub and merge :
d/mydomain/whatyouwant would be used as mysubdomain2.mydomain.bit and used as a part of mysubdomain3.mydomain.bit
d/mydomain/whatyouwant does not correspond to a real subdomain (whatyouwant2.mydomain.bit does not exists, unless it is declared in the parent zone !).
So, your domain can be "d/mydomain1.bit" and you can have a subdomain "mysub.mydomain1.bit" that merges records from another domain : "d/mydomain2.bit/blabla". This allows to declare a config once and use it several times.
Do we really need both sub + merge ? Only merge wouldn't be sufficient ?
Edit :
Creating domain names like "d/mydomain2/blabla" is a waste of a domain. Instead, the "merge":"d/mydomain2/blabla" could simply look at "d/mydomain2" and take the config from the subdomain "blabla". But, in that case, blabla.mydomain2.bit would exists too and we may not want that.
The second choice will create a problem with sub-sub domains because it could be interpreted as merged.whatyouwant.mydomain2.bit. This last sentence lead me the a question : the spec is not designed for sub-sub domains ?
I don't like the idea to use another namespace (s/) for the same type of data, and i hopefuly discovered another solution. In the DESIGN-namecoin.md file, vince write "The name is normally interpreted as a UTF-8 string composed of several slash-separated substrings".
So, if it is really possible, i propose to do things like that for sub and merge :
Code: Select all
{
"": { ... }
"mysubdomain1": "xxx.xxx.xx.xx",
"mysubdomain2":
{
"sub": "d/mydomain/whatyouwant"
}
"mysubdomain3":
{
"ip": "uuu.uuu.uuu.uuu",
"merge": "d/mydomain/whatyouwant"
}
}
d/mydomain/whatyouwant does not correspond to a real subdomain (whatyouwant2.mydomain.bit does not exists, unless it is declared in the parent zone !).
So, your domain can be "d/mydomain1.bit" and you can have a subdomain "mysub.mydomain1.bit" that merges records from another domain : "d/mydomain2.bit/blabla". This allows to declare a config once and use it several times.
Do we really need both sub + merge ? Only merge wouldn't be sufficient ?
Edit :
Creating domain names like "d/mydomain2/blabla" is a waste of a domain. Instead, the "merge":"d/mydomain2/blabla" could simply look at "d/mydomain2" and take the config from the subdomain "blabla". But, in that case, blabla.mydomain2.bit would exists too and we may not want that.
Code: Select all
mydomain1
{
"": { ... }
"mysubdomain1":
{
"merge": "d/mydomain2/whatyouwant"
}
}
Choice 1 :
mydomain2
{
"whatyouwant":
{
"nosub": "true", (or "fake: true", etc)
"ip": "uuu.uuu.uuu.uuu",
}
}
Choice 2 :
mydomain2
{
"whatyouwant":
{
"merged":
{
"ip": "uuu.uuu.uuu.uuu",
}
}
}
NamecoinID: id/khal
GPG : 9CC5B92E965D69A9
NMC: N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9
BTC: 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T
Register Namecoin domains with BTC
My bitcoin Identity - Send messages to bitcoin users
Charity Ad - Make a good deed without paying a cent
GPG : 9CC5B92E965D69A9
NMC: N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9
BTC: 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T
Register Namecoin domains with BTC
My bitcoin Identity - Send messages to bitcoin users
Charity Ad - Make a good deed without paying a cent