On 01/28/2019 04:13 AM, Blason R wrote:
Thanks for the revert however, in my scenario I have Windows AD server is being used as a Authoritative DNS for exmaple.local which has forwarding set to BIND acting as a RPZ and wanting to see if we can conceal this vulnerability on BIND.
Am I understanding you correctly in that you have a Windows DNS server that is both:
1) Authoritative for the example.local domain.2) Configured to forward queries to a BIND DNS server that is applying Response Policy Zone filtering.
I'm guessing that BIND is functioning as a recursive resolver for Windows. You don't currently have deny-answer-aliases enabled.Is all of this correct? (I'm assuming that it is unless / until you correct.)
Please clarify what vulnerability you are trying to conceal.
I think since BIND is not a NS for example domain even if I enable this protection on BIND not sure if that would take effect?
I don't see anything in the ARM talking about needing to be authoritative for the domain(s) in question. So I don't see how BIND not having the example.local zone is a problem.
Even if BIND did filter queries for example.local, the Windows server shouldn't be sending queries for example.local because Windows is authoritative for example.local.
What am I missing / misunderstanding?Finally, I would expect that you can use RPZ to do filtering that is comparable to "deny-answer-addresses {…};" and / or "deny-answer-aliases {…};".
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/bind-users
