Re: Unhelpful startup message re: RPZ
Hi John.
From the ARM:
response-policy
…
Blocks: options, view
Tags: server, security, query, zone
Specifies response policy zones for the view or among global options.
Blocks: says where this statement can be used; i.e. in global options or within
a view.
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.
Remember that as soon as you have one or more user-defined views, all zone “….”
statements must 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.
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.
Hope that helps.
Cheers, Greg
> On 21 Sep 2023, at 17:22, John Thurston wrote:
>
> I just spent 4 hours* of my life trying to figure out why BIND 9.16
> complained on startup:
>
>
>> rpz 'rpz.local' is not a master or slave zone
>
> when the zone was obviously defined, and was obviously loading. This was
> easily verified by looking at named-checkconf -px output, and by looking in
> the logs to see the XFR from its primary.
>
> It turns out . . . my global response-policy 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 response-policy must
> be specified in each relevant view.
>
> 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."
>
> And, now that I think about it, it also feels like a defect in
> named-checkconf that this is not called out. Or maybe I'm expecting too much
> from named-checkconf ?
>
> * 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.
>
> --
> --
> Do things because you should, not just because you can.
>
> John Thurston907-465-8591
> john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
> this list
>
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Unhelpful startup message re: RPZ
Hi John,GitLab is a good place to fill well-defined feature requests.Thanks,--Ondřej Surý — ISC (He/Him)My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.On 21. 9. 2023, at 18:22, John Thurston wrote: I just spent 4 hours* of my life trying to figure out why BIND 9.16 complained on startup: rpz 'rpz.local' is not a master or slave zone when the zone was obviously defined, and was obviously loading. This was easily verified by looking at named-checkconf -px output, and by looking in the logs to see the XFR from its primary. It turns out . . . my global response-policy 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 response-policy must be specified in each relevant view. 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." And, now that I think about it, it also feels like a defect in named-checkconf that this is not called out. Or maybe I'm expecting too much from named-checkconf ? * 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. -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Unhelpful startup message re: RPZ
I just spent 4 hours* of my life trying to figure out why BIND 9.16 complained on startup: rpz 'rpz.local' is not a master or slave zone when the zone was obviously defined, and was obviously loading. This was easily verified by looking at /named-checkconf -px/ output, and by looking in the logs to see the XFR from its primary. It turns out . . . my global /response-policy/ 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 /response-policy/ must be specified in each relevant view. 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." And, now that I think about it, it also feels like a defect in /named-checkconf/ that this is not called out. Or maybe I'm expecting too much from /named-checkconf/ ? * 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. -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
