DNSSEC signing of an internal zone gains nothing (unless??)

[Timothe Litt]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220802/9d077c4a/attachment-0001.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/9d077c4a/attachment-0001.sig>