Additionally authoritative servers for a zone are supposed to answer queries with RD=1 set with RA=0 if the client is not being offered recursion. REFUSED is the wrong answer of the query name involves zones you serve. Only if you are a recursive only server should you be considering REFUSED. On 3 Aug 2022, at 04:04, Timothe Litt <l...@acm.org> wrote:
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.
-- 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
|
OpenPGP_signature
Description: Binary data
--
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
