Jump to: navigation, search

Generify Transport Data Structures

The current spec basically renames Plain Old DNS entries, modifies their capabilities slightly, and manages to bring forward a bunch of cruft and weirdness. While some of the syntactical improvements make it a bit easier to use, the added confusion of figuring out when it follows vs deviates from the original spec makes the Namecoin DNS spec about as confusing as the PODS spec.

This proposal suggests refactoring the spec into generic and transport specific entries. The generic entries would be translated into the transport specific entry at run time.

Composition of a Namecoin URI

Each Namecoin record fundamentally consists of three items:

  • URN
  • Security Information
  • URL
  • Meta
{
  
  "name": "foo",  //urn
  "value": {
  
    //security
    "tls": {
      "tcp": {
        "443": [
          [1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1]
        ],
        "25": [
          [1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1]
        ]
      }
    },

    //URLS
    ////name server
    "ns": [ 
      "ns.bar.bit",
      "ns.bar.com",
      "192.168.1.1"
    ],
    ////default URLS
    "ip": "192.168.1.1",
    "ip6": "2001:4860:0:1001::68",
    "tor": "eqt5g4fuenphqinx.onion",

    ////URL-related structures
    "map": {
      "www": {
        "alias": ""
      },
      "ftp": {
        "ip": ["10.2.3.4", "10.4.3.2"]
      },
      "mail": {
        "ns": ["ns1.host.net", "ns12.host.net"]
      }
    },

    //meta
    "email": "hostmaster@example.bit",
    "info": "Example & Sons Co."
  }
}

Universal Resource Locators

Note that URL is meant in the most abstract sense: Universal Resource Locators. These come in two forms, a bag of default paths or a nameserver which is used to retrieve the exact paths.

A blockchain is not the ideal place to store default URLs. It's risky, it takes up a lot of unnecessary space, and most importantly, it's the same no matter what transport a person has access to! Indeed, the idea of pushing all such information to an ephemeral data store (such as a DHT like TeleHash) comes up regularly when discussing changes to the core.

That being said, having the URLs in the record is also very convenient and there is plenty of technical merit to having a default entry.

Transport Specific URLs

What's odd about the current spec is that we sometimes to specify the transport of a URL and forget about it the rest of the time. The convenience comes around when you are trying to parse a record to determine if you can connect. You can check for Tor or Ipv6 support on the client and then choose to ignore or use those URLs.

However, this is very limited and leads to a vast amount of duplication across transports, one could have a nearly identical entries for http/frame resolution, Tor, and I2P transports. It's also more complex for the parsing engine as you cannot cleanly divide the transport checker from value parser.

Declarative Transforms

Instead of entire spec mimicking PODS in the main spec and then carving out all of these special cases, we should abstract PODS as yet another "transport" try to make the underlying data structures generic for all of the transports. Whatever transport you support pods/bind, tor, http, i2p, etc would be used to transform the entry on the fly.

As a very naive and oversimplified example, lets reduce this down to a dictionary of sub-domains and an array of default values name link.

"name" : "foo",
  "value": {
    ...
    "link": ["foo.com", "bar.com", "32.155.135.3", ],
    "subs" : { 
        "*" : link[0],
        "bar" : link[1],
        "baz" : link[1],
    }
  }

The above would work fine for uncensored clients using HTTP or legacy DNS. Transforms could be applied to values in each as required by the specific transport, such as the BIND format needing a period '.' to the end of all FQDN.

I am not an expert with PODS, but I am sure that there will be structures which have no equivalent in other transports. For that, publishers could still include a transport specific default into each record:

"name" : "foo",
  "value": {
    ...
    "link": ["foo.com", "bar.com"],
    "subs" : { 
        "*" : link[0],
        "bar" : link[1]
    }
    "bind" : { 
        "A" : {"*" : link[0] },
        "CNAME" : { "bar" : "arbitrary.bar.com."}
        ...
    }
  }

These transport specific entries would either supplement or override (perhaps with _transport, i.e. _bind, _tor, ...) the existing generic structure. In addition, the nameserver could retrieve a "link" array or a complete override of the transports data structure.

Each transport would handle the nameserver in their own way. A traditional DNS client would make a traditional call to the nameserver and get a full-blown entry in response. A Tor client could query the nameserver for a Tor specific "link" list, which could include a mix of traditional domains and tor hidden service URLs. If a HTTP client gets a 451 error, it can make a call to nameserver asking for an individualized link array (the base domains would be known to the censor). In the future, we could explore a DHT nameserver which would enable a more complex set of interactions.