Request assistance configuring RPZ

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

Request assistance configuring RPZ

David Bank
Hello to the list. Long-time BIND user here - a big "Thank You!" to ISC
for all they do.

I'm finding myself out past the limits of my knowledge, and I'm asking for
help. My environment is BIND 9.11.2, on SLES 12 SP4.

I'm thinking of using the Response Policy Zones feature to solve a
problem, but I have no experience with the configuration. The online
examples and discussions I've found are geared more towards DNS firewalls,
which is not really what I'm trying to do.

Consider the Zone 'internal.local'. It has 2 DNS servers,
buzz.internal.local and woody.internal.local; they both are authoritative
(forward and reverse) for the Zone. They serve all of the clients in
internal.local, and all hosts have IP addresses 10.AAA.BBB.CCC

I've created a special network "bubble", where the IP addressing is
192.168.XXX.YYY, and in which selected hosts will briefly live before they
are moved to the 10.AAA.BBB.CCC network. While in this bubble, they
self-identify as hosts in the internal.local Domain; however, they have no
direct connectivity to buzz or woody; instead, via DHCP, they are told to
use zurg.internal.local for DNS. zurg is on a host that has IPs in both
the 10. and 192.168. networks (but zurg's DNS server only listens on the
192.168. network, and is the only DNS server in that network)

I want to configure zurg so that it will refer ALL requests to buzz or
woody; however, when a request is made to resolve andy.internal.local or
sid.internal.local, then zurg rewrites those IPs from the 10. addresses
that buzz and woody know about to 192.168. addresses that only zurg knows.
andy and sid also have addresses in both networks.

Reverse lookups shouldn't be an issue - hosts won't live in this bubble
long enough to care

