// 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; };