Slaved Zones with BIND9

Also refer to BIND9 Zone Configuration for ready to use zone file examples of Tier 1 and Tier 2 Servers.

Consider using the srvzone script.

For those wishing to set up a more robust local nameserver, or if you plan on running a public Tier 1 or Tier 2 server for OpenNIC, configuring BIND with slave zones is the preferred method. Please read the policies before running a public T2 server. You should also join the appropriate MailingLists so you'll be notified of changing situations which may affect your operation.

Slave zones contain the full record of domain names for each OpenNIC TLD. When a query is made for an OpenNIC domain, you have the exact information needed to proceed directly to that domain, thus eliminating several hops in processing a query. Note that the only difference between a Tier 1 and Tier 2 server is that Tier 1 servers do not process public queries for ICANN domains - they ONLY process OpenNIC TLD requests.

Linux - BIND8/9 Using your package manager, you may install either BIND8 or BIND9, however we recommend using BIND9 due to its more advanced tools for preventing abuse.

Most systems will install BIND either in /etc/bind/ or /var/named/. Within named.conf or one of its included files, you should find a block similar to this:

zone "." {
	type hint;
	file "/etc/bind/db.root";
};

You need to comment or remove these lines. Instead of using a hints file, you will now be slaving the root zone plus another zone which contains a list of all OpenNIC public Tier 2 servers. Typically you will have a 'named.conf.options' file in your default BIND configuration. Within the options file will be a directory parameter/statement. This parameter tells BIND where you plan on storing your slave files. For example, under debian/ubuntu systems, you may find something like this: directory “/var/named”; This line tells us that BIND will save your slave files under /var/named/. If you cannot find this parameter, or you are uncertain, you should use full path names in the file parameter specified for each zone. However if you do have a directory specified, you can simply give filenames, as short as 'example1.zone', 'example2.zone', and so on. Make sure you name the zone files according to the zone name, for identifying them later, as well as not having two identical names, as it will give an error.

It is common practice to only include the actual authoritative nameservers of a zone in the masters statement. However, for ease of use and setup, you may add the following lines to your named.conf in place of the above 'hint' section:

# check to make sure these are still correct!
masters opennicNS {
        161.97.219.84;                  # ns2.opennic.glue
        2001:470:4212:10:0:100:53:10;   # ns2.opennic.glue
        104.168.144.17;                 # ns3.opennic.glue
        2001:470:8269::53;              # ns3.opennic.glue
        163.172.168.171;                # ns4.opennic.glue
        2001:bc8:4400:2100::17:213;     # ns4.opennic.glue
        94.103.153.176;                 # ns5.opennic.glue
        2001:bc8:4400:2100::17:213;     # ns5.opennic.glue
        207.192.71.13;                  # ns6.opennic.glue
        178.63.116.152;                 # ns8.opennic.glue
        2a01:4f8:141:4281::999;         # ns8.opennic.glud
        138.68.128.160;                 # ns9.opennic.glue
        2a03:b0c0:1:a1::46b:a001;       # ns9.opennic.glue
        188.226.146.136;                # ns10.opennic.glue
        2001:470:1f04:ebf::2;           # ns10.opennic.glue
        45.55.97.204;                   # ns11.opennic.glue
        2604:a880:800:a1::14c1:1;       # ns11.opennic.glue
        79.124.7.81;                    # ns12.opennic.glue
        2a01:8740:1:ff13::ae67;         # ns12.opennic.glue
};
masters opennicPeers {
};

zone "." in {
	type slave;
	file "tld-root";
	allow-transfer { any; };
	notify yes;
	masters { opennicNS; };
};
zone "dns.opennic.glue" in {
	type slave;
	file "dns.opennic.glue.zone";
	allow-transfer { any; };
	notify yes;
	masters { opennicNS; opennicPeers; };
};

Note the masters sections which allows you to specify all of the available Tier 1 servers in a single block. This simplifies making updates when needed. OpenNIC peers will typically carry their own root zone, but otherwise provides all other OpenNIC zones.

If you have a firewall or port-forwarding configured to direct DNS traffic to your server, please ensure that port 53 for both UDP and TCP are enabled. The most common failure for a public Tier 2 server is that port 53 TCP is blocked, which will cause you to fail testing of the 'dns.opennic.glue' zone.

This completes the most basic slave zone configuration, and will be suitable for any private or public nameserver. However you can take this a step further and slave ALL of the OpenNIC zones, which further improves the efficiency of the queries your server performs. The caveat of this setup is that you must be aware of TLDs being added or removed, as noted on the mailing lists.

To slave all of the OpenNIC zones, visit BIND9 Example Files and add the zones to a zone file.
:!: Make sure they are still up to date! 1)
:!: If you decided to use the masters block containing all T1 servers, make sure to change all masters statements in the example file to masters { opennicNS; };. Your configuration will still be valid and working if you don't, but it decreases maintainability.

Finally, you will want to consider WHO is allowed to query your server and add an appropriate line to your options file. The default behavior (if you have not specified otherwise) is to only allow your local network to query, and the line for your options file would look like this:

allow-recursion { localnets; localhost; };

However if you wish to allow anyone from the internet to query your server (for example, running a public Tier 2 server), you would use this option:

allow-recursion { any; };

To finish your new configuration, restart BIND. If you have logging enabled, you should see BIND attempting to transfer the various zones to your server. If you look in the directory specified in the options file (or in the directory you specified if full path names were used), you should see the zone files being added.

If you are creating a public Tier 2, and have your firewall or port-forwarding configuration completed, you can test the public access of your service by visiting the test link https://servers.opennicproject.org/srvtest3/ and entering your IP address. If there are any failures you cannot resolve, please visit the mailing list or IRC to get help.

—————-Historical Note———————-

The old test link http://report.opennicproject.org/t2log/t2.php does not always produce favorable results

A standard configuration will provide full nameserver capabilities, however in certain cases you may wish to modify the configuration below. As an example, if you are setting up a server within a company or school campus which already has their own nameservers providing DNS information for locating on-site computers. To allow both on-site and OpenNIC name resolution, try the following:

  • Do not include the root zone or hints
  • Do include slave zones for all of the OpenNIC TLDs
  • Add 127.0.0.1 as the first nameserver in resolv.conf

This solution should allow your server to ONLY resolve OpenNIC domains, then pass resolution of everything else back to your network.


  • /wiki/data/pages/opennic/t2slaved.txt
  • Last modified: 2 years ago
  • by Olde16