To recap what I'm attempting to create: a host in the 10. network knows to
ask buzz or woody for DNS resolution, and if such a host wants to resolve
andy.internal.local, it gets (for example) 10.0.2.4 (moreover, the host
can't even reach the DNS server on zurg). This part already exists.

However, a host in the 192.168. network has been told to use zurg, and if
it asks to resolve andy.internal.local, I want it to get 192.168.8.9 (even
though when zurg forwarded the request to buzz, the response was 10.0.2.4)

When zurg takes a request from a host in the 192.168. network to resolve
anything EXCEPT andy or sid, then the request is processed normally, and
zurg returns whatever reply was given by buzz or woody

Is such a configuration possible, and how do I do it?

BTW, right now, zurg is up and running - I understand his configuration
will have to radically change. Currently, he considers himself as
authoritative for internal.local, but he only knows of 2 hosts (andy and
sid); he does not forward and does not contain the full Zone information
for internal.local

Please let me know if additional information is needed.
_______________________________________________
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: Request assistance configuring RPZ

Bind-Users forum mailing list
On 5/28/19 10:16 AM, David Bank wrote:
> I want to configure zurg so that it will refer ALL requests to buzz or
> woody; however, when a request is made to resolve andy.internal.local or
> sid.internal.local, then zurg rewrites those IPs from the 10. addresses
> that buzz and woody know about to 192.168. addresses that only zurg
> knows. andy and sid also have addresses in both networks.

Okay.

I'm not convinced that you need RPZ to do what I think you want to do.
But I'm not convinced that I fully understand what you want to do, much
less why you want to do it.  (More below.)

> Reverse lookups shouldn't be an issue - hosts won't live in this bubble
> long enough to care

I think reverse lookups may be a relatively simple after the fact, if
you care to do them.

> To recap what I'm attempting to create: a host in the 10. network knows
> to ask buzz or woody for DNS resolution, and if such a host wants to
> resolve andy.internal.local, it gets (for example) 10.0.2.4 (moreover,
> the host can't even reach the DNS server on zurg). This part already
> exists.

Do you want hosts on the 10/8 network (thus not in the bubble) to be
able to reach any of the hosts in the bubble?

Or is this simply wanting to make sure that hosts (outside the bubble)
in 10/8 resolve to IPs in 10/8 and that hosts (inside the bubble) in
192.168/16 resolve to IPs in 192.168/16?

I'm wondering if it might be possible to use a simple flat DNS zones
with sorting of replies.

> However, a host in the 192.168. network has been told to use zurg, and
> if it asks to resolve andy.internal.local, I want it to get 192.168.8.9
> (even though when zurg forwarded the request to buzz, the response was
> 10.0.2.4)

Sorting and apex overrides come to mind.

> When zurg takes a request from a host in the 192.168. network to resolve
> anything EXCEPT andy or sid, then the request is processed normally, and
> zurg returns whatever reply was given by buzz or woody
>
> Is such a configuration possible, and how do I do it?

I'm still not convinced that I understand what you're wanting to do,
much less why you want to do it.  As such, this response may be
completely wrong for you.

Can you have a single zone, internal.local that has records for all the
hosts, with andy.internal.local, sid.internal.local, and
zurg.internal.local having multiple A records, one in each network.
Then configure BIND to sort the replies based on the network the client
is coming from.

This would mean that any host in the 192.168/16 bubble would get a
192.168/16 address listed first in the reply.  Similarly, any host in
the main 10/8 network would get a 10/8 address listed first.

Based on my limited understanding of your needs, I think such sorting of
replies might solve your problem.  But my understanding is incomplete
and there may be other requirements that I'm not aware of.

Also, is there any reason that zurg can't be a slave for the zones that
buzz and woody are authoritative for?  (Especially if sorting addresses
the issue.)

> BTW, right now, zurg is up and running - I understand his configuration
> will have to radically change. Currently, he considers himself as
> authoritative for internal.local, but he only knows of 2 hosts (andy and
> sid); he does not forward and does not contain the full Zone information
> for internal.local

I don't see any reason to make zurg have a completely independent zone
with a conflicting name.  I don't see any reason why zurg can't have a
slave copy of the real zone(s).

> Please let me know if additional information is needed.

About the only thing that I can see RPZ being used for here would be to
override the information that zurg might return if the zone didn't
already have the data (multiple A records) which could be sorted.  I see
two potential solutions for this:

1)  Apex overrides
2)  RPZ overrides

#1 is simply a new zone that is the FQDN of what you want to override
and put an A record with the address you want in the apex.

#2 is configuring RPZ to return different IP(s) (in the 192.168/16
bubble) for specific query names.  (This is what traditional RPZ / DNS
firewalls do.)

Please ponder this and help me understand why having a single common
zone across buzz, woody, and zurg using response sorting wouldn't work.

Please help me understand why any assumptions I've made are incorrect.

Once we know which direction we're going, then we can get into syntax.
(Read:  I don't have time to look up syntax /now/ and am using this as
an excuse to do so later.  ;-)



--
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: [External] Re: Request assistance configuring RPZ

David Bank
On Tue, 28 May 2019, Grant Taylor via bind-users wrote:

Hello, Grant! Thanks for replying.

