bind: Modify default config to be more secure

By default BIND will happily serve as both an authoritative nameserver
and recursive resolver, but this is no longer a recommended or desirable
configuration. The previous default configuration did not draw attention
to this fact and the issues involved.

Users are now made to rename one of two sample configuration files,
named.conf.authoritative or named.conf.recursive. Comments inside either
file advise DNS administrators of the most prevalent security issues.

This ensures that users setting up an authoritative nameserver do not
unwittingly also operate a resolver. In the previous default
configuration, BIND would happily perform recursive resolution for
localhost, which means that the local machine may receive
non-authoritative data from what is supposed to be an authoritative
nameserver.

Both default configurations disable zone transfers by default, as BIND
defaults to enabling them for any host (!).

1 files changed, 104 insertions, 0 deletions

diff --git a/main/bind/named.conf.recursive b/main/bind/named.conf.recursive
new file mode 100644
index 0000000000..a068b22d76
--- /dev/null
+++ b/main/bind/named.conf.recursive
@@ -0,0 +1,104 @@
+// Copy this file to /etc/bind/named.conf if you want to run bind as a
+// recursive DNS resolver. If you want to run an authoritative nameserver
+// instead, see /etc/bind/named.conf.authoritative.
+//
+// BIND supports using the same daemon as both authoritative nameserver and
+// recursive resolver; it supports this because it is the oldest and original
+// nameserver and so was designed before it was realized that combining these
+// functions is inadvisable.
+//
+// In actual fact, combining these functions is a very bad idea. It is thus
+// recommended that you run a given instance of BIND as either an authoritative
+// nameserver or recursive resolver, not both. The example configuration herein
+// provides a starting point for running a recursive resolver.
+//
+//
+// *** IMPORTANT ***
+// You should note that running an open DNS resolver (that is, a resolver which
+// answers queries from any globally routable IP) makes the resolver vulnerable
+// to abuse in the form of reflected DDoS attacks.
+//
+// These attacks are now widely prevalent on the open internet. Even if
+// unadvertised, attackers can and will find your resolver by portscanning the
+// global IPv4 address space.
+//
+// In one case the traffic generated using such an attack reached 300 Gb/s (!).
+//
+// It is therefore imperative that you take care to configure the resolver to
+// only answer queries from IP address space you trust or control. See the
+// "allow-recursion" directive below.
+//
+// Bear in mind that with these attacks, the "source" of a query will actually
+// be the intended target of a DDoS attack, so this only protects other networks
+// from attack, not your own; ideally therefore you should firewall DNS traffic
+// at the borders of your network to eliminate spoofed traffic.
+//
+// This is a complex issue and some level of understanding of these attacks is
+// advisable before you attempt to configure a resolver.
+
+options {
+	directory "/var/bind";
+
+	// Specify a list of CIDR masks which should be allowed to issue recursive
+	// queries to the DNS server. Do NOT specify 0.0.0.0/0 here; see above.
+	allow-recursion {
+		127.0.0.1/32;
+	};
+
+	// If you want this resolver to itself resolve via means of another recursive
+	// resolver, uncomment this block and specify the IP addresses of the desired
+	// upstream resolvers.
+	//forwarders {
+	//	123.123.123.123;
+	//	123.123.123.123;
+	//};
+
+	// By default the resolver will attempt to perform recursive resolution itself
+	// if the forwarders are unavailable. If you want this resolver to fail outright
+	// if the upstream resolvers are unavailable, uncomment this directive.
+	//forward only;
+
+	// Configure the IPs to listen on here.
+	listen-on { 127.0.0.1; };
+	listen-on-v6 { none; };
+
+	// If you have problems and are behind a firewall:
+	//query-source address * port 53;
+
+	pid-file "/var/run/named/named.pid";
+
+	// Removing this block will cause BIND to revert to its default behaviour
+	// of allowing zone transfers to any host (!). There is no need to allow zone
+	// transfers when operating as a recursive resolver.
+	allow-transfer { none; };
+};
+
+// Briefly, a zone which has been declared delegation-only will be effectively
+// limited to containing NS RRs for subdomains, but no actual data beyond its
+// own apex (for example, its SOA RR and apex NS RRset). This can be used to
+// filter out "wildcard" or "synthesized" data from NAT boxes or from
+// authoritative name servers whose undelegated (in-zone) data is of no
+// interest.
+// See http://www.isc.org/products/BIND/delegation-only.html for more info
+
+//zone "COM" { type delegation-only; };
+//zone "NET" { type delegation-only; };
+
+zone "." IN {
+	type hint;
+	file "named.ca";
+};
+
+zone "localhost" IN {
+	type master;
+	file "pri/localhost.zone";
+	allow-update { none; };
+	notify no;
+};
+
+zone "127.in-addr.arpa" IN {
+	type master;
+	file "pri/127.zone";
+	allow-update { none; };
+	notify no;
+};