(re)adding local resolver.arpa zone

[Yorgos Thessalonikefs]

Hi Havard,

I took your suggestions and incorporated them into the man page along 
with some other changes.

https://github.com/NLnetLabs/unbound/commit/9602973c863d506cfce88d632919136627901bb4
https://github.com/NLnetLabs/unbound/commit/6ad26909dd3a22228ebf9711ebc9e2c3b4fa8d44

Best regards,
-- Yorgos



On 16/10/2025 19:06, Havard Eidnes via Unbound-users wrote:
>> I have been perusing the unbound.conf(5) man page and have the
>> following remarks:
>>
>> 1) It is somewhat unclear whether "auth-zone:" should be listed
>>     under another "clause", i.e. indented, or whether it should be
>>     on the outermost level in unbound.conf.  My current attempt
>>     has it at the outermost level, as shown above.
>>
>> 2) The manual page appears to make a distinction between what's
>>     called a "clause" (outermost level?), such as "server:", and
>>     what's referred to as "options" (to be found under a specific
>>     "clause"(?)).  However, the wording on this in general and
>>     wrt. "auth-zone:" could be more unambigious and explicit.
>>
>> 3) The various options listed under the "server:" clause (and
>>     other clauses) are not alphabetically sorted, which makes
>>     finding a given option quickly quite difficult, given the size
>>     of the man page.  Yes, I can search, but then the context of
>>     "under which clause am I now looking" gets lost.
>>
>> Given some clarification from the maintainers, I can probably
>> engage in crafting a reshuffling of the unbound.conf content and
>> to add some words of clarification.
> 
> Uh, I meant the unbound.conf(5) man page, not the example config
> file, if that wasn't obvious.  In addition to sorting the options
> under each clause, as an example, I think I would suggest to replace
> 
>         There must be whitespace between keywords.  Attribute keywords end with
>         a colon ':'.  An attribute is followed by a value,  or  its  containing
>         attributes in which case it is referred to as a clause.  Clauses can be
>         repeated throughout the file (or included files)  to  group  attributes
>         under the same clause.
> 
> with, probably something along the lines of...
> 
>         The configuration file is logically divided into "sections"
>         where each section is introduced by a "section clause".
> 
>         The recognized section clauses are:
> 
>         server:	      Most of the configuration of the recursive DNS
>         		      name server function is found in this section.
> 
>         auth-zone:     Configuration of local authoritative zones.
> 
>         cachedb:	      Configuration of the optional "cache DB"
> 		      feature to e.g. use redis for this function.
> 
>         dnscrypt:      Configuration of the optional dnscrypt
> 		      feature.
> 
>         dnstap:	      Configuration of the optional dnstap feature
> 		      to "mirror out" a copy of the DNS queries and
> 		      responses.
> 
>         dynlib:	      Configuration of the optional feature to load
> 		      dynamic custom shared libraries into unbound.
> 
>         forward-zone:  Configuration for selective query forwarding
> 		      of recursive requests where the answer is not
> 		      in the local cache.
> 
>         python:	      Configuration for the optional python script
> 		      module.
> 
>         remote-control: Configuration of the facility used by
>                        unbound-control(8).
> 
>         rpz:	      Configuration for Response Policy Zones,
> 		      allowing blocking or other custom actions for
> 		      certain lookups.
> 
>         stub-zone:     Configuration of redirection of certain parts
> 		      of the name space to "custom name servers",
> 		      e.g. for domain names not generally available
> 		      on the greater Internet.
> 
>         view:	      Configuration for different views of the name
> 		      space.  You can use e.g. access-control-tag or
> 		      access-control-vew options to direct certain
> 		      clients to certain views.  Views can be
> 		      combined with e.g. "rpz" to perform that
> 		      function for just a subset of allowed clients.
> 
>         Section clauses may occur more than once, to logically group
>         options for a given feature or aspect in one visually
>         cohesive group.  This may be particularly useful for the
>         "server:" clause with its myriad of options.
> 
>         Whitespace indentation of option names under each section is
>         insignificant, but is still recommended for visual clarity.
> 
> with a fact-check for the latter.  I beleive it to be accurate, so
> deviates both from what python and the .yml file format does...
> 
> Regards,
> 
> - Håvard