bind-users Digest, Vol 4031, Issue 3

[Timothe Litt]

On 02-Aug-22 11:09, bind-users-request at lists.isc.org wrote:

> | Before your authoritative view, define a recursive view with the internal
> ! zones defined as static-stub, match-recursive-only "yes",  and a
> ! server-address of localhost.
>
> Uh? Why before?

Because each request attempts to match the views in order.  You want the 
stub view to match recursive requests.  The non-RD requests will fall 
thru to the internal zone and get the authoritative data.  The latter 
includes the requests that the stub zone makes for authoritative data 
for its zones.  (You don't want the authoritative view to match the 
recursive requests, since that will not return AD.)  The ordered 
evaluation is why "match-clients {any;}};" in the "external" (last) view 
does NOT match the preceding views.

Then any non-matching clients (e.g. external) go thru the same process.  
Generally external follows internal because you know how to match 
internal (e.g. your IP addresses / RCC1918 addresses), and "external" is 
everyone else.

I find that views require less management than multiple instances, and 
properly set up, I don't buy the "safety in separate instances for 
authoritative and recursive servers" But that's somewhat of a religious 
discussion - there are arguments on both sides.

In any case, the point is that contrary to other advice, it IS possible 
to run an authoritative server that also returns AD to recursive requests.

You seem to have more than two views - that doesn't change the 
principle.  For each authoritative view that you want to return AD, you 
need to add a recursive view that is a static-stub.

The outline that I provided is extracted from my working configuration.

You do need the allow-* and match-clients, but those are site-specific.

You can also slave the root zone - that's orthogonal to AD.

I suggest taking one step at a time.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220802/90a99180/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220802/90a99180/attachment.sig>