On 2022-04-29 01:18, Mark Andrews wrote:
break-dnssec is about if the client could detect the re-write or not using
DNSSEC. If the client has DO=1 in the request and the normal response is
signed then rewrites can be detected. If break-dnssec is ’no’ the rewrite will
be prevented. If break-dnssec is ‘yes’ then the rewrite will occur.
the world <-> recursive server rpz w/ break-dnssec no <-> recursive server rpz
w/ break-dnssec no or yes;
| |
non dnssec client non dnssec
client
You don’t want the second recursive server to spend all its time re-asking
queries that will fail validation
On 29 Apr 2022, at 11:24, J Doe <gene...@nativemethods.com> wrote:
Hi,
I am configuring an RPZ for a validating resolver. I read in the BIND 9.18.2
ARM that there is a boolean option for RPZ zones called: break-dnssec.
The ARM states:
...In that case, RPZ actions are applied regardless of DNSSEC.
The name of the clause option reflects the fact that results
rewritten by RPZ actions cannot verify.
In my particular scenario, I want to use RPZ to give NXDOMAIN results for
certain domain names that I don't want accessible. So for normal queries
without DNSSEC validation requested and for queries with DNSSEC validation
requested for a domain name I am _not_ blocking, I want the lookups to work
(ie: don't validate when validation not requested, validate when validation
requested).
When a client attempts to lookup a domain name that _is_ blocked by RPZ, I want
the domain name blocked ... whether or not they requested DNSSEC validation.
Am I correct that: break-dnssec yes comes into play only if a client attempts
to resolve a DNSSEC secured domain name I _am_ blocking in RPZ ?
So for instance...
1. Client requests no validation for example.com which is not in RPZ and gets
normal result.
2. Client requests validation for example.com which is not in RPZ and gets
validated result.
3. Client requests no validation for evil.com which is in RPZ and gets NXDOMAIN
result.
4. Client requests validation for evil.com which is in RPZ and gets NXDOMAIN
result with broken DNSSEC validation due to rewrite.
This would mean that: break-dnssec yes:
...only breaks DNSSEC validation for evil.com because it is re-written
...does NOT break DNSSEC validation for sites _NOT_ in RPZ that use DNSSEC (ie:
ietf.org).
Is that correct ?
Thanks,
- J
Hi Mark,
Thanks for your reply! I think I might have done a poor job asking my
questions, which may have introduced some confusion - apologies. My
brain is still chewing on this!
In this particular scenario, I have one validating resolver. The
diagram would be:
Client (PC, mail server, etc.) -> My resolver -> The world
What I was wondering is if I configure my validating resolver to use:
break-dnssec yes, does that mean that DNSSEC validation is broken for
_ALL_ queries ?
I am thinking that this applies only when a client computer queries my
validating resolver and wants to know if DNSSEC is valid on a query that
my resolver has changed via RPZ. Because RPZ modified the data it can
no longer validate.
So the client queries my resolver for DNSSEC validity for a server that
is _NOT_ covered by my RPZ policy ... validation should _NOT_ break in
that circumstance, right ?
Thanks,
- J
--
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
