RPZ and forward zone trouble

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

RPZ and forward zone trouble

Miguel Mucio Santos Moreira
Hello everybody!

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.

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 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Lee
Reply | Threaded
Open this post in threaded view
|

Re: RPZ and forward zone trouble

Lee
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: RPZ and forward zone trouble

Miguel Mucio Santos Moreira
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 <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: RPZ and forward zone trouble

Crist Clark
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
<[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: RPZ and forward zone trouble

Bind-Users forum mailing list
On 3/25/19 11:15 PM, Crist Clark wrote:
> if they are cached and available, it will go ahead
> and use them.

Does having the necessary information in an authoritative zone count as
available in this context?



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RPZ and forward zone trouble

Miguel Mucio Santos Moreira
In reply to this post by Crist Clark
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 <[hidden email]> 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
<[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users