[SPEC] Domain name specification

[khal]

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

[gsan]

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.

[khal]

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

[gsan]

I'll put some examples in this section :
http://dot-bit.org/Domain_names#IP_Addresses

Cool.

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.

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.

Maybe we need to rename "ns" to "dns" (and keep "ns" as legacy support).

Should we separate DNS compatible fields from the others (which will need the use of a proxy) in the spec ?

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.

EDIT: So, as a result, some types cover both areas.

Maybe some remarks later on sub, merge and subdomain delegation.

Yes, and we also need to discuss about possible implications. This also goes for public key infrastructure.

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

COMMENT DELETED

OK, I get it now. This is something to think about. It's a very interesting idea...

[khal]

Should we separate DNS compatible fields from the others (which will need the use of a proxy) in the spec ?

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.

EDIT: So, as a result, some types cover both areas.

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.

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

COMMENT DELETED

OK, I get it now. This is something to think about. It's a very interesting idea...

Here are some examples :

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",
  }
}

Simple one, which would include an equivalent to the previous possibilities, or custom instructions :

Code: Select all

{
"mirror": "[http://othersite]/mirror.txt",
}

[gsan]

Simple one, which would include an equivalent to the previous possibilities, or custom instructions :

Code: Select all

{
"mirror": "[http://othersite]/mirror.txt",
}

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?

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?

[khal]

On the other hand, if you are proposing a standard way to mirror sites, that's a whole different thing of course.

All those messages to be able to understand ourself... :p You get it, good job !
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)

So, are these static mirrors of the site?

Yes

Who makes these mirror copies?

People who want to do a mirror, not the original owner

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?

I look at how wikileaks's mirror are done and :
- 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.

That way they won't need to be static.

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).

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?

I don't understand the additionnal record.
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...

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.

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.
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 [])
  }
}

On a-mirror.mydomain.bit :

Code: Select all

{
"mirror":
  {
    "source": "http://original.bit",
  }
}

On another-mirror.myotherdomain.bit that allows to do a mirror of the mirror :

Code: Select all

{
"mirror":
  {
    "source": "http://original.bit",
    "file": "http://whatyouwant.xxx/mirror.wahtyouwant"
  }
}

[gst]

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:

• 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.

In addition to decoupling the name data from the zone data there is another difference to the proposed solution: Tor and I2P records are missing. 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. Therefore, I think it would be better if Tor used its own version of namecoin, where block chain entries point to existing .onion URLs instead of nameservers or DHT IDs. Of course, this would also imply that the Tor namecoin version uses a TLD different than .bit.

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.

[gsan]

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.

Haven't run the numbers but I also think this is an important concern.

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?

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.

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.".

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.

[khal]

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 :

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 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.

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",
        }
    }
}

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 ?