[DNSfirewalls] rpz firewall + whitelisting
Paul Vixie
paul at redbarn.org
Wed Aug 28 19:12:36 UTC 2019
On Wednesday, 28 August 2019 15:19:07 UTC Vernon Schryver wrote:
> > From: Paul Vixie <paul at redbarn.org>
> >
> > ...
> > we could institute a change whereby a match on an empty nonterminal name
> > has the same effect (search for a wildcard; consider moving on to the
> > next policy zone) as a nonexistent name would have. ...
this is a behavioural change and is not being proposed. therefore answers of
the form "this is not easy" and "this would break working configs" are
implicitly off topic because i've explained why i'm not proposing this.
> > i think the BIND9 native, and the FastRPZ, implementations of the RPZ spec
> > could easily be changed to log warnings about empty non-terminals.
>
> I disagree strongly about "easily". The current BIND9 native RPZ
> code uses the main BIND9 database lookup code. Doing anything
> different just for the RPZ database lookups would not be easy.
all i would ask for is a detection, at time of use, by the RPZ layer, that a
name was found in the trigger dictionary, with no associated action. this
could be in the post-transfer RPZ generation/regeneration, or it could be
every time a query hits this trigger and finds no action. this is a proposal,
because the no-records case will almost never lead to an intuitive outcome.
> > ... an RPZ
> > generator
> >
> > would iteratively generate a "trigger action" rule for an owner name and
> > label-strip. ...
>
> A generator sounds more tractable.
right. and i'll be modifying my generators to add this label-strip iteration.
> Have the "Per-Zone Action Overrides" in section 6.1 of
> https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-rpz-00.txt
> been considered?
no -- and it's a delicious workaround!
> Could you put the few explicit records in one policy zone
> and whatever should be done for the empty non-terminals in
> a second zone but with a per-zone override?
> Or with a single covering wildcard?
when the policy need is for a deep trigger (sub-sub-sub-subdomains), this will
often be in dynamic content imported from a security feed provider. it's
therefore not predictable enough to be handled with explicit records.
--
Paul
More information about the DNSfirewalls
mailing list