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.
Security Considerations
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.
TESTING T2 Public Server
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
Alternate Configurations
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.