> On 5/28/19 10:16 AM, David Bank wrote:
>> To recap what I'm attempting to create: a host in the 10. network knows
>> to ask buzz or woody for DNS resolution, and if such a host wants to
>> resolve andy.internal.local, it gets (for example) 10.0.2.4 (moreover,
>> the host can't even reach the DNS server on zurg). This part already
>> exists.
>
> Do you want hosts on the 10/8 network (thus not in the bubble) to be
> able to reach any of the hosts in the bubble?

     No - the bubble is its own world for the most part. No reason for
general 10/8 inhabitants to try to talk to 192.168/16 - the very, very few
hosts that need to talk in 192.168/16 already have an IP in there.

> Or is this simply wanting to make sure that hosts (outside the bubble)
> in 10/8 resolve to IPs in 10/8 and that hosts (inside the bubble) in
> 192.168/16 resolve to IPs in 192.168/16?

    Hosts in 192.168/16 need to resolve 2 SPECIFIC names to 192.168/16 when
those names would otherwise resolve to 10/8 addresses. All other name
resolution whould be to 10/8.

> I'm wondering if it might be possible to use a simple flat DNS zones
> with sorting of replies.

    Perhaps I'm missing something, but I don't see how to make zurg reply
with 192.168/16 IPs for andy and sid, but correctly resolve the rest of
*.internal.local - at least not without supplying zurg with a flat file to
reference (which I don't want to do).

>> However, a host in the 192.168. network has been told to use zurg, and
>> if it asks to resolve andy.internal.local, I want it to get 192.168.8.9
>> (even though when zurg forwarded the request to buzz, the response was
>> 10.0.2.4)
>
> Sorting and apex overrides come to mind.

    I'm not familiar with those techniques, but I'm interested in learning.

> Can you have a single zone, internal.local that has records for all the
> hosts, with andy.internal.local, sid.internal.local, and
> zurg.internal.local having multiple A records, one in each network. Then
> configure BIND to sort the replies based on the network the client is
> coming from.

    No, because I don't have a non-manual way to supply zurg with the Zone
data for *.internal.local. And I'm not too keen on, say, having zurg do a
routine Zone dump from, say. buzz, and scripting something on zurg to
massage the information so the records for andy and sid return 192.168/16.

> This would mean that any host in the 192.168/16 bubble would get a
> 192.168/16 address listed first in the reply.  Similarly, any host in
> the main 10/8 network would get a 10/8 address listed first.

    Hosts in 10/8 don't talk to zurg (aside from the fact zurg will talk
with buzz and woody) - hosts in 10/8 only talk to buzz and woody, and buzz
and woody always resolve all queries to 10/8 (e.g. they always tell the
"truth").

> Also, is there any reason that zurg can't be a slave for the zones that
> buzz and woody are authoritative for?  (Especially if sorting addresses
> the issue.)

    No, I don't think so - but I didn't see how that would help, since I
want zurg to alter the replies for just 2 hosts in the Zone. Athough, zurg
is BIND on SLES; buzz and woody are Winblows DNS.

> About the only thing that I can see RPZ being used for here would be to
> override the information that zurg might return if the zone didn't
> already have the data (multiple A records) which could be sorted.  I see
> two potential solutions for this:
>
> 1)  Apex overrides
> 2)  RPZ overrides
>
> #1 is simply a new zone that is the FQDN of what you want to override
> and put an A record with the address you want in the apex.

    OK - I have no idea how to do it, but if that would work....

> #2 is configuring RPZ to return different IP(s) (in the 192.168/16
> bubble) for specific query names.  (This is what traditional RPZ / DNS
> firewalls do.)

    Yes, that's what I was thinking of originally.

> Please ponder this and help me understand why having a single common
> zone across buzz, woody, and zurg using response sorting wouldn't work.

    Well, I have no control over buzz and woody. I can only control zurg.
I'm not sure if Winblows can do response sorting, or if zurg would be able
to impose a sort on the data after he does a Zone transfer.
_______________________________________________
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: [External] Re: Request assistance configuring RPZ

Sten Carlsen
To me this looks like it could be done with a bit of programming.
If the addresses of the two hosts needed in 192.168.x.x don't change too often, a cron job could read those addresses and set them in zurg as dynamic entries using nsupdate. The time for cron would be smaller than the TTL of the RRs in their original location.

This is a different look at the task, if not relevant, just ignore.

On 28/05/2019 19.13, David Bank wrote:
On Tue, 28 May 2019, Grant Taylor via bind-users wrote:

Hello, Grant! Thanks for replying.

