<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">---------- Forwarded message ---------<br>From: Lars Kulseng <<a href="mailto:larskulseng@gmail.com">larskulseng@gmail.com</a>><br>Date: tor. 5. jan. 2017 kl. 15:34<br>Subject: Re: Need feedback on RPZ service setup<br>To: Tony Finch <<a href="mailto:dot@dotat.at">dot@dotat.at</a>><br></div><br><br><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">tor. 5. jan. 2017 kl. 14:24 skrev Tony Finch <<a href="mailto:dot@dotat.at" class="gmail_msg" target="_blank">dot@dotat.at</a>>:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Lars Kulseng <<a href="mailto:larskulseng@gmail.com" class="gmail_msg" target="_blank">larskulseng@gmail.com</a>> wrote:<br class="gmail_msg">
<br class="gmail_msg">
> I am setting up BIND to be used as a way to disseminate RPZ-zones for use<br class="gmail_msg">
> by third parties. I would like some feedback on my setup.<br class="gmail_msg">
<br class="gmail_msg">
Overall it sounds very sensible to me. A few notes...<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Great! Thanks for your detailed response.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> Access control is done by using TSIG-keys, with separate keys for: updates,<br class="gmail_msg">
> M1->S{1,2} transfers, and lastly there will be separate keys for each<br class="gmail_msg">
> Consumer of the RPZ-zone. The number of keys will then be 1 + 1 +<br class="gmail_msg">
> num_consumers. Each Consumer endpoint, where a transfer will take place,<br class="gmail_msg">
> will have to be defined by the server-clause in BIND, using the<br class="gmail_msg">
> keys-option, specifying an existing key.<br class="gmail_msg">
<br class="gmail_msg">
Instead of using server clauses, I would suggest having a big ACL listing<br class="gmail_msg">
all your consumer TSIG keys. You can then use this ACL in your RPZ<br class="gmail_msg">
allow-query and allow-transfer clauses. You should also include your<br class="gmail_msg">
internal zone transfer TSIGs and your management / monitoring clients in<br class="gmail_msg">
this ACL too! :-)<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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? </div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> Consumers will treat S1 and S2 as masters for the RPZ-zone, and can<br class="gmail_msg">
> allow-notify from S1 and S2 if they want instant updates.<br class="gmail_msg">
<br class="gmail_msg">
BIND will only send NOTIFY to a zone's advertised name servers - "stealth<br class="gmail_msg">
slaves" like your consumers have to rely on the SOA refresh timer.<br class="gmail_msg">
<br class="gmail_msg">
I have some rather horrible code which attempts to help stealth slaves get<br class="gmail_msg">
updates faster, by grepping the logs for zone transfers, and fanning out<br class="gmail_msg">
notify messages to all the xfer clients. But on balance it's probably more<br class="gmail_msg">
sensible to just reduce the refresh timer to a small number :-)<br class="gmail_msg">
<br class="gmail_msg">
<a href="http://www.dotat.at/prog/nsnotifyd/" rel="noreferrer" class="gmail_msg" target="_blank">http://www.dotat.at/prog/nsnotifyd/</a></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
<br class="gmail_msg">
> The RPZ-zone itself will never be queried, nor does it need resolving.<br class="gmail_msg">
> Since the name of the RPZ-zone is not important, and should in fact be<br class="gmail_msg">
> innocuous-sounding, the zone will be called something like<br class="gmail_msg">
> "_rainbow.orgname". This will ensure that there won't be any collisions<br class="gmail_msg">
> with other zones, and will not reveal that this is an RPZ-/blocking zone.<br class="gmail_msg">
<br class="gmail_msg">
In general it's better to use a subdomain of a properly registered domain,<br class="gmail_msg">
rather than making up a TLD that you hope will not collide. Or maybe I<br class="gmail_msg">
misunderstood what you meant by ".orgname"?<br class="gmail_msg">
<br class="gmail_msg">
There's not much need to be fussy about your zone names. For example, the<br class="gmail_msg">
Spamhaus DBL in RPZ format is called <a href="http://dbl.rpz.spamhaus.org" rel="noreferrer" class="gmail_msg" target="_blank">dbl.rpz.spamhaus.org</a>.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
Tony.<br class="gmail_msg">
--<br class="gmail_msg">
f.anthony.n.finch  <<a href="mailto:dot@dotat.at" class="gmail_msg" target="_blank">dot@dotat.at</a>>  <a href="http://dotat.at/" rel="noreferrer" class="gmail_msg" target="_blank">http://dotat.at/</a>  -  I xn--zr8h punycode<br class="gmail_msg">
South Utsire, Forties: Southerly 3 or 4, increasing 5 to 7, perhaps gale 8<br class="gmail_msg">
later. Moderate, becoming rough at times later. Showers, rain later. Good,<br class="gmail_msg">
occasionally poor later.<br class="gmail_msg">
</blockquote></div></div></div></div>