Major Upgrade - added very detailed configs for many scenarios, with lots of examples. The server is now fully functional for an authoritative master and a recursive/forwarding cacher. You can still mount over the /etc/bind and /var/bind directories and override everything yourself. This should help many users who did not know where to start with bind.
This commit is contained in:
@@ -0,0 +1,104 @@
|
||||
// Copy this file to /etc/bind/named.conf.options if you want to run bind as a
|
||||
// recursive DNS resolver. If you want to run an authoritative nameserver
|
||||
// instead, see Ventz's "example-configs/authoritative/named.conf.options"
|
||||
//
|
||||
// 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 {
|
||||
// 8.8.8.8;
|
||||
// 8.8.4.4;
|
||||
//};
|
||||
|
||||
// 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;
|
||||
};
|
||||
Reference in New Issue
Block a user