On 5/28/19 10:16 AM, David Bank wrote:
To recap what I'm attempting to create: a host in the 10. network knows
to ask buzz or woody for DNS resolution, and if such a host wants to
resolve andy.internal.local, it gets (for example) 10.0.2.4 (moreover,
the host can't even reach the DNS server on zurg). This part already
exists.

Do you want hosts on the 10/8 network (thus not in the bubble) to be able to reach any of the hosts in the bubble?

    No - the bubble is its own world for the most part. No reason for general 10/8 inhabitants to try to talk to 192.168/16 - the very, very few hosts that need to talk in 192.168/16 already have an IP in there.

Or is this simply wanting to make sure that hosts (outside the bubble) in 10/8 resolve to IPs in 10/8 and that hosts (inside the bubble) in 192.168/16 resolve to IPs in 192.168/16?

   Hosts in 192.168/16 need to resolve 2 SPECIFIC names to 192.168/16 when those names would otherwise resolve to 10/8 addresses. All other name resolution whould be to 10/8.

I'm wondering if it might be possible to use a simple flat DNS zones with sorting of replies.

   Perhaps I'm missing something, but I don't see how to make zurg reply with 192.168/16 IPs for andy and sid, but correctly resolve the rest of *.internal.local - at least not without supplying zurg with a flat file to reference (which I don't want to do).

However, a host in the 192.168. network has been told to use zurg, and
if it asks to resolve andy.internal.local, I want it to get 192.168.8.9
(even though when zurg forwarded the request to buzz, the response was
10.0.2.4)

Sorting and apex overrides come to mind.

   I'm not familiar with those techniques, but I'm interested in learning.

Can you have a single zone, internal.local that has records for all the hosts, with andy.internal.local, sid.internal.local, and zurg.internal.local having multiple A records, one in each network. Then configure BIND to sort the replies based on the network the client is coming from.

   No, because I don't have a non-manual way to supply zurg with the Zone data for *.internal.local. And I'm not too keen on, say, having zurg do a routine Zone dump from, say. buzz, and scripting something on zurg to massage the information so the records for andy and sid return 192.168/16.

This would mean that any host in the 192.168/16 bubble would get a
192.168/16 address listed first in the reply.  Similarly, any host in
the main 10/8 network would get a 10/8 address listed first.

   Hosts in 10/8 don't talk to zurg (aside from the fact zurg will talk with buzz and woody) - hosts in 10/8 only talk to buzz and woody, and buzz and woody always resolve all queries to 10/8 (e.g. they always tell the "truth").

Also, is there any reason that zurg can't be a slave for the zones that buzz and woody are authoritative for?  (Especially if sorting addresses the issue.)

   No, I don't think so - but I didn't see how that would help, since I want zurg to alter the replies for just 2 hosts in the Zone. Athough, zurg is BIND on SLES; buzz and woody are Winblows DNS.

About the only thing that I can see RPZ being used for here would be to
override the information that zurg might return if the zone didn't
already have the data (multiple A records) which could be sorted.  I see
two potential solutions for this:

1)  Apex overrides
2)  RPZ overrides

#1 is simply a new zone that is the FQDN of what you want to override
and put an A record with the address you want in the apex.

   OK - I have no idea how to do it, but if that would work....

#2 is configuring RPZ to return different IP(s) (in the 192.168/16 bubble) for specific query names.  (This is what traditional RPZ / DNS firewalls do.)

   Yes, that's what I was thinking of originally.

Please ponder this and help me understand why having a single common zone across buzz, woody, and zurg using response sorting wouldn't work.

   Well, I have no control over buzz and woody. I can only control zurg. I'm not sure if Winblows can do response sorting, or if zurg would be able to impose a sort on the data after he does a Zone transfer.
_______________________________________________
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: [External] Re: Request assistance configuring RPZ

Bind-Users forum mailing list
In reply to this post by David Bank
On 5/28/19 11:13 AM, David Bank wrote:
> Hello, Grant! Thanks for replying.

Hi.

You're welcome.

