<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi John.<div>From the ARM:</div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>response-policy</div><div>…</div><div><div>Blocks: options, view</div><div>Tags: server, security, query, zone</div><div>Specifies response policy zones for the view or among global options.</div></div></blockquote><div><br></div><div><b>Blocks</b>: says where this statement can be used; i.e. in global options or within a view.</div><div>The description is reasonably clear (I think) that you specify this globally (in options { ) if you don’t have views, or you specify it in a view along with the RPZ zone(s) you are defining.</div><div><br></div><div>Remember that as soon as you have one or more user-defined views, all zone “….” statements <b>must</b> go into them and you cannot have zones defined outside of views anymore - either/or. This means that if you define RPZ zones inside views then the corresponding “response-policy” statement(s) must also go into the same views.</div><div><br></div><div>Perhaps the log message could be a little less cryptic and yes, as Ondřej says, Gitlab is the place to go to request some nicer wording, or any other changes you think would be beneficial.</div><div><br></div><div>Hope that helps.</div><div>Cheers, Greg</div><div><br></div><div><br><div><br><blockquote type="cite"><div>On 21 Sep 2023, at 17:22, John Thurston <john.thurston@alaska.gov> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div><p>I just spent 4 hours* of my life trying to figure out why BIND
9.16 complained on startup:</p><div>
<br class="webkit-block-placeholder"></div><blockquote type="cite">rpz 'rpz.local' is not a master or slave
zone</blockquote><div><br class="webkit-block-placeholder"></div><p>when the zone was obviously defined, and was obviously loading.
This was easily verified by looking at <i>named-checkconf -px</i>
output, and by looking in the logs to see the XFR from its
primary.</p><p>It turns out . . . my global <i>response-policy</i> option
worked swimmingly when there was exactly one view defined. When
there is more than one view, the reference to the zone becomes
ambiguous and bind threw out that (not very) helpful message. When
there is more than one view, the <i>response-policy</i> must be
specified in each relevant view.<br>
</p><p>Where do I make a 'feature request'? I think I see how to
register defects (GitLab). Do feature requests go there, too? I'd
love to see the text of that message be a little more explanatory.
Maybe, "Dude. The zone you named exist, but with more than one
view your reference is ambiguous."<br>
</p><p>And, now that I think about it, it also feels like a defect in <i>named-checkconf</i>
that this is not called out. Or maybe I'm expecting too much from
<i>named-checkconf</i> ?<br>
</p><p>* Admittedly, the second and third hours were of diminishing
value, as my caffeine wore off and my frustration grew. After a
night's sleep, and a pot of fresh tea I figured it out.<br>
</p>
<pre class="moz-signature" cols="72">--
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
<a class="moz-txt-link-abbreviated" href="mailto:John.Thurston@alaska.gov">John.Thurston@alaska.gov</a>
Department of Administration
State of Alaska</pre>
</div>
-- <br>Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list<br><br>ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.<br><br><br>bind-users mailing list<br>bind-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/bind-users<br></div></blockquote></div><br></div></body></html>