104 lines
		
	
	
		
			4.1 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			104 lines
		
	
	
		
			4.1 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
// 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;
 | 
						|
}; |