Domain Name Specification

Goals of this Specification

• Standardized support for most, if not all¹, 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 NS servers, while still providing support for non-IP networks.
• Enabling hierarchical structures within 611 (SixEleven) [coin].
• Establish a standard for future extensions.

¹ Some standard resource records, like SOA, can be derived from other records, and others may not be applicable in a distributed naming service context. Also see #TODO.

Name field

Name is a lowercase string, which begins with d/, followed by the domain name will append the default SLD (.611.to) to the name specified here.

Example

d/example

Valid Domains

Only valid domain names are allowed. As per RFC 1035, Domain Names – Implementation and Specification,

They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less.

Note: Since this is a measure against compatibility issues with DNS, names consisting of all numeric values and underscore can be discussed.

Regular Expression

The following regular expression can be used to test valid domain names. You can visualize the regular expression and see unit tests here.

^[a-z]([a-z0-9-]{0,62}[a-z0-9])?$

International Domains

The IDNA standard encoding is used for internationalized domain names. This means that Unicode names need to be converted to ASCII compatible encoding according to IDNA, before registration. This can be done using the idn command-line tool:

$ idn -p Nameprep ŝtelo
xn--telo-u5a

Value field

Value is a UTF–8 encoded JSON object with a maximum size of 520 bytes, where all entries are case-sensitive.

The JSON object (the domain configuration) is an associative array of configuration options of the domain in context. Since sub-domains are also configured via a domain configuration, we will use the word domain to signify the item that is being configured, even though it may be a sub-domain in the context of the value field.

Example

{
    "ip"      : "192.168.1.1",
    "ip6"     : "2001:4860:0:1001::68",
    "tor"     : "eqt5g4fuenphqinx.onion",
    "email"   : "hostmaster@example.611.to",
    "info"    : "Example & Sons Co.",
    "service" : [ ["smtp", "tcp", 10, 0, 25, "mail"] ],
    "tls": {
        "tcp": 
	{
            "443": [ [1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1] ],
            "25": [ [1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1] ]
	}
    },
    "map":
    {
        "www" : { "alias": "" },
        "ftp" : { "ip": ["10.2.3.4", "10.4.3.2"] },
        "mail": { "ns": ["ns1.host.net", "ns12.host.net"] }
    }
}

Below is a list of possible entries. Matching DNS resource record types are also listed.

"i2p": {
    "destination": "XaZscx...0jGAAAA"
    "name": "example.i2p"
    "b32" : "ukeu...nkdq.b32.i2p"
}

"map": {
    "www": { "alias" : "www.example.com." },
    "www2": { "delegate": ["d/example", "www"] }
}

"tls": {
    "tcp": {
        "443": [ [1, "660008F9...7621B787", 1] ],
        "25": [ [1, "660008F9...7621B787", 1] ]
    }
}

"ds": [
    [31381,8,1,"pA1W...ceTI="],
    [31381,8,2,"toHB...ndexitQ6j8E="]
]

Addresses

Multiple addresses per domain can be specified using String Arrays. This is currently proposed for only IPv4 and IPv6 but can be extended to other addresses in the future. Multiple addresses will be used for round-robin load distribution.

Example with multiple IPs

`"ip6": ["2001:4860:0:1001::68", "2001:4860:0:1001::69", "2001:4860:0:1001::70"]`

Examples with a single IP

`"ip6": "2001:4860:0:1001::68"`
`"ip6": ["2001:4860:0:1001::68"]`

Domain references

service, alias and translate entries accept references to other domains.

To reference domains in the current context, enter the referenced name as-is, or in the case of inner sub-domains, insert dots (.) between names.

Examples

"www"
"ftp.eu"

An empty String ("") signifies the currently configured domain. In the below example, www.us.<domain> is an alias for us.<domain> (and not <domain> itself).

{ 
    "map": { 
        "us": {
            "map": { "www": { "alias": "" } }
        } 
    }
}

To reference absolute domain names, add a dot (.) to the end of the String to signify the root domain.

Examples

"google.com."
"ns.example.611.to."

