Request assistance configuring RPZ

Grant Taylor gtaylor at tnetconsulting.net
Tue May 28 16:41:57 UTC 2019


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190528/01a00617/attachment.bin>


More information about the bind-users mailing list