>      No - the bubble is its own world for the most part. No reason for
> general 10/8 inhabitants to try to talk to 192.168/16 - the very, very
> few hosts that need to talk in 192.168/16 already have an IP in there.

Okay.

>     Hosts in 192.168/16 need to resolve 2 SPECIFIC names to 192.168/16
> when those names would otherwise resolve to 10/8 addresses. All other
> name resolution whould be to 10/8.

Okay.

>     Perhaps I'm missing something, but I don't see how to make zurg
> reply with 192.168/16 IPs for andy and sid, but correctly resolve the
> rest of *.internal.local

At the moment, I'm thinking about having one zone, "internal.local",
with almost all hosts having A records in the 10/8 IP space.  "andy" and
"sid" would also have A records in the 192.168/16 IP space in addition
to their A records in the 10/8 IP space.  (More details below.)

> at least not without supplying zurg with a flat file to reference
> (which I don't want to do).

Please clarify, is it that you want to not have to maintain and update
special zone file(s) for zurg?  Or do you want zurg to not have the rest
of the zone contents that the main DNS servers have?

Asked another way:  Is it okay for zurg to have copies of the
"internal.local" zone?  (Assuming that the necessary IP changes can be
effected with easy.)

>     I'm not familiar with those techniques, but I'm interested in learning.

There may be a different name for what I call "apex override".  In
short, you would create two additional zones on zurg;
"andy.internal.local" and "sid.internal.local".  They would look
something like the following:

@andy.internal.local.   SOA   ...
                          NS    zurg.internal.local.
                          A     192.168.123.234

@sid.internal.local.    SOA   ...
                          NS    zurg.internal.local.
                          A     192.168.234.123

This way, when clients query andy.internal.local or sid.internal.local,
zurg will have a local authoritative zone that specifies alternate IPs
in the 192.168/16 network.

Note:  There is some potential for (lack of) delegation issues.  This is
because there's a very good chance that those names won't be delegated
in the internal.local zone.  -  However, this can be worked around by
doing delegation to service names.  -  The only time I've run into
problems like this is if you run some sort of test to validate
delegation.  All of the real world examples I've seen have worked okay.

Sorting, or "sortlist" in BIND / named parlance is a way to tell BIND /
named to sort the response records being sent to clients such that they
are (theoretically) in the best order for the client.

Link - DNS BIND9 Query Statements - sortlist
   - http://www.zytrax.com/books/dns/ch7/queries.html#sortlist

You would add sortlist something like the following:

options {
        ...
        sortlist {
                {
                        192.168/16;
                        {
                                192.168/16;
                        };
                };
                {
                        10/8;
                        {
                                10/8;
                        };
                }
        }
        ...
}

This tells BIND / named that when it replies to clients in the
192.168/16 network, that any address in the 192.168/16 network should be
listed first.  Similarly, clients in the 10/8 network should get IPs in
the 10/8 network as the first IP.

So BIND / named will reply to clients with multiple IPs.  It will just
order them in what it thinks (based on the configuration) is the best
order for the client.

So, if you have two A records for andy and sid, one in each network
(10/8 and 192.168/16), BIND / named will be able to use the zone as is
without modification.

>     No, because I don't have a non-manual way to supply zurg with the
> Zone data for *.internal.local.

Why do you have to do it manually?

Why can't you use standard zone transfer mechanisms?

> And I'm not too keen on, say, having zurg do a routine Zone dump from,
> say. buzz, and scripting something on zurg to massage the information
> so the records for andy and sid return 192.168/16.

You don't need to do a zone dump.  (See above.)

I'm not convinced that you /need/ to alter the zone.  (See above.)

>     Hosts in 10/8 don't talk to zurg (aside from the fact zurg will talk
> with buzz and woody) - hosts in 10/8 only talk to buzz and woody, and
> buzz and woody always resolve all queries to 10/8 (e.g. they always tell
> the "truth").

