<div dir="ltr"><span style="color:rgb(33,33,33);font-size:13px">I am setting up<span class="inbox-inbox-Apple-converted-space"> </span></span><span class="inbox-inbox-lG" style="background-color:rgba(251,246,167,0.498039);outline:transparent dashed 1px;color:rgb(33,33,33);font-size:13px">BIND</span><span style="color:rgb(33,33,33);font-size:13px"><span class="inbox-inbox-Apple-converted-space"> </span>to be used as a way to disseminate RPZ-zones for use by third parties. I would like some feedback on my setup. Any pitfalls I may encounter would be great to hear about.</span><div class="gmail_msg" style="color:rgb(33,33,33);font-size:13px"><br class="gmail_msg"></div><div class="gmail_msg" style="color:rgb(33,33,33);font-size:13px"><div class="gmail_msg">The system will only serve up RPZ-zones to external parties that will zone-transfer the RPZ-zone to use in their own DNS infrastructure, from now on called Consumers. <br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">To allow for some flexibility, the setup consists of three instances of<span class="inbox-inbox-Apple-converted-space"> </span><span class="inbox-inbox-lG" style="background-color:rgba(251,246,167,0.498039);outline:transparent dashed 1px">BIND</span><span class="inbox-inbox-Apple-converted-space"> </span>9.9.4 on three CentOS virtual machines. One master (M1) and two slaves (S1, S2). M1 is the only machine that can receive zone updates, but will send notify messages to S1 and S2 when the RPZ-zone changes. M1 will not allow queries, and will only send notify or transfer messages to S1 and S2. In turn, S1 and S2 must allow queries, since a zone transfer will include a SOA-query, but will only send zone data to allowed Customer endpoints. </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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<span class="inbox-inbox-Apple-converted-space"> </span><span class="inbox-inbox-lG" style="background-color:rgba(251,246,167,0.498039);outline:transparent dashed 1px">BIND</span>, using the keys-option, specifying an existing key.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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. The zone will be used as any other normal RPZ-zone in their<span class="inbox-inbox-Apple-converted-space"> </span><span class="inbox-inbox-lG" style="background-color:rgba(251,246,167,0.498039);outline:transparent dashed 1px">BIND</span><span class="inbox-inbox-Apple-converted-space"> </span>installation.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div></div><div class="gmail_msg" style="color:rgb(33,33,33);font-size:13px">Any feedback on this proposed setup is welcome.</div><div class="gmail_msg" style="color:rgb(33,33,33);font-size:13px"><br></div><div class="gmail_msg" style="color:rgb(33,33,33);font-size:13px"><br></div><div class="gmail_msg" style="color:rgb(33,33,33)">Lars</div></div>