Fwd: Need feedback on RPZ service setup

[Lars Kulseng]

---------- Forwarded message ---------
From: Lars Kulseng <larskulseng at gmail.com>
Date: tor. 5. jan. 2017 kl. 15:34
Subject: Re: Need feedback on RPZ service setup
To: Tony Finch <dot at dotat.at>


tor. 5. jan. 2017 kl. 14:24 skrev Tony Finch <dot at dotat.at>:

Lars Kulseng <larskulseng at gmail.com> wrote:

> I am setting up BIND to be used as a way to disseminate RPZ-zones for use
> by third parties. I would like some feedback on my setup.

Overall it sounds very sensible to me. A few notes...


Great! Thanks for your detailed response.



> Access control is done by using TSIG-keys, with separate keys for:
updates,
> M1->S{1,2} transfers, and lastly there will be separate keys for each
> Consumer of the RPZ-zone. The number of keys will then be 1 + 1 +
> num_consumers. Each Consumer endpoint, where a transfer will take place,
> will have to be defined by the server-clause in BIND, using the
> keys-option, specifying an existing key.

Instead of using server clauses, I would suggest having a big ACL listing
all your consumer TSIG keys. You can then use this ACL in your RPZ
allow-query and allow-transfer clauses. You should also include your
internal zone transfer TSIGs and your management / monitoring clients in
this ACL too! :-)


I wasn't aware that the ACL-clause could include TSIG-keys as well as
IP-addresses. So far I've been using the masters-clause to make the actual
list of servers and keys, but also using the server-clause. Perhaps the
server-clause is unnecessary, and I can simply refer to a defined key and
an IP-address in a masters-clause and use this as the ACL?



> Consumers will treat S1 and S2 as masters for the RPZ-zone, and can
> allow-notify from S1 and S2 if they want instant updates.

BIND will only send NOTIFY to a zone's advertised name servers - "stealth
slaves" like your consumers have to rely on the SOA refresh timer.

I have some rather horrible code which attempts to help stealth slaves get
updates faster, by grepping the logs for zone transfers, and fanning out
notify messages to all the xfer clients. But on balance it's probably more
sensible to just reduce the refresh timer to a small number :-)

http://www.dotat.at/prog/nsnotifyd/


Something I was considering, was to place an also-notify option in the zone
on S1 and S2, where I would refer to a masters-clause "rpz-endpoints". This
list also refers the TSIG-key for the external transfers. I would also put
a "notify explicit" option. This way, I don't have to rely on NS-entries in
the zone.




> The RPZ-zone itself will never be queried, nor does it need resolving.
> Since the name of the RPZ-zone is not important, and should in fact be
> innocuous-sounding, the zone will be called something like
> "_rainbow.orgname". This will ensure that there won't be any collisions
> with other zones, and will not reveal that this is an RPZ-/blocking zone.

In general it's better to use a subdomain of a properly registered domain,
rather than making up a TLD that you hope will not collide. Or maybe I
misunderstood what you meant by ".orgname"?

There's not much need to be fussy about your zone names. For example, the
Spamhaus DBL in RPZ format is called dbl.rpz.spamhaus.org.


The reason behind the strange name is to hide who is responsible for the
blocking to avoid retaliation from unscrupulous parties, as the name of the
RPZ-zone is revealed in a SOA-query response. What if I used a reserved TLD
for the zone name, for example "_rainbow.invalid". This should never appear
in the wild. This is not a major point for the block-zone to work, but it
may be something to consider.



Tony.
--
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
South Utsire, Forties: Southerly 3 or 4, increasing 5 to 7, perhaps gale 8
later. Moderate, becoming rough at times later. Showers, rain later. Good,
occasionally poor later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20170105/ec9ff037/attachment.html>