Bug 4229 - Unbound man pages/docslacxk crucial information on some points
Unbound man pages/docslacxk crucial information on some points
Status: ASSIGNED
Product: unbound
Classification: Unclassified
Component: server
1.8.3
All All
: P5 normal
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-02-27 05:49 CET by Stilez
Modified: 2019-02-27 07:56 CET (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stilez 2019-02-27 05:49:18 CET
SOme specific points where docs really lack key info, and there isn't an alternate source to google/look up. Can something be done just to clarify these if nothing else?

The "what happens if" is terse to the point of being unclear, in several places:

access-control: - "The most specific netblock match is used". Is this regardless of where it occurs (early or late) in the list of access controls?

access-control-tag-action and local-zone-tag - clearer  explanation of how clients who end up with multiple tags, are handled.

View Options - "There may be multiple view: clauses. Each with a name: and zero or more local-zone and local-data elements" - seems to suggest that a view can't advertise itself as authoritative for whatever data is held. It should be able to. Can it? 

Also, same section, what tags can go inside view:? This seems to say clearly that only local-zone/data can. But other pages say equally clearly that view-first can. Any others that need checking?
Comment 1 Wouter Wijngaards 2019-02-27 07:56:28 CET
Hi Stilez,

Access-control:   So the most specific is used and without the order being important, yes.

For local-zone-tag:  The intersection is used.

For access-control-tag-action:  I do not see what to explain more than what is there in the section for access-control-tag-action, what sort of text would you suggest?  It already talks about multiple tags and matching them in the order that the tags are defined with define-tag statements?

view options:  Nope, this is not bind.  View cannot advertise themselves as authoritative.  Are you looking for the auth-zone clause, where you can load an authority zone to speed up lookups, eg. for the root zone?

But you can add localzone elements to a view.  And those elements then give authoritative answers, like localzones do when you configure them what to answer.

Views can also contain view-first, response-ip, response-ip-data and local-data-ptr elements.

Thanks for the comments, the man page has been updated with some extra explanations.

Best regards, Wouter