173/8 Apr 03 IANA - Reserved 174/8 Apr 03 IANA - Reserved 175/8 Apr 03 IANA - Reserved 176/8 Apr 03 IANA - Reserved 177/8 Apr 03 IANA - Reserved 178/8 Apr 03 IANA - Reserved 179/8 Apr 03 IANA - Reserved 180/8 Apr 03 IANA - Reserved 181/8 Apr 03 IANA - Reserved 182/8 Apr 03 IANA - Reserved 183/8 Apr 03 IANA - Reserved 184/8 Apr 03 IANA - Reserved 185/8 Apr 03 IANA - Reserved 186/8 Apr 03 IANA - Reserved 187/8 Apr 03 IANA - Reserved 189/8 Apr 03 IANA - Reserved 190/8 Apr 03 IANA - Reserved
Changes in version 3.4:
Changes in version 3.0:
Changes in version 3.1:
Changes in version 3.2:
Changes in version 3.3:
If you are not familiar with BIND configuration, we highly recommend that you pick up a copy of DNS and BIND, by Albitz and Liu, published by O'Reilly and Associates.
There are numerous RFCs and FAQs associated with DNS. we value the following most of all:
There are several documents detailing the risks of improperly configured BIND servers, or risks in the older versions of BIND. Please take a look at the following:
As a prerequisite, the host on which the BIND is run should be secured with the latest patches and armoring techniques. The IP stack should also be tuned to provide robust performance and resistance to DoS attacks. Please review our IP Stack Tuning Guide for suggestions along these lines.
If you are looking for the previous version of the Secure BIND Template that includes the split-brain DNS method and support for BIND 8, please read the Secure BIND Template Version 2.2 . Versions of the BIND template prior to 3.0 are no longer under active development, though we will continue to answer questions on version 2.2.
It is not enough to secure the name server itself or the BIND software configuration. The border must also be resistant to attacks, and can be used to defend the name servers. Please take a look at the Secure IOS Template as well as the Secure BGP Template for ideas on border defense using Cisco routers.
Please feel free to share any suggestions or bug reports with me. This template would not be half as useful without the suggestions and insights of those who have read it. Feedback is always welcome! Send all feedback to noc@cymru.com.
For our purposes, we will assume that our external (visible to the Internet) network is 10.1.1.0/24. Our internal network is 192.168.1.0/24. Our name server has the IP address 10.1.1.1.
Technicality: Bogon filters would block all queries from hosts in the 192.168.1.0/24 and the 10.1.1.0/24 netblocks. This is an example only, after all. See RFC1918 for the details regarding the three netblocks (10/8, 172.16/12, and 192.168/16) designated for internal only use.
Ensure that you have the latest version of the BIND. You can obtain the latest version by visiting the Internet Software Consortium BIND site at http://www.isc.org/products/BIND/ The compilation and installation of the BIND is well detailed at this site. This template has been most recently tested with BIND version 9.1.3.
BIND 9.1.3 contains two interesting records in the CHAOS class - version.bind and authors.bind, both type TXT. The version.bind TXT record will return the version of BIND running on the server. The authors.bind TXT records (by default, there are multiple TXT records for authors.bind) will return a list of the authors of the BIND 9.X. While the version.bind TXT record may assist admins, it runs counter to the philosophy of "keep the miscreants guessing." Some of the scanning tools used by the miscreants query for the BIND version. For this reason, it is recommended that you hide these records from external hosts. This is done through a view, and it will be demonstrated in the template below.
You may wish to ensure that your BGP configuration does not dampen the netblocks that contain the DNS root servers. Please consult our Secure BGP Template for further details on this topic.
After building the chroot environment, create a small passwd file in the jail. The passwd file should contain only a root account and the BIND user. Call the user under which BIND will run named. Assign a UID greater than 100 to the named user, and remember to sync up the passwd file with the shadow file (pwconv in Solaris). Do not create a password for this accounts. Instead, lock it with entries in the shadow file such as this one:
root:*LK*:6445::::::
named:*LK*:11136::::::
We recommend using a shell that will allow no access, such as our own denial shell, nocando. The nocando denial shell, which includes detailed logging, can be found in the Tools section of our web site. The home directory for this account will be the directory we create below.
Next, create a directory structure to contain our configuration files. For example, use /jail/bind/var/named. In this directory, create a subdirectory named master for our master zones and slave for our slave zones, if such zones exist. Change the ownership of these subdirectories to the proper named UID, e.g.:
chown -R named:named /jail/bind/var/named
Configure the zone files normally, and place them in the proper subdirectories. Don't forget the hint file (often named db.cache), the loopback zone, and a named.conf file. The authoritative root name server file can be downloaded here:
Details regarding the creation of the hint and zone files can be found in the following:
We will now configure the named configuration files, with views for internal and external clients.
// @(#)named.conf 02 OCT 2001 Team Cymru noc@cymru.com
// Set up our ACLs
// In BIND 8, ACL names with quotes were treated as different from
// the same name without quotes. In BIND 9, both are treated as
// the same.
acl "xfer" {
none; // Allow no transfers.
If we have other
// name servers, place them here.
};
acl "trusted" {
logging {
// Set options for security
options {
directory "/var/named";
pid-file "/var/named/named.pid";
statistics-file "/var/named/named.stats";
memstatistics-file "/var/named/named.memstats";
dump-file "/var/adm/named.dump";
zone-statistics yes;
// Prevent DoS attacks by generating bogus zone
transfer
// requests. This will result in slower
updates to the
// slave servers (e.g. they will await the poll
interval
// before checking for updates).
notify no;
// Generate more efficient
zone transfers. This will place
// multiple DNS records in a DNS message, instead
of one per
// DNS message.
transfer-format many-answers;
// Set the maximum zone transfer time to something
more
// reasonable. In this case, we state
that any zone transfer
// that takes longer than 60 minutes is unlikely
to ever
// complete. WARNING: If you have
very large zone files,
// adjust this to fit your requirements.
max-transfer-time-in 60;
// We have no dynamic interfaces, so BIND shouldn't
need to
// poll for interface state {UP|DOWN}.
interface-interval 0;
allow-transfer {
// Zone tranfers limited
to members of the
// "xfer" ACL.
xfer;
};
allow-query {
// Accept queries from
our "trusted" ACL. We will
// allow anyone to query
our master zones below.
// This prevents us
from becoming a free DNS server
// to the masses.
trusted;
};
allow-query-cache {
// Accept queries of our cache from
our "trusted" ACL.
trusted;
};
};
view "internal-in" in {
// Our internal (trusted) view. We permit
the internal networks
// to freely access this view. We perform
recursion for our
// internal hosts, and retrieve data from
the cache for them.
match-clients { trusted; };
recursion yes;
additional-from-auth yes;
additional-from-cache yes;
zone "." in {
// Link in the root server hint file.
type hint;
file "db.cache";
};
zone "0.0.127.in-addr.arpa" in {
// Allow queries for the 127/8 network, but
not zone transfers.
// Every name server, both slave and master,
will be a master
// for this zone.
type master;
file "master/db.127.0.0";
allow-query {
any;
};
allow-transfer {
none;
};
};
zone "localhost" {
type master;
file "db.localhost";
allow-query {
any;
};
allow-transfer {
none;
};
};
zone "internal.example.com" in {
// Our internal A RR zone. There may be
several of these.
type master;
file "master/db.internal";
};
zone "1.168.192.in-addr.arpa" in {
// Our internal PTR RR zone. Again, there may be
several of these.
type master;
file "master/db.192.168.1";
};
// Create a view for external DNS clients.
view "external-in" in {
// Our external (untrusted) view. We permit
any client to access
// portions of this view. We do not perform
recursion or cache
// access for hosts using this view.
match-clients { any; };
recursion no;
additional-from-auth no;
additional-from-cache no;
zone "example.net" in {
type master;
file "master/db.example";
allow-query {
any;
};
};
zone "1.1.10.in-addr.arpa" in {
type master;
file "master/db.10.1.1";
allow-query {
any;
};
};
// Create a view for all clients perusing the CHAOS class.
// We allow internal hosts to query our version number.
// This is a good idea from a support point of view.
view "external-chaos" chaos {
match-clients { any; };
recursion no;
zone "." {
type hint;
file "/dev/null";
};
zone "bind" {
type master;
file "master/db.bind";
allow-query {
trusted;
};
allow-transfer {
none;
};
};
; @(#)db.bind v1.2 25 JAN 2001 Team Cymru Thomas noc@cymru.com
;
$TTL 1D
$ORIGIN bind.
@ 1D
CHAOS SOA localhost. root.localhost.
(
2001013101 ; serial
3H
; refresh
1H
; retry
1W
; expiry
1D )
; minimum
CHAOS NS
localhost.
version.bind. CHAOS TXT "BIND 9.1.3+robhacks"
authors.bind. CHAOS TXT "are better coders than I. :)"
Once the creation of the named.conf and zone file is completed, it is wise to verify the syntax of these files. This can be accomplished with two tools:
Team Cymru has removed all static bogon references from this template due to the high probability that the application of these bogon filters will be a one-time event. Unfortunately many of these templates are applied and never re-visited, despite our dire warnings that bogons do change.
This doesn't mean bogon filtering can't be accomplished in an automated manner. Why not consider peering with our globally distributed bogon route-server project? Alternately you can obtain a current and well maintained bogon feed from our DNS and RADb services. Read more on our Bogon Reference page.
cd /jail/bind
/usr/sbin/chroot /jail/bind usr/local/sbin/named -u named
By typing ps -fu named, you can verify that the chroot named daemon is running.
Once you have /etc/resolv.conf properly configured, you should be able to launch queries. Test a few basic queries for both internal and external names and addresses. Then test an intranet client to ensure that the ACLs are functioning properly. If you have secondary name servers, ensure that zone transfers are functional and complete. If possible, test the name server from an external host to ensure that the ACLs are functional and that logging is working.
Once all testing is successfully completed, modify /etc/init.d/inetsvc to start the chroot named daemon at boot. Comment out the current named lines and insert the following:
# Start chroot DNS
if [ -f /jail/bind/usr/local/sbin/named -a -f /jail/bind/usr/local/etc/named.conf ];
then
echo "Starting chroot BIND server."
(cd /jail/bind; /usr/sbin/chroot /jail/bind
usr/local/sbin/named -u named)
fi
Team Cymru, noc@cymru.com, http://www.cymru.com