Unfortunately, that doesn't indicate if anything about DNS needs to
prevent hosts in 10/8 from talking to hosts in 192.168/16 by never
resolving anything.  This is a key difference.

Is it okay for hosts in 10/8 to know that there are 192.168/16 IP
addresses?  Even if they will never use them?  Or does there /need/ to
be hard separation that prevents hosts in the 10/8 network from ever
knowing about 192.168/16?

I'm assuming that buzz and woody would apply the same type of sorting
(sortlist) technique to make sure they reply with the 10/8 IPs to clients.

>     No, I don't think so - but I didn't see how that would help, since I
> want zurg to alter the replies for just 2 hosts in the Zone.

I'm not convinced that zurg actually needs to alter the zone. Especially
if the zone already has the information that zurg needs and zurg just
needs to sort (sortlist above).

> Athough, zurg is BIND on SLES; buzz and woody are Winblows DNS.

I thought MS-DNS supported sorting replies.  I'm not sure.

>     OK - I have no idea how to do it, but if that would work....

See above.

>     Yes, that's what I was thinking of originally.

ACK

>     Well, I have no control over buzz and woody. I can only control
> zurg. I'm not sure if Winblows can do response sorting, or if zurg would
> be able to impose a sort on the data after he does a Zone transfer.

If you have no control (direct where you change or indirect where you
ask someone else to change) over buzz or woody, and you can't ensure
that it sorts properly, you will likely need apex overrides or RPZ.



--
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: [External] Re: Request assistance configuring RPZ

Bind-Users forum mailing list
In reply to this post by David Bank
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Tue, 2019-05-28 at 13:13 -0400, David Bank wrote:
> Perhaps I'm missing something, but I don't see how to make zurg reply
> with 192.168/16 IPs for andy and sid, but correctly resolve the rest
> of *.internal.local

On zurg, add a new dns zone rpz.ncdot.gov

============
$TTL 3600
rpz.ncdot.gov.     IN  SOA localhost. root.localhost.  (
                   2019052800  ; serial
                   3H  ; refresh
                   1H  ; retry
                   1W  ; expiry
                   1H) ; minimum
        IN  NS  localhost.


andy.internal.local  IN  A 192.168.10.10
sid.internal.local   IN  A 192.168.20.20
===========

Then in named.conf on zurg, add:

===========
   response-policy { zone "rpz.ncdot.gov";}
        qname-wait-recurse no;
===========


On zurg, all other names in internal.local will get the normal
processing, with answers via buzz. But when someone uses zurg to lookup
andy.internal.local, it will reply with 192.168.10.10 without even
asking buzz.

An alternative rpz mechanism it to allow zurg to query buzz, and then
have rpz rewrite the 10/8 address into 192.168/16. But if you have
multiple names that map to the same 10/8 address, and you only want some
of those names to resolve to 192.168/16, you will need to use the above
mechanism, which I think is simpler anyway.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlzt+e4ACgkQL6j7milTFsGjuQCbBsxNHh26aEGfhXzh4muEFcyN
a/UAn1w2mEs6WrUVjZ2oMMHA4MmDw+Fi
=D5Yv
-----END PGP SIGNATURE-----


_______________________________________________
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: [External] Re: Request assistance configuring RPZ

David Bank
On Tue, 28 May 2019, Carl Byington via bind-users wrote:

    Hi, Carl - thanks for replying.

> On zurg, add a new dns zone rpz.ncdot.gov

     Your suggestion didn't work for me.

     To test your suggestion, I had to add a "forwarders" statement to get
zurg to query buzz/woody; prior to testing, zurg had a zone file for
internal.local that told him he was the Master of the Zone, and the only
entries in it were for andy and sid. I commented that out for testing your
suggestion.

     When I implemented your suggestion, queries to zurg for andy and sid
