Revision history for Tier2ServerConfig
Additions:
~- **[[Tier2ConfigWindows2016|Windows 2016]]** (Recommended Setup! Slave Zone Method)
~- [[Tier2ConfigWindows2012|Windows 2012]] (Root-Hint Method)
~- [[Tier2ConfigWindows2008|Windows 2008]] (Root-Hint Method)
~- ++[[Tier2ConfigWindows2000|Windows 2000]]++ (Depreciated!)
~- [[Tier2ConfigWindows2012|Windows 2012]] (Root-Hint Method)
~- [[Tier2ConfigWindows2008|Windows 2008]] (Root-Hint Method)
~- ++[[Tier2ConfigWindows2000|Windows 2000]]++ (Depreciated!)
Deletions:
~- **[[Tier2ConfigWindows2008|Windows 2008]]**
~- **[[Tier2ConfigWindows2012|Windows 2012]]**
Additions:
++For Debian OS users, AlejandroMarquez has contributed [[Tier2Config-Script|this set of scripts]].++ (//since 2015-10-09 the host needed for this method is down//)
Deletions:
Additions:
++[[Tier2Config-Script]] by [[AlejandroMarquez|Alejandro Marquez]]++ (//since 2015-10-09 the host needed for this method is down//)
Deletions:
Additions:
For Debian OS users, AlejandroMarquez has contributed [[Tier2Config-Script|this set of scripts]].
Additions:
++[[opennicZoneScript]] by [[JeffTaylor|Jeff Taylor]]++ (//This procedure and script no longer work//)
Deletions:
Additions:
CategorySupport
Additions:
~- Tier-2 servers **will** experience ""DDoS"" attacks. Please be sure to visit the **Tier2Security** page for information on how to mitigate these attacks. Other members will do what they can to provide assistance, however ultimately it is your responsibility to ensure that your own servers do not participate in man-in-the-middle or amplification attacks. You do not want to become part of an attack!
Deletions:
Additions:
~- Tier-2 servers **will** experience ""DDoS"" attacks. Please be sure to visit the **Tier2Security** page for information on how to mitigate these attacks. Other members will do what they can to provide assistance, however ultimately it is your responsibility to ensure that your own servers do not participate in man-in-the-middle or [[DNSAmplification|amplification attacks]]. You do not want to become part of an attack!
Deletions:
Additions:
~- Typical bandwidth usage may only be a few-hundred MB/month, but a ""DDoS"" attack can easily put you into hundreds of **gigabytes** in a few days!
Deletions:
Additions:
++[[srvzoneScript]] by [[JeffTaylor|Jeff Taylor]]++ (//This procedure and script no longer work//)
Deletions:
Additions:
[[srvzoneScript|srvzone script]] by [[JeffTaylor|Jeff Taylor]]
++[[opennicZoneScript]] by [[JeffTaylor|Jeff Taylor]]++ (//This procedure and script no longer work//)
++[[opennicZoneScript]] by [[JeffTaylor|Jeff Taylor]]++ (//This procedure and script no longer work//)
Deletions:
Additions:
Recommended minimum system:
~- Linux: Single cpu, 512MB of ram, 4GB HDD
~- Typical bandwidth usage may only be a few-hundred MB/month, but a DDoS attack can easily put you into hundreds of **gigabytes** in a few days!
~- Linux: Single cpu, 512MB of ram, 4GB HDD
~- Typical bandwidth usage may only be a few-hundred MB/month, but a DDoS attack can easily put you into hundreds of **gigabytes** in a few days!
Additions:
[[Tier2Config-Script]] by [[AlejandroMarquez|Alejandro Marquez]]
Deletions:
Additions:
Consider using the **BIND automated method** if you want:
~- Minimal work required to keep up with current updates
++[[opennicZoneScript]] by [[JeffTaylor|Jeff Taylor]]++ (//This procedure and script need updated and may no longer work//)
Tier2Config-Script by [[AlejandroMarquez|Alejandro Marquez]]
~- Minimal work required to keep up with current updates
++[[opennicZoneScript]] by [[JeffTaylor|Jeff Taylor]]++ (//This procedure and script need updated and may no longer work//)
Tier2Config-Script by [[AlejandroMarquez|Alejandro Marquez]]
Deletions:
Consider using the **[[opennicZoneScript|BIND automated method]]** if you want:
~- No manual updates required
++
~- The procedure for this method is outdated and needs rewritten
Additions:
++
++
~- The procedure for this method is outdated and needs rewritten
++
~- The procedure for this method is outdated and needs rewritten
Additions:
[[Tier2ServerConfigES Español]]
Additions:
~- Tier-2 servers **will** experience DDoS attacks. Please be sure to visit the **Tier2Security** page for information on how to mitigate these attacks. Other members will do what they can to provide assistance, however ultimately it is your responsibility to ensure that your own servers do not participate in man-in-the-middle or [[DNSAmplification|amplification attacks]]. You do not want to become part of an attack!
Deletions:
Additions:
~- Tier-2 servers **will** experience DDoS attacks. Please be sure to visit the Tier2Security page for information on how to mitigate these attacks. Other members will do what they can to provide assistance, however ultimately it is your responsibility to ensure that your own servers do not participate in man-in-the-middle or [[DNSAmplification|amplification attacks]]. You do not want to become part of an attack!
~- Various attacks will use up a lot of bandwidth. If your provider places data caps on your monthly internet usage, you may want to reconsider having a public service. Every attack is different, so no predictions can be on what your data usage will be each month -- however as an example, attacks can continue for several months and have been known to blast up to 20Mb/s of queries to an individual server. **If you wish to run a public service, be prepared for the worst!**
~- Various attacks will use up a lot of bandwidth. If your provider places data caps on your monthly internet usage, you may want to reconsider having a public service. Every attack is different, so no predictions can be on what your data usage will be each month -- however as an example, attacks can continue for several months and have been known to blast up to 20Mb/s of queries to an individual server. **If you wish to run a public service, be prepared for the worst!**
Deletions:
~- Various attacks will use up a lot of bandwidth. If your provider places data caps on your monthly internet usage, you want to reconsider having a public service. Every attack is different, so no predictions can be on what your data usage will be each month -- however as an example, while writing this page I am currently weathering an attack which has lasted more than ten days and sent over 300GB of data to my firewall. If you wish to run a public service, be prepared for the worst!
Additions:
~- Many tier-2 servers will experience DDoS attacks. Other operators will do what they can to provide assistance, however ultimately it is your responsibility to ensure that your own servers do not participate in man-in-the-middle or [[DNSAmplification|amplification attacks]]. You do not want to become part of an attack!
Deletions:
Additions:
=====Configuring Your Tier 2 Server=====
A tier-2 server can be used for both public and private DNS lookups, including OpenNIC and ICANN domains.
When considering if you wish to set up a public tier-2 server for the OpenNIC project, please keep the following points in mind:
~- Your server and network equipment, including your internet connection, must be reliable.
~- You will personally need to monitor your equipment and be willing to quickly resolve any failures. This includes having the knowledge to troubleshoot both hardware and software failures
~- When your service becomes unavailable from the internet for more than two hours, you will receive an automated email warning. Please do not ignore these emails -- you will only receive them when there is a problem.
~- Many tier-2 servers will experience DDoS attacks. Other operators will do what they can to provide assistance, however ultimately it is your responsibility to ensure that your own servers do not participate in man-in-the-middle or amplification attacks. You do not want to become part of an attack!
~- Various attacks will use up a lot of bandwidth. If your provider places data caps on your monthly internet usage, you want to reconsider having a public service. Every attack is different, so no predictions can be on what your data usage will be each month -- however as an example, while writing this page I am currently weathering an attack which has lasted more than ten days and sent over 300GB of data to my firewall. If you wish to run a public service, be prepared for the worst!
=====Available Configuration Options=====
There are a number of configuration methods available, and the benefits of each method should be considered when setting up your own service.
Consider using the **[[Tier2ConfigBindHint|BIND root-hints method]]** if you want:
~- Easy configuration
~- No local maintenance required
Consider using the **[[Tier2ConfigBindSlave|BIND slaved zone method]]** if you want:
~- Local redundancy of zone files
~- Minimize the number of queries sent to other servers
~- No reliance on other OpenNic servers for resolving OpenNic domains
~- Have a special case where you want to resolve OpenNic domains but also need to resolve local network entries
Note that this method requires manual updates when new TLDs are created or dropped.
Consider using the **[[opennicZoneScript|BIND automated method]]** if you want:
~- All the advantages of slaved zones
~- No manual updates required
For those who prefer DJBDNS, please refer to the **[[Tier2ConfigDJBDNS|DJBDNS guide]]**.
For those who prefer Unbound, please refer to the **[[Tier2ConfigUnbound|Unbound guide]]**.
For Windows server users, please select from your version:
~- **[[Tier2ConfigWindows2000|Windows 2000]]** (Not recommended)
~- **[[Tier2ConfigWindows2008|Windows 2008]]**
~- **[[Tier2ConfigWindows2012|Windows 2012]]**
=====Operation=====
After you have finished configuring your new server, the following information may be helpful...
~- This guide will help you configure **[[Tier2ConfigBindLogging|BIND logging]]**.
~- If you prefer anonymity for your users, this page will help you **[[Tier2ConfigObfuscatingLogs|obfuscate your log files]]**.
~- Please be sure to visit the **[[Tier2Security|tier-2 security]]** and the OpenNIC mailing lists for information on how you can protect your server from various forms of attack.
A tier-2 server can be used for both public and private DNS lookups, including OpenNIC and ICANN domains.
When considering if you wish to set up a public tier-2 server for the OpenNIC project, please keep the following points in mind:
~- Your server and network equipment, including your internet connection, must be reliable.
~- You will personally need to monitor your equipment and be willing to quickly resolve any failures. This includes having the knowledge to troubleshoot both hardware and software failures
~- When your service becomes unavailable from the internet for more than two hours, you will receive an automated email warning. Please do not ignore these emails -- you will only receive them when there is a problem.
~- Many tier-2 servers will experience DDoS attacks. Other operators will do what they can to provide assistance, however ultimately it is your responsibility to ensure that your own servers do not participate in man-in-the-middle or amplification attacks. You do not want to become part of an attack!
~- Various attacks will use up a lot of bandwidth. If your provider places data caps on your monthly internet usage, you want to reconsider having a public service. Every attack is different, so no predictions can be on what your data usage will be each month -- however as an example, while writing this page I am currently weathering an attack which has lasted more than ten days and sent over 300GB of data to my firewall. If you wish to run a public service, be prepared for the worst!
=====Available Configuration Options=====
There are a number of configuration methods available, and the benefits of each method should be considered when setting up your own service.
Consider using the **[[Tier2ConfigBindHint|BIND root-hints method]]** if you want:
~- Easy configuration
~- No local maintenance required
Consider using the **[[Tier2ConfigBindSlave|BIND slaved zone method]]** if you want:
~- Local redundancy of zone files
~- Minimize the number of queries sent to other servers
~- No reliance on other OpenNic servers for resolving OpenNic domains
~- Have a special case where you want to resolve OpenNic domains but also need to resolve local network entries
Note that this method requires manual updates when new TLDs are created or dropped.
Consider using the **[[opennicZoneScript|BIND automated method]]** if you want:
~- All the advantages of slaved zones
~- No manual updates required
For those who prefer DJBDNS, please refer to the **[[Tier2ConfigDJBDNS|DJBDNS guide]]**.
For those who prefer Unbound, please refer to the **[[Tier2ConfigUnbound|Unbound guide]]**.
For Windows server users, please select from your version:
~- **[[Tier2ConfigWindows2000|Windows 2000]]** (Not recommended)
~- **[[Tier2ConfigWindows2008|Windows 2008]]**
~- **[[Tier2ConfigWindows2012|Windows 2012]]**
=====Operation=====
After you have finished configuring your new server, the following information may be helpful...
~- This guide will help you configure **[[Tier2ConfigBindLogging|BIND logging]]**.
~- If you prefer anonymity for your users, this page will help you **[[Tier2ConfigObfuscatingLogs|obfuscate your log files]]**.
~- Please be sure to visit the **[[Tier2Security|tier-2 security]]** and the OpenNIC mailing lists for information on how you can protect your server from various forms of attack.
Deletions:
Here are some basic instructions on configuring your name server to access, and serve, the OpenNIC Top-Level Domains (TLDs). This page has, at the moment, instructions for only a limited range of nameservers. If you've configured another DNS server to use OpenNIC, please post instructions to the [[MailingLists discussion list]] (or edit this page) so we can expand this document.
Configuration entails a simple modification of the default configuration file to access the new Top-Level Domains (TLDs) by using the root (Tier1) servers administered by OpenNIC.
Please read the [[DNSSRVOperation 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.
==== BIND (8/9) ====
Most Unix systems put the BIND configuration file at either /etc/named.conf (as most Linux distributions do) or ar /var/named/named.conf (as the bind8 port installer for OpenBSD does).
=== Root Setup ===
In the named.conf (or one of its includes), find a block that looks like this:
%%
zone "." in
{
type hint;
file "root.cache";
};
%%
This specifies a hint zone named '.', the root zone. Hints specified in the root.cache file are used to locate root servers and perform recursive queries. The root.cache file may also be called named.cache.
== //method 1:// Hints File ==
To switch from the IANA root servers to OpenNIC root servers:
%%
dig . NS @IP > root.cache && /usr/sbin/rndc reload 1>/dev/null
%%
BIND will query a root servers in the hints file for the NS records for '.' (the root zone), and use that list of root servers to perform queries. This is how a normal recursive DNS server operates, even outside of OpenNIC. Make sure to update this file via cron on a weekly basis. This is the easiest way to configure BIND to use the OpenNIC root.
You should replace IP with a IP from the [[http://wiki.opennicproject.org/Tier1 T1 List]]. Please check which server is closest to you and insert the ip. Please dont use the Domain Name since it will lead to problems when you dont have OpenNIC aware resolvers.
== //method 2:// Root Slave ==
Alternatively, you can slave the root zone from root servers that allow transfer of the root zone. Change it to look like this:
%%
zone "." IN
{
type slave;
file "/etc/bind/zones/db.root";
masters { [server IP number]; [server IP number]; [server IP number]; };
notify no;
};
%%
You can have from 1 to many entries in the "master" section. We recommend using at least three Tier1 servers.
=== Slaving dns.opennic.glue. ===
Regardless of the options chosen above, the ''dns.opennic.glue.'' zone must also be slaved:
%%
zone "dns.opennic.glue" IN {
type slave;
file "/etc/bind/zones/slaves/db.dns.opennic";
masters { 75.127.96.89; };
notify no;
};
%%
//Note: The above IP is the Tier0 server.//
=== Reloading Bind ===
After the above settings are changed, you must reload named.
==== BIND 4====
Most Unix systems put the BIND 4 configuration file at either /etc/named.boot (as most Linux distributions do) or ar /var/named/named.boot (as the default install for OpenBSD does).
In the named.boot, you should have a line that looks like this:
%%
cache . root.cache
%%
Change it to look like this (please choose the nearest Tier1 server for this):
%%
secondary . [server IP number] tld-root
%%
==== DJBDNS ====
Instructions provided by Alan Hodgson, .geek hostnaster.
1) Change into your dnscache root/servers directory.
%%
# cd /service/dnscache/root/servers
%%
2) Replace your root servers file (root/servers/@) with the IP numbers of the Tier1 servers, obtained by using dnsq to query the Tier0 IP number (this step can be done manually, as well).
%%
# cp -f @ /tmp/@.saved
# dnsq ns . [Server IP number] | grep -iv ns0.opennic.glue \
| awk '{ if (/^additional/) print $5}' > /tmp/@.new
# cat /tmp/@.new
%%
3) If it looks okay (i.e. a list of IP addresses), replace the file.
%%
# mv -f /tmp/@.new @
%%
4) Restart dnscache
%%
# svc -t /service/dnscache
%%
5) Verify that it's working
%%
# dnsip www.opennic.glue
%%
==== unbound ====
Use the default unbound.conf or one specifically for OpenNIC and have setting similar to the following:
%%
server:
verbosity: 1
statistics-interval: 3600
interface: <your IP address>
access-control: 0.0.0.0/0 allow
# this path is for OpenBSD
root-hints: "/var/unbound/etc/opennic.cache"
hide-version: yes
log-queries: no
%%
There are various other settings to tune your threads etc.
You will then need to get a copy of the root cache file and update it as per the instructions above.
==== Windows 2000 DNS Server ====
Contributed by [[http://www.techiesplace.com Michael Patrick]].
1) Bring up the DNS Administrator from Administrative Tools...
1) Bring up the properties of the DNS Server
1) Go to the "Root Hints" tab
1) Remove the root server entries
1) Replace them with the Tier 1 servers from here.
1) Stop and Start the DNS service
1) If needed, clear and refresh your view of the cache and you should see .glue
1) try it out on http://www.opennic.glue.
My C:\WINNT\system32\dns\cache.dns file after modification (I would recommend keeping a copy of your file in case something bad happens to it). [And keep in mind that server IPs can change.]
===== Operation =====
===== Logging in Bind 9 =====
Lets go through turning on some logging for your bind9 DNS server. These logs are interesting to look through, but should not be archived. If you wish to archive them, provided is a perl script, written by Brianko, which will remove all IP addresses and replace them with XXX.XXX.XXX.XXX. It is important that we protect our members' right to browse the internet in complete privacy, so use of this perl script is highly encouraged.
To turn on logging, open named.conf.options in your favourite text editor and add the below to the end of the file:
%%
logging {
channel "misc" {
file "/var/log/misc.log" versions 2 size 25M;
severity info; print-severity no;
print-category yes; print-time yes;
};
channel "querylog" {
file "/var/log/named.log" versions 2 size 25M;
severity info; print-severity no;
print-category no; print-time yes;
};
category "queries" { "querylog"; };
category default { "misc"; };
};
%%
Depending on your bind setup(we always recommend chroot), the log dir can live in two locations. In a chroot setup it is at /var/lib/named/var/log, and in a normal install it is at /var/log. You know how yours is installed, so go to the log dir, and issue:
%%
touch named.log
chown bind:bind named.log
touch misc.log
chown misc.log
%%
===== Obfuscating named logs =====
In the interest of privacy and anonymity, a couple of ideas for obfuscating named logs are presented below. There is no official OpenNIC policy that addresses the privacy and retention of named logs.
==== //method 1:// Post-logging processing ====
This setup anonymizes the named log after queries have been logged.
Here is that script that Brianko wrote;
%%
#! /usr/bin/perl
#
# blurAddys.pl - Obfuscate IP addresses in a file
#
# cat some.log | blurAddys.pl > some_blurred.log
#
#####################################################################
use strict;
while(<STDIN>)
{
s/\d{1,3}(\.|-)\d{1,3}(\.|-)\d{1,3}(\.|-)\d{1,3}/XX$1XX$2XX$3XX/g;
s/([0-9A-Fa-f]{4}:[0-9A-Fa-f:]+:[0-9A-Fa-f]{1,4})([^:0-9A-Fa-f])/XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX$2/g;
print $_;
}
%%
Its easy to add this to a script:
%%
#!/bin/sh
date=`date +%d`
current=`date +%d%m%y`
if [ "$(echo $date)" = 01 ];then
tar cfvz /var/log/named/named.$current.tar.gz /var/log/named/*.log.*
rm /var/log/named/*.log.*
fi
cat /var/lib/named/var/log/named.log | /usr/local/bin/blurAddys.pl > /var/log/named/named.log.$current
rm /var/lib/named/var/log/named.log
touch /var/lib/named/var/log/named.log
chown bind:bind /var/lib/named/var/log/named.log
/etc/init.d/bind9 restart
%%
==== //method 2:// Log anonymization using named pipes ====
<<**Notes**
##named## will refuse to start, most likely without meaningful error messages, if the perl script is not running prior to starting named!
Please be aware that this method exposes data (in this case, log entries) to processes outside the chroot jail. Be very careful when processing this data, as it is feasible that an injection-type attack is possible if an attacker is aware of vulnerabilities in the external script.<<::c::
This method anonymizes named logs as they are generated. It also permits preprocessing of raw log data (with IP addresses intact) for purposes of traffic analysis, blacklisting, etc. The instructions below assume the following:
~- Running on Unix system that supports signals and 'pidof' utility.
~- Running BIND named daemon in a chroot jail under user 'named'. The chroot jail is /var/named/chroot in this example.
~- Log will be saved in /var/named/chroot/var/log directory.
~- Support for named pipes.
~- Using logrotate to manage logs.
=== Installation instructions ===
~- Install the following script **outside** of your chroot jail. Set the permissions so that it can be executed by user 'named'. (In this example, I've copied the script to /var/named.)
%%(perl)
#! /usr/bin/perl
#
# processNamedLog.pl - Obfuscate IPv4 addresses in a named log.
# Respawns upon receipt of HUP signal (useful for logrotate).
#
# Usage: su -c ./processNamedLog.pl named &
#
# Author: Brian Koontz (http://wiki.opennic.glue/BrianKoontz)
# Docs: http://wiki.opennic.glue/RunningT2
#
#####################################################################
use strict;
use POSIX();
# Set autoflush on (keeps named pipe from getting full)
my $oldfh = select(OUT);
$| = 1;
select($oldfh);
# POSIX-compliant signal handler
my $sigset = POSIX::SigSet->new();
my $action = POSIX::SigAction->new(
'HUP_handler',
$sigset,
&POSIX::SA_NODEFER);
POSIX::sigaction(&POSIX::SIGHUP, $action);
sub HUP_handler {
close IN;
close OUT;
my @args = ("/var/named/processNamedLog.pl&");
exec @args;
exit(0);
}
my $pipe = "/var/named/chroot/var/tmp/named.pipe";
my $out = "/var/named/chroot/var/log/named.log";
open(IN, "+<$pipe") or die "Can't open $pipe for reading!";
open(OUT, ">>$out") or die "Can't open $out for writing!";
while(<IN>)
{
s/\d{1,3}(\.|-)\d{1,3}(\.|-)\d{1,3}(\.|-)\d{1,3}/XX$1XX$2XX$3XX/g;
s/([0-9A-Fa-f]{4}:[0-9A-Fa-f:]+:[0-9A-Fa-f]{1,4})([^:0-9A-Fa-f])/XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX$2/g;
print OUT $_;
}
%%
~- Create a named pipe in the directory of your choice.
%%(bash)
# cd /var/named/chroot/var/tmp
# mknod named.pipe p
# chmod 0666 named.pipe
%%
~- Create a new channel in your named.conf file. Change your category logging directives to use this new channel for all logging.
%%
channel pipe_log {
file "/var/tmp/named.pipe";
print-category no; // Category unneeded in debug file?
print-severity yes;
print-time yes;
};
%%
~- (Optional) Add a new entry in your /etc/logrotate.conf file.
%%
# system-specific logs may be also be configured here.
/var/named/chroot/var/log/named.log {
rotate 3
size 20M
postrotate
kill -HUP `/sbin/pidof -x processNamedLog.pl`
endscript
}
%%
~- Start the perl script in the background, and then reload your named.conf file. {{color c="red" text="The named process will hang if the perl script is not running prior to reload!"}}
%%(bash)
# su - c /var/named/processNamedLog.pl named &
# /sbin/rndc reload
%%
~- Check to make sure named.log has been created and is logging data.
%%(bash)
# tail -f /var/named/chroot/var/log/named.log
%%
~- Check to make sure logs are rotated when logrotate is called, and that logging is initiated in the newly-created named.log file.
%%(bash)
# /usr/sbin/logrotate -f /etc/logrotate.conf
%%
~- (Optional) Check to ensure processNamedLog.pl is being respawned. Example output to stdout is for demonstration purposes only.
%%(bash)
# ps -ax | grep processNamedLog.pl
8330 ? S 0:00 /usr/bin/perl /var/named/processNamedLog.pl
# kill -HUP 8330
# ps -ax | grep processNamedLog.pl
9566 ? S 0:00 /usr/bin/perl /var/named/processNamedLog.pl
# tail -f /var/named/chroot/var/log/named.log
26-Jun-2009 04:16:23.132 info: client XX.XX.XX.XX#60287: view tier2_server_ipv4: query: ISAI.gateway.2wire.net IN A +
26-Jun-2009 04:16:25.880 info: client XX.XX.XX.XX#62970: view tier2_server_ipv4: query: ISAI.gateway.2wire.net IN A +
etc...
%%
Hope that this guide has helped you in your Tier 2 and OpenNIC adventures. Once you have yours working, if you plan to donate your DNS services and bandwidth to OpenNIC, please post your server IP on the [[MailingLists mailing list]] with a request to have it included in the T2 list.
Additions:
==== unbound ====
Use the default unbound.conf or one specifically for OpenNIC and have setting similar to the following:
server:
verbosity: 1
statistics-interval: 3600
interface: <your IP address>
access-control: 0.0.0.0/0 allow
# this path is for OpenBSD
root-hints: "/var/unbound/etc/opennic.cache"
hide-version: yes
log-queries: no
There are various other settings to tune your threads etc.
You will then need to get a copy of the root cache file and update it as per the instructions above.
Use the default unbound.conf or one specifically for OpenNIC and have setting similar to the following:
server:
verbosity: 1
statistics-interval: 3600
interface: <your IP address>
access-control: 0.0.0.0/0 allow
# this path is for OpenBSD
root-hints: "/var/unbound/etc/opennic.cache"
hide-version: yes
log-queries: no
There are various other settings to tune your threads etc.
You will then need to get a copy of the root cache file and update it as per the instructions above.
Additions:
dig . NS @IP > root.cache && /usr/sbin/rndc reload 1>/dev/null
Deletions:
Additions:
dig . NS @IP > root.cache && rndc reload 1>/dev/null
Deletions:
Additions:
dig . NS @IP > root.cache
You should replace IP with a IP from the [[http://wiki.opennicproject.org/Tier1 T1 List]]. Please check which server is closest to you and insert the ip. Please dont use the Domain Name since it will lead to problems when you dont have OpenNIC aware resolvers.
type slave;
file "/etc/bind/zones/slaves/db.dns.opennic";
masters { 75.127.96.89; };
notify no;
file "/var/log/misc.log" versions 2 size 25M;
severity info; print-severity no;
print-category yes; print-time yes;
};
file "/var/log/named.log" versions 2 size 25M;
severity info; print-severity no;
print-category no; print-time yes;
};
tar cfvz /var/log/named/named.$current.tar.gz /var/log/named/*.log.*
rm /var/log/named/*.log.*
'HUP_handler',
$sigset,
&POSIX::SA_NODEFER);
channel pipe_log {
file "/var/tmp/named.pipe";
print-category no; // Category unneeded in debug file?
print-severity yes;
print-time yes;
};
kill -HUP `/sbin/pidof -x processNamedLog.pl`
You should replace IP with a IP from the [[http://wiki.opennicproject.org/Tier1 T1 List]]. Please check which server is closest to you and insert the ip. Please dont use the Domain Name since it will lead to problems when you dont have OpenNIC aware resolvers.
type slave;
file "/etc/bind/zones/slaves/db.dns.opennic";
masters { 75.127.96.89; };
notify no;
file "/var/log/misc.log" versions 2 size 25M;
severity info; print-severity no;
print-category yes; print-time yes;
};
file "/var/log/named.log" versions 2 size 25M;
severity info; print-severity no;
print-category no; print-time yes;
};
tar cfvz /var/log/named/named.$current.tar.gz /var/log/named/*.log.*
rm /var/log/named/*.log.*
'HUP_handler',
$sigset,
&POSIX::SA_NODEFER);
channel pipe_log {
file "/var/tmp/named.pipe";
print-category no; // Category unneeded in debug file?
print-severity yes;
print-time yes;
};
kill -HUP `/sbin/pidof -x processNamedLog.pl`
Deletions:
type slave;
file "/etc/bind/zones/slaves/db.dns.opennic";
masters { 75.127.96.89; };
notify no;
file "/var/log/misc.log" versions 2 size 25M;
severity info; print-severity no;
print-category yes; print-time yes;
};
file "/var/log/named.log" versions 2 size 25M;
severity info; print-severity no;
print-category no; print-time yes;
};
tar cfvz /var/log/named/named.$current.tar.gz /var/log/named/*.log.*
rm /var/log/named/*.log.*
'HUP_handler',
$sigset,
&POSIX::SA_NODEFER);
channel pipe_log {
file "/var/tmp/named.pipe";
print-category no; // Category unneeded in debug file?
print-severity yes;
print-time yes;
};
kill -HUP `/sbin/pidof -x processNamedLog.pl`
Additions:
Here are some basic instructions on configuring your name server to access, and serve, the OpenNIC Top-Level Domains (TLDs). This page has, at the moment, instructions for only a limited range of nameservers. If you've configured another DNS server to use OpenNIC, please post instructions to the [[MailingLists discussion list]] (or edit this page) so we can expand this document.
Please read the [[DNSSRVOperation 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.
Please read the [[DNSSRVOperation 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.
Deletions:
You should also join the appropriate [[MailingLists]] so you'll be notified of changing situations which may affect your operation.
Revision [2453]
Edited on 2011-02-27 00:35:35 by BryonEldridge [change dns.opennic.glue to use tier0]Additions:
masters { 75.127.96.89; };
//Note: The above IP is the Tier0 server.//
//Note: The above IP is the Tier0 server.//
Deletions:
Additions:
BIND will query a root servers in the hints file for the NS records for '.' (the root zone), and use that list of root servers to perform queries. This is how a normal recursive DNS server operates, even outside of OpenNIC. Make sure to update this file via cron on a weekly basis. This is the easiest way to configure BIND to use the OpenNIC root.
Deletions:
Deletions:
Revision [2391]
Edited on 2011-01-04 14:35:40 by BrianKoontz [added warnings about named and pipes not playing nicely]Additions:
<<**Notes**
##named## will refuse to start, most likely without meaningful error messages, if the perl script is not running prior to starting named!
Please be aware that this method exposes data (in this case, log entries) to processes outside the chroot jail. Be very careful when processing this data, as it is feasible that an injection-type attack is possible if an attacker is aware of vulnerabilities in the external script.<<::c::
~- Start the perl script in the background, and then reload your named.conf file. {{color c="red" text="The named process will hang if the perl script is not running prior to reload!"}}
##named## will refuse to start, most likely without meaningful error messages, if the perl script is not running prior to starting named!
Please be aware that this method exposes data (in this case, log entries) to processes outside the chroot jail. Be very careful when processing this data, as it is feasible that an injection-type attack is possible if an attacker is aware of vulnerabilities in the external script.<<::c::
~- Start the perl script in the background, and then reload your named.conf file. {{color c="red" text="The named process will hang if the perl script is not running prior to reload!"}}
Deletions:
~- Start the perl script in the background, and then reload your named.conf file.
Additions:
=== Reloading Bind ===
After the above settings are changed, you must reload named.
After the above settings are changed, you must reload named.
Deletions:
After the above settings are changed, you must restart named. A reload command is insufficient to update the root DNS servers SOA record.
Additions:
=== Restarting Bind ===
After the above settings are changed, you must restart named. A reload command is insufficient to update the root DNS servers SOA record.
After the above settings are changed, you must restart named. A reload command is insufficient to update the root DNS servers SOA record.
Revision [2342]
Edited on 2010-12-30 09:27:45 by BryonEldridge [break out code blocks, redo headings]Additions:
==== BIND (8/9) ====
=== Root Setup ===
This specifies a hint zone named '.', the root zone. Hints specified in the root.cache file are used to locate root servers and perform recursive queries. The root.cache file may also be called named.cache.
== //method 1:// Hints File ==
To switch from the IANA root servers to OpenNIC root servers:
== //method 2:// Root Slave ==
zone "." IN
=== Slaving dns.opennic.glue. ===
Regardless of the options chosen above, the ''dns.opennic.glue.'' zone must also be slaved:
zone "dns.opennic.glue" IN {
==== BIND 4====
==== DJBDNS ====
==== Windows 2000 DNS Server ====
===== Operation =====
===== Logging in Bind 9 =====
===== Obfuscating named logs =====
==== //method 1:// Post-logging processing ====
==== //method 2:// Log anonymization using named pipes ====
=== Installation instructions ===
=== Root Setup ===
This specifies a hint zone named '.', the root zone. Hints specified in the root.cache file are used to locate root servers and perform recursive queries. The root.cache file may also be called named.cache.
== //method 1:// Hints File ==
To switch from the IANA root servers to OpenNIC root servers:
== //method 2:// Root Slave ==
zone "." IN
=== Slaving dns.opennic.glue. ===
Regardless of the options chosen above, the ''dns.opennic.glue.'' zone must also be slaved:
zone "dns.opennic.glue" IN {
==== BIND 4====
==== DJBDNS ====
==== Windows 2000 DNS Server ====
===== Operation =====
===== Logging in Bind 9 =====
===== Obfuscating named logs =====
==== //method 1:// Post-logging processing ====
==== //method 2:// Log anonymization using named pipes ====
=== Installation instructions ===
Deletions:
===BIND (8/9)===
This specifies a hint zone named '.', the root zone. Hints specified in the root.cache file are used to locate root servers and perform recursive queries. The root.cache file may also be called named.cache. To switch from the IANA root servers to OpenNIC root servers:
zone "dns.opennic.glue" {
===BIND 4===
===DJBDNS===
===Windows 2000 DNS Server===
====Operation====
====Logging in Bind 9====
==== Obfuscating named logs ====
=== //method 1:// Post-logging processing ===
=== //method 2:// Log anonymization using named pipes ===
==Installation instructions==
Additions:
file "/etc/bind/zones/db.root";
zone "dns.opennic.glue" {
type slave;
file "/etc/bind/zones/slaves/db.dns.opennic";
masters { [server IP number]; [server IP number]; [server IP number]; };
notify no;
allow-transfer { any; };
zone "dns.opennic.glue" {
type slave;
file "/etc/bind/zones/slaves/db.dns.opennic";
masters { [server IP number]; [server IP number]; [server IP number]; };
notify no;
allow-transfer { any; };
Additions:
BIND will query a root servers in the hints file for the NS records for '.' (the root zone), and use that list of root servers to perform queries. This is how a normal recursive DNS server operates, even outside of OpenNIC. Make sure to update this file via cron. This is the easiest way to configure BIND to use the OpenNIC root.
Deletions:
Revision [2317]
Edited on 2010-12-24 08:38:07 by BryonEldridge [add operation and logging from RunningT2]Additions:
====Configuring Your Name Server====
====Operation====
There is not much to running a OpenNIC Tier2 server. Once you have it configured, the AuditingWG will monitor it, and let you know via email if anything goes wrong along the way. You can also expect to use a few gig of bandwidth each month of DNS traffic; this varies on how much your DNS server is used.
====Logging in Bind 9====
Lets go through turning on some logging for your bind9 DNS server. These logs are interesting to look through, but should not be archived. If you wish to archive them, provided is a perl script, written by Brianko, which will remove all IP addresses and replace them with XXX.XXX.XXX.XXX. It is important that we protect our members' right to browse the internet in complete privacy, so use of this perl script is highly encouraged.
To turn on logging, open named.conf.options in your favourite text editor and add the below to the end of the file:
logging {
channel "misc" {
file "/var/log/misc.log" versions 2 size 25M;
severity info; print-severity no;
print-category yes; print-time yes;
};
channel "querylog" {
file "/var/log/named.log" versions 2 size 25M;
severity info; print-severity no;
print-category no; print-time yes;
};
category "queries" { "querylog"; };
category default { "misc"; };
Depending on your bind setup(we always recommend chroot), the log dir can live in two locations. In a chroot setup it is at /var/lib/named/var/log, and in a normal install it is at /var/log. You know how yours is installed, so go to the log dir, and issue:
touch named.log
chown bind:bind named.log
touch misc.log
chown misc.log
==== Obfuscating named logs ====
In the interest of privacy and anonymity, a couple of ideas for obfuscating named logs are presented below. There is no official OpenNIC policy that addresses the privacy and retention of named logs.
=== //method 1:// Post-logging processing ===
This setup anonymizes the named log after queries have been logged.
Here is that script that Brianko wrote;
#! /usr/bin/perl
#
# blurAddys.pl - Obfuscate IP addresses in a file
#
# cat some.log | blurAddys.pl > some_blurred.log
#
#####################################################################
use strict;
while(<STDIN>)
s/\d{1,3}(\.|-)\d{1,3}(\.|-)\d{1,3}(\.|-)\d{1,3}/XX$1XX$2XX$3XX/g;
s/([0-9A-Fa-f]{4}:[0-9A-Fa-f:]+:[0-9A-Fa-f]{1,4})([^:0-9A-Fa-f])/XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX$2/g;
print $_;
}
Its easy to add this to a script:
#!/bin/sh
date=`date +%d`
current=`date +%d%m%y`
if [ "$(echo $date)" = 01 ];then
tar cfvz /var/log/named/named.$current.tar.gz /var/log/named/*.log.*
rm /var/log/named/*.log.*
fi
cat /var/lib/named/var/log/named.log | /usr/local/bin/blurAddys.pl > /var/log/named/named.log.$current
rm /var/lib/named/var/log/named.log
touch /var/lib/named/var/log/named.log
chown bind:bind /var/lib/named/var/log/named.log
/etc/init.d/bind9 restart
=== //method 2:// Log anonymization using named pipes ===
//Note: Please be aware that this method exposes data (in this case, log entries) to processes outside the chroot jail. Be very careful when processing this data, as it is feasible that an injection-type attack is possible if an attacker is aware of vulnerabilities in the external script.//
This method anonymizes named logs as they are generated. It also permits preprocessing of raw log data (with IP addresses intact) for purposes of traffic analysis, blacklisting, etc. The instructions below assume the following:
~- Running on Unix system that supports signals and 'pidof' utility.
~- Running BIND named daemon in a chroot jail under user 'named'. The chroot jail is /var/named/chroot in this example.
~- Log will be saved in /var/named/chroot/var/log directory.
~- Support for named pipes.
~- Using logrotate to manage logs.
==Installation instructions==
~- Install the following script **outside** of your chroot jail. Set the permissions so that it can be executed by user 'named'. (In this example, I've copied the script to /var/named.)
%%(perl)
#! /usr/bin/perl
#
# processNamedLog.pl - Obfuscate IPv4 addresses in a named log.
# Respawns upon receipt of HUP signal (useful for logrotate).
#
# Usage: su -c ./processNamedLog.pl named &
#
# Author: Brian Koontz (http://wiki.opennic.glue/BrianKoontz)
# Docs: http://wiki.opennic.glue/RunningT2
#
#####################################################################
use strict;
use POSIX();
# Set autoflush on (keeps named pipe from getting full)
my $oldfh = select(OUT);
$| = 1;
select($oldfh);
# POSIX-compliant signal handler
my $sigset = POSIX::SigSet->new();
my $action = POSIX::SigAction->new(
'HUP_handler',
$sigset,
&POSIX::SA_NODEFER);
POSIX::sigaction(&POSIX::SIGHUP, $action);
sub HUP_handler {
close IN;
close OUT;
my @args = ("/var/named/processNamedLog.pl&");
exec @args;
exit(0);
}
my $pipe = "/var/named/chroot/var/tmp/named.pipe";
my $out = "/var/named/chroot/var/log/named.log";
open(IN, "+<$pipe") or die "Can't open $pipe for reading!";
open(OUT, ">>$out") or die "Can't open $out for writing!";
while(<IN>)
s/\d{1,3}(\.|-)\d{1,3}(\.|-)\d{1,3}(\.|-)\d{1,3}/XX$1XX$2XX$3XX/g;
s/([0-9A-Fa-f]{4}:[0-9A-Fa-f:]+:[0-9A-Fa-f]{1,4})([^:0-9A-Fa-f])/XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX$2/g;
print OUT $_;
}
~- Create a named pipe in the directory of your choice.
%%(bash)
# cd /var/named/chroot/var/tmp
# mknod named.pipe p
# chmod 0666 named.pipe
~- Create a new channel in your named.conf file. Change your category logging directives to use this new channel for all logging.
channel pipe_log {
file "/var/tmp/named.pipe";
print-category no; // Category unneeded in debug file?
print-severity yes;
print-time yes;
};
~- (Optional) Add a new entry in your /etc/logrotate.conf file.
# system-specific logs may be also be configured here.
/var/named/chroot/var/log/named.log {
rotate 3
size 20M
postrotate
kill -HUP `/sbin/pidof -x processNamedLog.pl`
endscript
}
~- Start the perl script in the background, and then reload your named.conf file.
%%(bash)
# su - c /var/named/processNamedLog.pl named &
# /sbin/rndc reload
~- Check to make sure named.log has been created and is logging data.
%%(bash)
# tail -f /var/named/chroot/var/log/named.log
~- Check to make sure logs are rotated when logrotate is called, and that logging is initiated in the newly-created named.log file.
%%(bash)
# /usr/sbin/logrotate -f /etc/logrotate.conf
~- (Optional) Check to ensure processNamedLog.pl is being respawned. Example output to stdout is for demonstration purposes only.
%%(bash)
# ps -ax | grep processNamedLog.pl
8330 ? S 0:00 /usr/bin/perl /var/named/processNamedLog.pl
# kill -HUP 8330
# ps -ax | grep processNamedLog.pl
9566 ? S 0:00 /usr/bin/perl /var/named/processNamedLog.pl
# tail -f /var/named/chroot/var/log/named.log
26-Jun-2009 04:16:23.132 info: client XX.XX.XX.XX#60287: view tier2_server_ipv4: query: ISAI.gateway.2wire.net IN A +
26-Jun-2009 04:16:25.880 info: client XX.XX.XX.XX#62970: view tier2_server_ipv4: query: ISAI.gateway.2wire.net IN A +
etc...
%%
Hope that this guide has helped you in your Tier 2 and OpenNIC adventures. Once you have yours working, if you plan to donate your DNS services and bandwidth to OpenNIC, please post your server IP on the [[MailingLists mailing list]] with a request to have it included in the T2 list.
====Operation====
There is not much to running a OpenNIC Tier2 server. Once you have it configured, the AuditingWG will monitor it, and let you know via email if anything goes wrong along the way. You can also expect to use a few gig of bandwidth each month of DNS traffic; this varies on how much your DNS server is used.
====Logging in Bind 9====
Lets go through turning on some logging for your bind9 DNS server. These logs are interesting to look through, but should not be archived. If you wish to archive them, provided is a perl script, written by Brianko, which will remove all IP addresses and replace them with XXX.XXX.XXX.XXX. It is important that we protect our members' right to browse the internet in complete privacy, so use of this perl script is highly encouraged.
To turn on logging, open named.conf.options in your favourite text editor and add the below to the end of the file:
logging {
channel "misc" {
file "/var/log/misc.log" versions 2 size 25M;
severity info; print-severity no;
print-category yes; print-time yes;
};
channel "querylog" {
file "/var/log/named.log" versions 2 size 25M;
severity info; print-severity no;
print-category no; print-time yes;
};
category "queries" { "querylog"; };
category default { "misc"; };
Depending on your bind setup(we always recommend chroot), the log dir can live in two locations. In a chroot setup it is at /var/lib/named/var/log, and in a normal install it is at /var/log. You know how yours is installed, so go to the log dir, and issue:
touch named.log
chown bind:bind named.log
touch misc.log
chown misc.log
==== Obfuscating named logs ====
In the interest of privacy and anonymity, a couple of ideas for obfuscating named logs are presented below. There is no official OpenNIC policy that addresses the privacy and retention of named logs.
=== //method 1:// Post-logging processing ===
This setup anonymizes the named log after queries have been logged.
Here is that script that Brianko wrote;
#! /usr/bin/perl
#
# blurAddys.pl - Obfuscate IP addresses in a file
#
# cat some.log | blurAddys.pl > some_blurred.log
#
#####################################################################
use strict;
while(<STDIN>)
s/\d{1,3}(\.|-)\d{1,3}(\.|-)\d{1,3}(\.|-)\d{1,3}/XX$1XX$2XX$3XX/g;
s/([0-9A-Fa-f]{4}:[0-9A-Fa-f:]+:[0-9A-Fa-f]{1,4})([^:0-9A-Fa-f])/XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX$2/g;
print $_;
}
Its easy to add this to a script:
#!/bin/sh
date=`date +%d`
current=`date +%d%m%y`
if [ "$(echo $date)" = 01 ];then
tar cfvz /var/log/named/named.$current.tar.gz /var/log/named/*.log.*
rm /var/log/named/*.log.*
fi
cat /var/lib/named/var/log/named.log | /usr/local/bin/blurAddys.pl > /var/log/named/named.log.$current
rm /var/lib/named/var/log/named.log
touch /var/lib/named/var/log/named.log
chown bind:bind /var/lib/named/var/log/named.log
/etc/init.d/bind9 restart
=== //method 2:// Log anonymization using named pipes ===
//Note: Please be aware that this method exposes data (in this case, log entries) to processes outside the chroot jail. Be very careful when processing this data, as it is feasible that an injection-type attack is possible if an attacker is aware of vulnerabilities in the external script.//
This method anonymizes named logs as they are generated. It also permits preprocessing of raw log data (with IP addresses intact) for purposes of traffic analysis, blacklisting, etc. The instructions below assume the following:
~- Running on Unix system that supports signals and 'pidof' utility.
~- Running BIND named daemon in a chroot jail under user 'named'. The chroot jail is /var/named/chroot in this example.
~- Log will be saved in /var/named/chroot/var/log directory.
~- Support for named pipes.
~- Using logrotate to manage logs.
==Installation instructions==
~- Install the following script **outside** of your chroot jail. Set the permissions so that it can be executed by user 'named'. (In this example, I've copied the script to /var/named.)
%%(perl)
#! /usr/bin/perl
#
# processNamedLog.pl - Obfuscate IPv4 addresses in a named log.
# Respawns upon receipt of HUP signal (useful for logrotate).
#
# Usage: su -c ./processNamedLog.pl named &
#
# Author: Brian Koontz (http://wiki.opennic.glue/BrianKoontz)
# Docs: http://wiki.opennic.glue/RunningT2
#
#####################################################################
use strict;
use POSIX();
# Set autoflush on (keeps named pipe from getting full)
my $oldfh = select(OUT);
$| = 1;
select($oldfh);
# POSIX-compliant signal handler
my $sigset = POSIX::SigSet->new();
my $action = POSIX::SigAction->new(
'HUP_handler',
$sigset,
&POSIX::SA_NODEFER);
POSIX::sigaction(&POSIX::SIGHUP, $action);
sub HUP_handler {
close IN;
close OUT;
my @args = ("/var/named/processNamedLog.pl&");
exec @args;
exit(0);
}
my $pipe = "/var/named/chroot/var/tmp/named.pipe";
my $out = "/var/named/chroot/var/log/named.log";
open(IN, "+<$pipe") or die "Can't open $pipe for reading!";
open(OUT, ">>$out") or die "Can't open $out for writing!";
while(<IN>)
s/\d{1,3}(\.|-)\d{1,3}(\.|-)\d{1,3}(\.|-)\d{1,3}/XX$1XX$2XX$3XX/g;
s/([0-9A-Fa-f]{4}:[0-9A-Fa-f:]+:[0-9A-Fa-f]{1,4})([^:0-9A-Fa-f])/XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX$2/g;
print OUT $_;
}
~- Create a named pipe in the directory of your choice.
%%(bash)
# cd /var/named/chroot/var/tmp
# mknod named.pipe p
# chmod 0666 named.pipe
~- Create a new channel in your named.conf file. Change your category logging directives to use this new channel for all logging.
channel pipe_log {
file "/var/tmp/named.pipe";
print-category no; // Category unneeded in debug file?
print-severity yes;
print-time yes;
};
~- (Optional) Add a new entry in your /etc/logrotate.conf file.
# system-specific logs may be also be configured here.
/var/named/chroot/var/log/named.log {
rotate 3
size 20M
postrotate
kill -HUP `/sbin/pidof -x processNamedLog.pl`
endscript
}
~- Start the perl script in the background, and then reload your named.conf file.
%%(bash)
# su - c /var/named/processNamedLog.pl named &
# /sbin/rndc reload
~- Check to make sure named.log has been created and is logging data.
%%(bash)
# tail -f /var/named/chroot/var/log/named.log
~- Check to make sure logs are rotated when logrotate is called, and that logging is initiated in the newly-created named.log file.
%%(bash)
# /usr/sbin/logrotate -f /etc/logrotate.conf
~- (Optional) Check to ensure processNamedLog.pl is being respawned. Example output to stdout is for demonstration purposes only.
%%(bash)
# ps -ax | grep processNamedLog.pl
8330 ? S 0:00 /usr/bin/perl /var/named/processNamedLog.pl
# kill -HUP 8330
# ps -ax | grep processNamedLog.pl
9566 ? S 0:00 /usr/bin/perl /var/named/processNamedLog.pl
# tail -f /var/named/chroot/var/log/named.log
26-Jun-2009 04:16:23.132 info: client XX.XX.XX.XX#60287: view tier2_server_ipv4: query: ISAI.gateway.2wire.net IN A +
26-Jun-2009 04:16:25.880 info: client XX.XX.XX.XX#62970: view tier2_server_ipv4: query: ISAI.gateway.2wire.net IN A +
etc...
%%
Hope that this guide has helped you in your Tier 2 and OpenNIC adventures. Once you have yours working, if you plan to donate your DNS services and bandwidth to OpenNIC, please post your server IP on the [[MailingLists mailing list]] with a request to have it included in the T2 list.
Deletions:
===General Information===
Additions:
Here are some basic instructions on configuring your name server to access, and serve, the OpenNIC Top-Level Domains (TLDs). This page has, at the moment, instructions for only a limited range of nameservers. If you've configured another DNS server to use OpenNIC, please post instructions to the [[MailingLists discussion list]] (or edit this page!) so we can expand this page.
Configuration entails a simple modification of the default configuration file to access the new Top-Level Domains (TLDs) by using the root (Tier1) servers administered by OpenNIC.
You should also join the appropriate [[MailingLists]] so you'll be notified of changing situations which may affect your operation.
In the named.conf (or one of its includes), find a block that looks like this:
This specifies a hint zone named '.', the root zone. Hints specified in the root.cache file are used to locate root servers and perform recursive queries. The root.cache file may also be called named.cache. To switch from the IANA root servers to OpenNIC root servers:
dig . NS @ns0.opennic.glue > root.cache
BIND will query a root servers in the hints file for the NS records for '.' (the root zone), and use that list of root servers to perform queries. This is how a normal recursive DNS server operates, even outside of OpenNIC. This is the easiest way to configure BIND to use the OpenNIC root.
Alternatively, you can slave the root zone from root servers that allow transfer of the root zone. Change it to look like this:
You can have from 1 to many entries in the "master" section. We recommend using at least three Tier1 servers.
Change it to look like this (please choose the nearest Tier1 server for this):
2) Replace your root servers file (root/servers/@) with the IP numbers of the Tier1 servers, obtained by using dnsq to query the Tier0 IP number (this step can be done manually, as well).
Configuration entails a simple modification of the default configuration file to access the new Top-Level Domains (TLDs) by using the root (Tier1) servers administered by OpenNIC.
You should also join the appropriate [[MailingLists]] so you'll be notified of changing situations which may affect your operation.
In the named.conf (or one of its includes), find a block that looks like this:
This specifies a hint zone named '.', the root zone. Hints specified in the root.cache file are used to locate root servers and perform recursive queries. The root.cache file may also be called named.cache. To switch from the IANA root servers to OpenNIC root servers:
dig . NS @ns0.opennic.glue > root.cache
BIND will query a root servers in the hints file for the NS records for '.' (the root zone), and use that list of root servers to perform queries. This is how a normal recursive DNS server operates, even outside of OpenNIC. This is the easiest way to configure BIND to use the OpenNIC root.
Alternatively, you can slave the root zone from root servers that allow transfer of the root zone. Change it to look like this:
You can have from 1 to many entries in the "master" section. We recommend using at least three Tier1 servers.
Change it to look like this (please choose the nearest Tier1 server for this):
2) Replace your root servers file (root/servers/@) with the IP numbers of the Tier1 servers, obtained by using dnsq to query the Tier0 IP number (this step can be done manually, as well).
Deletions:
**Additional Information** is at http://www.opennicproject.org/en/client_setup.html
Configuration entails a simple modification of the default configuration file to access the new Top-Level Domains (TLDs) by using the root ([[Tier1]]) servers administered by OpenNIC.
**Note**: In any place in the information below where you would normally see an IP number, those numbers have been replaced with a link to the page of [[VolunteerHosts Public Name Servers]]. Please see this list to choose the appropriate server for your use.
You should also join the appropriate [[MailingLists]] so you'll be notified of changing situations which may affect your operation..
In the named.conf (or one of its includes), you should find a block that looks like this:
This specifies a hint zone named '.', the root zone. Hints specified int he root.cache file are used to locate root servers and perform recursive queries. The root.cache file may also be called named.cache. To switch from the IANA root servers to OpenNIC root servers, fetch http://smtp.jdcomputers.com.au/hints/db.root and replace your hint file with its contents.
BIND will query a root server in the hints file for the NS records for '.' (the root zone), and use that list of root servers to perform queries. This is how a normal recursive DNS server operates, even outside of OpenNIC. This is the easiest way to configure BIND to use the OpenNIC root.
Alternatively (slightly experimental), you can slave the root zone from root servers that allow transfer of the root zone. This may not be supported by all root servers. Note that slaving a zone via AXFR or IXFR uses a TCP connection, which requires more resources than a regular DNS query (via the connectionless UDP protocol). Note that historically, the only reason BIND 8/9 users were encouraged to slave the root was due to BIND mysteriously reverting to the IANA root servers. This behavior has not been fully documented and is presumed not to exist in current versions of BIND software.
Change it to look like this (you can have from 1 to many entries in the "master" section; we recommend at least 3 [[Tier1Status Master Pool (Tier 1)]] servers):
file "tld-root";
Alternatively OpenNIC now accepts the use of a hints file. To use the hints file issue;
dig . NS @ns0.opennic.glue > root.cache
This file then overwrites the current bind9 root.cache file.
Change it to look like this (please choose the nearest [[VolunteerHosts Tier 1 server]] for this):
2) Replace your root servers file (root/servers/@) with the IP numbers of the [[VolunteerHosts OpenNIC Tier 1 servers]], obtained by using dnsq to query the Tier 0 IP number (this step can be done manually, as well).
Additions:
**Additional Information** is at http://www.opennicproject.org/en/client_setup.html
No Differences
Additions:
Alternatively OpenNIC now accepts the use of a hints file. To use the hints file issue;
dig . NS @ns0.opennic.glue > root.cache
This file then overwrites the current bind9 root.cache file.
dig . NS @ns0.opennic.glue > root.cache
This file then overwrites the current bind9 root.cache file.
Revision [1203]
Edited on 2008-02-22 09:31:08 by AaronJAngel [added note about hints zone in BIND 8/9 and more information re slaving '.']Additions:
This specifies a hint zone named '.', the root zone. Hints specified int he root.cache file are used to locate root servers and perform recursive queries. The root.cache file may also be called named.cache. To switch from the IANA root servers to OpenNIC root servers, fetch http://smtp.jdcomputers.com.au/hints/db.root and replace your hint file with its contents.
BIND will query a root server in the hints file for the NS records for '.' (the root zone), and use that list of root servers to perform queries. This is how a normal recursive DNS server operates, even outside of OpenNIC. This is the easiest way to configure BIND to use the OpenNIC root.
Alternatively (slightly experimental), you can slave the root zone from root servers that allow transfer of the root zone. This may not be supported by all root servers. Note that slaving a zone via AXFR or IXFR uses a TCP connection, which requires more resources than a regular DNS query (via the connectionless UDP protocol). Note that historically, the only reason BIND 8/9 users were encouraged to slave the root was due to BIND mysteriously reverting to the IANA root servers. This behavior has not been fully documented and is presumed not to exist in current versions of BIND software.
BIND will query a root server in the hints file for the NS records for '.' (the root zone), and use that list of root servers to perform queries. This is how a normal recursive DNS server operates, even outside of OpenNIC. This is the easiest way to configure BIND to use the OpenNIC root.
Alternatively (slightly experimental), you can slave the root zone from root servers that allow transfer of the root zone. This may not be supported by all root servers. Note that slaving a zone via AXFR or IXFR uses a TCP connection, which requires more resources than a regular DNS query (via the connectionless UDP protocol). Note that historically, the only reason BIND 8/9 users were encouraged to slave the root was due to BIND mysteriously reverting to the IANA root servers. This behavior has not been fully documented and is presumed not to exist in current versions of BIND software.
Deletions:
forwarders {};
allow-query { any; };
Revision [1118]
Edited on 2008-02-05 02:35:06 by AvoYager [clean up page in prep for new MLs and hints file]Additions:
Here are some basic instructions on configuring your name server to access, and serve, the OpenNIC Top-Level Domains (TLDs). This page has, at the moment, instructions for only a limited range of nameservers. If you've configured another DNS server to use OpenNIC, please post some instructions to the [[MailingLists discussion list]] (or edit this page!) so we can expand this page.
Configuration entails a simple modification of the default configuration file to access the new Top-Level Domains (TLDs) by using the root ([[Tier1]]) servers administered by OpenNIC.
You should also join the appropriate [[MailingLists]] so you'll be notified of changing situations which may affect your operation..
Configuration entails a simple modification of the default configuration file to access the new Top-Level Domains (TLDs) by using the root ([[Tier1]]) servers administered by OpenNIC.
You should also join the appropriate [[MailingLists]] so you'll be notified of changing situations which may affect your operation..
Deletions:
Please note that these instructions are for configuring a nameserver as an OpenNIC Tier 2 server or for your own use. Configuration of an [[Tier1ServerConfig OpenNIC Tier 1 server]] is significantly different. You should ask the [[MailingLists mailing list]] for advice.
OpenNIC is a simple addition to the BIND configuration file to inform your name server of the new Top-Level Domains (TLDs) administered by OpenNIC. What this does, basically, is set your server back to the old days when that file was a cache of pointers to the root servers. BIND these days just uses that cache as a list of servers to query at startup for up-to-date root lists, but we don't have to do that.
You will also need to join the [[MailingLists Announcements list]] (or join the [[MailingLists Discussion list]]) so you'll get notified when we add new Tier 1 servers, so you can add them to the list of masters on your name server. The more widespread we get with our Tier 1 servers, the less susceptible we are to a disruption due to a network outage anywhere.
And, for the curious, here's an example [[RootZone tld-root file]] after we've merged the OpenNIC changes into it, along with the script that generates it.
Revision [1101]
Edited on 2008-02-03 00:45:08 by AvoYager [clean up page in prep for new MLs and hints file]Additions:
forwarders {};
Revision [1054]
Edited on 2008-01-18 00:32:54 by AvoYager [clean up page in prep for new MLs and hints file]Additions:
notify no;
Revision [979]
Edited on 2007-10-17 00:09:03 by AvoYager [clean up page in prep for new MLs and hints file]Additions:
Change it to look like this (you can have from 1 to many entries in the "master" section; we recommend at least 3 [[Tier1Status Master Pool (Tier 1)]] servers):
Deletions:
Additions:
===BIND (8/9)===
Most Unix systems put the BIND configuration file at either /etc/named.conf (as most Linux distributions do) or ar /var/named/named.conf (as the bind8 port installer for OpenBSD does).
In the named.conf (or one of its includes), you should find a block that looks like this:
recursion yes;
allow-query { any; };
Most Unix systems put the BIND configuration file at either /etc/named.conf (as most Linux distributions do) or ar /var/named/named.conf (as the bind8 port installer for OpenBSD does).
In the named.conf (or one of its includes), you should find a block that looks like this:
recursion yes;
allow-query { any; };
Deletions:
named.conf
// note, the 'view' encapsulation is optional
view "internet" {
match-clients { any; };
allow-query { any; };
allow-recursion { any; };
allow-transfer { any; };
zone "." in {
type slave;
file "opennic/tld-root";
masters { 58.6.115.42; 66.150.224.233; 216.87.84.214; };
};
zone "0.0.127.in-addr.arpa" {
type master;
file "internet/db.127.0.0";
notify no;
};
%%
Make sure /var/named/opennic exists and is writable by the named user.
===BIND 8===
Most Unix systems put the BIND 8 configuration file at either /etc/named.conf (as most Linux distributions do) or ar /var/named/named.conf (as the bind8 port installer for OpenBSD does).
In the named.conf, you should have a block that looks like this:
Additions:
// note, the 'view' encapsulation is optional
Deletions:
acl lan { 192.168.1.0/24; };
//Options
options {
directory "/var/bind";
pid-file "/var/run/named/named.pid";
// allow-query { ; } ;
// recursion yes;
view "lan" {
match-clients { localnets; };
notify no;
file "lan/db.127.0.0";
Additions:
----
CategoryHostmastering
CategoryHostmastering
Deletions:
@ NS ns1.opennic.glue.
ns1.opennic.glue A 157.238.46.24
@ NS ns2.opennic.glue.
ns2.opennic.glue A 209.104.33.250
@ NS ns3.opennic.glue.
ns3.opennic.glue A 209.104.63.249
@ NS ns4.opennic.glue.
ns4.opennic.glue A 130.94.168.216
@ NS ns5.opennic.glue.
ns5.opennic.glue A 209.21.75.53
@ NS ns6.opennic.glue.
ns6.opennic.glue A 64.114.34.119
@ NS ns7.opennic.glue.
ns7.opennic.glue A 207.6.128.246
@ NS ns8.opennic.glue.
ns8.opennic.glue A 167.216.255.199
@ NS ns9.opennic.glue.
ns9.opennic.glue. A 62.208.181.95
@ NS ns10.opennic.glue.
ns10.opennic.glue. A 216.87.153.98
@ NS ns11.opennic.glue.
ns11.opennic.glue. A 216.178.136.116
Additions:
And, for the curious, here's an example [[RootZone tld-root file]] after we've merged the OpenNIC changes into it, along with the script that generates it.
Deletions:
Additions:
named.conf
//Define address aliases
acl lan { 192.168.1.0/24; };
//Options
options {
directory "/var/bind";
pid-file "/var/run/named/named.pid";
// allow-query { ; } ;
// recursion yes;
view "lan" {
match-clients { localnets; };
allow-query { any; };
allow-recursion { any; };
allow-transfer { any; };
notify no;
zone "." in {
type slave;
file "opennic/tld-root";
masters { 58.6.115.42; 66.150.224.233; 216.87.84.214; };
};
zone "0.0.127.in-addr.arpa" {
type master;
file "lan/db.127.0.0";
};
view "internet" {
match-clients { any; };
allow-query { any; };
allow-recursion { any; };
allow-transfer { any; };
zone "." in {
type slave;
file "opennic/tld-root";
masters { 58.6.115.42; 66.150.224.233; 216.87.84.214; };
};
zone "0.0.127.in-addr.arpa" {
type master;
file "internet/db.127.0.0";
notify no;
};
%%
Make sure /var/named/opennic exists and is writable by the named user.
//Define address aliases
acl lan { 192.168.1.0/24; };
//Options
options {
directory "/var/bind";
pid-file "/var/run/named/named.pid";
// allow-query { ; } ;
// recursion yes;
view "lan" {
match-clients { localnets; };
allow-query { any; };
allow-recursion { any; };
allow-transfer { any; };
notify no;
zone "." in {
type slave;
file "opennic/tld-root";
masters { 58.6.115.42; 66.150.224.233; 216.87.84.214; };
};
zone "0.0.127.in-addr.arpa" {
type master;
file "lan/db.127.0.0";
};
view "internet" {
match-clients { any; };
allow-query { any; };
allow-recursion { any; };
allow-transfer { any; };
zone "." in {
type slave;
file "opennic/tld-root";
masters { 58.6.115.42; 66.150.224.233; 216.87.84.214; };
};
zone "0.0.127.in-addr.arpa" {
type master;
file "internet/db.127.0.0";
notify no;
};
%%
Make sure /var/named/opennic exists and is writable by the named user.
Deletions:
Additions:
@@=====Configuring Your Tier 2 Server=====@@
