Gopher and OpenNIC

Resolving `gopher` domains

In addition to the guides available at OpenNIC, below you can find other ways to resolve gopher domains, namely ones in which you don't need to delegate all your DNS queries to OpenNIC, but only those for the gopher domains.

Some of the reasons you might want to do this resolution "split" could be:

  • perhaps your "regular" DNS name-server (to which you forward requests to) also resolves some non-public domains, which otherwise will become un-resolvable if all your queries are sent to OpenNIC;
  • perhaps your "regular" DNS name-server (again to which you forward requests to) implements the split-horizon technique, which again won't work if you forward everything to OpenNIC name-servers;

  • or perhaps you don't trust OpenNIC enough to forward all your DNS traffic to;

Configuring `dnscache`

If you have dnscache running as your DNS (recursive) resolver, you can easily configure it to delegate only the gopher domains to OpenNIC, and leave the resolution for the rest of the domains "alone" (i.e. through the current "chain").

The steps needed to delegate only the gopher domains to OpenNIC are simple:

You could instead create a ns folder right besides the servers folder, where you put a file named ns/opennic which contains all the previously mentioned IP addresses, and the you just symlink it to the servers/gopher and servers/opennic.glue.

This is helpful because if you would like to resolve other domains hosted by OpenNIC (like geek or parody) you can just create a new symlink in there, and if some OpenNIC Tier1 name-server goes missing, or a new one appears, in one edit you update all the name-servers for all these TLD's.

Verifying the `dnscache` configuration

You can verify that the resolution is working by trying to resolve the SOA of gopher, or the A of register.gopher.

Configuring `unbound`

Use either one of the configuration options below. To verify any of these configurations, just follow the same procedure like in the case of dnscache.

Configuring `unbound` by using "stub-zones"

You can configure unbound to do the recursive resolution itself starting from the OpenNIC Tier1 name-servers (see also the finding OpenNIC name-servers section on how to obtain the list).

To achieve this add the following lines to the unbound.conf configuration file:

Configuring `unbound` by using "forward-zones"

You can configure unbound to forward the recursive resolution to the OpenNIC Tier2 name-servers.

To achieve this add the following lines to the unbound.conf configuration file:

Registering `gopher` domains

Please note that the registration and management pages do not use HTTPS, thus all the data you submit (including passwords) are sent in clear-text, thus being susceptible to being captured by unwanted parties.

For this reason (and as a general best-practice rule), use a password dedicated only to this purpose.

To register a new gopher domain you'll have to follow the procedure listed on register.gopher.

Basically all you have to do is follow the instructions listed at register.gopher page. However below I present the full process (as it was on 2014-10-18), with some useful annotations.

In order to register a gopher domain, all you need to do is:

Managing `gopher` domains

Please note that the management pages do not use HTTPS, thus all the data you submit (including passwords) are sent in clear-text, thus being susceptible to being captured by unwanted parties.

To manage a gopher domain you'll have to access the Manage page at register.gopher.

It seems there are two ways to host a gopher domain:

Delegating a `gopher` domain

If you haven't already registered a gopher domain, you can do so by following the steps presented in the registering gopher domains section above.

The single prerequisite of delegating a gopher domain is to have access to an authoritative DNS name-server (like Bind, NSD or Knot, etc.)

In order to host yourself a gopher domain, all you need to do is:

When you add a name-server glue for your gopher domain, you should follow the suggested simple names like ns, ns1, dns, or dns1.

However if instead you want to use a more complex name, like say dns1.services.example.gopher, you must use a fully qualified name, like dns1.services.example.gopher, or else the NS record isn't properly created.

Unfortunately after doing this you'll see in the management page a wrong name, something like dns1.services.example.gopher.example.gopher, which seems to be a bug in the page code, but the NS record is properly created.

Verifying the `gopher` domain delegation

There seems to be some considerable delay between when you add the name-server glue, and until you actually can see it published via DNS. The wizard suggests something like 10 to 30 minutes, however in my case it seems it took much longer than that (perhaps an hour or so).

Moreover if one of the following commands fails, or doesn't respond with what you would expect, execute it a few more times, because each time it will (probably) choose a different server. But don't over-due it, as each server will cache that answer, and you'll (probably) have to wait the entire timeout period (which is probably about a few hours).

To check the proper delegation do the following (replace drill by dig and volution.gopher. with your own domain):

OpenNIC miscellanea

Finding the OpenNIC Tier1 name-servers

Finding the OpenNIC Tier2 name-servers