{{define "Main"}}

Namecoin DNS Services

Access any Namecoin .bit domain by appending "{{.TLD}}". For example, example.bit becomes example.{{.CanonicalSuffix}}. Caveats.

Check a domain name

You can use this lookup tool to check the validity of a domain's configuration.

Other tools: Validate JSON

{{.CanonicalSuffix}} provides public Namecoin authoritative DNS services. The nameservers it provides can be used to convert domain names into Namecoin suffixes, or directly to query the .bit zone.

  1. The {{.CanonicalSuffix}} nameservers are authoritative for the .bit zone. For example:

    $ dig A nf.bit. @{{.SelfName}}
94.23.252.190

    You can use the nameservers in this mode by configuring a suitable DNS resolver. Unbound is recommended due to its support for {{if .HasDNSSEC}} DNSSEC and {{end}} configurable stub zones. See how to configure Unbound.

  2. The {{.CanonicalSuffix}} nameservers are authoritative for any matching suffix. A suffix matches if it contains the label "bit". Such suffixes are automatically aliased to the "bit" zone. For example, "example.{{.CanonicalSuffix}}" is equivalent to "example.bit", but because it uses an ICANN TLD, it can be accessed without prior configuration.

    Since the {{.CanonicalSuffix}} nameservers automatically recognise any suffix containing the label "bit", you can convert any suitable name (of the form bit.tld, or rather more verbosely bit.yourdomain.tld) to a .bit suffix by changing its nameservers to those of {{.CanonicalSuffix}}.

    There are a number of caveats to this mode of operation; see Caveats.

Both of these modes of operation require you to trust the {{.CanonicalSuffix}} operator (and the operator of {{.TLD}}, and ICANN, etc.); see Caveats.

Nameservers

The following nameservers are provided for public use in the modes described above:

    {{range .CanonicalNameservers}}
  1. {{.}}
    2. {{end}}

Configuring Unbound

The following is an example of the directives which should be placed in an Unbound configuration file:

server:
  # (other directives omitted){{if .HasDNSSEC}}
  trust-anchor-file: "/etc/unbound/keys/{{.CanonicalSuffix}}.key"{{end}}
  stub-zone:
    name: bit.
{{range .CanonicalNameservers}}    stub-host: {{.}}
{{end}}    stub-prime: yes
{{if .HasDNSSEC}}

You will need to place the {{.CanonicalSuffix}} trust anchor (a DS record) in /etc/unbound/keys/{{.CanonicalSuffix}}.key. See DNSSEC.

{{end}}

See the Unbound documentation for information on setting up Unbound.

Caveats

Using a suffix has the following caveats:

DNSSEC

{{if .HasDNSSEC}}

The {{.CanonicalSuffix}} nameservers support DNSSEC. For use as a suffix, operation is automatic so long as you use a validating resolver. (Third party suffixes using the {{.CanonicalSuffix}} nameservers should avoid attempting to configure DS records at this time due to the potential need for KSK rollover.)

If using the {{.CanonicalSuffix}} nameservers to access .bit directly, a DNSSEC trust anchor must be configured. You should use a validating resolver to lookup the DS records for {{.CanonicalSuffix}} and use those as the trust anchor. See Unbound for details on how to configure Unbound.

{{else}}

The {{.CanonicalSuffix}} nameservers do not support DNSSEC.

{{end}}

Webserver Configuration

Apache

You can configure a virtual host in Apache which responds to any hostname of the form "example.bit.X." using the following:

<VirtualHost ...>
  ServerName example.bit
  ServerAlias example.bit.*
</VirtualHost>

Nginx

You can configure a virtual host in nginx which responds to any hostname of the form "example.bit.X." using the following:

server {
  listen 80;
  server_name example.bit example.bit.*;
}

nginx also supports regexes for server names; see the nginx documentation.

Lighttpd

Lighttpd can use regexes to match hostnames, so configuring suffix support is easy:

$HTTP["host"] =~ "(^|\.)example\.bit(\..*)?$" {
  ...
}

Origin Issues

Web browsers use a database of public suffixes to determine the maximum domain scope at which a cookie can be set. For example, a site a.b.c.com can set a cookie at a.b.c.com and c.com but not com. Conversely, domains such as this one can have cookies set on them by domains under them. example.{{.CanonicalSuffix}} can set a cookie for {{.CanonicalSuffix}}, thereby creating a “supercookie” which tracks users over all domains under the suffix.

The optimal solution to this is to have the domain placed on the public suffix list. However even when this is done it may take some time to be rolled out.

This page will erase all cookies visible to it whenever you visit it. Thus visiting this page will always erase any suffix-wide supercookies. This is the least (and most) that can be done about the issue without the use of the public suffix list.

Source Code

Each {{.CanonicalSuffix}} nameserver runs a Namecoin full node and ncdns, a daemon for serving DNS records from the Namecoin .bit zone. ncdns relies on the full node.

This has the advantage that each nameserver is operationally completely independent of one another (aside from possessing the same zone signing private key, as described above).

This software is open source.

Point of Contact

Send enquiries, issues, questions, threats, etc. to {{.Hostmaster}}. {{end}}