were resolved to their 10/8 addresses (meaning zurg forwarded the request
to buzz/woody and returned an answer without alteration). zurg seemed to
ignore the RPZ config.

     Re-reading the ARM, it seemed to me that I needed to add a

  zone "rpz.internal.local" { file "rpz.internal.local"; };

     statement as well. When I did that, zurg still gave the 10/8 replies.

> On zurg, all other names in internal.local will get the normal
> processing, with answers via buzz. But when someone uses zurg to lookup
> andy.internal.local, it will reply with 192.168.10.10 without even
> asking buzz.

    That IS what I'm trying to do. Unfortunately, the config you suggested
didn't get me there.
_______________________________________________
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: [External] Re: Request assistance configuring RPZ

Bind-Users forum mailing list
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, 2019-05-29 at 09:05 -0400, David Bank wrote:
> Re-reading the ARM, it seemed to me that I needed to add a

After adding the zone and the response-policy statement to named.conf, I
presume you did:

    rndc reconfig

To test that you can:

    dig rpz.internal.local axfr @zurg

That should dump the rpz zone, and verify that zurg is serving it. The
response-policy should be in the global options.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlzuk4QACgkQL6j7milTFsEtgQCaA2gk7mvDO9jWYlAGTm+soYty
aEcAn1L7goSEfLdCIBIChF8wklA4MRFA
=q+pb
-----END PGP SIGNATURE-----



_______________________________________________
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: [External] Re: Request assistance configuring RPZ

xmatt
Hi Grant,

I don't usually wade in on these but I also believe RPZ would be the simplest way to achieve this.

You're close I think. Using Carl's information and what you've done there, add the following.

In order to keep the same zone working with 10. Addressing for all other (not in bubble) clients, create CNAME records in your master internal.local zone for these two records you want to have a 192. Address for.  On the same master, create a new zone where you will have the A record your CNAME will resolve to, a 10. Address.  This will take care of all clients not in the bubble.

On zurg, with your RPZ, have that configured for the same domain as the new domain you've created on the master.

This should mean that, all queries are forwarded to your other boxes, except anything for that domain in the RPZ. The initial query for Andy or sid will be forwarded to the forwarding servers but will return a CNAME for the zurg recursor. Zurg should then go to resolve the cname but check its RPZ first, responding with the 192.x addressing you've got in the RPZ for each of the two hosts.

It's not tidy, I'll give you that but, this is an interesting scenario for more than just this DNS, you're bridging 2 networks with multiple multi-homed machines. This is not recommended from a security perspective and should use a gateway/FW to perform this work, routing between the networks.

All the best.
Jon


On Thu, 30 May 2019, 02:14 Carl Byington via bind-users, <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, 2019-05-29 at 09:05 -0400, David Bank wrote:
> Re-reading the ARM, it seemed to me that I needed to add a

After adding the zone and the response-policy statement to named.conf, I
presume you did:

    rndc reconfig

To test that you can:

    dig rpz.internal.local axfr @zurg

That should dump the rpz zone, and verify that zurg is serving it. The
response-policy should be in the global options.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlzuk4QACgkQL6j7milTFsEtgQCaA2gk7mvDO9jWYlAGTm+soYty
aEcAn1L7goSEfLdCIBIChF8wklA4MRFA
=q+pb
-----END PGP SIGNATURE-----



_______________________________________________
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: [External] Re: Request assistance configuring RPZ

Bind-Users forum mailing list
On 5/29/19 3:15 PM, Jon wrote:
> Hi Grant,

Hi,

> I don't usually wade in on these but I also believe RPZ would be the
> simplest way to achieve this.

I tend to agree.

DNSSEC can complicate this a bit (requiring additional settings).

> In order to keep the same zone working with 10. Addressing for all other
> (not in bubble) clients, create CNAME records in your master
> internal.local zone for these two records you want to have a 192.
> Address for.  On the same master, create a new zone where you will have
> the A record your CNAME will resolve to, a 10. Address.  This will take
> care of all clients not in the bubble.

