Re: RPZ and forward zone trouble

Wed Mar 27 12:28:14 UTC 2019

Hello folks!

Clark,

Thanks for explanation, I think it makes really sense. I''m gonna perform more tests to try clarify exactly what is it.

Thankful
--

Miguel Moreira
Gerente
DPR/SRE/GSR - Gerência de Serviços de Rede
+55(31)3339-1401
PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais

Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Em Terça, Março 26, 2019 02:15 -03, Crist Clark <cjc+bind-users at pumpky.net> escreveu:In order to make the determination whether to apply an rpz-nsip rule,
the DNS server must have the NS records and their corresponding A
records. In a recursive resolver, it would have had to lookup said NS
and A records to find the answer to the query, so they are cached and
available. In a forwarding resolver, it does not need to look up the
intermediate NS records to answer the query. It does not have the NS
records available.

You basically need your forwarder to act like a recursive resolver in
order for it to get the info in needs. Looks like BIND follows its
directive to be a forwarder as the higher calling, and doesn't do the
extra look ups necessary to get the answers it could use for the RPZ
policies. However, if they are cached and available, it will go ahead
and use them.

I think the right answer is that if you want full capabilities for
RPZ, you need full recursive resolver functionality.

(Just a BIND user explaining how I understand these features to work.
I may be way off. Also, you should be sure to read the following if
you have not already. I may not be correctly understanding your
explanation, and this document is specifically about limitations and
unexpected behaviors of this functionality,
https://kb.isc.org/docs/aa-00862
)

On Mon, Mar 25, 2019 at 4:45 PM Miguel Mucio Santos Moreira
<miguel at prodemge.gov.br> wrote:
>
> Lee, thanks for your quick answer.
> I applied the policy based on rpz-nsip trigger instead of mg.gov.br QNAME because of some others situations in my environment. Like I said earlier, the doubt is why when there's no forward zone the trigger works properly? In my opinion it should'nt have different behaviour just because of forward zone, at least I can't imagine why this is happening.
> The Bind version deployed is 9.11.4, I was imagining It could be a bug, and It seems bind 9.12 version has a fix related to this problem, but I'm not sure.
>
> thanks one more time.
>
>
>
> Miguel Moreira
> Gerente
> DPR/SRE/GSR - Gerência de Serviços de Rede
> +55(31)3339-1401
> PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais
>
>
> Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Em Segunda, Março 25, 2019 18:37 -03, Lee <ler762 at gmail.com> escreveu:
>
> On 3/25/19, Miguel Mucio Santos Moreira wrote:
> >
> > Hello everybody!
>
> Hi!
>
> > I have a problem with DNS-RPZ and forward zone working together.
> > I've created a rpz zone with the following trigger on my recursive DNS
> > Server:
> > 18.0.0.198.200.rpz-nsip IN CNAME rpz-passthru.
>
> Which means anybody can answer with a 200.198.0.0/18 address and it
> will be accepted. .. probably not what you want.
>
> > It means any query response comming from a DNS Server which IP address
> > matching with the any IP address at entire CIDR block 200.198.0.0/18 will be
> > answered with rpz-passthru
> > It works perfectly for any domain hosted in my Authoritative DNS Servers.
> > But when I apply on my recursive RPZ DNS Server a forward zone for those
> > domains hosted on my Authoritative DNS Servers the problems appear and it is
> > very weird.
> >
> > I have a mg.gov.br domain
>
> I'd go with
>
> mg.gov.br IN CNAME rpz-passthru.
> -- it's your domain so hopefully you can trust whatever answers it gives
> 18.0.0.198.200.rpz-nsip IN CNAME .
> -- nobody else gets to answer with your address space
>
> Regards,
> Lee
>
> > and its NS Servers are zeus.prodemge.gov.br
> > (200.198.5.13), titanio.prodemge.gov.br (200.198.5.5), tupan.prodemge.gov.br
> > (200.198.4.4) and jupiter.prodemge.gov.br (200.198.5.2).
> > If I perform a dig at my workstation using Recursive DNS with RPZ looking
> > for any record in mg.gov.br domain, rpz-passthru policy is not applied,
> > however if I perform a dig looking for any record in prodemge.gov.br domain
> > and after that I perform the same dig before it works properly.
> >
> >
> > Note: Recursive DNS Servers and Authoritative DNS Servers are not the same.
> >
> > As workaround solution I applied 4 rpz-nsdname triggers above that one
> > mentioned in the begining this email with my authoritative name servers with
> > rpz-passthru policy.
> > titanio.prodemge.gov.br.rpz-nsdname IN CNAME rpz-passthru.
> > jupiter.prodemge.gov.br.rpz-nsdname IN CNAME rpz-passthru.
> > tupan.prodemge.gov.br.rpz-nsdname IN CNAME rpz-passthru.
> > zeus.prodemge.gov.br.rpz-nsdname IN CNAME rpz-passthru.
> >
> > I would like to understand why it didn't work without workaround solution,
> > anyone has any idea about it?
> >
> > Thanks in advance
> > --
> >
> > Miguel Moreira
> > Gerente
> > DPR/SRE/GSR - Gerência de Serviços de Rede
> > +55(31)3339-1401
> > PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais
> >
> >
> > Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é
> > dirigida, podendo conter informação sigilosa e legalmente protegida. O uso
> > impróprio será tratado conforme as normas da empresa e a legislação em
> > vigor. Caso não seja o destinatário, favor notificar o remetente, ficando
> > proibidas a utilização, divulgação, cópia e distribuição.
> >
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> 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/20190327/f7f5f47c/attachment.html>