Currently I'm using the "hosts" file for this, but that's getting harder to maintain over multiple workstations... I'd like to setup a nameserver in our local network which can overwrite or append hosts to existing domains. Eg. sql.ourdomain.tld is defined in the "master dns" SOA dns.ourdomain.tld with IN A 80.90.100.200 and I like to overwrite it with IN A 192.168.15.5 in our local nameserver. So its "answer locally first, forward every NXDOMAIN to a different resolver" I guess there is such a solution because "pihole" does similar things.

I wanted to take my existing internal DNS Bind servers and add some RPZ security. Previously I had split DNS with my internal view set to forward 3 specific domains to my offices internal DNS servers. zone "company.tld" IN { type forward; forward only; forwarders { 10.10.161.1; 10.11.161.1; }; Which worked great. Once I added RPZ after signing up with a transfer provider: response-policy { zone "oisd-full.ioc2rpz" policy nxdomain; } qname-wait-recurse no break-dnssec yes; I can see my RPZ working great, but my forwarded zone is being caught in the RPZ. (Yeah, one of many companies I have worked for that inadvertently used an internal TLD that is now on someone's naughty list). I tried making this domain a whitelist, but bind requires that my zone definition be a MASTER or SLAVE type, not a forward. I am not finding a good example of anyone that has got both features to work.. IE: Allow Bind to either look at all it's local zones first, before RPZ, or tag a whitelist so that it still looks at it's view configuration for answers if it is marked passthru. Ideas?

Situation: A Linux box with two physical network interfaces (say eth0 for LAN and eth1 for WAN). Box acts as a router and IPTables firewall, too. Furthermore, an XFRM-Interface (say 'vpn') is there (VPN channel with strongSwan established via WAN interface). The DNS zones are set up in a way that a specific zone specifies forwarders dedicated for the vpn network interface. The routing is set up properly. Is it possible to configure the bind in a way that it **ONLY** sends traffic for forwarders of the vpn zone via the vpn-XFRM-interface? Background: I saw UDP packets transmitted via the WAN=eth1 interface dedicated for DNS forwarders of the VPN zone, which should have been sent out only via the vpn-XFRM-interface. Additional information: RPZ was also set up but did not really help.

I use RPZ to blacklist some domains and my configuration looks like: > *.com A 127.0.0.1 > mydomain.net A 127.0.0.1 if i query a whatever domain .com it works correctly giving me 127.0.0.1 let's dig fun.com @localhost, my reply will be: ;; ANSWER SECTION: fun.com. 5 IN A 127.0.0.1 now let's edit the previous config and make my zone now look like: > *.com A 127.0.0.1 mydomain.net A 127.0.0.1 **this.fun.com 127.0.0.1** It's unnecessary because the master *.com should cover all the cases however I have my domains loaded by multiple sources so the list is compiled automatically and things like this can happen. While this seems to be an harmless change and if I do dig this.fun.com @localhost it will reply again stuff like: ;; ANSWER SECTION: this.fun.com. 5 IN A 127.0.0.1 If I now query the root domain dig fun.com @localhost I will get: ;; ANSWER SECTION: fun.com. 86400 IN A 209.61.131.188 **Like.. WHAAT? What happened here? adding this.fun.com masked out fun.com main domain from the upper omni-inclusive *.com?** Is this a wanted behaviour of bind? Did I found some kind of weird bug? How can avoid this? Should I write a script that recurse all the domains removing the ones contained into the bigger ones? (annoying but doable - in search of better alternatives) **TL;DR: Add of a 3rd level domain in bind rpz in order to BLACKLIST IT make the 2nd level domain not follow the main FILTER resulting WHITELISTED.**

I'm trying to setup a basic DNS server for my lan that is able to put in a nullroute or 127.0.0.1 lots of domains. The domains I want to block come from a list but I also want to block some domains using regular expressions (this is a must for my setup). My candidate software for doing this business seemed to be Unbound, a recursive caching secure DNS server with various useful functions. **However Unbound doesn't seem to support any regular expression!** Also, Unbound is very picky when it comes for zones repetitions. My domain list is builded from many mixed sources so I can have many repetitions that I filter out with some scripts but also domains in list like: **aaah.very.this.com** but also **very.this.com** This lead Unbound scream for errors because there is a zone repetition. While this is a minor issue, that I can remove by cleaning even better the domain list, my main issue is the lack of regexp for handling the domain requests. Can i somehow block all *.com or *.biz or stuff like that? [\w\.\-]+.com A 127.0.0.1 [\w\.\-]+.com AAAA ::1 My regex is an example, i could go with more complex ones... BONUS ----- Can I instead do something even more nasty? Have everything pointing to nullroute or 127.0.0.1 and ONLY a whitelist of domains get resolved by being forwarded to an external DNS ? If replying please do not forget this extra question as I am very interesting in knowing the answer. **What i can go for? Bind9, dnsmasq, unbound, pdns-recursor...**

*My setup is getting more complex, generally I tend to divide things in pieces and assemble them together by myself. But it seems this time I need more help to get the whole gears working together. That's why I was requested by user @Rui F Ribeiro to ask this one as a separate question.* --- What I'm trying to achieve? Basically what I found called on the internet as DNS Firewall. I need a BIND server configured with this features: - It want it to being able to FORWARD by default all the requests to an external DNS (in my case OpenDNS: 208.67.222.222, 208.67.220.220) - It must NOT for and for any case query the ROOT-SERVERS, because OpenDNS have some useful function of domain blocking/manipulating. So, if my bind server starts to ask things to OpenDNS and Root Servers randomly I will have different results each time. **(note: this forward must be done in encrypt mode for various reasons, including not getting intercepted and further manipulated by other servers in between)** - The bind server also has to serve as cache, it's ok send the queries to OpenDNS but if I have already fresh data is unnecessary to query again and again wasting bandwidth and time. - **Here come my other main request that is making my config even more complex:** I want to setup a RPZ zone with a huge list of domains i don't want them be able to be resolved, basically i want to have them resolving as 127.0.0.1 or another ip/host of my lan that should serve as catch-all http server for ad purpose and so on. How can I achieve a so complex configuration ? There's my config files, I guess something here is not working as necessary, so please help me with the config. --- # named.conf // This is the primary configuration file for the BIND DNS server named. // // Please read /usr/share/doc/bind9/README.Debian.gz for information on the // structure of BIND configuration files in Debian, *BEFORE* you customize // this configuration file. // // If you are just adding zones, please do that in /etc/bind/named.conf.local include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones"; # named.conf.options acl "trusted" { 127.0.0.1/8; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; ::1; }; options { directory "/var/cache/bind"; # bind cache directory recursion yes; # enables resursive queries allow-query { trusted; } ; allow-recursion { trusted; }; # allows recursive queries from "trusted" clients //listen-on { 0.0.0.0; }; # interfaces where to listen allow-transfer { none; }; # disable zone transfers by default // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See http://www.kb.cert.org/vuls/id/800113 // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing // the all-0's placeholder. forward only; forwarders { 208.67.222.222; 208.67.220.220; }; //======================================================================== // If BIND logs error messages about the root key being expired, // you will need to update your keys. See https://www.isc.org/bind-keys //======================================================================== dnssec-enable no; dnssec-validation no; dnssec-lookaside auto; auth-nxdomain no; # conform to RFC1035 #listen-on-v6 { any; }; response-policy { zone "rpz-white" policy PASSTHRU; // my own white list zone "rpz-foreign"; // obtained from producer }; }; zone "rpz-white" { type master; file "/etc/bind/rpz-white.db"; }; zone "rpz-foreign" { type master; file "/etc/bind/rpz-foreign.db"; }; # named.conf.local // // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918"; # named.conf.default-zones // prime the server with knowledge of the root servers //zone "." { // type hint; // file "/etc/bind/db.root"; //}; // be authoritative for the localhost forward and reverse zones, and for // broadcast zones as per RFC 1912 zone "localhost" { type master; file "/etc/bind/db.local"; }; zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; }; zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; }; zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; };

I have a DNS server which has two views, one for internal users and one for external (internet for example). I want to config RPZ so that when internal users request (external recursive queries will be denied anyway) a sample website, they will be redirected to another website (a filter page) showing that access is not allowed to this website. But RPZ is not working, query for bad.com returns its real address. I can't find out the problem. **named.conf.options:** options { directory "/var/cache/bind"; // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See http://www.kb.cert.org/vuls/id/800113 // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing // the all-0's placeholder. forwarders { 8.8.8.8; }; response-policy {zone "filter" recursive-only no;}; //======================================================================== // If BIND logs error messages about the root key being expired, // you will need to update your keys. See https://www.isc.org/bind-keys //======================================================================== # dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; }; **named.conf.local:** // // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918"; acl internal {172.17.116/24; 192.168.20/24; 127/8;}; view "internal" { match-clients {internal;}; recursion yes; zone "wsi.org" { type master; file "/etc/bind/internal.zone"; }; zone "filter" { type master; file "/etc/bind/filter.zone"; }; include "/etc/bind/named.conf.default-zones"; }; view "external" { match-clients {any;}; recursion no; zone "wsi.org" { type master; file "/etc/bind/external.zone"; }; zone "filter" { type master; file "/etc/bind/filter2.zone"; }; include "/etc/bind/named.conf.default-zones"; }; **filter.zone:** TTL 604800 @ IN SOA wsi.org. root.wsi.org. ( 3 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL bad.com A filter.wsi.org bad.net A filter.wsi.org **filter2 zone:** TTL 604800 @ IN SOA wsi.org. root.wsi.org. ( 3 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL bad.com A filter.wsi.org bad.net CNAME rpz-passthru nslookup shows the real address of bad.net and bad.com always. I was experimenting and that's why there are two zones.