6

My objective is to block certain domains in bind WITHOUT first looking up their address (this is a small caching bind dns server).

Currently my configuration will forward the request for badhost.com and get the IP address (I can see this in wireshark), and then it will overwrite that response with NXDOMAIN.

bind.log:

client 192.168.1.1#46107 (badhost.com): rpz QNAME NXDOMAIN rewrite badhost.com via badhost.com.rpz

But there is no point in fetching the IP address and it delays the query. I just want it to quickly return NXDOMAIN for the blocked domains without doing the forwarding.

configuration:

options {
  response-policy { zone "rpz" policy nxdomain; };
  cleaning-interval 360;
  forward only;
  forwarders { x.x.x.x; y.y.y.y; };
  allow-recursion { any; };
  allow-query { any; };
  allow-query-cache { any; };

}

zone "rpz" {
  type master;
  file "/etc/bind/rpz.zone";
};
zone "0.0.127.in-addr.arpa" {
        type master;
    notify no;
        file "pz/127.0.0";
};
zone "1.168.192.in-addr.arpa" {
        type master;
        notify no;
        file "pz/192.168.1";
};
zone "lan" {
        type master;
        notify no;
        file "pz/lan";
};

rpz.zone

$TTL    604800
@       IN      SOA     ns1.example.local. info.example.local. (
                          2         ; Serial
                     604800         ; Refresh
                      86400         ; Retry
                    2419200         ; Expire
                     604800 )       ; Negative Cache TTL

@       IN      NS      local.

$INCLUDE rpz.blacklist.db

rpz.blacklist.db

badhost.com CNAME .

There will be thousands of entries, so I do not want a zone pointing to the same file (0.0.0.0 or 127.0.0.1) for each one.

Jon T
  • 63
  • 1
  • 4

1 Answers1

5

This can be accomplished with qname-wait-recurse. Here is the documentation from the BIND 9.10 ARM regarding the usage of this feature:

No DNS records are needed for a QNAME or Client-IP trigger. The name or IP address itself is sufficient, so in principle the query name need not be recursively resolved. However, not resolving the requested name can leak the fact that response policy rewriting is in use and that the name is listed in a policy zone to operators of servers for listed names. To prevent that information leak, by default any recursion needed for a request is done before any policy triggers are considered. Because listed domains often have slow authoritative servers, this default behavior can cost significant time. The qname-wait-recurse no option overrides that default behavior when recursion cannot change a non-error response. The option does not affect QNAME or client-IP triggers in policy zones listed after other zones containing IP, NSIP and NSDNAME triggers, because those may depend on the A, AAAA, and NS records that would be found during recursive resolution. It also does not affect DNSSEC requests (DO=1) unless break-dnssec yes is in use, because the response would depend on whether or not RRSIG records were found during resolution. Using this option can cause error responses such as SERVFAIL to appear to be rewritten, since no recursion is being done to discover problems at the authoritative server.

The syntax for enabling this feature is a little obscure. Instead of putting it in the global options {}; block, it needs to appear before the trailing semicolon in your response-policy {}; definition.

[ response-policy {
    zone zone_name
    [ policy (given | disabled | passthru | drop |
              nxdomain | nodata | cname domain) ]
    [ recursive-only yes_or_no ]
    [ max-policy-ttl number ]
    ; [...]
} [ recursive-only yes_or_no ]
  [ max-policy-ttl number ]
  [ break-dnssec yes_or_no ]
  [ min-ns-dots number ]
  [ qname-wait-recurse yes_or_no ]
  [ automatic-interface-scan yes_or_no ]
; ]

Before:

response-policy { zone "rpz"; };

After:

response-policy { zone "rpz"; } qname-wait-recurse no;
Andrew B
  • 31,858
  • 12
  • 90
  • 128
  • 1
    Thank you. I hope it not only avoids "wait"ing for the response, but avoids performing the forwarding/lookup completely. – Jon T Apr 13 '17 at 22:58
  • This works and does not appear to leak the blackholed domains to forwarders (and to the potentially malicious SOA servers for those ). I’ll need to check for queries with tcpdump or something similar, but the full verbose logs show forwarding with the “qname-wait-recurse no” option absent and do not show forwarding for the blacklisted domains with it present. – Alain O'Dea May 05 '19 at 17:42