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

Mark Andrews marka at isc.org
Wed Aug 3 06:49:35 UTC 2022


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

> On 3 Aug 2022, at 04:04, Timothe Litt <litt at 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-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. 
> 
> -- 
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220803/368ea5aa/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/octet-stream
Size: 495 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220803/368ea5aa/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220803/368ea5aa/attachment-0001.htm>


More information about the bind-users mailing list