The @ character is also an absolute reference, and is converted to the topmost domain of the 611 [coin] value field that is being configured. For standard domains in the d/ namespace, that is the domain name (see #Importing and delegation).

Sub-domains

"map" Object is an associative array mapping sub-domains to their configurations. Configuration format is the the same as the value field itself, making moving, copying and importing domains easier.

There are two special sub-domain specifiers, "" and "*", which are respectively the reference to current domain and the wildcard record. Wildcard matches all non-existent sub-domain names in the current context.

If a map record contains a “” record, but the root specifies a corrosponding record (such as an ip/ip6/onion record), than the record in the root takes precedence.

Sample entry for d/domain

{
    "ip" : "8.8.8.8",
    "map":
    {
        "us":
        {
            "ip" : "1.2.3.4",
            "map": { "www": { "alias": "" } }
        },
        "eu":
        {
            "map": { "www": { "alias": "us.@" } }
        },
        "*": { "alias": "" }
    }
}

In the above example, us.domain.611.to www.us.domain.611.to and www.eu.domain.611.to resolve to the IP 1.2.3.4, while eu.domain.611.to doesn’t have an assigned IP.

Also, the wildcard implies that, for instance, www.domain.611.to is an alias for domain.611.to and resolves to 8.8.8.8, but it doesn’t imply that nonexistent.us.domain.611.to will resolve.

Importing and delegation

Delegation of domain configuration is made possible by the delegate record type. This can be used to extend the space for domain data, better organization, handing over management responsibilities, sharing data between domains, etc.

Note: The s/ application specifier is proposed to distinguish non-resolvable domain data from domain names. Other specifiers, like dd/ for “domain data” can also be considered.

Examples

"delegate": ["s/example001"]
"delegate": ["d/example", "ftp"]
"delegate": ["s/exampledata99", ""]

The referenced 611 [coin] entry does not have to be in the domain namespace ("d/"), and will be treated as a domain configuration JSON Object. The s/ application specifier is proposed to distinguish non-resolvable domain data from domain names.

Sub-domains can be referenced through a second item in the array, using the sub-domain reference notation. So, ["s/example001"] and ["s/example001", ""] refer to the same data.

Such delegations override all other entries, including ns and info. Since this renders other entries unnecessary, a second notation is proposed at the sub-domain mapping level:

"map": {
    "ftp": ["s/somerandomname"],
    "www": ["d/otherdomain", "www"]
}

Note: If the above proposal is accepted, the delegate directive would get precedence in the case of "" sub-domain.

Warning: Details about the below import directive aren’t clear yet.

The import directive is provided to simply merge domains from different 611 [coin] records with the current one. It’s an array of references to 611 [coin] domain entries, which have the same notation as delegate references. However, instead of passing the control to the referred configurations, data is imported to the current context and then overridden by explicitly provided entries.

d/example

{
    "import": [ ["s/shareddata", "www"], ["s/shareddata", "ftp"] ],
    "ip"    : "10.2.3.4",
    "map"   : { "ftp" : { "email": "example@mail.611.to" } }
}

s/shareddata

{
    "ip" : "10.0.0.1",
    "map": { 
        "www" : { "alias": "" },
        "ftp" : { "ip": "10.0.1.2", "email": "shared@mail.611.to" }
    }
}

Here, data from d/shareddata is imported from within d/example. Since data is imported as-is, www.example.611.to becomes a reference to example.611.to and resolves to 10.2.3.4 and not 10.0.0.1. On the other hand, email field of the imported ftp subdomain is modified.

Of course, instead of importing specific subdomains one by one, "import": [ ["s/shareddata"] ] could be used in the above example.

Service records

TODO (see http://en.wikipedia.org/wiki/SRV_record)

DNS MX records need to be derived from the service records for SMTP.

TLS support

The traditional TLS trust model is very centralized. The ability to create a certificate for your web site is concentrated in the hands of a select few governments and corporations. By having your site support TLS, you are putting yourself at their mercy. This goes squarely against the principles of decentralization and distributed trust at the core of the 611 (SixEleven) [coin] project.

Fortunately, it is possible to use TLS without relying on a central certificate authority list. The mechanism is defined as follow:

• Generate a self-signed certificate for your 611 (SixEleven) [coin] domain, or a sub-domain. Wildcards are okay.
• Add a fingerprint field in your 611 (SixEleven) [coin] record, containing the fingerprint for this certificate. If targeting a sub-domain, place it in the proper map field.

On the user side, 611 [coin] client software that implement this specification will intercept TLS requests to your domain/sub-domain. The certificate returned by your server will be matched against your 611 [coin] record.
If the certificate is self-signed, the certificate common name matches the requested hostame, the certificate time range is valid and the certificate fingerprint matches one of the fingerprint found in the record subset matching the given hostname, the client software will allow the TLS connection to proceed, and make it appear valid and trusted to the user.

That later part is tricky, as most TLS clients are designed to work with a centralized trust model. It is recommended that 611 [coin] client software generate a unique self-signed certificate and install it as a trusted root Certificate Authority in the appropriate TLS clients, such as web browsers. Once that initial setup is done, 611 [coin] client software can use that root certificate to generate TLS certificates that browsers will accept. 611 [coin] client software should cache such generated certificates and reuse them as needed.

Note that the fingerprint accepts an array of fingerprint. This allows a site owner to update their TLS certificate without downtime. In such a scenario, a site owner would generate a new certificate, update his 611 [coin] record to hold both the old and new fingerprint, and wait until the record has safely propagated. Then the site could start using the new certificate, and the old fingerprint could be safely removed from the record.

This isn’t the first attempt to use TLS certificate fingerprint in a DNS-like system to replace the traditional CA model. In fact Chrome 14 supports certificate fingerprints in DNSSEC-signed responses (http://www.imperialviolet.org/2011/06/16/dnssecchrome.html ), and there are talks in the Firefox dev team to implement something similar (https://wiki.mozilla.org/Security/DNSSEC-TLS )
This opens the possibility that there might be a smoother way in the future to implement this in 611 (SixEleven) [coin] that wouldn’t require users to add a strange CA to their browsers.
I’d be interested in someone knowledgeable in DNSSEC commenting on this, and the odds of 611 (SixEleven) [coin] being able to serve DNSSEC records that end-user applications might accept.

—

(LS: Someone knowledgeable in DNSSEC… That’ll be hard to find around here. I’ve done my best to work with it, and it’s just like ‘authoritative’ SSL. You pretty much have to cram a bunch of authorities down someones throat to bootstrap it, then eventually decorate it with some gold, green, or color du jour. While I don’t consider myself an expert in it at all, I’ve done enough work with it to see it as the same thing. 611 (SixEleven) [coin] is definitely the appropriate way to manifest the illusion DNSSEC is aiming to create, and I fully support the above proposal. I’m sure we’ll find a lot of people vested the current DNS oligarchy to critique, and possibly admire the work, but there’s a very slim chance that we’ll get them to allow us into their certificate chain, or even a user to control their own chain as authorative… I do however, recommend that we aim to have each locally trusted 611 (SixEleven) [coin] DNS server be considered ‘the root authority’ for their own users… And if the users don’t like it, they can learn how to read. Then the local DNS server can ‘sign’ everything it finds in SIL space, and the browser can match the signatures. — during the transition to ‘611 [coin] everywhere,’ at least)

—

Ugh, SSL, the kludgy hack that protects no-one. This has been studied in-depth and it will need to be patched in the http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/ (http://www.youtube.com/watch?v=pDmj_xe7EIQ), probably using concensus from independent nortary systems and heuristics to check the quality of the security, much like phishing and anti-virus protection. Bottom line: this problem is much, much bigger than DNS and so will any solutions. I don’t see the harm in defining a mechanism for publishing public keys, but this should be a low priority issue for now. —Indolering 05:54, 18 August 2013 (UTC)

—

Using the cert fingerprint directly creates an unnecessary barrier to updates. Publishing an “authoritative” public key instead allows the domain owner to sign/update his own certs and revocations without having to update the blockchain. This essentially makes it possible for each site owner to become his own CA, or if he doesn’t want the hassle of maintaining his own secure infrastructure (e.g. air gapped signing computer that never sees the network), he can carefully choose a CA that he personally trusts, and let his visitors know about that choice.

All of the proposed content of these records could be replaced with a single DNSCurve style NS record, which server could securely publish all of this info. (Using ECC instead of RSA is an important optimization: keys are smaller, encryption is faster and more secure.)

—

Could browsers be amended such that they check 3 places in order, first wins: 1) DNSSEC for an TXT (SSL) record, 2) 611 (SixEleven) [coin] record for the domain (obviously only .611.to domains as of now), and failing that 3) check signature against CA certificates in the browse as normal. Those using the new systems do not need a root CA signed certificate, and legacy certificate will still work.

In cases 1 and 2 the public half of the key used to self-sign the SSL certificate would be stored in the DNNSEC/611 (SixEleven) [coin] record and can be trusted. With option 3, it’s business as usual.

—Drak 14:49, 15 December 2013 (UTC)

—

Discussion

1023 character value limit

…

Whois

A public 611 (SixEleven) [coin] WHOIS server is available:

$ whois -h whois.611.to example.611.to

TODO (Also, fix the info examples in the document accordingly.)

Legacy support

Below rules are supported, but will be obsoleted at one point:

• Sub-domains can be associated directly with String values, which will be interpreted as IPv4 addresses. E.g.: "map": { "www": "10.0.0.1" }
• ns is as an alias for dns.
• Empty sub-domain name ("") may be used to configure the domain. Entries specified here have lower precedence.

Implementation

TODO: Insert implementation notes here.

Some entries act like directives that change the way other entries are processed. In order of precedence, these are:

• delegate : Hands over control, so other entries can be ignored.
• import : Imports modify the currently processed object. Latest modifications have precedence.
• ns : DNS bridges hand over control, so other entries can be ignored.

However, “glue” records, like “ip” or “ip6” records for a host within the domain being defined must be used. E.g.

{ "ns": [ "ns1.example.611.to" ], "map": { "ns1": { "ip6": [ "2001:db8::1" ] } } }  

Similarly, “ds” data from the blockchain, not the DNS server, should be used to verify results from a DNSSEC zonefile. More sophisticated proxy resolvers that can serve non-IP services can resolve those addresses but need to ignore IP services that are hierarchically below this point. How this would actually work is not clear yet.

• translate : Only affects sub-domain resolution. In effect, this causes the sub-domains in the map Object to be ignored. Addresses and other information in the domain context are still processed.
• alias : This works like the opposite of translate. It ignores the records in the current context and resolves to the referred address instead. Otherwise, sub-domains entries are still processed as usual. (Note: DNS bridge implementors must keep in mind that CNAME records cannot coincide with other records.)

The topmost email record is to be used as the SOA e-mail address. email records of other entries can be converted to DNS RP records. This only involves DNS bridges. Whois servers could interpret this entry as the host master e-mail address.

Non-IP services, such as tor and freenet can be supported by a special resolver (e.g. in a proxy server). If a name resolves to both an IP and a hidden service, or even multiple different hidden services, the resolver needs to pick one.

=== EPP / OpenReg Prior Work === Definitely look at [OpenReg] from 2004 and the related EPP RFCs, [RFC 3730] [RFC 3731] [RFC 3732] [RFC 3733] [RFC 3734] [RFC 3735]. Much of what’s being written here has been mapped out already, and already has BIND integration.

Similarities between OpenReg and this draft are quite apparent. If we can indeed take a large portion of this well thought out (but not marketed, obviously) system. Some changes would have to be done (replacing timestamps by block count, establishing multi-block translation and exchanges, and either removal of XML to something lighter or doing the esil to point to EPP data)…

Security

The purpose of 611 (SixEleven) [coin] is to provide a decentralized, yet authoritative database. It is certain that domains defined in the system are authentic and cannot be mangled by an unauthorized entity. (Although there may be caveats about this, they are outside the scope of this document.)

However, it’s hard to be certain about the information we get from the external DNS servers supplied through dns entries. How to solve this properly is being discussed, please join in.

One advantage of running on a locally authoritative system is that a certification authority for public keys isn’t needed. (see #TODO)

Mirror sites

A method to make mirroring of sites more manageable is proposed on the forum.

Encoding

Current encoding for values is UTF–8 encoded JSON strings, which isn’t very space efficient. A binary encoding like BSON wouldn’t yield significant space savings, but gzip compression is likely to give good results.

Gzip compression gives us variable savings, but we can expect to be able to fit between 1500 and 2000 characters in most cases.

In return, we lose the ability to strictly predict if a given record will fit in the blockchain, at least until the record is gzipped.

Implementing gzip compression in a backward-compatible fashion should be relatively transparent if done in 611d itself. The magic number that starts a gzip stream cannot start a valid JSON payload, and can as such be reliably used to identify compressed streams.

ASN.1 would be a nice fit, and if we are dealing with X.509 certs, we already have a parser. Also permits compression. –LittleBrother

Future extensions

esil

Regarding #Encoding

Proposed Question: How far do we really want to push the encoding? Being able to fit in like, I dunno, 3-4k would be nice, but there’s a point at which the SIL system should just be handling the secondaries (+ a little extra) authority system that NS’s almost everything secondary.

Proposed Solution: Like EDNS, maybe we should allow

{
    "esil" : {
            "map" : {"https://whatever/ns.txt", "http://blahblah.i2p/blah/ns.txt", "ftp://whatever.onion/ns.txt", "freenodeid","magnet://..." "finger://..."},
            "auth": { 
                     {hash: {"sha256": "c48c7a3388b98f8b999d9db4e8a5dc63fdc831183e0223b46a30886c514cb72d"}, "sig" : "yadayadya"},
                     {hash: {"sha256": "225e787582914bcbcf0eadb995bce7a555b99697b0d6a9babb3dcc443c371244"}, "sig" : "yadayadya"},
                     {hash: {"md5": "9f8d067fdb2373a64b4c3e420f31f4cc"}, "sig" : "yadayadya"}
            }
}

Where “sig” and “hash” will be a list of valid hashes and signatures OF THE FILE BEING DOWNLOADED (different protocols may result in different results)

The EDNS proposed above is quite fat, 569 bytes, but should still allow enough room in the other areas for a bootstrap of the domains used to get the files.

I don’t think we need to waste more bits on saying which network is used to access the url, but hey, thats just me… They seem to all be quantum enough with what we have today – famous last words to be

• There’s definite value in having self-contained records that don’t triggered externally observable requests when resolved. Note that we have import and delegate mechanisms to spread the definition of a domain across several 611 [coin] records.

• I’m in agreement. However these seem to mostly be NS record DNS based, and if we’re branching away from DNS spec, then having alternative methods other then just plain NS->IP to access these records may be wise. I think it’s ripe for abuse, and the “p/” trust would definitely have a part to play in if a resolver is interested in following those routes (either for trust or cost of accessing these networks). #EPP / OpenReg Prior Work may have some solutions, I haven’t dug through everything over there yet. -ls

TODO

Priority TODO

• Specifications of useful DNS records, such as spf and CERT are currently missing. (Note: spf record type will be converted to both SPF and TXT by DNS bridges.) Hint: 611 [coin] client allows you to setup a TXT spf record using the name record type.
• Research into usefulness of technologies like NAPTR and HIP is needed before finalizing the specification.
• Ideas about the 611 (SixEleven) [coin] PKI involves domains as well.
• TLS, how will will handle the time delay between revocation of a certificate and potential siezure of the private key. I mean, we could be talking about a good hour of signed traffic to the wrong party. Possibly an emergency alert broadcast system with abuse prevention (like alerts signed by your p/’s? and via web of trust?) (see my note above on using the public key instead of the fingerprint. Is your emergency broadcast idea going to be faster than the DNS TTL? If so, I predict that it will be ripe for abuse. —LittleBrother)
• Development Versioning: I’ve dubbed the spec as was on 20110717 “DRFT20110717” or just “DRFT01” in my code internally. I got some decent work done parsing the current domains into a format that works with what’s currently posted here, as well as what’s acceptably used. While I did build in some flags to handle “sloppy A records” (SPEC01_TYPE_SLOPPY_ARECORDS
• Protocol/Software changes (within a single chain) should be done by a n% vote, where n > cost of starting an alternative chain (discussed below). It’s wild west right now, but steady growth is going to require consensus. I don’t care if we disagree on what’s better, but I’d like to be able to log into your irc server at a named location to maintain diplomatic relations however corporate or dada they may be. Disconnection from diplomacy can only be assured by Layer 1 desperation (or in the event of war, a whole lot of Layer 0 NO CARRIERS)