I don't think that David has any influence on the "internal.local" zone
on buzz and woody.  As such, CNAMEing to alternate zones is not likely
to happen.

> On zurg, with your RPZ, have that configured for the same domain as the
> new domain you've created on the master.

Why use CNAMEs to a separate zone on woody & buzz but not use the same
separate zones on zurg?

I'd think that you'd use separate zones everywhere (woody, buzz, and
zurg) or nowhere.

Yes, RPZ can make it trivial to override the names in the bubble.

> This should mean that, all queries are forwarded to your other boxes,
> except anything for that domain in the RPZ. The initial query for Andy
> or sid will be forwarded to the forwarding servers but will return a
> CNAME for the zurg recursor. Zurg should then go to resolve the cname
> but check its RPZ first, responding with the 192.x addressing you've got
> in the RPZ for each of the two hosts.

I'm not tracking what you're saying.  (If we want to delve further into
this, seeing as how David can't change the zone on woody or buzz.)
Please outline what zones you would have on what server as well as where
the CNAMEs would be and what they would refer to.

> It's not tidy, I'll give you that but, this is an interesting scenario
> for more than just this DNS, you're bridging 2 networks with multiple
> multi-homed machines. This is not recommended from a security
> perspective and should use a gateway/FW to perform this work, routing
> between the networks.

I largely agree.  However there is no reason that there can't also be
DNS separation in addition to routing / firewall.  Thus this scenario
can exist even with routing and firewalls.



--
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
|

[SOLUTION] Re: Request assistance configuring RPZ

David Bank
In reply to this post by Bind-Users forum mailing list
    About a week-and-a-half ago, I wrote into the list, looking for some
help configuring RPZ. I wanted to have a name server (zurg) in a special
network that, when queried for two specific hosts (andy and sid) in a
zone, would give replies from its own information, while forwarding on all
other requests to the "real" DNS servers (buzz, woody) for the zone and
returning whatever they said.

    Thanks to Carl Byington for replying.

    The solution came from Grant Taylor, after some off-list dicussion, but
the idea was one he mentioned on-list - instead of using RPZ, configure
the special name server with "Apex" zones for the two host names I needed
to handle differently.

    So zurg regards himself as master of zones "andy.internal.local" and
"sid.internal.local", and has a Zone file that returns specific 192.168/16
addresses for them.

    For all other requests, zurg forwards to buzz and woody (which will
return 10/8 addresses for everything).

    On zurg, the relevant parts of /etc/named.conf look like:

  # (buzz) (woody)
  forwarders { 10.1.2.10; 10.1.2.20; };
  allow-recursion { any; };

  zone "andy.internal.local" in {
  type master;
  file "andy.internal.local.zone";
  };

  zone "sid.internal.local" in {
  type master;
  file "sid.internal.local.zone";
  };

    Also, the Zone files look like:

  $TTL 1D

  $ORIGIN sid.internal.ebsad.local.
  @ IN SOA  @   ns (
  201906030 ; Serial #
  2H ; refresh
  4M ; retry
  1M ; expiry
  1H ) ; minimum

  ; Apex record for the Zone
  @ IN A 192.168.1.11
  ; Name server info for zone
  @ IN NS ns
  ns IN A       192.168.1.10

    That does exactly what I was looking for, so thank you Grant.
_______________________________________________
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: [SOLUTION] Re: Request assistance configuring RPZ

Bind-Users forum mailing list
Hi David,

On 6/11/19 2:05 PM, David Bank wrote:
> About a week-and-a-half ago, I wrote into the list, looking for some
> help configuring RPZ.

Thank you for the follow up with details on how someone else could
reproduce this for themselves if they find themselves with a similar
need / desire.

> That does exactly what I was looking for, so thank you Grant.

You're welcome.  I'm glad that you got things working the way that you
wanted.  :-)



--
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