On 20/06/2014 10:11, Paul Vixie wrote:
> 
> 
> Nick Urbanik wrote:
>> ...
>> We are using BIND 9.8.  Can anyone suggest a good scalable method of
>> allowing queries to a parent domain, but blocking all queries to all
>> its subdomains?
> 
> BIND has a DNS Firewall capability built into it now, called RPZ.
> (Someday I hope to see Unbound and other RDNS servers also adopt RPZ.)
> 
> https://kb.isc.org/category/110/0/10/Software-Products/BIND9/Features/DNSRPZ/
> 
> basically you need a local policy zone that you share via zone transfer
> between your master server (where you edit) and all of your recursive
> servers (where you consume). you'll use two rules for each domain you
> want made safe while its children are firewalled:
> 
> *.foo.com CNAME .
> foo.com CNAME foo.com.
> 
> note the deliberate lack of a trailing "." on the owner names. the
> documentation at kb.isc.org explains further.
> 
> vixie

One addition to this is that for the above to be effective, you will
also need this option:

qname-wait-recurse no;

It was introduced in the RPZ2 patches (that you can download from the
Redbarn site), and is built-in to the DNSRPZ distributed with ISC BIND
from versions 9.9.5-S1 (subscription only) and in 9.10 (current version
9.10.0-P2).

Here's the Administrator Reference Manual description of what it is and
why you need it:

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.

Cathy

_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Reply via email to