On 02-Aug-22 13:18, Peter wrote:
On Tue, Aug 02, 2022 at 11:54:02AM -0400, Timothe Litt wrote:
!
! On 02-Aug-22 11:09,bind-users-requ...@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.

Ahh, I see. But this does not work so well for me, because I have the
public authoritative server also in the same process. And from the
Internet will come requests with RD flag set, and these must get a
REFUSED ("recursion desired but not available").

So I considered it too dangerous to select views depending on the RD
flag being present or not, and resolve this with a slightly different
ordering of the views.

-- PMc

Order matters, and changing it will change behaviors.

My example combines the internal and public servers into one bind instance.  It provides 
recursive and authoritative service to internal clients; the recursive view will set AD.  
For external clients, it is authoritative - but there is provision for known clients to 
get recursive service (with AD).  Such clients would be excluded from matching the 
"*internal" views.  You might use this for DMZ systems, or for management tools 
(e.g. if you want to AXFR the external view.)

My public authoritative server(s) are the "external" view.

The server doesn't select ONLY on the RD flag.  It also selects on IP address 
and/or TSIG keys.  The RD flag is only used to select between the recursive and 
authoritative view pairs for MATCHING CLIENTS.

So you should order the views as I showed.

The public clients will fail the "match-clients" clause of the internal views 
regardless of the RD because of their IP addresses.  They will fall thru to the 
r-external view.  That will also fail unless they are listed clients.  So again, they 
fall thru to the external view.  That has recursion no - which means that RD will return 
REFUSED.

The only danger comes from failing to properly setup the client matching ACLs, 
or from making changes to the logic without understanding how it works.

Instead of guessing, use what I provided and test it.  It works.  It has worked 
for many years.  Once you have tested it and completely understand it, THEN 
make changes.  Carefully.  And test them.

This technique is straightforward if you completely understand what it's doing, 
but if you make assumptions you are likely to get into trouble.


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

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

-- 
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

Reply via email to